diff --git a/docs/TRANSLATIONS.md b/docs/TRANSLATIONS.md new file mode 100644 index 00000000000..33aee7d2dd6 --- /dev/null +++ b/docs/TRANSLATIONS.md @@ -0,0 +1,90 @@ +# Translated documentation + +The docs site is multilingual. English is the source of truth; every other +language is a translation of an English page and is regenerated from it. + +## How translations are stored + +Translations live **beside** their English page using Hugo's filename-suffix +layout: + +``` +content/get_started/about/about_defectdojo.md <- English (source) +content/get_started/about/about_defectdojo.de.md <- German +``` + +We deliberately do not use a per-language `contentDir`, because that would +require moving all 466 English pages into `content/en/` and would break +existing tooling and any open docs PR. + +A translated page keeps the English page's `slug`, `weight`, `aliases`, and +`audience` values, so URLs, ordering, and the Open Source / Pro version +toggle behave identically in every language. Only `title`, `description`, +`summary`, and the body text are translated. + +## What is translated + +The core guides: `get_started`, `import_data`, `triage_findings`, +`asset_modelling`, `metrics_reports`, `issue_tracking`, `admin`, `automation`, +`help`, `navigation`, and the site home page. 160 pages, about 102,000 words. + +Deliberately **not** translated: + +- `releases/` changelogs - they change with every release, and stale + translations of a changelog are worse than an English one. +- `supported_tools/` parser reference - 219 pages that are mostly tables, + scanner names, and CWE/CVE identifiers, which are the same in any language. +- `archived_docs/`. + +Navigation entries for untranslated sections point at the English URL, so +nothing in the nav 404s in a translated language. + +## Site chrome + +UI text that lives in templates rather than content (navigation labels, +homepage cards, footer, screen-reader labels) is looked up with Hugo's +`i18n` function and translated in `i18n/.toml`. English values are in +`i18n/en.toml`; adding a key there without adding it to every language is +safe (missing keys fall back to English). + +Terminology comes from the product UI catalogs (`dojo/locale//`), so a +severity or status word reads the same in the docs as it does in DefectDojo. + +## Adding a language + +Languages are added to `config/_default/languages.toml` **only once their +translated content exists** - the switcher must never offer a language with +nothing behind it. Per language you need: + +1. `content/**/..md` for the translated pages. +2. `i18n/.toml` for the chrome strings. +3. `config/_default/menus/menus..toml` - translated labels, same URLs, + prefixed with `/` for sections that exist in that language. +4. The `[]` block in `languages.toml`, plus + `languageDirection = "rtl"` for Arabic, Hebrew, Persian, and Urdu. + +The pipeline that produces 1-3 is the `i18n-translate` skill: it exports +pages to JSON, fans translation out to per-language agents, and applies the +results only after checking that code fences, shortcodes, link URLs, heading +structure, and protected frontmatter survived unchanged. + +## Keeping translations current + +**Refresh quarterly.** English pages change constantly; a translation that +silently rots tells non-English readers we do not care about them. The +refresh is incremental - export only the pages whose English source changed +since the last run: + +```bash +export_docs.py --content content --work --langs de \ + --changed-since +``` + +Everything downstream is unchanged, because pages are addressed by path. + +## Provenance + +These translations are machine-generated and integrity-checked (structure, +tokens, and terminology are verified automatically), but they have **not** +been reviewed by native speakers. Treat a native-speaker pass as the next +step for any language you intend to promote heavily. diff --git a/docs/config/_default/hugo.toml b/docs/config/_default/hugo.toml index a9115bdd396..3ea9ace1b8e 100644 --- a/docs/config/_default/hugo.toml +++ b/docs/config/_default/hugo.toml @@ -13,7 +13,7 @@ summarylength = 20 # 70 (default) # Multilingual defaultContentLanguage = "en" -disableLanguages = ["de", "nl"] +disableLanguages = [] defaultContentLanguageInSubdir = false copyRight = "Copyright (c) 2020-2025 DefectDojo, Inc." diff --git a/docs/config/_default/languages.toml b/docs/config/_default/languages.toml index 3866f834b04..30e7deb5396 100644 --- a/docs/config/_default/languages.toml +++ b/docs/config/_default/languages.toml @@ -1,7 +1,43 @@ +# Languages are added here only once their translated content exists, so the +# switcher never offers a language with nothing behind it. Translations live +# beside the English page as ..md (Hugo filename-suffix layout); +# per-language contentDir would require moving all English content into +# content/en and would break existing tooling and open PRs. +# +# Right-to-left languages (ar, he, fa, ur) need languageDirection = "rtl"; +# layouts/baseof.html emits from it. + [en] languageName = "English" - contentDir = "content/en" weight = 10 [en.params] languageISO = "EN" - languageTag = "en-US" \ No newline at end of file + languageTag = "en-US" + +[de] + languageName = "Deutsch" + weight = 20 + [de.params] + languageISO = "DE" + languageTag = "de" + +[es] + languageName = "Español" + weight = 30 + [es.params] + languageISO = "ES" + languageTag = "es" + +[fr] + languageName = "Français" + weight = 40 + [fr.params] + languageISO = "FR" + languageTag = "fr" + +[ja] + languageName = "日本語" + weight = 50 + [ja.params] + languageISO = "JA" + languageTag = "ja" diff --git a/docs/config/_default/menus/menus.de.toml b/docs/config/_default/menus/menus.de.toml new file mode 100644 index 00000000000..ee1c5ecb4b5 --- /dev/null +++ b/docs/config/_default/menus/menus.de.toml @@ -0,0 +1,131 @@ +# Generated: labels translated; URLs point at the translated page when +# that section exists in this language, and fall back to the English +# URL when it does not (e.g. supported_tools), so no nav item 404s. +# Social entries are copied verbatim so the icons survive. +# Keep the entry set in step with menus.en.toml: Hugo does not merge menus +# across languages, so a tab missing here is a tab missing in German, and a +# URL that only existed in an older English menu is a 404 the link checker +# will catch. +[[main]] + name = "Erste Schritte" + url = "/de/get_started/about/about_defectdojo" + weight = 10 + +[[main]] + name = "Daten importieren" + url = "/de/import_data/import_intro/comparison/" + weight = 12 + +[[main]] + name = "Befunde triagieren" + url = "/de/triage_findings/findings_workflows/intro_to_findings/" + weight = 12 + +[[main]] + name = "Assets modellieren" + url = "/de/asset_modelling/engagements_tests/os__assets/" + weight = 13 + +[[main]] + name = "Connectors" + url = "/de/connectors/about/" + weight = 13 + +[[main]] + name = "Metriken & Berichte" + url = "/de/metrics_reports/dashboards/introduction_dashboard/" + weight = 14 + +[[main]] + name = "Sensei" + # Sensei is Pro-only. Default to the Open Source "Pro feature" page; custom.js + # swaps this tab to the full guide (/sensei/about_sensei/) when Pro is selected. + url = "/de/sensei/os__sensei/" + weight = 14 + +[[main]] + name = "Administration" + url = "/de/admin/admin_intro/intro/" + weight = 16 + +[[main]] + name = "Automatisierung" + url = "/de/automation/api/api-v2-docs/" + weight = 15 + +[[main]] + name = "Unterstützte Tools" + url = "/supported_tools/" + weight = 16 + +# Left-hand section sidebar for the Sensei chapter. pageRef resolves per +# language, so these point at the German pages automatically. +[[sidebar_sensei]] + name = "Sensei" + pageRef = "/sensei/OS__sensei" + weight = 0 + +[[sidebar_sensei]] + name = "Über Sensei" + pageRef = "/sensei/about_sensei" + weight = 1 + +[[sidebar_sensei]] + name = "Sensei einrichten" + pageRef = "/sensei/setup_sensei" + weight = 2 + +[[sidebar_sensei]] + name = "Befunde mit Sensei beheben" + pageRef = "/sensei/fixing_findings" + weight = 3 + +[[sidebar_sensei]] + name = "Sensei-Referenz" + pageRef = "/sensei/sensei_reference" + weight = 4 + +[[social]] + name = "YouTube" + pre = '' + url = "https://www.youtube.com/@defectdojo" + weight = 9 + +[[social]] + name = "X" + pre = '' + url = "https://x.com/defectdojo" + weight = 10 + +[[social]] + name = 'Linkedin' + pre = '' + url = "https://www.linkedin.com/company/defectdojo/" + weight = 10 + +[[social]] + name = "GitHub" + pre = '' + url = "https://github.com/DefectDojo/django-DefectDojo" + post = "v0.1.0" + weight = 30 + +[[footer]] + name = "DefectDojo.com" + url = "https://defectdojo.com" + weight = 10 + +[[footer]] + name = "GitHub" + url = "https://github.com/DefectDojo/django-DefectDojo" + weight = 20 + +[[footer]] + name = "Community" + url = "https://defectdojo.com/open-source" + weight = 30 + +[[footer]] + name = "Support" + url = "mailto:support@defectdojo.com" + weight = 40 diff --git a/docs/config/_default/menus/menus.es.toml b/docs/config/_default/menus/menus.es.toml new file mode 100644 index 00000000000..dcbc777a572 --- /dev/null +++ b/docs/config/_default/menus/menus.es.toml @@ -0,0 +1,125 @@ +# Generated from menus.en.toml by regen_menus.py - do not hand-edit. +# Labels are translated; a URL is language-prefixed when that page exists +# in this language and left as the English URL when it does not, so no nav +# entry 404s. Hugo does not merge menus across languages, so this file must +# carry every entry menus.en.toml has. + +[[main]] + name = "Comenzar" + url = "/es/get_started/about/about_defectdojo" + weight = 10 + +[[main]] + name = "Importar datos" + url = "/es/import_data/import_intro/comparison/" + weight = 12 + +[[main]] + name = "Clasificar hallazgos" + url = "/es/triage_findings/findings_workflows/intro_to_findings/" + weight = 12 + +[[main]] + name = "Modelar sus activos" + url = "/es/asset_modelling/engagements_tests/os__assets/" + weight = 13 + +[[main]] + name = "Conectores" + url = "/es/connectors/about/" + weight = 13 + +[[main]] + name = "Métricas e informes" + url = "/es/metrics_reports/dashboards/introduction_dashboard/" + weight = 14 + +[[main]] + name = "Sensei" + url = "/es/sensei/os__sensei/" + weight = 14 + +[[main]] + name = "Administración" + url = "/es/admin/admin_intro/intro/" + weight = 16 + +[[main]] + name = "Automatización" + url = "/es/automation/api/api-v2-docs/" + weight = 15 + +[[main]] + name = "Herramientas compatibles" + url = "/supported_tools/" + weight = 16 + +[[sidebar_sensei]] + name = "Sensei" + pageRef = "/sensei/OS__sensei" + weight = 0 + +[[sidebar_sensei]] + name = "Acerca de Sensei" + pageRef = "/sensei/about_sensei" + weight = 1 + +[[sidebar_sensei]] + name = "Configurar Sensei" + pageRef = "/sensei/setup_sensei" + weight = 2 + +[[sidebar_sensei]] + name = "Corrección de hallazgos con Sensei" + pageRef = "/sensei/fixing_findings" + weight = 3 + +[[sidebar_sensei]] + name = "Referencia de Sensei" + pageRef = "/sensei/sensei_reference" + weight = 4 + +[[social]] + name = "YouTube" + pre = '' + url = "https://www.youtube.com/@defectdojo" + weight = 9 + +[[social]] + name = "X" + pre = '' + url = "https://x.com/defectdojo" + weight = 10 + +[[social]] + name = 'Linkedin' + pre = '' + url = "https://www.linkedin.com/company/defectdojo/" + weight = 10 + +[[social]] + name = "GitHub" + pre = '' + url = "https://github.com/DefectDojo/django-DefectDojo" + post = "v0.1.0" + weight = 30 + +[[footer]] + name = "DefectDojo.com" + url = "https://defectdojo.com" + weight = 10 + +[[footer]] + name = "GitHub" + url = "https://github.com/DefectDojo/django-DefectDojo" + weight = 20 + +[[footer]] + name = "Community" + url = "https://defectdojo.com/open-source" + weight = 30 + +[[footer]] + name = "Support" + url = "mailto:support@defectdojo.com" + weight = 40 diff --git a/docs/config/_default/menus/menus.fr.toml b/docs/config/_default/menus/menus.fr.toml new file mode 100644 index 00000000000..bdf3ae97dfb --- /dev/null +++ b/docs/config/_default/menus/menus.fr.toml @@ -0,0 +1,125 @@ +# Generated from menus.en.toml by regen_menus.py - do not hand-edit. +# Labels are translated; a URL is language-prefixed when that page exists +# in this language and left as the English URL when it does not, so no nav +# entry 404s. Hugo does not merge menus across languages, so this file must +# carry every entry menus.en.toml has. + +[[main]] + name = "Démarrer" + url = "/fr/get_started/about/about_defectdojo" + weight = 10 + +[[main]] + name = "Importer des données" + url = "/fr/import_data/import_intro/comparison/" + weight = 12 + +[[main]] + name = "Trier les constatations" + url = "/fr/triage_findings/findings_workflows/intro_to_findings/" + weight = 12 + +[[main]] + name = "Modéliser vos actifs" + url = "/fr/asset_modelling/engagements_tests/os__assets/" + weight = 13 + +[[main]] + name = "Connecteurs" + url = "/fr/connectors/about/" + weight = 13 + +[[main]] + name = "Métriques et rapports" + url = "/fr/metrics_reports/dashboards/introduction_dashboard/" + weight = 14 + +[[main]] + name = "Sensei" + url = "/fr/sensei/os__sensei/" + weight = 14 + +[[main]] + name = "Administration" + url = "/fr/admin/admin_intro/intro/" + weight = 16 + +[[main]] + name = "Automatisation" + url = "/fr/automation/api/api-v2-docs/" + weight = 15 + +[[main]] + name = "Outils pris en charge" + url = "/supported_tools/" + weight = 16 + +[[sidebar_sensei]] + name = "Sensei" + pageRef = "/sensei/OS__sensei" + weight = 0 + +[[sidebar_sensei]] + name = "À propos de Sensei" + pageRef = "/sensei/about_sensei" + weight = 1 + +[[sidebar_sensei]] + name = "Configurer Sensei" + pageRef = "/sensei/setup_sensei" + weight = 2 + +[[sidebar_sensei]] + name = "Corriger les constatations avec Sensei" + pageRef = "/sensei/fixing_findings" + weight = 3 + +[[sidebar_sensei]] + name = "Référence Sensei" + pageRef = "/sensei/sensei_reference" + weight = 4 + +[[social]] + name = "YouTube" + pre = '' + url = "https://www.youtube.com/@defectdojo" + weight = 9 + +[[social]] + name = "X" + pre = '' + url = "https://x.com/defectdojo" + weight = 10 + +[[social]] + name = 'Linkedin' + pre = '' + url = "https://www.linkedin.com/company/defectdojo/" + weight = 10 + +[[social]] + name = "GitHub" + pre = '' + url = "https://github.com/DefectDojo/django-DefectDojo" + post = "v0.1.0" + weight = 30 + +[[footer]] + name = "DefectDojo.com" + url = "https://defectdojo.com" + weight = 10 + +[[footer]] + name = "GitHub" + url = "https://github.com/DefectDojo/django-DefectDojo" + weight = 20 + +[[footer]] + name = "Community" + url = "https://defectdojo.com/open-source" + weight = 30 + +[[footer]] + name = "Support" + url = "mailto:support@defectdojo.com" + weight = 40 diff --git a/docs/config/_default/menus/menus.ja.toml b/docs/config/_default/menus/menus.ja.toml new file mode 100644 index 00000000000..a1f7a898c18 --- /dev/null +++ b/docs/config/_default/menus/menus.ja.toml @@ -0,0 +1,125 @@ +# Generated from menus.en.toml by regen_menus.py - do not hand-edit. +# Labels are translated; a URL is language-prefixed when that page exists +# in this language and left as the English URL when it does not, so no nav +# entry 404s. Hugo does not merge menus across languages, so this file must +# carry every entry menus.en.toml has. + +[[main]] + name = "はじめに" + url = "/ja/get_started/about/about_defectdojo" + weight = 10 + +[[main]] + name = "データのインポート" + url = "/ja/import_data/import_intro/comparison/" + weight = 12 + +[[main]] + name = "検出事項のトリアージ" + url = "/ja/triage_findings/findings_workflows/intro_to_findings/" + weight = 12 + +[[main]] + name = "資産のモデル化" + url = "/ja/asset_modelling/engagements_tests/os__assets/" + weight = 13 + +[[main]] + name = "コネクタ" + url = "/ja/connectors/about/" + weight = 13 + +[[main]] + name = "メトリクスとレポート" + url = "/ja/metrics_reports/dashboards/introduction_dashboard/" + weight = 14 + +[[main]] + name = "Sensei" + url = "/ja/sensei/os__sensei/" + weight = 14 + +[[main]] + name = "管理" + url = "/ja/admin/admin_intro/intro/" + weight = 16 + +[[main]] + name = "自動化" + url = "/ja/automation/api/api-v2-docs/" + weight = 15 + +[[main]] + name = "対応ツール" + url = "/supported_tools/" + weight = 16 + +[[sidebar_sensei]] + name = "Sensei" + pageRef = "/sensei/OS__sensei" + weight = 0 + +[[sidebar_sensei]] + name = "Senseiについて" + pageRef = "/sensei/about_sensei" + weight = 1 + +[[sidebar_sensei]] + name = "Senseiのセットアップ" + pageRef = "/sensei/setup_sensei" + weight = 2 + +[[sidebar_sensei]] + name = "Senseiによる検出事項の修正" + pageRef = "/sensei/fixing_findings" + weight = 3 + +[[sidebar_sensei]] + name = "Senseiリファレンス" + pageRef = "/sensei/sensei_reference" + weight = 4 + +[[social]] + name = "YouTube" + pre = '' + url = "https://www.youtube.com/@defectdojo" + weight = 9 + +[[social]] + name = "X" + pre = '' + url = "https://x.com/defectdojo" + weight = 10 + +[[social]] + name = 'Linkedin' + pre = '' + url = "https://www.linkedin.com/company/defectdojo/" + weight = 10 + +[[social]] + name = "GitHub" + pre = '' + url = "https://github.com/DefectDojo/django-DefectDojo" + post = "v0.1.0" + weight = 30 + +[[footer]] + name = "DefectDojo.com" + url = "https://defectdojo.com" + weight = 10 + +[[footer]] + name = "GitHub" + url = "https://github.com/DefectDojo/django-DefectDojo" + weight = 20 + +[[footer]] + name = "Community" + url = "https://defectdojo.com/open-source" + weight = 30 + +[[footer]] + name = "Support" + url = "mailto:support@defectdojo.com" + weight = 40 diff --git a/docs/config/_default/params.toml b/docs/config/_default/params.toml index d1a9ca9c5ed..7105cde5fdc 100644 --- a/docs/config/_default/params.toml +++ b/docs/config/_default/params.toml @@ -65,7 +65,7 @@ mainSections = ["docs"] scrollSpy = true # true (default) or false # Multilingual - multilingualMode = false # false (default) or true + multilingualMode = true # language switcher in the header showMissingLanguages = true # whether or not to show untranslated languages in the language menu; true (default) or false # Versioning diff --git a/docs/content/_index.de.md b/docs/content/_index.de.md new file mode 100644 index 00000000000..d265988a779 --- /dev/null +++ b/docs/content/_index.de.md @@ -0,0 +1,5 @@ +--- +title: DefectDojo-Dokumentation +date: 2021-02-02 20:46:29+01:00 +draft: false +--- diff --git a/docs/content/_index.es.md b/docs/content/_index.es.md new file mode 100644 index 00000000000..147a8d23404 --- /dev/null +++ b/docs/content/_index.es.md @@ -0,0 +1,5 @@ +--- +title: Documentación de DefectDojo +date: 2021-02-02 20:46:29+01:00 +draft: false +--- diff --git a/docs/content/_index.fr.md b/docs/content/_index.fr.md new file mode 100644 index 00000000000..b1443890502 --- /dev/null +++ b/docs/content/_index.fr.md @@ -0,0 +1,5 @@ +--- +title: Documentation DefectDojo +date: 2021-02-02 20:46:29+01:00 +draft: false +--- diff --git a/docs/content/_index.ja.md b/docs/content/_index.ja.md new file mode 100644 index 00000000000..eaf55ae51b0 --- /dev/null +++ b/docs/content/_index.ja.md @@ -0,0 +1,5 @@ +--- +title: DefectDojo ドキュメント +date: 2021-02-02 20:46:29+01:00 +draft: false +--- diff --git a/docs/content/admin/admin_intro/_index.de.md b/docs/content/admin/admin_intro/_index.de.md new file mode 100644 index 00000000000..80760758c85 --- /dev/null +++ b/docs/content/admin/admin_intro/_index.de.md @@ -0,0 +1,16 @@ +--- +title: Einführung +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- diff --git a/docs/content/admin/admin_intro/_index.es.md b/docs/content/admin/admin_intro/_index.es.md new file mode 100644 index 00000000000..996a0b5a840 --- /dev/null +++ b/docs/content/admin/admin_intro/_index.es.md @@ -0,0 +1,16 @@ +--- +title: Introducción +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- diff --git a/docs/content/admin/admin_intro/_index.fr.md b/docs/content/admin/admin_intro/_index.fr.md new file mode 100644 index 00000000000..6199fda95a2 --- /dev/null +++ b/docs/content/admin/admin_intro/_index.fr.md @@ -0,0 +1,16 @@ +--- +title: Introduction +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- diff --git a/docs/content/admin/admin_intro/_index.ja.md b/docs/content/admin/admin_intro/_index.ja.md new file mode 100644 index 00000000000..20cbf0ebd07 --- /dev/null +++ b/docs/content/admin/admin_intro/_index.ja.md @@ -0,0 +1,16 @@ +--- +title: はじめに +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- diff --git a/docs/content/admin/admin_intro/intro.de.md b/docs/content/admin/admin_intro/intro.de.md new file mode 100644 index 00000000000..505c6fe52c0 --- /dev/null +++ b/docs/content/admin/admin_intro/intro.de.md @@ -0,0 +1,10 @@ +--- +title: DefectDojo-Administrationsfunktionen +description: Administrative Steuerungsmöglichkeiten zum Konfigurieren, Absichern und + Warten Ihrer DefectDojo-Instanz. +weight: 0 +--- + +Administrative Aktionen in DefectDojo bieten die Steuerungsmöglichkeiten, die zum Konfigurieren und Warten der Plattform in Ihrer gesamten Organisation erforderlich sind. Diese Aktionen richten sich an Administratoren, die für Benutzerverwaltung und Systemkonfiguration verantwortlich sind und dafür sorgen, dass DefectDojo auch im großen Maßstab sicher und zuverlässig läuft. + +Mit administrativen Aktionen verwalten Sie zentrale Aspekte von DefectDojo, darunter Authentifizierungsmethoden, Benutzerzugriff, globale Einstellungen und Integrationen. Von der Ersteinrichtung bis zur laufenden Wartung legen diese Steuerungsmöglichkeiten fest, wie DefectDojo sich verhält und wie Benutzer damit arbeiten. diff --git a/docs/content/admin/admin_intro/intro.es.md b/docs/content/admin/admin_intro/intro.es.md new file mode 100644 index 00000000000..0a90f4e5fbc --- /dev/null +++ b/docs/content/admin/admin_intro/intro.es.md @@ -0,0 +1,10 @@ +--- +title: Controles de administración de DefectDojo +description: Controles administrativos para configurar, proteger y mantener su instancia + de DefectDojo. +weight: 0 +--- + +Las acciones de administración en DefectDojo proporcionan los controles necesarios para configurar y mantener la plataforma en toda su organización. Estas acciones están pensadas para los administradores responsables de la gestión de usuarios, la configuración del sistema y garantizar que DefectDojo funcione de forma segura y fiable a gran escala. + +Las acciones administrativas le permiten gestionar aspectos centrales de DefectDojo, incluidos los métodos de autenticación, el acceso de usuarios, la configuración global y las integraciones. Desde la configuración inicial hasta el mantenimiento continuo, estos controles definen cómo se comporta DefectDojo y cómo interactúan los usuarios con él. diff --git a/docs/content/admin/admin_intro/intro.fr.md b/docs/content/admin/admin_intro/intro.fr.md new file mode 100644 index 00000000000..e426048cebb --- /dev/null +++ b/docs/content/admin/admin_intro/intro.fr.md @@ -0,0 +1,10 @@ +--- +title: Contrôles d'administration DefectDojo +description: Contrôles administratifs pour configurer, sécuriser et maintenir votre + instance DefectDojo. +weight: 0 +--- + +Les actions d'administration dans DefectDojo fournissent les contrôles nécessaires pour configurer et maintenir la plateforme à l'échelle de votre organisation. Ces actions sont conçues pour les administrateurs responsables de la gestion des utilisateurs, de la configuration du système, et de garantir que DefectDojo fonctionne de manière sécurisée et fiable à grande échelle. + +Les actions administratives vous permettent de gérer les aspects fondamentaux de DefectDojo, notamment les méthodes d'authentification, l'accès des utilisateurs, les paramètres globaux et les intégrations. De la configuration initiale à la maintenance continue, ces contrôles définissent le comportement de DefectDojo et la manière dont les utilisateurs interagissent avec lui. diff --git a/docs/content/admin/admin_intro/intro.ja.md b/docs/content/admin/admin_intro/intro.ja.md new file mode 100644 index 00000000000..bcfc92bf9bc --- /dev/null +++ b/docs/content/admin/admin_intro/intro.ja.md @@ -0,0 +1,9 @@ +--- +title: DefectDojo管理者コントロール +description: DefectDojoインスタンスの設定、保護、保守のための管理者コントロール。 +weight: 0 +--- + +DefectDojoの管理者アクションは、組織全体でプラットフォームを設定・保守するために必要なコントロールを提供します。これらのアクションは、ユーザー管理、システム設定、そしてDefectDojoが大規模環境でも安全かつ確実に動作することを担う管理者向けに設計されています。 + +管理者アクションを使うと、認証方式、ユーザーアクセス、グローバル設定、インテグレーションなど、DefectDojoの中核部分を管理できます。初期セットアップから日常の保守に至るまで、これらのコントロールがDefectDojoの動作とユーザーとの関わり方を規定します。 diff --git a/docs/content/admin/diagnostics/PRO__diagnostics.de.md b/docs/content/admin/diagnostics/PRO__diagnostics.de.md new file mode 100644 index 00000000000..ead0d4d7055 --- /dev/null +++ b/docs/content/admin/diagnostics/PRO__diagnostics.de.md @@ -0,0 +1,169 @@ +--- +title: Diagnostics +description: 'Lesen Sie das subsystemübergreifende Logbuch der Integrationsversuche: + was aufgezeichnet wird, wie Sie es filtern, wie Zugangsdaten ferngehalten werden + und wer die technischen Details sehen kann' +weight: 1 +audience: pro +--- + +Diagnostics ist ein einziges Logbuch für jeden Versuch, den DefectDojo unternimmt, um mit einem System außerhalb von sich selbst zu kommunizieren – und für die Versuche anderer Systeme, mit DefectDojo zu kommunizieren. Wenn ein Ticket nie erschienen ist, ein Scan nie importiert wurde oder sich ein Benutzer nicht anmelden konnte, ist dies die Seite, die zeigt, was passiert ist, wann es passiert ist, welche Konfiguration betroffen war und wer es ausgelöst hat. + +Diagnostics ist eine **DefectDojo Pro**-Funktion. Sie finden es unter **Connect > Diagnostics**. + +![Das Diagnostics-Logbuch, Ansicht „Fehler“](images/diagnostics_errors.png) + +## Was aufgezeichnet wird + +Pro Versuch wird eine Zeile geschrieben, aus jedem Subsystem, das über DefectDojo hinausreicht: + +| Quelle | Was Zeilen erzeugt | +| --- | --- | +| **Connector** | Discover- und Sync-Läufe von Upstream-Connectors | +| **Downstream-Integrator** | Pushes an Jira, GitHub, GitLab, ServiceNow und die anderen Downstream-Connectors | +| **Jira** | Die klassische Jira-Integration: Pushes, Kommentare und Vorschauen | +| **SSO (OIDC/OAuth2)** | Anmeldeversuche über einen OAuth-Provider | +| **SAML** | SAML-Assertions, einschließlich Signatur- und Attributfehlern | +| **LDAP** | LDAP-Binds und -Lookups | +| **Import / Reimport** | Scan-Uploads, ob über UI, API oder Zeitplan | +| **Regel-Engine** | Regelauswertungen und die dabei versuchten Aktionen | +| **Planung** | Geplante Läufe, einschließlich solcher, die nie gestartet sind | +| **Sensei** | Repository-Scans und Fix-Läufe | +| **Benachrichtigung** | Ausgehende Benachrichtigungszustellung | +| **System** | Instanzweite Aktivität, die zu keinem Produkt gehört | + +Zeilen werden *neben* dem Subsystem geschrieben, niemals an dessen Stelle. Jeder Adapter ist an den Ursprungsdatensatz angehängt und bewusst fail-safe: Wenn das Schreiben einer Diagnosezeile einen Fehler auslöst, wird dieser Fehler abgefangen und der ursprüngliche Vorgang läuft weiter. Diagnostics kann daher niemals der Grund dafür sein, dass ein Push, Import oder Login fehlschlägt. + +Da Zeilen anhand des Datensatzes indiziert werden, der sie erzeugt hat, aktualisiert ein erneutes Speichern eines Ursprungsdatensatzes die vorhandene Diagnosezeile, anstatt ein Duplikat hinzuzufügen. Ein Versuch ist während seines gesamten Lebenszyklus eine Zeile, von `Queued` über `Running` bis zu seinem Ergebnis. + +### Felder einer Zeile + +| Feld | Bedeutung | +| --- | --- | +| **Wann** | Wann die Zeile aufgezeichnet wurde; **Gestartet**, **Beendet** und **Dauer** beschreiben den Versuch selbst | +| **Quelle** | Das Subsystem, aus der obigen Tabelle | +| **Anbieter** | Das konkrete Tool oder der Provider innerhalb dieser Quelle (`jira`, `github`, `okta`, ein Scanner-Name) | +| **Vorgang** | Was versucht wurde (`push`, `sync`, `login`, `reimport`, `rule_run`) | +| **Status** | `Queued`, `Running`, `Success`, `Failed`, `Timed out`, `Skipped` oder `Dry run` | +| **Schweregrad** | `Info`, `Warning`, `Error` oder `Critical` | +| **Zusammenfassung** | Ein einzeiliges Ergebnis, das sich auf einen Blick erfassen lässt | +| **Auslöser** | Was den Versuch ausgelöst hat: `UI`, `API`, `Scheduled`, `Webhook`, `Automatic`, `Command line` oder `System` | +| **Ausgelöst von** | Der verantwortliche Benutzer, oder `System` bei unbeaufsichtigten Vorgängen | +| **Asset** | Das Produkt, zu dem der Versuch gehört; leer bedeutet instanzweit | +| **Zugehöriges Objekt** | Der Befund, das Engagement oder ein anderer Datensatz, um den es bei dem Versuch ging | +| **Konfiguration** | Welche Konfiguration verwendet wurde, anhand ihrer Bezeichnung | +| **Externe Referenz** | Die vom anderen System zurückgegebene Kennung, etwa der Schlüssel eines erstellten Issues | +| **Korrelations-ID** | Verknüpft Zeilen desselben logischen Vorgangs | +| **Gemeldete Details** und **Kontext** | Die vollständigen technischen Details (eingeschränkt, siehe [Wer sieht was](#who-sees-what)) | + +## Die vier Ansichten + +Die Tabs oberhalb der Tabelle sind gespeicherte Ausgangspunkte, keine Filter, die Sie jedes Mal neu aufbauen müssen: + +* **Fehler** – Fehlschläge und Zeitüberschreitungen. Diese Ansicht sollten Sie zuerst öffnen. +* **Erfolge** – der Nachweis, dass eine funktionierende Integration tatsächlich funktioniert; nützlich, wenn jemand meldet, dass „nichts synchronisiert wird“. +* **Nie abgeschlossen** – Versuche, die noch `Queued` oder `Running` sind, obwohl sie längst hätten fertig sein sollen. Das sind die stillen Fälle: Nichts ist fehlgeschlagen, also wurde auch nichts gemeldet – aber es ist auch nichts angekommen. +* **Alle Ereignisse** – alles, ungefiltert. + +![Alle Ereignisse, mit allen Quellen](images/diagnostics_all_events.png) + +Die aktive Ansicht ist Teil der Seiten-URL, sodass eine Ansicht verlinkbar ist und einen Refresh übersteht. + +## Die Liste eingrenzen + +* **Zeitraum** – 24 Stunden, 7 Tage, 30 Tage oder 90 Tage, über die Schaltflächen im Kopfbereich. +* **Quellenzähler** – die farbigen Zähler unter den Übersichtskarten sind ebenfalls Schnellfilter. Klicken Sie auf einen, um nur diese Quelle anzuzeigen; klicken Sie erneut darauf (oder auf **Quellfilter zurücksetzen**), um zurückzukehren. Es ist immer höchstens einer aktiv. +* **Filter und Sortierung pro Spalte** – jede Spalte lässt sich filtern und sortieren, einschließlich Schweregrad und Quelle. Schweregrad sortiert nach Schwere (`Critical` → `Info`) statt alphabetisch, und Quelle sortiert nach der angezeigten Bezeichnung statt nach dem intern gespeicherten Wert. +* **Stichwortsuche** – durchsucht alle Textfelder gleichzeitig. +* **Spalteneinstellungen** – die Spaltenauswahl und die gespeicherten Layouts verhalten sich wie bei jeder anderen Pro-Liste. + +![Ein Quellenzähler, der als Schnellfilter verwendet wird](images/diagnostics_chip_filter.png) + +Klicken Sie auf die Lupe am Anfang einer Zeile, um den gesamten Versuch zu öffnen: + +![Ein einzelnes Ereignis, einschließlich des Hinweises zur Schwärzung](images/diagnostics_detail.png) + +## Zugangsdaten werden entfernt, bevor die Zeile geschrieben wird + +Integrationsfehler zitieren die fehlgeschlagene Anfrage, und diese Zitate enthalten Geheimnisse: einen `Authorization`-Header, ein Token in einem Query-String, ein Passwort innerhalb einer Verbindungs-URL. Diagnostics entfernt diese **auf dem Weg hinein**, sodass der ursprüngliche Wert niemals in der Datenbank landet und auch kein späterer Sinneswandel ihn offenlegen kann. + +Zwei Dinge werden bereinigt: + +* **Werte unter Schlüsseln, die wie Zugangsdaten aussehen** – alles, dessen Schlüssel wie ein Geheimnis aussieht (`password`, `token`, `secret`, `api_key`, `authorization`, `private_key` und Ähnliches, unabhängig von Groß-/Kleinschreibung oder mit Bindestrichen oder Leerzeichen). Eine kleine Gruppe von Schlüsseln ist ausgenommen, weil nur ihr *Vorhandensein* zählt, niemals ihr Inhalt. +* **Werte, die überall dort wie Zugangsdaten aussehen, wo sie auftauchen** – Bearer- und Basic-Authorization-Header, JWTs, in URLs eingebettete Zugangsdaten (`https://user:pass@host`), erkennbare Anbieter-Token-Präfixe und PEM-Blöcke. + +Jeder Wert wird durch `[redacted]` ersetzt. Die umgebende Meldung bleibt erhalten, sodass der Fehler lesbar bleibt: + +```text +401 Unauthorized: Authorization: [redacted] +upload rejected: https://svc:[redacted]@sftp.example/out/… +``` + +Lange Werte werden gekürzt, und tief verschachtelter Kontext wird abgeflacht, damit eine einzelne riesige Payload die Tabelle nicht aufblähen kann. + +Wenn aus einer Zeile etwas entfernt wurde, wird dies in der Zeile vermerkt, anstatt Sie im Unklaren zu lassen, ob das Feld leer war oder geleert wurde. + +> **Die Schwärzung ist bewusst als Best-Effort-Mechanismus ausgelegt.** Die Bereinigung erkennt *Muster* von Zugangsdaten. Ein Geheimnis, das wie gewöhnlicher Fließtext aussieht, unter einem Schlüssel, der nicht sensibel wirkt, kann trotzdem aufgezeichnet werden. Behandeln Sie Diagnostics als Betriebsprotokoll, nicht als einen Ort, an dem garantiert keine Geheimnisse vorkommen – und beschränken Sie die technischen Details auf die Personen, die sie wirklich benötigen. + +## Wer sieht was + +Diagnostics ist gestaffelt, denn die Zusammenfassung eines Fehlschlags ist für einen Produktverantwortlichen nützlich, die rohe Anfrage dahinter dagegen nicht. + +| | Superuser | Alle anderen | +| --- | --- | --- | +| Zeilen für Produkte, für die sie autorisiert sind | Ja | Ja | +| Instanzweite Zeilen (kein Produkt) | Ja | Nein | +| Zusammenfassung, Quelle, Status, Schweregrad, Zeiten, Konfiguration | Ja | Ja | +| **Gemeldete Details**, **Kontext**, **Remote-IP** | Ja | Zurückgehalten, und als zurückgehalten gekennzeichnet | + +Ein Nicht-Superuser sieht, dass ein Detail existiert und zurückgehalten wird, statt eines leeren Felds, das wie fehlende Daten wirkt. Instanzweite Zeilen – SSO, SAML, LDAP und andere Aktivitäten, die zu keinem Produkt gehören – sind nur für Superuser sichtbar, da es keine Produktmitgliedschaft gibt, die Zugriff darauf gewähren könnte. + +## Wie lange Datensätze aufbewahrt werden + +Ein geplanter Task kürzt das Logbuch, damit es nicht unbegrenzt wächst: + +| Schweregrad | Aufbewahrungsdauer | +| --- | --- | +| `Info` | 30 Tage | +| `Warning`, `Error`, `Critical` | 180 Tage | + +Beide Zeiträume lassen sich über die Einstellungen `DIAGNOSTIC_EVENT_INFO_RETENTION_DAYS` und `DIAGNOSTIC_EVENT_RETENTION_DAYS` konfigurieren. Das Löschen erfolgt in Batches, sodass eine große Bereinigung keine lange Transaktion offen hält. + +## API + +Das Logbuch ist über die API unter `/api/v2/diagnostic_events/` nur lesbar: + +| Endpunkt | Rückgabe | +| --- | --- | +| `GET /api/v2/diagnostic_events/` | Die Liste, mit den unten aufgeführten Filtern | +| `GET /api/v2/diagnostic_events/{id}/` | Ein Ereignis | +| `GET /api/v2/diagnostic_events/summary/` | Die Zähler hinter den Übersichtskarten, einschließlich der Werte pro Quelle | +| `GET /api/v2/diagnostic_events/choices/` | Die gültigen Werte für `source`, `status`, `severity` und `trigger` | + +Nützliche Parameter: + +| Parameter | Wirkung | +| --- | --- | +| `source`, `status`, `severity`, `trigger` | Akzeptieren mehrere kommagetrennte Werte gleichzeitig | +| `failures_only=true` | Fehlschläge und Zeitüberschreitungen | +| `unresolved_only=true` | Versuche, die noch in der Warteschlange sind oder laufen | +| `product_name` | Filtert nach Produktname | +| `object_model` | Filtert nach der Art des Datensatzes, um den es bei dem Versuch ging | +| `o=` | Sortierung, mit vorangestelltem `-` zum Umkehren (`o=-created_at`) | + +Es gelten dieselben Zugriffsregeln: Ein Nicht-Superuser erhält produktbezogene Zeilen, bei denen die eingeschränkten Felder zurückgehalten werden. + +## Herausfinden, was schiefgelaufen ist + +* **Ein Ticket ist nie erschienen.** Filtern Sie Quelle nach dem Integrator (oder Jira) und prüfen Sie dann Status. `Failed` liefert Ihnen den Grund in Zusammenfassung; `Queued` lange nach dem erwarteten Zeitpunkt bedeutet, dass der Job nie gelaufen ist – das ist eher ein Worker- oder Planungsproblem als ein Problem mit den Zugangsdaten. +* **Ein Benutzer kann sich nicht anmelden.** Filtern Sie Quelle nach SSO, SAML oder LDAP und lesen Sie den Fehlschlag zu seinem Versuch – eine ungültige Assertion-Signatur, ein abgelehnter Bind, ein nicht übereinstimmendes Attribut. Diese Zeilen sind instanzweit und daher nur für Superuser sichtbar. +* **Ein Scan ist nicht aufgetaucht.** Filtern Sie Quelle nach Import / Reimport. Schauen Sie sich Auslöser an, um einen unbeaufsichtigten geplanten Upload von einem manuellen zu unterscheiden, und Ausgelöst von, um zu sehen, wen Sie fragen müssen. +* **Etwas versucht es endlos erneut.** Sortieren Sie nach Korrelations-ID oder filtern Sie danach, um alle Versuche desselben logischen Vorgangs gemeinsam zu sehen. +* **„Nichts funktioniert.“** Öffnen Sie zuerst Erfolge für denselben Zeitraum. Eine gesunde Liste dort macht aus einem vagen Ausfall einen konkreten. + +## Verwandte Themen + +* [Feature Flags](/admin/feature_flags/pro__feature_flags/) – optionale Pro-Funktionen ein- und ausschalten +* [Connectors](/connectors/upstream/about/) – Befunde einholen +* [Pro Integrations](/connectors/downstream/about/) – Befunde weitergeben +* [Single Sign-On](/admin/sso/) – die Identity-Provider, deren Anmeldeversuche hier erscheinen diff --git a/docs/content/admin/diagnostics/PRO__diagnostics.es.md b/docs/content/admin/diagnostics/PRO__diagnostics.es.md new file mode 100644 index 00000000000..3e9dfddd18f --- /dev/null +++ b/docs/content/admin/diagnostics/PRO__diagnostics.es.md @@ -0,0 +1,169 @@ +--- +title: Diagnósticos +description: 'Consulte el registro entre subsistemas de los intentos de integración: + qué se registra, cómo filtrarlo, cómo se excluyen las credenciales y quién puede + ver el detalle técnico' +weight: 1 +audience: pro +--- + +Diagnósticos es un único registro de todos los intentos que DefectDojo realiza para comunicarse con algo externo a sí mismo, y de los intentos que otros sistemas realizan para comunicarse con él. Cuando un ticket nunca aparece, un escaneo nunca se importa o un usuario no puede iniciar sesión, esta es la página que indica qué ocurrió, cuándo, en qué configuración y quién lo originó. + +Diagnósticos es una función de **DefectDojo Pro**. Se encuentra en **Conectar > Diagnósticos**. + +![El registro de Diagnósticos, vista de Errores](images/diagnostics_errors.png) + +## Qué se registra + +Se escribe una fila por cada intento, proveniente de cada subsistema que se comunica fuera de DefectDojo: + +| Origen | Qué genera las filas | +| --- | --- | +| **Conector** | Ejecuciones de descubrimiento y sincronización de conectores ascendentes | +| **Integrador descendente** | Envíos a Jira, GitHub, GitLab, ServiceNow y los demás conectores descendentes | +| **Jira** | La integración heredada de Jira: envíos, comentarios y vistas previas | +| **SSO (OIDC/OAuth2)** | Intentos de inicio de sesión a través de un proveedor OAuth | +| **SAML** | Aserciones SAML, incluidos los fallos de firma y de atributos | +| **LDAP** | Enlaces (binds) y búsquedas LDAP | +| **Importar / Reimportar** | Cargas de escaneos, ya sea por la interfaz, la API o programación | +| **Motor de reglas** | Evaluaciones de reglas y las acciones que intentan | +| **Programación** | Ejecuciones programadas, incluidas las que nunca comenzaron | +| **Sensei** | Escaneos de repositorios y ejecuciones de corrección | +| **Notificación** | Envío de notificaciones salientes | +| **Sistema** | Actividad a nivel de instancia que no pertenece a ningún producto | + +Las filas se escriben *junto al* subsistema, nunca en su lugar. Cada adaptador está vinculado al registro de origen y se diseñó deliberadamente para no generar fallos: si al escribir una fila de diagnóstico se produce un error, este se absorbe y la operación original continúa. Por lo tanto, Diagnósticos nunca puede ser la causa de que falle un envío, una importación o un inicio de sesión. + +Dado que las filas se indexan según el registro que las generó, volver a guardar un registro de origen actualiza su fila de diagnóstico existente en lugar de agregar un duplicado. Un intento es una fila durante toda su vida, desde `Queued`, pasando por `Running`, hasta su resultado. + +### Campos de una fila + +| Campo | Significado | +| --- | --- | +| **Cuándo** | Cuándo se registró la fila; **Iniciado**, **Finalizado** y **Duración** describen el intento en sí | +| **Origen** | El subsistema, según la tabla anterior | +| **Proveedor** | La herramienta o proveedor específico dentro de ese origen (`jira`, `github`, `okta`, el nombre de un scanner) | +| **Operación** | Qué se intentó (`push`, `sync`, `login`, `reimport`, `rule_run`) | +| **Estado** | `Queued`, `Running`, `Success`, `Failed`, `Timed out`, `Skipped` o `Dry run` | +| **Severidad** | `Info`, `Warning`, `Error` o `Critical` | +| **Resumen** | Un resultado de una línea, seguro de leer de un vistazo | +| **Activador** | Qué originó el intento: `UI`, `API`, `Scheduled`, `Webhook`, `Automatic`, `Command line` o `System` | +| **Activado por** | El usuario responsable, o `System` para trabajos no supervisados | +| **Activo** | El producto al que pertenece el intento; vacío significa a nivel de instancia | +| **Objeto relacionado** | El hallazgo, compromiso u otro registro con el que se relacionaba el intento | +| **Configuración** | Qué configuración se usó, por su etiqueta | +| **Referencia externa** | El identificador que devolvió el otro sistema, como una clave de incidencia creada | +| **ID de correlación** | Vincula las filas de una misma operación lógica | +| **Detalle notificado** y **Contexto** | El detalle técnico completo (restringido, ver [Quién ve qué](#who-sees-what)) | + +## Las cuatro vistas + +Las pestañas sobre la tabla son puntos de partida guardados, no filtros que deba reconstruir: + +* **Errores**: fallas y tiempos de espera agotados. La primera que conviene abrir. +* **Éxitos**: prueba de que una integración que funciona, efectivamente funciona; útil cuando alguien informa que "nada se está sincronizando". +* **Nunca completados**: intentos que siguen en `Queued` o `Running` mucho después de cuando deberían haber terminado. Son los silenciosos: nada falló, así que nada se informó, pero tampoco llegó nada. +* **Todos los eventos**: todo, sin filtrar. + +![Todos los eventos, mostrando cada origen](images/diagnostics_all_events.png) + +La vista activa forma parte de la URL de la página, por lo que se puede enlazar y sobrevive a una actualización de la página. + +## Acotar la lista + +* **Rango de tiempo** — 24 horas, 7 días, 30 días o 90 días, desde los botones del encabezado. +* **Recuentos por origen** — los recuentos con color debajo de las tarjetas de resumen también funcionan como filtros rápidos. Haga clic en uno para mostrar solo ese origen; vuelva a hacer clic (o en **Clear source filter**) para volver atrás. Solo uno, o ninguno, puede estar activo a la vez. +* **Filtros y ordenamiento por columna** — todas las columnas permiten filtrar y ordenar, incluidas Severidad y Origen. Severidad ordena por gravedad (`Critical` → `Info`) en lugar de alfabéticamente, y Origen ordena por la etiqueta que se ve en pantalla y no por el valor almacenado internamente. +* **Búsqueda por palabra clave** — busca en todos los campos de texto a la vez. +* **Preferencias de columnas** — el selector de columnas y sus diseños guardados se comportan igual que en el resto de las listas de Pro. + +![Un recuento de origen usado como filtro rápido](images/diagnostics_chip_filter.png) + +Haga clic en la lupa al comienzo de una fila para abrir el intento completo: + +![Un solo evento, incluido el aviso de redacción](images/diagnostics_detail.png) + +## Las credenciales se eliminan antes de escribir la fila + +Los errores de integración citan la solicitud que falló, y esas citas contienen secretos: un encabezado `Authorization`, un token en una cadena de consulta, una contraseña dentro de una URL de conexión. Diagnósticos los elimina **al momento de ingresar**, de modo que el valor original nunca llega a la base de datos y ningún cambio de opinión posterior puede exponerlo. + +Se depuran dos cosas: + +* **Valores bajo claves con forma de credencial** — todo aquello cuya clave parezca un secreto (`password`, `token`, `secret`, `api_key`, `authorization`, `private_key` y similares, con cualquier capitalización o con guiones o espacios). Un pequeño conjunto de claves está exento porque solo importa su *presencia*, nunca su contenido. +* **Valores que parecen credenciales dondequiera que aparezcan** — encabezados de autorización bearer y basic, JWT, credenciales incrustadas en URL (`https://user:pass@host`), prefijos de token de proveedores reconocibles y bloques PEM. + +Cada uno se reemplaza con `[redacted]`. El mensaje circundante se conserva, de modo que el error sigue siendo legible: + +```text +401 Unauthorized: Authorization: [redacted] +upload rejected: https://svc:[redacted]@sftp.example/out/… +``` + +Los valores largos se truncan y el contexto muy anidado se aplana, de modo que una carga útil enorme no puede inflar la tabla. + +Cuando se elimina algo de una fila, la fila lo indica, en lugar de dejarlo preguntándose si el campo estaba vacío o fue vaciado. + +> **La redacción es un esfuerzo razonable por diseño.** El depurador reconoce *formas* de credenciales. Un secreto que parece prosa común, bajo una clave que no se lee como sensible, aún puede quedar registrado. Trate Diagnósticos como un registro operativo, no como un lugar donde se garantiza la ausencia de secretos, y mantenga el detalle técnico restringido a las personas que lo necesitan. + +## Quién ve qué + +Diagnósticos está organizado por niveles, porque el resumen de una falla es útil para el propietario de un producto, mientras que la solicitud sin procesar detrás de ella no lo es. + +| | Superusuario | Todos los demás | +| --- | --- | --- | +| Filas de los productos en los que están autorizados | Sí | Sí | +| Filas a nivel de instancia (sin producto) | Sí | No | +| Resumen, origen, estado, severidad, tiempos, configuración | Sí | Sí | +| **Detalle notificado**, **Contexto**, **IP remota** | Sí | Se oculta, y se etiqueta como oculto | + +Un usuario que no es superusuario ve que un detalle existe y está siendo ocultado, en lugar de un campo vacío que parece un dato faltante. Las filas a nivel de instancia — SSO, SAML, LDAP y otra actividad que no pertenece a ningún producto — son exclusivas de superusuarios, ya que no existe una membresía de producto que pudiera otorgar acceso a ellas. + +## Cuánto tiempo se conservan los registros + +Una tarea programada recorta el registro para que no pueda crecer sin límite: + +| Severidad | Se conserva durante | +| --- | --- | +| `Info` | 30 días | +| `Warning`, `Error`, `Critical` | 180 días | + +Ambos períodos se pueden configurar con los ajustes `DIAGNOSTIC_EVENT_INFO_RETENTION_DAYS` y `DIAGNOSTIC_EVENT_RETENTION_DAYS`. La eliminación se ejecuta por lotes, de modo que una purga grande no mantiene abierta una transacción larga. + +## API + +El registro es de solo lectura a través de la API, en `/api/v2/diagnostic_events/`: + +| Endpoint | Devuelve | +| --- | --- | +| `GET /api/v2/diagnostic_events/` | La lista, con los filtros descritos a continuación | +| `GET /api/v2/diagnostic_events/{id}/` | Un evento | +| `GET /api/v2/diagnostic_events/summary/` | Los recuentos detrás de las tarjetas del encabezado, incluidos los totales por origen | +| `GET /api/v2/diagnostic_events/choices/` | Los valores válidos para `source`, `status`, `severity` y `trigger` | + +Parámetros útiles: + +| Parámetro | Efecto | +| --- | --- | +| `source`, `status`, `severity`, `trigger` | Aceptan varios valores separados por comas a la vez | +| `failures_only=true` | Fallas y tiempos de espera agotados | +| `unresolved_only=true` | Intentos que aún están en cola o en ejecución | +| `product_name` | Filtrar por nombre de producto | +| `object_model` | Filtrar por el tipo de registro con el que se relacionaba el intento | +| `o=` | Ordenamiento, con el prefijo `-` para invertir (`o=-created_at`) | + +Se aplican las mismas reglas de acceso: un usuario que no es superusuario obtiene filas limitadas a sus productos, con los campos restringidos ocultos. + +## Cómo averiguar qué salió mal + +* **Un ticket nunca apareció.** Filtre Origen por el integrador (o Jira) y luego lea Estado. `Failed` le da el motivo en Resumen; `Queued` mucho después del hecho significa que el trabajo nunca se ejecutó, lo cual es un problema de worker o de programación, no de credenciales. +* **Un usuario no puede iniciar sesión.** Filtre Origen por SSO, SAML o LDAP, y lea el fallo de su intento — una firma de aserción incorrecta, un bind rechazado, un atributo no coincidente. Estas filas son a nivel de instancia, por lo que son exclusivas de superusuarios. +* **Un escaneo no apareció.** Filtre Origen por Importar / Reimportar. Observe Activador para distinguir una carga programada no supervisada de una manual, y Activado por para saber a quién preguntar. +* **Algo sigue reintentando sin parar.** Ordene por ID de correlación, o filtre por uno, para ver juntos todos los intentos de la misma operación lógica. +* **"Nada funciona."** Abra primero Éxitos para la misma ventana de tiempo. Una lista saludable allí convierte una interrupción vaga en una específica. + +## Relacionado + +* [Feature Flags](/admin/feature_flags/pro__feature_flags/) — activar y desactivar funciones opcionales de Pro +* [Conectores](/connectors/upstream/about/) — para incorporar hallazgos +* [Integraciones Pro](/connectors/downstream/about/) — para enviar hallazgos +* [Inicio de sesión único](/admin/sso/) — los proveedores de identidad cuyos intentos de inicio de sesión aparecen aquí diff --git a/docs/content/admin/diagnostics/PRO__diagnostics.fr.md b/docs/content/admin/diagnostics/PRO__diagnostics.fr.md new file mode 100644 index 00000000000..060ff50d028 --- /dev/null +++ b/docs/content/admin/diagnostics/PRO__diagnostics.fr.md @@ -0,0 +1,169 @@ +--- +title: Diagnostics +description: 'Consultez le registre inter-sous-systèmes des tentatives d''intégration + : ce qui est enregistré, comment le filtrer, comment les identifiants en sont exclus, + et qui peut voir le détail technique' +weight: 1 +audience: pro +--- + +Diagnostics est un registre unique de chaque tentative de DefectDojo pour communiquer avec quelque chose en dehors de lui-même — et des tentatives d'autres systèmes pour communiquer avec lui. Lorsqu'un ticket n'apparaît jamais, qu'un scan n'est jamais importé, ou qu'un utilisateur n'a pas pu se connecter, c'est cette page qui indique ce qui s'est passé, quand, pour quelle configuration, et qui en est à l'origine. + +Diagnostics est une fonctionnalité de **DefectDojo Pro**. Vous la trouverez sous **Connect > Diagnostics**. + +![Le registre Diagnostics, vue Errors](images/diagnostics_errors.png) + +## Ce qui est enregistré + +Une ligne est écrite par tentative, pour chaque sous-système qui communique en dehors de DefectDojo : + +| Source | Ce qui génère des lignes | +| --- | --- | +| **Connector** | Les exécutions de découverte et de synchronisation des connecteurs en amont (upstream) | +| **Downstream integrator** | Les envois vers Jira, GitHub, GitLab, ServiceNow, et les autres connecteurs en aval (downstream) | +| **Jira** | L'intégration Jira historique : envois, commentaires et aperçus | +| **SSO (OIDC/OAuth2)** | Les tentatives de connexion via un fournisseur OAuth | +| **SAML** | Les assertions SAML, y compris les échecs de signature et d'attribut | +| **LDAP** | Les liaisons (binds) et recherches LDAP | +| **Import / Reimport** | Les imports de scans, que ce soit via l'interface, l'API ou une planification | +| **Rules engine** | Les évaluations de règles et les actions qu'elles tentent | +| **Scheduling** | Les exécutions planifiées, y compris celles qui n'ont jamais démarré | +| **Sensei** | Les analyses de dépôts et les exécutions de correctifs | +| **Notification** | La livraison des notifications sortantes | +| **System** | L'activité au niveau de l'instance qui n'appartient à aucun produit | + +Les lignes sont écrites *en parallèle* du sous-système, jamais à sa place. Chaque adaptateur est rattaché à l'enregistrement d'origine et est délibérément conçu pour échouer sans danger (fail-safe) : si l'écriture d'une ligne de diagnostic déclenche une erreur, celle-ci est absorbée et l'opération d'origine se poursuit. Diagnostics ne peut donc jamais être la cause de l'échec d'un envoi, d'un import ou d'une connexion. + +Comme les lignes sont indexées sur l'enregistrement qui les a produites, le fait de réenregistrer un enregistrement d'origine met à jour sa ligne de diagnostic existante plutôt que d'en ajouter une nouvelle. Une tentative correspond à une ligne pour toute sa durée de vie, de `Queued` à `Running` jusqu'à son résultat final. + +### Champs d'une ligne + +| Champ | Signification | +| --- | --- | +| **When** | Le moment où la ligne a été enregistrée ; **Started**, **Finished** et **Duration** décrivent la tentative elle-même | +| **Source** | Le sous-système, parmi ceux du tableau ci-dessus | +| **Provider** | L'outil ou le fournisseur spécifique au sein de cette source (`jira`, `github`, `okta`, un nom de scanner) | +| **Operation** | Ce qui a été tenté (`push`, `sync`, `login`, `reimport`, `rule_run`) | +| **Status** | `Queued`, `Running`, `Success`, `Failed`, `Timed out`, `Skipped`, ou `Dry run` | +| **Severity** | `Info`, `Warning`, `Error`, ou `Critical` | +| **Summary** | Un résultat en une ligne, sûr à lire d'un coup d'œil | +| **Trigger** | Ce qui a déclenché la tentative : `UI`, `API`, `Scheduled`, `Webhook`, `Automatic`, `Command line`, ou `System` | +| **Triggered by** | L'utilisateur responsable, ou `System` pour un travail sans supervision | +| **Asset** | Le produit auquel appartient la tentative ; vide signifie qu'elle est au niveau de l'instance | +| **Related object** | La constatation, l'engagement ou tout autre enregistrement concerné par la tentative | +| **Configuration** | La configuration utilisée, par son libellé | +| **External reference** | L'identifiant renvoyé par l'autre système, comme la clé d'un ticket créé | +| **Correlation ID** | Relie entre elles les lignes issues d'une même opération logique | +| **Reported detail** et **Context** | Le détail technique complet (restreint, voir [Qui voit quoi](#who-sees-what)) | + +## Les quatre vues + +Les onglets au-dessus du tableau sont des points de départ enregistrés, et non des filtres à reconstruire à chaque fois : + +* **Errors** — échecs et délais dépassés. Celui à ouvrir en premier. +* **Successes** — la preuve qu'une intégration fonctionnelle fonctionne, utile lorsque quelqu'un signale que « rien ne se synchronise ». +* **Never completed** — les tentatives toujours `Queued` ou `Running` bien après le moment où elles auraient dû se terminer. Ce sont les silencieuses : rien n'a échoué, donc rien n'a été signalé, mais rien n'est arrivé non plus. +* **All events** — tout, sans filtre. + +![All events, montrant chaque source](images/diagnostics_all_events.png) + +La vue active fait partie de l'URL de la page, elle est donc partageable par lien et survit à une actualisation. + +## Restreindre la liste + +* **Time range** — 24 heures, 7 jours, 30 jours ou 90 jours, depuis les boutons de l'en-tête. +* **Source counts** — les compteurs colorés sous les cartes de synthèse sont aussi des filtres rapides. Cliquez sur l'un d'eux pour n'afficher que cette source ; cliquez à nouveau dessus (ou sur **Clear source filter**) pour revenir en arrière. Un seul est actif à la fois, ou aucun. +* **Filtres et tri par colonne** — chaque colonne se filtre et se trie, y compris Severity et Source. Severity se trie par gravité (`Critical` → `Info`) plutôt qu'alphabétiquement, et Source se trie selon le libellé affiché plutôt que la valeur stockée en interne. +* **Keyword Search** — recherche simultanément dans tous les champs texte. +* **Préférences de colonnes** — le sélecteur de colonnes et ses dispositions enregistrées se comportent comme sur toute autre liste Pro. + +![Un compteur de source utilisé comme filtre rapide](images/diagnostics_chip_filter.png) + +Cliquez sur la loupe au début d'une ligne pour ouvrir la tentative dans son intégralité : + +![Un événement unique, avec la mention de rédaction](images/diagnostics_detail.png) + +## Les identifiants sont supprimés avant l'écriture de la ligne + +Les erreurs d'intégration citent la requête qui a échoué, et ces citations contiennent des secrets : un en-tête `Authorization`, un jeton dans une chaîne de requête, un mot de passe dans une URL de connexion. Diagnostics les supprime **à l'entrée**, de sorte que la valeur d'origine n'atteint jamais la base de données et qu'aucun changement d'avis ultérieur ne peut l'exposer. + +Deux choses sont nettoyées : + +* **Les valeurs sous des clés ayant la forme d'un identifiant** — tout ce dont la clé ressemble à un secret (`password`, `token`, `secret`, `api_key`, `authorization`, `private_key`, et similaires, quelle que soit la casse ou avec des tirets ou des espaces). Un petit ensemble de clés est exempté car seule leur *présence* compte, jamais leur contenu. +* **Les valeurs qui ressemblent à des identifiants où qu'elles apparaissent** — en-têtes d'autorisation bearer et basic, JWT, identifiants intégrés dans des URL (`https://user:pass@host`), préfixes de jetons de fournisseurs reconnaissables, et blocs PEM. + +Chacune est remplacée par `[redacted]`. Le message environnant est conservé, afin que l'erreur reste lisible : + +```text +401 Unauthorized: Authorization: [redacted] +upload rejected: https://svc:[redacted]@sftp.example/out/… +``` + +Les valeurs longues sont tronquées, et le contexte profondément imbriqué est aplati, afin qu'une charge utile énorme ne puisse pas alourdir le tableau. + +Lorsque quelque chose a été retiré d'une ligne, la ligne l'indique, plutôt que de vous laisser deviner si le champ était vide ou vidé. + +> **La rédaction est faite au mieux, par conception.** Le nettoyeur reconnaît des *formes* d'identifiants. Un secret qui ressemble à du texte ordinaire, sous une clé qui ne paraît pas sensible, peut malgré tout être enregistré. Considérez Diagnostics comme un journal opérationnel, pas comme un endroit où l'absence de secrets est garantie — et réservez le détail technique aux personnes qui en ont besoin. + +## Qui voit quoi + +Diagnostics est hiérarchisé, car le résumé d'un échec est utile à un propriétaire de produit, alors que la requête brute qui se cache derrière ne l'est pas. + +| | Superuser | Tous les autres | +| --- | --- | --- | +| Lignes pour les produits sur lesquels ils sont autorisés | Oui | Oui | +| Lignes au niveau de l'instance (sans produit) | Oui | Non | +| Summary, source, status, severity, timings, configuration | Oui | Oui | +| **Reported detail**, **Context**, **Remote IP** | Oui | Masqués, et signalés comme tels | + +Un utilisateur non superuser voit qu'un détail existe et qu'il est masqué, plutôt qu'un champ vide qui ressemblerait à une donnée manquante. Les lignes au niveau de l'instance — SSO, SAML, LDAP et autres activités n'appartenant à aucun produit — sont réservées aux superusers, puisqu'aucune appartenance à un produit ne pourrait y donner accès. + +## Durée de conservation des enregistrements + +Une tâche planifiée réduit le registre afin qu'il ne puisse pas croître sans limite : + +| Severity | Conservé pendant | +| --- | --- | +| `Info` | 30 jours | +| `Warning`, `Error`, `Critical` | 180 jours | + +Les deux fenêtres sont configurables via les paramètres `DIAGNOSTIC_EVENT_INFO_RETENTION_DAYS` et `DIAGNOSTIC_EVENT_RETENTION_DAYS`. La suppression s'exécute par lots, afin qu'une purge volumineuse ne maintienne pas une transaction longue ouverte. + +## API + +Le registre est en lecture seule via l'API, à `/api/v2/diagnostic_events/` : + +| Endpoint | Retourne | +| --- | --- | +| `GET /api/v2/diagnostic_events/` | La liste, avec les filtres ci-dessous | +| `GET /api/v2/diagnostic_events/{id}/` | Un événement | +| `GET /api/v2/diagnostic_events/summary/` | Les compteurs derrière les cartes de l'en-tête, y compris les totaux par source | +| `GET /api/v2/diagnostic_events/choices/` | Les valeurs valides pour `source`, `status`, `severity` et `trigger` | + +Paramètres utiles : + +| Paramètre | Effet | +| --- | --- | +| `source`, `status`, `severity`, `trigger` | Acceptent plusieurs valeurs séparées par des virgules à la fois | +| `failures_only=true` | Échecs et délais dépassés | +| `unresolved_only=true` | Tentatives encore en file d'attente ou en cours | +| `product_name` | Filtrer par nom de produit | +| `object_model` | Filtrer par type d'enregistrement concerné par la tentative | +| `o=` | Tri, préfixé par `-` pour inverser (`o=-created_at`) | + +Les mêmes règles d'accès s'appliquent : un utilisateur non superuser obtient des lignes limitées au périmètre de ses produits, avec les champs restreints masqués. + +## Comprendre ce qui n'a pas fonctionné + +* **Un ticket n'est jamais apparu.** Filtrez Source sur l'intégrateur (ou Jira), puis lisez Status. `Failed` vous donne la raison dans Summary ; `Queued` longtemps après coup signifie que la tâche n'a jamais été exécutée, ce qui relève d'un problème de worker ou de planification plutôt que d'identifiants. +* **Un utilisateur ne peut pas se connecter.** Filtrez Source sur SSO, SAML ou LDAP, et lisez l'échec de sa tentative — une signature d'assertion invalide, une liaison (bind) rejetée, un attribut incohérent. Ces lignes sont au niveau de l'instance, donc réservées aux superusers. +* **Un scan n'est pas apparu.** Filtrez Source sur Import / Reimport. Regardez Trigger pour distinguer un envoi planifié sans supervision d'un envoi manuel, et Triggered by pour savoir à qui demander. +* **Quelque chose retente indéfiniment.** Triez par Correlation ID, ou filtrez sur un identifiant précis, pour voir ensemble toutes les tentatives d'une même opération logique. +* **« Rien ne fonctionne ».** Ouvrez d'abord Successes pour la même période. Une liste saine à cet endroit transforme une panne vague en une panne précise. + +## Voir aussi + +* [Feature Flags](/admin/feature_flags/pro__feature_flags/) — activer et désactiver les fonctionnalités Pro optionnelles +* [Connectors](/connectors/upstream/about/) — récupérer des constatations +* [Pro Integrations](/connectors/downstream/about/) — envoyer des constatations vers l'extérieur +* [Single Sign-On](/admin/sso/) — les fournisseurs d'identité dont les tentatives de connexion apparaissent ici diff --git a/docs/content/admin/diagnostics/PRO__diagnostics.ja.md b/docs/content/admin/diagnostics/PRO__diagnostics.ja.md new file mode 100644 index 00000000000..c8f6f04b7dc --- /dev/null +++ b/docs/content/admin/diagnostics/PRO__diagnostics.ja.md @@ -0,0 +1,167 @@ +--- +title: 診断 +description: サブシステム横断の統合試行台帳を読み解きます。何が記録されるか、どのようにフィルタリングするか、認証情報がどのように除外されるか、誰が技術的な詳細を閲覧できるかを説明します。 +weight: 1 +audience: pro +--- + +診断は、DefectDojoが自身の外部と通信を試みたすべての試行、そして他のシステムがDefectDojoと通信を試みたすべての試行を記録する、単一の台帳です。チケットが作成されなかったとき、スキャンがインポートされなかったとき、あるいはユーザーがサインインできなかったとき、何が起きたのか、いつ起きたのか、どの設定に対してか、そして誰がそれを引き起こしたのかを教えてくれるのがこのページです。 + +Diagnosticsは **DefectDojo Pro** の機能です。**Connect > Diagnostics** の下にあります。 + +![診断台帳、エラー表示](images/diagnostics_errors.png) + +## 記録される内容 + +DefectDojoの外部に到達するすべてのサブシステムについて、試行ごとに1行が記録されます。 + +| ソース | 生成される行の内容 | +| --- | --- | +| **コネクタ** | アップストリームコネクタによるdiscoverおよびsyncの実行 | +| **ダウンストリームインテグレーター** | Jira、GitHub、GitLab、ServiceNow、その他のダウンストリームコネクタへのプッシュ | +| **Jira** | レガシーJira連携: プッシュ、コメント、プレビュー | +| **SSO (OIDC/OAuth2)** | OAuthプロバイダー経由のサインイン試行 | +| **SAML** | SAMLアサーション（署名や属性の失敗を含む） | +| **LDAP** | LDAPバインドおよびルックアップ | +| **インポート / 再インポート** | UI、API、スケジュールのいずれかによるスキャンのアップロード | +| **ルールエンジン** | ルール評価とそれが試みるアクション | +| **スケジューリング** | スケジュール実行（一度も開始されなかったものを含む） | +| **Sensei** | リポジトリスキャンおよび修正の実行 | +| **通知** | 送信通知の配信 | +| **システム** | どの製品にも属さないインスタンスレベルの活動 | + +行はサブシステムの*代わりに*ではなく、サブシステムと*並行して*書き込まれます。各アダプターは元のレコードに紐付けられており、意図的にフェイルセーフに設計されています。診断行の書き込みで例外が発生しても、そのエラーは握りつぶされ、元の操作はそのまま続行されます。したがって、診断がプッシュ、インポート、ログインの失敗の原因になることは決してありません。 + +行はそれを生成したレコードをキーとしているため、元のレコードを再保存すると、重複を追加するのではなく既存の診断行が更新されます。1回の試行は、`Queued` から `Running` を経て結果に至るまで、その生涯を通じて1つの行のままです。 + +### 行のフィールド + +| フィールド | 意味 | +| --- | --- | +| **日時** | 行が記録された日時。**開始**、**終了**、**所要時間** は試行自体を表します | +| **ソース** | 上記の表にあるサブシステム | +| **プロバイダー** | そのソース内の具体的なツールまたはプロバイダー（`jira`、`github`、`okta`、スキャナー名など） | +| **操作** | 試みられた内容（`push`、`sync`、`login`、`reimport`、`rule_run`） | +| **ステータス** | `Queued`、`Running`、`Success`、`Failed`、`Timed out`、`Skipped`、または `Dry run` | +| **深刻度** | `Info`、`Warning`、`Error`、または `Critical` | +| **概要** | ひと目で安全に読める一行の結果 | +| **トリガー** | 試行を開始させたもの: `UI`、`API`、`Scheduled`、`Webhook`、`Automatic`、`Command line`、または `System` | +| **実行者** | 責任を持つユーザー、または無人実行の場合は `System` | +| **アセット** | 試行が属する製品。空欄はインスタンスレベルを意味します | +| **関連オブジェクト** | 試行の対象となった検出事項、エンゲージメント、その他のレコード | +| **設定** | どの設定が使用されたか、そのラベルで示します | +| **外部参照** | 作成されたIssueキーなど、他システムが返した識別子 | +| **相関ID** | 1つの論理操作に属する行をひも付けます | +| **報告された詳細** および **コンテキスト** | 完全な技術的詳細（制限あり、[誰が何を見られるか](#who-sees-what) を参照） | + +## 4つのビュー + +テーブル上部のタブは、あらかじめ用意された起点であり、自分で組み立て直す必要のあるフィルターではありません。 + +* **エラー** — 失敗とタイムアウト。最初に開くべきタブです。 +* **成功** — 動作している連携が実際に機能している証拠。「何も同期されていない」という報告を受けたときに役立ちます。 +* **完了しなかった** — 完了すべき時間をとうに過ぎても、まだ `Queued` または `Running` のままの試行。これらは静かな失敗です。何も失敗していないので何も報告されませんが、何も届いてもいません。 +* **すべてのイベント** — フィルターなしのすべて。 + +![すべてのイベント、あらゆるソースを表示](images/diagnostics_all_events.png) + +現在表示中のビューはページURLの一部になっているため、ビューにリンクを張ることができ、リフレッシュしても保持されます。 + +## 一覧を絞り込む + +* **期間** — ヘッダーのボタンから、24時間、7日間、30日間、または90日間を選択できます。 +* **ソース件数** — サマリーカード下の色付きの件数もクイックフィルターとして機能します。クリックするとそのソースのみを表示し、もう一度クリックする（または **ソースフィルターを解除**）と元に戻ります。一度にアクティブにできるのは1つまたはゼロです。 +* **列ごとのフィルターと並べ替え** — 深刻度やソースを含め、すべての列でフィルターと並べ替えができます。深刻度は五十音順ではなく重大さ順（`Critical` → `Info`）で並べ替えられ、ソースは内部で保持されている値ではなく画面に表示されているラベルで並べ替えられます。 +* **キーワード検索** — テキストフィールドを横断して一度に検索します。 +* **列の表示設定** — 列の選択やその保存済みレイアウトは、他のPro一覧と同様に動作します。 + +![クイックフィルターとして使われるソース件数](images/diagnostics_chip_filter.png) + +行の先頭にある虫眼鏡アイコンをクリックすると、試行の全体を開くことができます。 + +![マスキング通知を含む単一のイベント](images/diagnostics_detail.png) + +## 行が書き込まれる前に認証情報は除去されます + +連携エラーは失敗したリクエストを引用しますが、その引用には `Authorization` ヘッダー、クエリ文字列内のトークン、接続URL内のパスワードなど、機密情報が含まれることがあります。診断は**入力の時点で**それらを取り除くため、元の値がデータベースに到達することはなく、後から気が変わってもそれが露出することはありません。 + +除去される対象は2種類あります。 + +* **認証情報らしいキーの下にある値** — `password`、`token`、`secret`、`api_key`、`authorization`、`private_key` など、キー名が秘密情報らしく見えるものすべて（大文字小文字やハイフン・スペースの有無は問いません）。ごく一部のキーは、その*内容*ではなく*存在すること*自体が重要であるため対象外です。 +* **どこに現れても認証情報らしく見える値** — bearerおよびbasic認証ヘッダー、JWT、URLに埋め込まれた認証情報（`https://user:pass@host`）、識別可能なベンダーのトークンプレフィックス、PEMブロック。 + +それぞれは `[redacted]` に置き換えられます。周囲のメッセージはそのまま残るため、エラーは読める状態を保ちます。 + +```text +401 Unauthorized: Authorization: [redacted] +upload rejected: https://svc:[redacted]@sftp.example/out/… +``` + +長い値は切り詰められ、深くネストしたコンテキストはフラット化されるため、一つの巨大なペイロードによってテーブルが肥大化することはありません。 + +行から何かが除去された場合、そのフィールドが元々空だったのか除去されて空になったのか迷わせることなく、行自体がその旨を示します。 + +> **マスキングは設計上ベストエフォートです。** スクラバーは認証情報の*形状*を認識します。機密情報らしく見えないキーの下にある、普通の文章のように見える秘密情報は、記録されてしまう可能性があります。診断を、秘密情報が絶対に存在しないことが保証された場所としてではなく、運用ログとして扱ってください。そして技術的な詳細は、必要な人だけに閲覧を制限しておいてください。 + +## 誰が何を見られるか + +診断は階層化されています。失敗の概要は製品オーナーにとって有用ですが、その背後にある生のリクエストはそうではないためです。 + +| | スーパーユーザー | それ以外のユーザー | +| --- | --- | --- | +| 自分が権限を持つ製品の行 | はい | はい | +| インスタンスレベルの行（製品に紐付かない） | はい | いいえ | +| 概要、ソース、ステータス、深刻度、日時、設定 | はい | はい | +| **報告された詳細**、**コンテキスト**、**リモートIP** | はい | 非表示（非表示である旨が表示されます） | + +スーパーユーザー以外のユーザーには、データが欠落しているように見える空欄ではなく、詳細情報が存在していて非表示になっていることが示されます。SSO、SAML、LDAPなど、どの製品にも属さない活動を示すインスタンスレベルの行は、アクセスを許可し得る製品メンバーシップが存在しないため、スーパーユーザー専用です。 + +## レコードの保持期間 + +スケジュールタスクが台帳を刈り込むため、無制限に増え続けることはありません。 + +| 深刻度 | 保持期間 | +| --- | --- | +| `Info` | 30日間 | +| `Warning`、`Error`、`Critical` | 180日間 | + +両方の期間は `DIAGNOSTIC_EVENT_INFO_RETENTION_DAYS` および `DIAGNOSTIC_EVENT_RETENTION_DAYS` の設定で変更できます。削除はバッチ単位で実行されるため、大規模な削除でも長時間トランザクションを保持し続けることはありません。 + +## API + +この台帳はAPI経由では読み取り専用で、`/api/v2/diagnostic_events/` で提供されます。 + +| エンドポイント | 返される内容 | +| --- | --- | +| `GET /api/v2/diagnostic_events/` | 以下のフィルターに対応した一覧 | +| `GET /api/v2/diagnostic_events/{id}/` | 1件のイベント | +| `GET /api/v2/diagnostic_events/summary/` | ヘッダーカードの元になる件数（ソースごとの集計を含む） | +| `GET /api/v2/diagnostic_events/choices/` | `source`、`status`、`severity`、`trigger` の有効な値 | + +便利なパラメーター: + +| パラメーター | 効果 | +| --- | --- | +| `source`、`status`、`severity`、`trigger` | カンマ区切りで複数の値を同時に指定できます | +| `failures_only=true` | 失敗とタイムアウト | +| `unresolved_only=true` | まだキューにあるか実行中の試行 | +| `product_name` | 製品名でフィルタリング | +| `object_model` | 試行の対象となったレコードの種類でフィルタリング | +| `o=` | 並べ替え。`-` を付けると逆順になります（`o=-created_at`） | + +同じアクセス規則が適用されます。スーパーユーザー以外は、制限されたフィールドが非表示になった、製品スコープの行のみを取得します。 + +## 何が問題だったのかを突き止める + +* **チケットが一度も作成されなかった。** ソースをインテグレーター（またはJira）に絞り込み、ステータスを確認します。`Failed` であれば概要に理由が示されます。事後もずっと `Queued` のままであれば、ジョブが一度も実行されなかったことを意味し、認証情報の問題ではなくワーカーやスケジューリングの問題です。 +* **ユーザーがサインインできない。** ソースをSSO、SAML、またはLDAPに絞り込み、そのユーザーの試行の失敗内容を確認します。不正なアサーション署名、拒否されたバインド、一致しない属性などです。これらの行はインスタンスレベルのため、スーパーユーザーのみが閲覧できます。 +* **スキャンが表示されない。** ソースをインポート / 再インポートに絞り込みます。トリガーを見れば無人のスケジュールアップロードか誰かの手動アップロードかが分かり、実行者を見れば誰に確認すればよいかが分かります。 +* **何かが延々とリトライしている。** 相関IDで並べ替える、または1つに絞り込むことで、同一の論理操作に属するすべての試行をまとめて確認できます。 +* **「何も動いていない」。** まず同じ期間の成功を開いてください。そこで健全な一覧が見えれば、漠然とした障害を具体的なものに絞り込めます。 + +## 関連項目 + +* [Feature Flags](/admin/feature_flags/pro__feature_flags/) — オプションのPro機能のオン・オフ切り替え +* [Connectors](/connectors/upstream/about/) — 検出事項を取り込む +* [Pro Integrations](/connectors/downstream/about/) — 検出事項を送信する +* [Single Sign-On](/admin/sso/) — サインイン試行がここに表示されるIDプロバイダー diff --git a/docs/content/admin/diagnostics/_index.de.md b/docs/content/admin/diagnostics/_index.de.md new file mode 100644 index 00000000000..e74b401881f --- /dev/null +++ b/docs/content/admin/diagnostics/_index.de.md @@ -0,0 +1,25 @@ +--- +title: Diagnostics +description: Ein zentraler Ort, um zu sehen, warum ein Integrationsversuch fehlgeschlagen + ist – über alle Subsysteme hinweg, die mit einem System außerhalb von DefectDojo + kommunizieren +summary: '' +date: 2026-07-30 00:00:00+00:00 +lastmod: 2026-07-30 00:00:00+00:00 +draft: false +weight: 6 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +--- + +Wenn etwas nicht ankommt – ein Ticket, das nie erstellt wurde, ein Scan, der nie importiert wurde, ein Benutzer, der sich nicht anmelden kann – lagen die Beweise bisher in welchem Subsystem auch immer der Versuch zufällig stattfand. Diagnostics zeichnet jeden dieser Versuche in einem einzigen Logbuch auf, sodass die Frage „Warum ist das nicht passiert?“ eine einzige Seite statt acht erfordert. + +Diagnostics ist eine **DefectDojo Pro**-Funktion. + +* [Diagnostics](./pro__diagnostics/) – was aufgezeichnet wird, wie Sie das Logbuch lesen und filtern, wie Zugangsdaten davon ferngehalten werden, wer die technischen Details sehen kann und wie lange Datensätze aufbewahrt werden. diff --git a/docs/content/admin/diagnostics/_index.es.md b/docs/content/admin/diagnostics/_index.es.md new file mode 100644 index 00000000000..dfbdf4488cf --- /dev/null +++ b/docs/content/admin/diagnostics/_index.es.md @@ -0,0 +1,24 @@ +--- +title: Diagnósticos +description: Un solo lugar para ver por qué falló un intento de integración, en todos + los subsistemas que se comunican con algo externo a DefectDojo +summary: '' +date: 2026-07-30 00:00:00+00:00 +lastmod: 2026-07-30 00:00:00+00:00 +draft: false +weight: 6 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +--- + +Cuando algo no llega — un ticket que nunca se creó, un escaneo que nunca se importó, un usuario que no puede iniciar sesión — la evidencia solía estar en el subsistema que hubiera sido responsable del intento. Diagnósticos registra cada uno de esos intentos en un único registro, de modo que la pregunta "¿por qué no ocurrió eso?" se resuelve en una sola página en lugar de ocho. + +Diagnósticos es una función de **DefectDojo Pro**. + +* [Diagnósticos](./pro__diagnostics/) — qué se registra, cómo leer y filtrar el registro, cómo se mantienen fuera las credenciales, quién puede ver el detalle técnico y cuánto tiempo se conservan los registros. diff --git a/docs/content/admin/diagnostics/_index.fr.md b/docs/content/admin/diagnostics/_index.fr.md new file mode 100644 index 00000000000..1880a913553 --- /dev/null +++ b/docs/content/admin/diagnostics/_index.fr.md @@ -0,0 +1,25 @@ +--- +title: Diagnostics +description: Un seul endroit pour comprendre pourquoi une tentative d'intégration + a échoué, à travers tous les sous-systèmes qui communiquent avec l'extérieur de + DefectDojo +summary: '' +date: 2026-07-30 00:00:00+00:00 +lastmod: 2026-07-30 00:00:00+00:00 +draft: false +weight: 6 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +--- + +Lorsque quelque chose n'arrive pas — un ticket qui n'a jamais été créé, un scan qui n'a jamais été importé, un utilisateur qui ne peut pas se connecter — la preuve se trouvait auparavant dans le sous-système qui possédait la tentative en question. Diagnostics enregistre chacune de ces tentatives dans un registre unique, de sorte que la question « pourquoi cela ne s'est-il pas produit ? » tienne sur une seule page au lieu de huit. + +Diagnostics est une fonctionnalité de **DefectDojo Pro**. + +* [Diagnostics](./pro__diagnostics/) — ce qui est enregistré, comment lire et filtrer le registre, comment les identifiants en sont exclus, qui peut voir le détail technique, et combien de temps les enregistrements sont conservés. diff --git a/docs/content/admin/diagnostics/_index.ja.md b/docs/content/admin/diagnostics/_index.ja.md new file mode 100644 index 00000000000..ba31b3b484e --- /dev/null +++ b/docs/content/admin/diagnostics/_index.ja.md @@ -0,0 +1,23 @@ +--- +title: 診断 +description: DefectDojoの外部と通信するあらゆるサブシステムを横断して、連携の試行がなぜ失敗したのかを一箇所で確認できます。 +summary: '' +date: 2026-07-30 00:00:00+00:00 +lastmod: 2026-07-30 00:00:00+00:00 +draft: false +weight: 6 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +--- + +何かが届かないとき——作成されなかったチケット、インポートされなかったスキャン、サインインできなかったユーザー——その証拠は、たまたまその試行を所有していたサブシステムの中に埋もれていました。診断はそうした試行のすべてを単一の台帳に記録するため、「なぜそれが起きなかったのか」という問いは、8ページ分ではなく1ページで済むようになります。 + +診断は **DefectDojo Pro** の機能です。 + +* [診断](./pro__diagnostics/) — 何が記録されるか、台帳の読み方とフィルタリング方法、認証情報がどのように除外されるか、誰が技術的な詳細を閲覧できるか、そしてレコードがどのくらいの期間保持されるか。 diff --git a/docs/content/admin/feature_flags/PRO__feature_flags.de.md b/docs/content/admin/feature_flags/PRO__feature_flags.de.md new file mode 100644 index 00000000000..5a7ec7cedda --- /dev/null +++ b/docs/content/admin/feature_flags/PRO__feature_flags.de.md @@ -0,0 +1,143 @@ +--- +title: Feature Flags +description: Aktivieren und deaktivieren Sie optionale DefectDojo Pro-Funktionen über + die DefectDojo-Benutzeroberfläche +weight: 1 +audience: pro +--- + +Mit Feature Flags können Sie optionale DefectDojo Pro-Funktionen für Ihre eigene Instanz aktivieren und deaktivieren – Funktionen, die zuvor nur durch Kontaktaufnahme mit dem DefectDojo Support aktiviert werden konnten, lassen sich jetzt selbst über die Benutzeroberfläche verwalten. + +Die Seite „Feature Flags" ist nur für **Superuser** sichtbar. Andere Benutzer, einschließlich Global Owners, sehen sie nicht. + +## Öffnen der Seite „Feature Flags" + +Gehen Sie in der linken Seitenleiste zu **Settings > Feature Flags**. + +Die Seite listet jede optionale Funktion mit folgenden Angaben auf: + +* **Name** — die Funktion, mit einem **BETA**-Tag, solange sie sich noch in der Beta-Phase befindet +* **Description** — was die Funktion tut +* **Documentation link** — wo es Dokumentation zu dieser Funktion gibt +* **Toggle** — ob die Funktion derzeit aktiviert ist + +Verwenden Sie das Suchfeld, um die Liste nach Funktionsname oder Beschreibung zu filtern. + +### Funktionen, die nicht aufgeführt werden + +Die Seite listet die Funktionen auf, die Sie sich aktiv entscheiden können zu übernehmen. Zwei Arten von Funktionen fehlen darin. + +**Immer aktiviert.** Sobald eine Funktion die allgemeine Verfügbarkeit erreicht, ist sie für jede Instanz aktiviert und wird nicht mehr aufgeführt, da es keine Entscheidung mehr zu treffen gibt: + +* **Downstream Connectors** — siehe [Downstream Connectors](/connectors/downstream/about/) +* **Universal Parser** — siehe [Universal Parser](/import_data/pro/specialized_import/universal_parser/) +* **Asset Hierarchy** — siehe [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/) +* **Appearance** und **Feature Flags** — die beiden gleichnamigen Settings-Seiten + +Für Ihre Instanz ändert sich nichts, wenn eine dieser Funktionen bereits aktiviert war. War eine deaktiviert, ist sie jetzt aktiviert: Diese Funktionen sind Teil von DefectDojo Pro und nicht mehr optional. Wenden Sie sich an den [DefectDojo Support](mailto:support@defectdojo.com), falls dies für Ihre Instanz ein Problem darstellt. + +**Auf Anfrage von DefectDojo aktiviert.** Einige Funktionen hängen von einer Infrastruktur ab, die pro Instanz bereitgestellt wird, und werden daher von DefectDojo aktiviert statt über diese Seite: + +* **Scheduling Service** — siehe [Scheduling Rules](/automation/rules_engine/scheduling/) + +Wenden Sie sich an den [DefectDojo Support](mailto:support@defectdojo.com), um eine dieser Funktionen aktivieren zu lassen. Ist sie für Ihre Instanz bereits aktiviert, bleibt sie es. + +## Eine Funktion aktivieren oder deaktivieren + +1. Suchen Sie die Funktion in der Liste. +2. Klicken Sie auf ihren Toggle. +3. Die Änderung wird sofort wirksam. Andere Benutzer erhalten die Änderung beim nächsten Laden der Seite. + +Bei manchen Funktionen erscheint vor der Änderung ein Bestätigungsdialog. Dies geschieht, wenn eine Funktion aktiviert wird, die mit einem Warnhinweis versehen ist (zum Beispiel weil ein Neustart erforderlich ist oder bestehende Daten betroffen sein können), oder die sich nicht mehr deaktivieren lässt. + +Eine Funktion zu deaktivieren ist normalerweise einfach die Umkehrung ihrer Aktivierung. Die Ausnahmen werden unter [Wenn ein Toggle gesperrt ist](#when-a-toggle-is-locked) beschrieben. + +### Organization / Asset Relabeling + +**Organization / Asset Relabeling** benennt „Product Type" in „Organization" und „Product" in „Asset" um. Die Funktion ist standardmäßig aktiviert und wird wie jede andere Funktion über diese Seite umgeschaltet, aber es lohnt sich zu wissen, welche Teile von DefectDojo sie betrifft: + +* Die **Pro UI** folgt diesem Toggle. Die neuen Bezeichnungen erscheinen beim nächsten Laden der Seite. +* Die Seiten der **Classic UI**, ihre URLs und generierte Berichte übernehmen ihre Benennung von der Deployment-Einstellung `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` (ebenfalls standardmäßig aktiviert), die beim Start von DefectDojo gelesen wird. Dieser Toggle ändert sie nicht, und auch ein Neustart bewirkt keine Änderung. + +Der gespeicherte Toggle wurde ursprünglich aus dieser Deployment-Einstellung übernommen, daher stimmen beide überein, bis Sie eine der beiden ändern. Wenn Sie die Umbenennung hier deaktivieren und außerdem die Classic UI verwenden, setzen Sie `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL=False` in Ihrem Deployment und starten Sie neu, damit beide Oberflächen übereinstimmen. Wenden Sie sich bei [DefectDojo Pro (Cloud)](/get_started/pro/cloud/) an den [DefectDojo Support](mailto:support@defectdojo.com), um die Deployment-Einstellung ändern zu lassen. + +Die Funktion trägt aus diesem Grund auf der Seite „Feature Flags" das Tag **Restart Recommended**: Die außerhalb der Pro UI verwendete Benennung wird beim Start des Prozesses festgelegt. Die Umbenennung ist in jedem Fall rein kosmetisch. Datenbankmodelle, Feldnamen und API-Endpunkte bleiben unverändert, sodass bestehende Automatisierungen weiterhin funktionieren. Siehe [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/). + +## Wenn ein Toggle gesperrt ist + +Eine Funktion, die Sie nicht ändern können, wird mit einem Schloss-Badge angezeigt, das den Grund erklärt: + +| Badge | Bedeutung | Was zu tun ist | +| --- | --- | --- | +| **Managed by DefectDojo** | DefectDojo hat diese Funktion zentral für Ihre Instanz festgelegt. Ihre Einstellung kann dies nicht überschreiben. | Wenden Sie sich an den [DefectDojo Support](mailto:support@defectdojo.com), wenn Sie eine Änderung benötigen. | +| **Unavailable on This Deployment** | Die Funktion wird für Ihren Installationstyp nicht angeboten. Siehe [Verfügbarkeit von Funktionen](#feature-availability) unten. | Nichts. Die Funktion ist für Ihre Instanz nicht relevant. | +| **Cannot Be Disabled** | Die Funktion ist bereits aktiviert und lässt sich nur in eine Richtung schalten. Es gibt keine Möglichkeit, sie rückgängig zu machen. | Nichts. Das ist so vorgesehen. | +| **Managed by deployment** | Die Funktion wird durch Ihre Deployment-Konfiguration gesteuert und nicht über diese Seite. | Siehe [DefectDojo Pro (On-Premise)](#defectdojo-pro-on-premise) unten. | + +## DefectDojo Pro (Cloud) + +Bei [DefectDojo Pro (Cloud)](/get_started/pro/cloud/) genügt **Settings > Feature Flags**. Schalten Sie eine Funktion ein, und sie ist sofort aktiv. + +Zwei Dinge werden von DefectDojo statt von Ihnen verwaltet: + +* **Managed by DefectDojo** — die Funktion ist zentral festgelegt. Wenden Sie sich an den [DefectDojo Support](mailto:support@defectdojo.com), um sie ändern zu lassen. +* **Managed by deployment** — die Funktion ist Teil davon, wie Ihre Instanz bereitgestellt wird. Wenden Sie sich auch hierfür an den Support, da Cloud-Instanzen Kunden keine Deployment-Konfiguration zugänglich machen. + +Cloud-Instanzen haben außerdem Zugriff auf Funktionen, die On-Premise nicht angeboten werden. Siehe [Verfügbarkeit von Funktionen](#feature-availability). + +## DefectDojo Pro (On-Premise) + +Bei [DefectDojo Pro (On-Premise)](/get_started/pro/onprem/) funktionieren die meisten Funktionen genau wie in der Cloud: Öffnen Sie **Settings > Feature Flags** und schalten Sie sie um. + +Eine kleine Anzahl von Funktionen wird stattdessen aus Ihrer Deployment-Konfiguration gelesen. Sie ändern, wie die Anwendung startet, und können daher nicht zur Laufzeit umgeschaltet werden. Diese erscheinen auf der Seite schreibgeschützt, mit der Kennzeichnung **Managed by deployment**, und nennen die Umgebungsvariable, die sie steuert, zum Beispiel `DD_V3_FEATURE_LOCATIONS` für [Locations](/asset_modelling/locations/pro__locations_overview/). + +Da diese Funktionen einen Neustart erfordern und sich einige davon nach der Aktivierung nicht mehr rückgängig machen lassen, prüfen Sie vor einer Änderung die jeweilige Dokumentation der Funktion. Mehrere lassen sich am besten mit Unterstützung des [DefectDojo Support](mailto:support@defectdojo.com) aktivieren. + +So ändern Sie eine dieser Funktionen: + +1. Setzen Sie die Umgebungsvariable in Ihrem DefectDojo-Deployment. Die Seite zeigt Ihnen an, welche Variable zu setzen ist. +2. Starten Sie DefectDojo neu, damit der neue Wert beim Start gelesen wird. +3. Laden Sie die Seite „Feature Flags" neu, um den neuen Status zu bestätigen. + +Da diese Werte beim Start gelesen werden, ist eine Änderung über die Benutzeroberfläche nicht möglich, und ein Umschalten in Ihrer Umgebung ohne Neustart hat keine Wirkung. + +Funktionen, die nur in der Cloud angeboten werden, erscheinen auf einer On-Premise-Instanz als **Unavailable on This Deployment**. Das ist so vorgesehen und kein Lizenzproblem. + +## Verfügbarkeit von Funktionen + +Die meisten Funktionen sind für beide Installationstypen verfügbar. Die Ausnahmen sind: + +| Feature | Availability | How it is controlled | +| --- | --- | --- | +| Request a New Connector | Nur [DefectDojo Pro (Cloud)](/get_started/pro/cloud/) | Seite „Feature Flags". Wird On-Premise als **Unavailable on This Deployment** angezeigt. | +| Locations | Beide | Seite „Feature Flags". Beachten Sie, dass sich Locations nach der Aktivierung nicht mehr deaktivieren lässt. Siehe [Locations Overview](/asset_modelling/locations/pro__locations_overview/). | +| Organization / Asset Relabeling | Beide | Seite „Feature Flags" für die Pro UI; die Classic UI, ihre URLs und generierte Berichte folgen der Deployment-Einstellung `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`. Siehe [oben](#organization--asset-relabeling). | + +Jede andere optionale Funktion wird sowohl in der Cloud als auch On-Premise direkt über die Seite „Feature Flags" umgeschaltet. + +## Feature Flags außerhalb der Benutzeroberfläche auslesen + +Sie müssen die Seite „Feature Flags" nicht öffnen, um herauszufinden, welche Funktionen aktiviert sind — der Status der Flags lässt sich auch programmgesteuert auslesen, was nützlich ist, wenn eine Automatisierung prüfen muss, ob eine Funktion verfügbar ist, bevor sie sich darauf verlässt. + +``` +GET /api/v2/defectdojo_information/feature_flags/ +``` + +Dies liefert ein JSON-Array mit einem Objekt pro Feature Flag. Neben `key`, `title` und `description` des Flags meldet jedes Objekt die Werte, die eine Automatisierung meist benötigt: `effective` (ob die Funktion für diese Instanz tatsächlich aktiviert ist), `default`, `application_value` (die eigene Einstellung der Instanz oder `null`, falls nicht gesetzt), `editable` sowie `locked_reason`, falls sich ein Flag nicht ändern lässt. Aus dem Produkt entfernte Flags werden nicht aufgeführt. + +Jeder **authentifizierte** Benutzer kann dies auslesen — eine Superuser-Rolle ist nicht erforderlich. Das genaue Antwortschema für Ihre Version finden Sie in der interaktiven API-Dokumentation Ihrer Instanz unter `/api/v2/oa3/swagger-ui/`, die aus dem laufenden Build generiert wird. Siehe auch die [API v2-Dokumentation](/automation/api/api-v2-docs/). + +Dieselbe schreibgeschützte Auflistung wird außerdem auf der `/api/mcp/`-Oberfläche der Instanz veröffentlicht, unter `/api/mcp/defectdojo_information/feature_flags/`. + +Dieser Endpunkt ist **schreibgeschützt (read-only)**. Eine Funktion zu aktivieren oder zu deaktivieren erfolgt weiterhin über die Seite „Feature Flags" oder — bei den oben genannten deployment-konfigurierten Funktionen — in Ihren Deployment-Einstellungen. + +## Häufig gestellte Fragen + +**Eine gewünschte Funktion steht nicht in der Liste.** +Die Liste zeigt nur optionale Funktionen. Funktionen, die immer aktiviert sind, erscheinen nicht. Falls Sie eine fehlende Funktion erwartet haben, prüfen Sie, ob Ihre Lizenz sie enthält, und wenden Sie sich dann an den [DefectDojo Support](mailto:support@defectdojo.com). + +**Ich habe eine Funktion aktiviert, sehe sie aber nicht.** +Laden Sie die Seite neu — Menüeinträge und Routen werden beim Laden der Seite ausgewertet, sodass eine neu aktivierte Funktion erst beim nächsten Laden erscheint und nicht sofort in der aktuellen Ansicht. + +**Ändert ein Upgrade meine Einstellungen?** +Nein. Ein Upgrade behält die aktivierten und die deaktivierten Funktionen bei. diff --git a/docs/content/admin/feature_flags/PRO__feature_flags.es.md b/docs/content/admin/feature_flags/PRO__feature_flags.es.md new file mode 100644 index 00000000000..6923e77f265 --- /dev/null +++ b/docs/content/admin/feature_flags/PRO__feature_flags.es.md @@ -0,0 +1,143 @@ +--- +title: Feature Flags +description: Active y desactive funciones opcionales de DefectDojo Pro desde la interfaz + de DefectDojo +weight: 1 +audience: pro +--- + +Feature Flags le permite activar y desactivar funciones opcionales de DefectDojo Pro para su propia instancia — funciones que antes solo podían habilitarse contactando con el equipo de soporte de DefectDojo ahora se pueden autogestionar desde la interfaz. + +La página de Feature Flags solo es visible para **superusuarios**. El resto de usuarios, incluidos los Propietarios globales, no la ven. + +## Cómo abrir la página de Feature Flags + +Vaya a **Settings > Feature Flags** en la barra lateral izquierda. + +La página enumera todas las funciones opcionales con: + +* **Name** — la función, con una etiqueta **BETA** cuando aún está en fase beta +* **Description** — qué hace la función +* **Documentation link** — dónde existe documentación para esa función +* **Toggle** — si la función está actualmente activada + +Use el cuadro de búsqueda para filtrar la lista por nombre o descripción de la función. + +### Funciones que no aparecen en la lista + +La página enumera las funciones que usted puede optar por adoptar. Hay dos tipos de función que están ausentes de ella. + +**Siempre activas.** Cuando una función alcanza la disponibilidad general, queda activada para todas las instancias y deja de aparecer en la lista, porque ya no hay ninguna decisión que tomar: + +* **Downstream Connectors** — consulte [Downstream Connectors](/connectors/downstream/about/) +* **Universal Parser** — consulte [Universal Parser](/import_data/pro/specialized_import/universal_parser/) +* **Asset Hierarchy** — consulte [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/) +* **Appearance** y **Feature Flags** — las dos páginas de Settings con ese mismo nombre + +Nada cambia para su instancia si ya tenía una de estas funciones activada. Si la tenía desactivada, ahora está activa: estas funciones forman parte de DefectDojo Pro en lugar de ser opcionales. Contacte con [DefectDojo Support](mailto:support@defectdojo.com) si esto supone un problema para su instancia. + +**Habilitadas por DefectDojo a solicitud.** Algunas funciones dependen de infraestructura que se aprovisiona por instancia, por lo que las activa DefectDojo en lugar de hacerlo desde esta página: + +* **Scheduling Service** — consulte [Scheduling Rules](/automation/rules_engine/scheduling/) + +Contacte con [DefectDojo Support](mailto:support@defectdojo.com) para que se le habilite alguna de estas funciones. Si ya está activa en su instancia, permanece activa. + +## Activar o desactivar una función + +1. Busque la función en la lista. +2. Haga clic en su interruptor. +3. El cambio surte efecto de inmediato. Los demás usuarios lo verán reflejado en su siguiente carga de página. + +Algunas funciones muestran un cuadro de diálogo de confirmación antes de aplicar el cambio. Esto ocurre al habilitar una función que conlleva una advertencia (por ejemplo, una que requiere un reinicio o que puede afectar a datos existentes), o una que no se puede volver a desactivar. + +Desactivar una función normalmente es simplemente el proceso inverso de activarla. Las excepciones se indican en [Cuándo un interruptor está bloqueado](#when-a-toggle-is-locked). + +### Organization / Asset Relabeling + +**Organization / Asset Relabeling** cambia el nombre de "Product Type" a "Organization" y de "Product" a "Asset". Está activada de forma predeterminada y se activa o desactiva desde esta página como cualquier otra función, pero conviene saber qué partes de DefectDojo gobierna: + +* La **Pro UI** sigue este interruptor. Las nuevas etiquetas aparecen en su siguiente carga de página. +* Las páginas de la **Classic UI**, sus URL y los informes generados toman su nomenclatura de la configuración de despliegue `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` (también activada de forma predeterminada), que se lee cuando DefectDojo se inicia. Este interruptor no las modifica, y reiniciar tampoco hace que las modifique. + +El interruptor almacenado se inicializó a partir de esa configuración de despliegue, de modo que ambos coinciden hasta que usted cambie uno de ellos. Si desactiva el cambio de nombre aquí y además usa la Classic UI, establezca `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL=False` en su despliegue y reinicie para que ambas superficies coincidan. En [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), contacte con [DefectDojo Support](mailto:support@defectdojo.com) para que se le cambie la configuración de despliegue. + +Por este motivo, la función lleva una etiqueta **Restart Recommended** en la página de Feature Flags: la nomenclatura usada fuera de la Pro UI queda fijada cuando arranca el proceso. El cambio de nombre es cosmético en cualquier caso. Los modelos de base de datos, los nombres de campo y los endpoints de la API no cambian, por lo que la automatización existente sigue funcionando. Consulte [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/). + +## Cuándo un interruptor está bloqueado + +Una función que usted no puede cambiar se muestra con una insignia de candado que explica el motivo: + +| Badge | What it means | What to do | +| --- | --- | --- | +| **Managed by DefectDojo** | DefectDojo ha configurado esta función de forma centralizada para su instancia. Su configuración no puede anularla. | Contacte con [DefectDojo Support](mailto:support@defectdojo.com) si necesita que se cambie. | +| **Unavailable on This Deployment** | La función no se ofrece en su tipo de instalación. Consulte [Disponibilidad de funciones](#feature-availability) más abajo. | Nada. La función no es aplicable a su instancia. | +| **Cannot Be Disabled** | La función ya está activada y es de un solo sentido. No existe ningún mecanismo para revertirla. | Nada. Esto es lo esperado. | +| **Managed by deployment** | La función está controlada por su configuración de despliegue en lugar de por esta página. | Consulte [DefectDojo Pro (On-Premise)](#defectdojo-pro-on-premise) más abajo. | + +## DefectDojo Pro (Cloud) + +En [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), **Settings > Feature Flags** es el único lugar que necesita. Active una función y quedará operativa de inmediato. + +Hay dos cosas que gestiona DefectDojo en lugar de usted: + +* **Managed by DefectDojo** — la función está fijada de forma centralizada. Contacte con [DefectDojo Support](mailto:support@defectdojo.com) para que se le cambie. +* **Managed by deployment** — la función forma parte de cómo se aprovisiona su instancia. Contacte también con Soporte para estos casos, ya que las instancias Cloud no exponen la configuración de despliegue a los clientes. + +Las instancias Cloud también tienen acceso a funciones que no se ofrecen on-premise. Consulte [Disponibilidad de funciones](#feature-availability). + +## DefectDojo Pro (On-Premise) + +En [DefectDojo Pro (On-Premise)](/get_started/pro/onprem/), la mayoría de las funciones funcionan exactamente igual que en Cloud: abra **Settings > Feature Flags** y actívelas o desactívelas. + +Un pequeño número de funciones se leen en cambio desde su configuración de despliegue. Estas cambian la forma en que arranca la aplicación, por lo que no se pueden alternar en tiempo de ejecución. Aparecen en la página como de solo lectura, etiquetadas como **Managed by deployment**, e indican el nombre de la variable de entorno que las controla, por ejemplo `DD_V3_FEATURE_LOCATIONS` para [Locations](/asset_modelling/locations/pro__locations_overview/). + +Dado que estas funciones requieren un reinicio, y que algunas no se pueden revertir una vez habilitadas, consulte la documentación propia de la función antes de cambiar alguna. Varias de ellas es mejor habilitarlas con ayuda de [DefectDojo Support](mailto:support@defectdojo.com). + +Para cambiar una de esas funciones: + +1. Establezca la variable de entorno en su despliegue de DefectDojo. La página le indica qué variable establecer. +2. Reinicie DefectDojo para que el nuevo valor se lea en el arranque. +3. Vuelva a cargar la página de Feature Flags para confirmar el nuevo estado. + +Dado que estos valores se leen en el arranque, no es posible cambiarlos desde la interfaz, y alternarlos en su entorno sin reiniciar no tiene ningún efecto. + +Las funciones que se ofrecen solo en Cloud aparecen como **Unavailable on This Deployment** en una instancia on-premise. Esto es lo esperado y no es un problema de licencia. + +## Disponibilidad de funciones + +La mayoría de las funciones están disponibles en ambos tipos de instalación. Las excepciones son: + +| Feature | Availability | How it is controlled | +| --- | --- | --- | +| Request a New Connector | Solo [DefectDojo Pro (Cloud)](/get_started/pro/cloud/) | Página de Feature Flags. Se muestra como **Unavailable on This Deployment** en on-premise. | +| Locations | Ambos | Página de Feature Flags. Tenga en cuenta que Locations no se puede volver a desactivar una vez habilitada. Consulte [Locations Overview](/asset_modelling/locations/pro__locations_overview/). | +| Organization / Asset Relabeling | Ambos | Página de Feature Flags para la Pro UI; la Classic UI, sus URL y los informes generados siguen la configuración de despliegue `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`. Consulte [arriba](#organization--asset-relabeling). | + +El resto de funciones opcionales se activan directamente en la página de Feature Flags tanto en instancias Cloud como On-Premise. + +## Leer los feature flags fuera de la interfaz + +No es necesario abrir la página de Feature Flags para saber qué funciones están activadas — el estado de los flags también se puede leer mediante programación, lo cual resulta útil cuando la automatización necesita comprobar que una función está disponible antes de depender de ella. + +``` +GET /api/v2/defectdojo_information/feature_flags/ +``` + +Esto devuelve un array JSON con un objeto por cada feature flag. Junto a `key`, `title` y `description` del flag, cada objeto informa de los valores que la automatización suele necesitar: `effective` (si la función está realmente activa para esta instancia), `default`, `application_value` (la configuración propia de la instancia, o `null` si no está definida), `editable`, y `locked_reason` cuando un flag no se puede cambiar. Los flags retirados del producto se omiten. + +Cualquier usuario **autenticado** puede leerlo — no se requiere rol de superusuario. Para el esquema de respuesta exacto de su versión, consulte la documentación interactiva de la API de su instancia en `/api/v2/oa3/swagger-ui/`, que se genera a partir de la compilación en ejecución. Consulte también la [documentación de la API v2](/automation/api/api-v2-docs/). + +El mismo listado de solo lectura también se publica en la superficie `/api/mcp/` de la instancia, en `/api/mcp/defectdojo_information/feature_flags/`. + +Este endpoint es de **solo lectura**. Activar o desactivar una función se sigue haciendo desde la página de Feature Flags, o bien — para las funciones configuradas por despliegue mencionadas anteriormente — en su configuración de despliegue. + +## Preguntas frecuentes + +**No encuentro en la lista una función que busco.** +La lista muestra únicamente funciones opcionales. Las funciones que están siempre activas no aparecen. Si esperaba encontrar una función que falta, confirme que su licencia la incluye y, a continuación, contacte con [DefectDojo Support](mailto:support@defectdojo.com). + +**Activé una función pero no la veo.** +Vuelva a cargar la página — las entradas de menú y las rutas se evalúan cuando la página se carga, de modo que una función recién habilitada aparece en la siguiente carga en lugar de al instante en la vista actual. + +**¿Actualizar la versión cambiará mi configuración?** +No. Actualizar conserva las funciones que ha activado y las que ha desactivado. diff --git a/docs/content/admin/feature_flags/PRO__feature_flags.fr.md b/docs/content/admin/feature_flags/PRO__feature_flags.fr.md new file mode 100644 index 00000000000..1e23908d67f --- /dev/null +++ b/docs/content/admin/feature_flags/PRO__feature_flags.fr.md @@ -0,0 +1,143 @@ +--- +title: Indicateurs de fonctionnalités +description: Activez et désactivez les fonctionnalités optionnelles de DefectDojo + Pro depuis l'interface de DefectDojo +weight: 1 +audience: pro +--- + +Les indicateurs de fonctionnalités vous permettent d'activer et de désactiver les fonctionnalités optionnelles de DefectDojo Pro sur votre propre instance — des fonctionnalités qu'il fallait auparavant activer en contactant le support DefectDojo peuvent désormais être gérées en libre-service depuis l'interface. + +La page Indicateurs de fonctionnalités n'est visible que par les **superutilisateurs**. Les autres utilisateurs, y compris les propriétaires globaux, ne la voient pas. + +## Ouvrir la page Indicateurs de fonctionnalités + +Accédez à **Settings > Feature Flags** dans la barre latérale gauche. + +La page répertorie chaque fonctionnalité optionnelle avec : + +* **Nom** — la fonctionnalité, avec une étiquette **BETA** lorsqu'elle est encore en bêta +* **Description** — ce que fait la fonctionnalité +* **Lien vers la documentation** — s'il existe une documentation pour cette fonctionnalité +* **Interrupteur** — indique si la fonctionnalité est actuellement activée + +Utilisez le champ de recherche pour filtrer la liste par nom de fonctionnalité ou par description. + +### Fonctionnalités non répertoriées + +La page répertorie les fonctionnalités que vous pouvez choisir d'adopter. Deux types de fonctionnalités en sont absents. + +**Toujours activées.** Une fois qu'une fonctionnalité atteint la disponibilité générale, elle est activée pour toutes les instances et cesse d'être répertoriée, car il n'y a plus de décision à prendre : + +* **Downstream Connectors** — voir [Downstream Connectors](/connectors/downstream/about/) +* **Universal Parser** — voir [Universal Parser](/import_data/pro/specialized_import/universal_parser/) +* **Asset Hierarchy** — voir [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/) +* **Appearance** et **Feature Flags** — les deux pages de Paramètres portant ce nom + +Rien ne change pour votre instance si l'une de ces fonctionnalités était déjà activée. Si l'une d'elles était désactivée, elle est désormais activée : ces fonctionnalités font désormais partie intégrante de DefectDojo Pro plutôt que d'être optionnelles. Contactez le [support DefectDojo](mailto:support@defectdojo.com) si cela pose problème pour votre instance. + +**Activées par DefectDojo sur demande.** Quelques fonctionnalités dépendent d'une infrastructure provisionnée par instance ; elles sont donc activées par DefectDojo plutôt que depuis cette page : + +* **Scheduling Service** — voir [Scheduling Rules](/automation/rules_engine/scheduling/) + +Contactez le [support DefectDojo](mailto:support@defectdojo.com) pour faire activer l'une de ces fonctionnalités. Si elle est déjà activée sur votre instance, elle le reste. + +## Activer ou désactiver une fonctionnalité + +1. Trouvez la fonctionnalité dans la liste. +2. Cliquez sur son interrupteur. +3. Le changement prend effet immédiatement. Les autres utilisateurs le voient au prochain chargement de la page. + +Certaines fonctionnalités affichent une boîte de dialogue de confirmation avant l'application du changement. C'est le cas lors de l'activation d'une fonctionnalité comportant un avertissement (par exemple une fonctionnalité nécessitant un redémarrage ou pouvant affecter des données existantes), ou d'une fonctionnalité qui ne peut plus être désactivée ensuite. + +Désactiver une fonctionnalité consiste normalement simplement à inverser son activation. Les exceptions sont signalées dans [Quand un interrupteur est verrouillé](#when-a-toggle-is-locked). + +### Renommage Organisation / Actif + +**Renommage Organisation / Actif** renomme « Product Type » en « Organization » et « Product » en « Asset ». Cette fonctionnalité est activée par défaut et se bascule depuis cette page comme toute autre fonctionnalité, mais il est utile de savoir quelles parties de DefectDojo elle régit : + +* L'**interface Pro** suit cet interrupteur. Les nouveaux libellés apparaissent au prochain chargement de la page. +* Les pages de l'**interface classique**, leurs URL et les rapports générés tirent leur dénomination du paramètre de déploiement `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` (également activé par défaut), qui est lu au démarrage de DefectDojo. Cet interrupteur ne les modifie pas, et un redémarrage ne les fait pas non plus changer. + +L'interrupteur enregistré a été initialisé à partir de ce paramètre de déploiement, les deux restent donc synchronisés tant que vous n'en modifiez pas un. Si vous désactivez le renommage ici et que vous utilisez également l'interface classique, définissez `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL=False` sur votre déploiement et redémarrez afin que les deux interfaces correspondent. Sur [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), contactez le [support DefectDojo](mailto:support@defectdojo.com) pour faire modifier ce paramètre de déploiement. + +C'est pour cette raison que la fonctionnalité porte une étiquette **Restart Recommended** sur la page Indicateurs de fonctionnalités : la dénomination utilisée en dehors de l'interface Pro est figée au démarrage du processus. Dans tous les cas, le renommage est purement cosmétique. Les modèles de base de données, les noms de champs et les points de terminaison de l'API restent inchangés, si bien que l'automatisation existante continue de fonctionner. Voir [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/). + +## Quand un interrupteur est verrouillé + +Une fonctionnalité que vous ne pouvez pas modifier s'affiche avec un badge de verrouillage expliquant pourquoi : + +| Badge | Signification | Action à mener | +| --- | --- | --- | +| **Managed by DefectDojo** | DefectDojo a défini cette fonctionnalité de manière centralisée pour votre instance. Votre paramètre ne peut pas la remplacer. | Contactez le [support DefectDojo](mailto:support@defectdojo.com) si vous avez besoin d'un changement. | +| **Unavailable on This Deployment** | La fonctionnalité n'est pas proposée pour votre type d'installation. Voir [Feature availability](#feature-availability) ci-dessous. | Rien. La fonctionnalité ne s'applique pas à votre instance. | +| **Cannot Be Disabled** | La fonctionnalité est déjà activée et l'opération est à sens unique. Il n'existe aucun mécanisme pour revenir en arrière. | Rien. C'est normal. | +| **Managed by deployment** | La fonctionnalité est contrôlée par votre configuration de déploiement plutôt que par cette page. | Voir [DefectDojo Pro (On-Premise)](#defectdojo-pro-on-premise) ci-dessous. | + +## DefectDojo Pro (Cloud) + +Sur [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), **Settings > Feature Flags** est le seul endroit dont vous avez besoin. Activez une fonctionnalité et elle est immédiatement en service. + +Deux éléments sont pris en charge par DefectDojo plutôt que par vous : + +* **Managed by DefectDojo** — la fonctionnalité est fixée de manière centralisée. Contactez le [support DefectDojo](mailto:support@defectdojo.com) pour la faire modifier. +* **Managed by deployment** — la fonctionnalité fait partie du mode de provisionnement de votre instance. Contactez également le support pour celles-ci, car les instances Cloud n'exposent pas la configuration de déploiement aux clients. + +Les instances Cloud ont également accès à des fonctionnalités qui ne sont pas proposées sur site. Voir [Feature availability](#feature-availability). + +## DefectDojo Pro (sur site) + +Sur [DefectDojo Pro (sur site)](/get_started/pro/onprem/), la plupart des fonctionnalités fonctionnent exactement comme sur le Cloud : ouvrez **Settings > Feature Flags** et activez-les. + +Un petit nombre de fonctionnalités sont plutôt lues depuis votre configuration de déploiement. Elles modifient la façon dont l'application démarre, et ne peuvent donc pas être basculées à l'exécution. Elles apparaissent sur la page en lecture seule, étiquetées **Managed by deployment**, avec le nom de la variable d'environnement qui les contrôle, par exemple `DD_V3_FEATURE_LOCATIONS` pour [Locations](/asset_modelling/locations/pro__locations_overview/). + +Comme ces fonctionnalités nécessitent un redémarrage, et que certaines d'entre elles ne peuvent pas être annulées une fois activées, consultez la documentation propre à la fonctionnalité avant d'en modifier une. Il est préférable d'activer plusieurs d'entre elles avec l'aide du [support DefectDojo](mailto:support@defectdojo.com). + +Pour modifier l'une de ces fonctionnalités : + +1. Définissez la variable d'environnement sur votre déploiement DefectDojo. La page vous indique quelle variable définir. +2. Redémarrez DefectDojo afin que la nouvelle valeur soit lue au démarrage. +3. Rechargez la page Indicateurs de fonctionnalités pour confirmer le nouvel état. + +Comme ces valeurs sont lues au démarrage, il n'est pas possible de les modifier depuis l'interface, et les basculer dans votre environnement sans redémarrage n'a aucun effet. + +Les fonctionnalités proposées uniquement sur le Cloud apparaissent comme **Unavailable on This Deployment** sur une instance sur site. C'est normal et ce n'est pas un problème de licence. + +## Disponibilité des fonctionnalités + +La plupart des fonctionnalités sont disponibles pour les deux types d'installation. Voici les exceptions : + +| Fonctionnalité | Disponibilité | Mode de contrôle | +| --- | --- | --- | +| Request a New Connector | [DefectDojo Pro (Cloud)](/get_started/pro/cloud/) uniquement | Page Indicateurs de fonctionnalités. Affichée comme **Unavailable on This Deployment** sur site. | +| Locations | Les deux | Page Indicateurs de fonctionnalités. Notez que Locations ne peut plus être désactivée une fois activée. Voir [Locations Overview](/asset_modelling/locations/pro__locations_overview/). | +| Organization / Asset Relabeling | Les deux | Page Indicateurs de fonctionnalités pour l'interface Pro ; l'interface classique, ses URL et les rapports générés suivent le paramètre de déploiement `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`. Voir [ci-dessus](#organization--asset-relabeling). | + +Toutes les autres fonctionnalités optionnelles se basculent directement sur la page Indicateurs de fonctionnalités, aussi bien sur les instances Cloud que sur site. + +## Lire les indicateurs de fonctionnalités en dehors de l'interface + +Il n'est pas nécessaire d'ouvrir la page Indicateurs de fonctionnalités pour savoir quelles fonctionnalités sont activées — l'état des indicateurs peut aussi être lu par programmation, ce qui est utile lorsqu'une automatisation doit vérifier qu'une fonctionnalité est disponible avant d'en dépendre. + +``` +GET /api/v2/defectdojo_information/feature_flags/ +``` + +Cela renvoie un tableau JSON contenant un objet par indicateur de fonctionnalité. Outre les champs `key`, `title` et `description` de l'indicateur, chaque objet fournit les valeurs habituellement utiles à l'automatisation : `effective` (indique si la fonctionnalité est réellement activée pour cette instance), `default`, `application_value` (le paramètre propre à l'instance, ou `null` s'il n'est pas défini), `editable`, et `locked_reason` lorsqu'un indicateur ne peut pas être modifié. Les indicateurs retirés du produit sont omis. + +Tout utilisateur **authentifié** peut le lire — aucun rôle de superutilisateur n'est requis. Pour le schéma exact de la réponse sur votre version, consultez la documentation API interactive de votre instance à l'adresse `/api/v2/oa3/swagger-ui/`, générée à partir de la version en cours d'exécution. Voir aussi la [documentation de l'API v2](/automation/api/api-v2-docs/). + +La même liste en lecture seule est également publiée sur la surface `/api/mcp/` de l'instance, à l'adresse `/api/mcp/defectdojo_information/feature_flags/`. + +Ce point de terminaison est en **lecture seule**. L'activation ou la désactivation d'une fonctionnalité se fait toujours depuis la page Indicateurs de fonctionnalités, ou — pour les fonctionnalités configurées au niveau du déploiement mentionnées ci-dessus — dans vos paramètres de déploiement. + +## Questions fréquentes + +**Une fonctionnalité que je souhaite n'est pas dans la liste.** +La liste ne présente que les fonctionnalités optionnelles. Les fonctionnalités toujours activées n'y figurent pas. Si vous vous attendiez à voir une fonctionnalité manquante, vérifiez que votre licence l'inclut, puis contactez le [support DefectDojo](mailto:support@defectdojo.com). + +**J'ai activé une fonctionnalité mais je ne la vois pas.** +Rechargez la page — les entrées de menu et les routes sont évaluées au chargement de la page, si bien qu'une fonctionnalité nouvellement activée apparaît au chargement suivant plutôt qu'instantanément dans la vue actuelle. + +**Une mise à niveau modifiera-t-elle mes paramètres ?** +Non. La mise à niveau conserve les fonctionnalités que vous avez activées et celles que vous avez désactivées. diff --git a/docs/content/admin/feature_flags/PRO__feature_flags.ja.md b/docs/content/admin/feature_flags/PRO__feature_flags.ja.md new file mode 100644 index 00000000000..e6304c2d3f1 --- /dev/null +++ b/docs/content/admin/feature_flags/PRO__feature_flags.ja.md @@ -0,0 +1,142 @@ +--- +title: 機能フラグ +description: DefectDojo UIからDefectDojo Proのオプション機能のオン/オフを切り替える +weight: 1 +audience: pro +--- + +機能フラグを使うと、自分のインスタンス上でDefectDojo Proのオプション機能のオン/オフを切り替えることができます。これまではDefectDojoサポートに連絡しなければ有効化できなかった機能を、UIからセルフサービスで有効化できるようになりました。 + +機能フラグページは**スーパーユーザー**のみに表示されます。グローバルオーナーを含む他のユーザーには表示されません。 + +## 機能フラグページを開く + +左サイドバーの**Settings > Feature Flags**に移動します。 + +このページには、すべてのオプション機能が以下の情報とともに一覧表示されます。 + +* **Name**(名前) — 機能名。まだベータ版の場合は**BETA**タグが付きます +* **Description**(説明) — その機能が何をするか +* **Documentation link**(ドキュメントリンク) — その機能のドキュメントがある場所 +* **Toggle**(トグル) — 現在オンになっているかどうか + +検索ボックスを使うと、機能名や説明で一覧を絞り込めます。 + +### 一覧に表示されない機能 + +このページには、選択して導入できる機能が一覧表示されます。2種類の機能はここには表示されません。 + +**常時オン。** 機能が一般提供(GA)に達すると、すべてのインスタンスでオンになり、選択の余地がなくなるため一覧から外れます。 + +* **Downstream Connectors** — [Downstream Connectors](/connectors/downstream/about/)を参照 +* **Universal Parser** — [Universal Parser](/import_data/pro/specialized_import/universal_parser/)を参照 +* **Asset Hierarchy** — [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/)を参照 +* **Appearance**と**Feature Flags** — 同名の2つのSettingsページ + +これらの機能をすでにオンにしていた場合、インスタンスに変化はありません。オフにしていた場合は、現在はオンになっています。これらの機能はオプトインではなく、DefectDojo Proの一部となったためです。インスタンスにとって問題がある場合は、[DefectDojo Support](mailto:support@defectdojo.com)にお問い合わせください。 + +**依頼に応じてDefectDojoが有効化。** 一部の機能はインスタンスごとにプロビジョニングされるインフラに依存するため、このページからではなくDefectDojoによって有効化されます。 + +* **Scheduling Service** — [Scheduling Rules](/automation/rules_engine/scheduling/)を参照 + +これらの機能を有効化するには[DefectDojo Support](mailto:support@defectdojo.com)にお問い合わせください。すでにインスタンスでオンになっている場合は、そのままオンの状態が維持されます。 + +## 機能のオン/オフを切り替える + +1. 一覧から該当の機能を見つけます。 +2. トグルをクリックします。 +3. 変更は即座に反映されます。他のユーザーには、次回のページ読み込み時に変更が反映されます。 + +一部の機能では、変更が適用される前に確認ダイアログが表示されます。これは、警告が伴う機能(たとえば再起動が必要なものや、既存データに影響する可能性があるもの)や、一度オンにすると元に戻せない機能を有効化する場合に発生します。 + +機能をオフにする操作は、通常はオンにする操作の逆にすぎません。例外については[トグルがロックされている場合](#when-a-toggle-is-locked)で説明します。 + +### Organization / Asset Relabeling + +**Organization / Asset Relabeling**は、「Product Type」を「Organization」に、「Product」を「Asset」にリネームします。デフォルトでオンになっており、他の機能と同様にこのページから切り替えられますが、DefectDojoのどの部分がこのトグルの対象になるかを知っておく価値があります。 + +* **Pro UI**はこのトグルに従います。新しいラベルは次回のページ読み込み時に表示されます。 +* **Classic UI**のページ、そのURL、生成されるレポートの命名は、DefectDojoの起動時に読み込まれる`DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`デプロイ設定(こちらもデフォルトでオン)に従います。このトグルはそれらを変更せず、再起動してもそれらは変わりません。 + +保存されているトグルはそのデプロイ設定から初期値を引き継いでいるため、どちらか一方を変更するまでは両者は一致しています。ここでリネームをオフにし、Classic UIも使用している場合は、デプロイ側で`DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL=False`を設定し、再起動して両方の画面を一致させてください。[DefectDojo Pro (Cloud)](/get_started/pro/cloud/)では、デプロイ設定の変更について[DefectDojo Support](mailto:support@defectdojo.com)にお問い合わせください。 + +この機能に機能フラグページで**Restart Recommended**(再起動推奨)タグが付いているのはこのためです。Pro UI以外で使われる名称は、プロセスの起動時に確定します。いずれにせよリネームは見た目だけのものです。データベースモデル、フィールド名、APIエンドポイントは変更されないため、既存の自動化は引き続き動作します。[Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/)を参照してください。 + +## When a toggle is locked + +変更できない機能には、その理由を説明するロックバッジが表示されます。 + +| Badge | What it means | What to do | +| --- | --- | --- | +| **Managed by DefectDojo** | DefectDojoがこの機能をインスタンスに対して一元的に設定しています。ユーザー側の設定で上書きすることはできません。 | 変更が必要な場合は[DefectDojo Support](mailto:support@defectdojo.com)にお問い合わせください。 | +| **Unavailable on This Deployment** | この機能はお使いのインストール形態では提供されていません。詳細は下記の[Feature availability](#feature-availability)を参照してください。 | 対応不要です。この機能はインスタンスに適用されません。 | +| **Cannot Be Disabled** | この機能はすでにオンになっており、一方向のみの変更です。元に戻す手段はありません。 | 対応不要です。これは想定された動作です。 | +| **Managed by deployment** | この機能はこのページではなく、デプロイ設定によって制御されます。 | 下記の[DefectDojo Pro (On-Premise)](#defectdojo-pro-on-premise)を参照してください。 | + +## DefectDojo Pro (Cloud) + +[DefectDojo Pro (Cloud)](/get_started/pro/cloud/)では、**Settings > Feature Flags**だけで完結します。機能をオンに切り替えれば、その場で有効になります。 + +次の2つはユーザーではなくDefectDojoが対応します。 + +* **Managed by DefectDojo** — 機能が一元的に固定されています。変更するには[DefectDojo Support](mailto:support@defectdojo.com)にお問い合わせください。 +* **Managed by deployment** — 機能はインスタンスのプロビジョニング方法の一部です。Cloudインスタンスではデプロイ設定が顧客に公開されないため、こちらについてもSupportにお問い合わせください。 + +Cloudインスタンスでは、オンプレミスでは提供されていない機能も利用できます。詳細は[Feature availability](#feature-availability)を参照してください。 + +## DefectDojo Pro (On-Premise) + +[DefectDojo Pro (On-Premise)](/get_started/pro/onprem/)では、ほとんどの機能はCloudとまったく同じように動作します。**Settings > Feature Flags**を開いて切り替えるだけです。 + +ごく一部の機能は、代わりにデプロイ設定から読み込まれます。これらはアプリケーションの起動方法を変えるため、実行時に切り替えることはできません。ページ上では読み取り専用として表示され、**Managed by deployment**というラベルが付き、それを制御する環境変数の名前(たとえば[Locations](/asset_modelling/locations/pro__locations_overview/)の場合は`DD_V3_FEATURE_LOCATIONS`)が示されます。 + +これらの機能は再起動が必要であり、一部は一度有効にすると元に戻せないため、変更する前にその機能自体のドキュメントを確認してください。いくつかは[DefectDojo Support](mailto:support@defectdojo.com)の支援を受けて有効化するのが最善です。 + +これらの機能のいずれかを変更するには、 + +1. DefectDojoのデプロイで環境変数を設定します。設定すべき変数はページに表示されます。 +2. DefectDojoを再起動し、新しい値が起動時に読み込まれるようにします。 +3. 機能フラグページを再読み込みし、新しい状態を確認します。 + +これらの値は起動時に読み込まれるため、UI上で変更することはできず、再起動せずに環境で切り替えても効果はありません。 + +Cloudでのみ提供されている機能は、オンプレミスインスタンスでは**Unavailable on This Deployment**と表示されます。これは想定された動作であり、ライセンスの問題ではありません。 + +## Feature availability + +ほとんどの機能はどちらのインストール形態でも利用できます。例外は以下のとおりです。 + +| Feature | Availability | How it is controlled | +| --- | --- | --- | +| Request a New Connector | [DefectDojo Pro (Cloud)](/get_started/pro/cloud/)のみ | 機能フラグページ。オンプレミスでは**Unavailable on This Deployment**と表示されます。 | +| Locations | 両方 | 機能フラグページ。Locationsは一度有効にすると元に戻せない点に注意してください。[Locations Overview](/asset_modelling/locations/pro__locations_overview/)を参照してください。 | +| Organization / Asset Relabeling | 両方 | Pro UIについては機能フラグページ。Classic UI、そのURL、生成されるレポートは`DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`デプロイ設定に従います。[上記](#organization--asset-relabeling)を参照してください。 | + +その他のオプション機能はすべて、CloudとOn-Premiseの両インスタンスで機能フラグページから直接切り替えられます。 + +## UIの外から機能フラグを読み取る + +どの機能が有効になっているかを確認するために機能フラグページを開く必要はありません。フラグの状態はプログラムからも読み取れるため、自動化がある機能に依存する前にその可用性を確認したい場合に便利です。 + +``` +GET /api/v2/defectdojo_information/feature_flags/ +``` + +これは機能フラグごとに1つのオブジェクトを持つJSON配列を返します。各オブジェクトには、フラグの`key`、`title`、`description`に加えて、自動化が通常必要とする値、すなわち`effective`(このインスタンスで実際にオンになっているか)、`default`、`application_value`(インスタンス独自の設定。未設定の場合は`null`)、`editable`、そしてフラグを変更できない場合の`locked_reason`が含まれます。製品から廃止されたフラグは含まれません。 + +**認証済み**であればどのユーザーでも読み取ることができ、スーパーユーザー権限は不要です。お使いのバージョンでの正確なレスポンススキーマについては、実行中のビルドから生成されるインスタンスのインタラクティブAPIドキュメント`/api/v2/oa3/swagger-ui/`を参照してください。[API v2 documentation](/automation/api/api-v2-docs/)も参照してください。 + +同じ読み取り専用の一覧は、インスタンスの`/api/mcp/`エンドポイント`/api/mcp/defectdojo_information/feature_flags/`でも公開されています。 + +このエンドポイントは**読み取り専用**です。機能のオン/オフの切り替えは、引き続き機能フラグページから、あるいは前述のデプロイ設定される機能についてはデプロイ設定から行います。 + +## よくある質問 + +**使いたい機能が一覧にありません。** +この一覧にはオプション機能のみが表示されます。常時オンの機能は表示されません。表示されるはずの機能が見当たらない場合は、ライセンスにその機能が含まれているかを確認したうえで、[DefectDojo Support](mailto:support@defectdojo.com)にお問い合わせください。 + +**機能をオンにしたのに表示されません。** +ページを再読み込みしてください。メニュー項目やルートはページの読み込み時に評価されるため、新しく有効化した機能は現在の画面に即座には反映されず、次回の読み込み時に表示されます。 + +**アップグレードすると設定は変わりますか。** +いいえ。アップグレードしても、オンにした機能とオフにした機能はそのまま保持されます。 diff --git a/docs/content/admin/feature_flags/_index.de.md b/docs/content/admin/feature_flags/_index.de.md new file mode 100644 index 00000000000..417ee015eeb --- /dev/null +++ b/docs/content/admin/feature_flags/_index.de.md @@ -0,0 +1,23 @@ +--- +title: Feature Flags +description: Aktivieren und deaktivieren Sie optionale DefectDojo Pro-Funktionen für + Ihre Instanz +summary: '' +date: 2026-07-20 00:00:00+00:00 +lastmod: 2026-07-20 00:00:00+00:00 +draft: false +weight: 4 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +Viele Funktionen von DefectDojo Pro werden hinter einem Feature Flag ausgeliefert, sodass Sie sie übernehmen können, wenn Sie bereit dafür sind, statt bereits mit dem Release, das sie einführt. + +Feature Flags sind eine Funktion von DefectDojo Pro. Open-Source-DefectDojo verfügt über keine Feature-Flag-Oberfläche. + +* [Feature Flags](./pro__feature_flags/) — zeigen Sie jede optionale Funktion an, aktivieren und deaktivieren Sie Funktionen und erfahren Sie, warum eine Funktion auf Ihrer Instanz möglicherweise nicht verfügbar ist. diff --git a/docs/content/admin/feature_flags/_index.es.md b/docs/content/admin/feature_flags/_index.es.md new file mode 100644 index 00000000000..258768ef82a --- /dev/null +++ b/docs/content/admin/feature_flags/_index.es.md @@ -0,0 +1,22 @@ +--- +title: Feature Flags +description: Active y desactive funciones opcionales de DefectDojo Pro para su instancia +summary: '' +date: 2026-07-20 00:00:00+00:00 +lastmod: 2026-07-20 00:00:00+00:00 +draft: false +weight: 4 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +Muchas funciones de DefectDojo Pro se publican detrás de un feature flag, de modo que pueda adoptarlas cuando esté listo en lugar de tener que hacerlo en la versión que las introduce. + +Feature Flags es una función de DefectDojo Pro. DefectDojo de código abierto no dispone de una superficie de feature flags. + +* [Feature Flags](./pro__feature_flags/) — vea todas las funciones opcionales, active y desactive funciones, y entienda por qué una función podría no estar disponible en su instancia. diff --git a/docs/content/admin/feature_flags/_index.fr.md b/docs/content/admin/feature_flags/_index.fr.md new file mode 100644 index 00000000000..e19af16f9c3 --- /dev/null +++ b/docs/content/admin/feature_flags/_index.fr.md @@ -0,0 +1,23 @@ +--- +title: Indicateurs de fonctionnalités +description: Activez et désactivez les fonctionnalités optionnelles de DefectDojo + Pro pour votre instance +summary: '' +date: 2026-07-20 00:00:00+00:00 +lastmod: 2026-07-20 00:00:00+00:00 +draft: false +weight: 4 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +De nombreuses fonctionnalités de DefectDojo Pro sont livrées derrière un indicateur de fonctionnalité, afin que vous puissiez les adopter quand vous êtes prêt plutôt qu'au moment de la version qui les introduit. + +Les indicateurs de fonctionnalités sont une fonctionnalité de DefectDojo Pro. DefectDojo open source ne dispose pas d'une telle interface. + +* [Feature Flags](./pro__feature_flags/) — consultez chaque fonctionnalité optionnelle, activez et désactivez les fonctionnalités, et comprenez pourquoi une fonctionnalité pourrait être indisponible sur votre instance. diff --git a/docs/content/admin/feature_flags/_index.ja.md b/docs/content/admin/feature_flags/_index.ja.md new file mode 100644 index 00000000000..1cd946ee70a --- /dev/null +++ b/docs/content/admin/feature_flags/_index.ja.md @@ -0,0 +1,22 @@ +--- +title: 機能フラグ +description: インスタンスでDefectDojo Proのオプション機能のオン/オフを切り替える +summary: '' +date: 2026-07-20 00:00:00+00:00 +lastmod: 2026-07-20 00:00:00+00:00 +draft: false +weight: 4 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +多くのDefectDojo Pro機能は機能フラグの背後で提供されるため、導入されたリリースのタイミングではなく、準備が整ったときに採用できます。 + +機能フラグはDefectDojo Proの機能です。オープンソース版のDefectDojoには機能フラグの画面はありません。 + +* [Feature Flags](./pro__feature_flags/) — すべてのオプション機能を確認し、機能のオン/オフを切り替え、機能がインスタンスで利用できない理由を理解できます。 diff --git a/docs/content/admin/notifications/_index.de.md b/docs/content/admin/notifications/_index.de.md new file mode 100644 index 00000000000..14362890ae0 --- /dev/null +++ b/docs/content/admin/notifications/_index.de.md @@ -0,0 +1,16 @@ +--- +title: Benachrichtigungen +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 7 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +exclude_search: true +--- diff --git a/docs/content/admin/notifications/_index.es.md b/docs/content/admin/notifications/_index.es.md new file mode 100644 index 00000000000..70e564cc248 --- /dev/null +++ b/docs/content/admin/notifications/_index.es.md @@ -0,0 +1,16 @@ +--- +title: Notificaciones +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 7 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +exclude_search: true +--- diff --git a/docs/content/admin/notifications/_index.fr.md b/docs/content/admin/notifications/_index.fr.md new file mode 100644 index 00000000000..888b95d91ae --- /dev/null +++ b/docs/content/admin/notifications/_index.fr.md @@ -0,0 +1,16 @@ +--- +title: Notifications +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 7 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +exclude_search: true +--- diff --git a/docs/content/admin/notifications/_index.ja.md b/docs/content/admin/notifications/_index.ja.md new file mode 100644 index 00000000000..5d158df1143 --- /dev/null +++ b/docs/content/admin/notifications/_index.ja.md @@ -0,0 +1,16 @@ +--- +title: 通知 +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 7 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +exclude_search: true +--- diff --git a/docs/content/admin/notifications/about_notifications.de.md b/docs/content/admin/notifications/about_notifications.de.md new file mode 100644 index 00000000000..f4c18b45e2c --- /dev/null +++ b/docs/content/admin/notifications/about_notifications.de.md @@ -0,0 +1,103 @@ +--- +title: Über Benachrichtigungen & 🔔 Warnungen +description: Erfahren Sie mehr über Benachrichtigungen und In-App-Warnungen +aliases: +- /de/en/customize_dojo/notifications/about_notifications +--- + +DefectDojo hält Sie auf verschiedene Weise auf dem Laufenden. Benachrichtigungen können für bevorstehende Engagements, [Benutzererwähnungen](/triage_findings/findings_workflows/intro_to_findings/#notes-and-mentions), ablaufende SLAs und andere Ereignisse in der Software gesendet werden. + +Dieser Artikel bietet einen Überblick über Benachrichtigungen sowohl auf systemweiter als auch auf persönlicher Ebene. + +## Benachrichtigungstypen + +DefectDojo behandelt Benachrichtigungen auf zwei unterschiedliche Arten: + +* **Systemweite Benachrichtigungen** werden an alle Benutzer gesendet. +* **Persönliche Benachrichtigungen werden von einzelnen Benutzern festgelegt und zusätzlich zu allen systemweiten Benachrichtigungen empfangen.** + +In beiden Fällen gelten die Regeln der [rollenbasierten Zugriffskontrolle](../../user_management/about_perms_and_roles/), sodass Benutzer keine Aktivitätsbenachrichtigungen für Produkte oder Produkttypen (oder deren zugehörige Objekte) erhalten, auf die sie keinen Zugriff haben. + +## Zustellmethoden für Benachrichtigungen + +Es gibt vier Zustellmethoden für DefectDojo-Benachrichtigungen: + +* DefectDojo kann **🔔 Warnungen** anzeigen, die als Liste in der DefectDojo-Oberfläche gespeichert werden +* DefectDojo kann Benachrichtigungen an eine **E-Mail**-Adresse senden +* DefectDojo kann Benachrichtigungen an **Slack** senden, entweder in einen gemeinsamen oder einen individuellen Kanal +* DefectDojo kann Benachrichtigungen außerdem an **Microsoft Teams** in einen gemeinsamen Kanal senden + +Benachrichtigungen können gleichzeitig an mehrere Ziele gesendet werden. + +Um Slack- und Teams-Benachrichtigungen zu empfangen, benötigen Sie eine funktionierende Integration. Weitere Informationen zur Einrichtung dieser Integration finden Sie in unserem [Leitfaden](../email_slack_teams). + +## In-App-Warnungen + +Das Warnungssystem von DefectDojo hält Sie über alle Produkt- oder Systemaktivitäten auf dem Laufenden. + +### Die Warnungsliste + +Die Warnungsliste ist immer in der oberen rechten Ecke von DefectDojo sichtbar und enthält eine kompakte Liste von Benachrichtigungen. Ein Klick auf eine Warnung führt Sie direkt zur entsprechenden Seite in DefectDojo. + +Sie können Ihre Warnungsliste öffnen, indem Sie auf das **🔔▼-Symbol** in der oberen rechten Ecke klicken: + +![image](images/About_In-App_Alerts.png) + +Um alle Ihre Benachrichtigungen mit zusätzlichen Details anzuzeigen, klicken Sie auf die Schaltfläche **Alle Warnungen anzeigen \>**, wodurch die **Warnungsseite** geöffnet wird. + +Sie können in der Warnungsliste auch **Alle Warnungen löschen \>**. + +### Die Warnungsseite + +Die Warnungsseite speichert alle Ihre Warnungen in DefectDojo mit zusätzlichen Details. Auf dieser Seite können Sie die Beschreibungen der einzelnen Warnungen in DefectDojo lesen und sie aus der Warnungswarteschlange entfernen, sobald Sie sie nicht mehr benötigen. + +![image](images/About_In-App_Alerts_2.png) + +Um eine oder mehrere Warnungen von der Warnungsseite zu entfernen, aktivieren Sie das leere Kästchen daneben und klicken Sie anschließend auf die Schaltfläche **Auswahl entfernen** in der unteren rechten Ecke der Seite. + +### Hinweise zu Warnungen + +* Das Lesen einer Warnung oder das Öffnen der Warnungsseite entfernt keine Warnungen aus der Zählung neben dem Glockensymbol. So können Sie problemlos auf frühere Warnungen zugreifen, um sie als Erinnerungen oder persönliches Aktivitätsprotokoll zu nutzen. +* Die Verwendung der Funktion **Alle Warnungen löschen \>** im Warnungsmenü löscht auch die **Warnungsseite** vollständig, verwenden Sie diese Funktion daher mit Vorsicht. +* Das Entfernen einer Warnung wirkt sich nur auf Ihre eigene Warnungsliste aus \- die Warnungen anderer Benutzer sind davon nicht betroffen. +* Das Entfernen einer Warnung entfernt keinen Importverlauf oder Aktivitätsprotokolle aus DefectDojo. + +## Eingrenzen von Benachrichtigungen für Überprüfungsanfragen (Pro) + +Wenn eine Überprüfung von allen berechtigten Prüfern angefordert wird, werden alle für dieses Asset berechtigten Personen benachrichtigt. Das ist eine Menge E-Mails für einen Prüfer, der nur einen Teil Ihres Bestands betreut. + +In der Benutzeroberfläche von DefectDojo Pro können Sie Ihre eigenen Benachrichtigungen für Überprüfungsanfragen eingrenzen. Auf Ihrer Seite für Benachrichtigungseinstellungen, unter **Überprüfungsanfragen**: + +* **Umfang der Überprüfungsanfrage** — *Alle* (die Standardeinstellung) benachrichtigt Sie über alles, was Sie sehen können. *Ausgewählt* grenzt dies auf die von Ihnen ausgewählten Assets und Asset-Typen ein. +* **Assets für Überprüfungsanfragen** / **Asset-Typen für Überprüfungsanfragen** — der Ausschnitt des Bestands, über den Sie informiert werden möchten. Eine Anfrage passt, wenn sie sich auf eines Ihrer ausgewählten Assets *oder* einen Ihrer ausgewählten Asset-Typen bezieht. + +Zwei Dinge sollten klar sein: + +* Wenn Sie *Ausgewählt* wählen und nichts auswählen, bedeutet das **keine**, nicht alle. +* Das Eingrenzen unterdrückt die Benachrichtigung, **nicht die Anfrage**. Sie bleiben ein angeforderter Prüfer, und die Anfrage erscheint weiterhin in Ihrer Warteschlange [Meine Arbeit](/metrics_reports/dashboards/pro__my_work/) unter **Wartet auf meine Überprüfung** — Sie werden lediglich nicht darüber benachrichtigt. Dies ist beabsichtigt: Die Warteschlange ist der dauerhafte Datensatz, Benachrichtigungen sind die Erinnerung. + +Diese Eingrenzung hat außerdem Vorrang vor dem weiter unten beschriebenen Override auf Systemebene, sodass ein Prüfer, der sich selbst ausgegrenzt hat, auch dann nicht benachrichtigt wird, wenn `review_requested` so konfiguriert ist, dass es persönliche Einstellungen überstimmt. + +Die Eingrenzung kann auch über die API am Benachrichtigungs-Endpunkt festgelegt werden, was die praktische Vorgehensweise ist, wenn Sie viele Prüfer gleichzeitig konfigurieren. + +## Benachrichtigungen zu Arbeitszuweisungen (Pro) + +Wenn Ihnen Befunde zugewiesen werden, teilt Ihnen die Benachrichtigung **Arbeit zugewiesen** mit, wie viele es sind, und verlinkt zu Ihrer Warteschlange „Meine Arbeit". + +Sie wird pro Person und nicht pro Befund zusammengefasst: Das Zuweisen von hundert Befunden sendet eine einzige Nachricht, nicht hundert. Wie bei Überprüfungsanfragen ist die Zuweisung in Ihrer Warteschlange sichtbar, unabhängig davon, ob die Benachrichtigung Sie erreicht. + +## Überlegungen zur Open-Source-Version + +### Spezifische Overrides + +Systembenachrichtigungseinstellungen (scope: system) beschreiben das Senden von Benachrichtigungen an Superadmins. Benutzerbenachrichtigungseinstellungen (scope: personal) beschreiben das Senden von Benachrichtigungen an den jeweiligen Benutzer. + +Es gibt jedoch einen speziellen Anwendungsfall, bei dem der Benutzer Benachrichtigungen deaktiviert (um weniger Störungen zu haben), die Systemeinstellung dieses Verhalten jedoch außer Kraft setzt. Diese Overrides gelten standardmäßig nur für `user_mentioned` und `review_requested`. + +Der Umfang dieser Einstellung ist anpassbar (siehe die Umgebungsvariable `DD_NOTIFICATIONS_SYSTEM_LEVEL_TRUMP`). + +Weitere Informationen zu diesem Verhalten finden Sie im [zugehörigen Pull Request #9699](https://github.com/DefectDojo/django-DefectDojo/pull/9699/) + +### Webhooks (experimentell) + +DefectDojo unterstützt außerdem Webhooks, die denselben Ereignissen wie andere Benachrichtigungen folgen (Sie können in denselben Situationen benachrichtigt werden). Details zur Einrichtung finden Sie auf [der zugehörigen Seite](/automation/api/notification_webhooks/). diff --git a/docs/content/admin/notifications/about_notifications.es.md b/docs/content/admin/notifications/about_notifications.es.md new file mode 100644 index 00000000000..ccd6f226fa4 --- /dev/null +++ b/docs/content/admin/notifications/about_notifications.es.md @@ -0,0 +1,103 @@ +--- +title: Acerca de las Notificaciones y las 🔔 Alertas +description: Aprenda sobre las notificaciones y las alertas dentro de la aplicación +aliases: +- /es/en/customize_dojo/notifications/about_notifications +--- + +DefectDojo lo mantiene al día de diversas maneras. Se pueden enviar notificaciones para Compromisos próximos, [Menciones de usuario](/triage_findings/findings_workflows/intro_to_findings/#notes-and-mentions), vencimiento de SLA y otros eventos del software. + +Este artículo ofrece una visión general de las notificaciones tanto a nivel de Sistema como Personal. + +## Tipos de Notificación + +DefectDojo gestiona las notificaciones de dos maneras distintas: + +* Las **Notificaciones a Nivel de Sistema** se envían a todos los usuarios. +* **Las Notificaciones Personales las configura cada usuario individualmente, y se reciben además de cualquier Notificación a Nivel de Sistema.** + +En ambos casos, se aplican las reglas de [Control de Acceso Basado en Roles](../../user_management/about_perms_and_roles/), por lo que los usuarios no recibirán notificaciones de actividad de Productos o Tipos de Producto (ni de sus objetos relacionados) a los que no tengan acceso. + +## Métodos de Entrega de Notificaciones + +Existen cuatro métodos de entrega para las notificaciones de DefectDojo: + +* DefectDojo puede compartir **🔔 Alertas**, almacenadas como una lista en la interfaz de DefectDojo +* DefectDojo puede enviar notificaciones a una dirección de **Email** +* DefectDojo puede enviar notificaciones a **Slack**, ya sea en un canal compartido o individual +* DefectDojo también puede enviar notificaciones a **Microsoft Teams** en un canal compartido + +Las notificaciones se pueden enviar a varios destinos simultáneamente. + +Para recibir notificaciones de Slack y Teams necesitará tener una integración en funcionamiento. Para más información sobre cómo configurar esta integración, consulte nuestra [Guía](../email_slack_teams). + +## Alertas dentro de la aplicación + +El sistema de Alertas de DefectDojo lo mantiene al día de toda la actividad de Producto o del sistema. + +### La Lista de Alertas + +La Lista de Alertas siempre está visible en la esquina superior derecha de DefectDojo, y contiene una lista compacta de notificaciones. Al hacer clic en cada Alerta se le llevará directamente a la página correspondiente en DefectDojo. + +Puede abrir su Lista de Alertas haciendo clic en el **ícono 🔔▼** en la esquina superior derecha: + +![image](images/About_In-App_Alerts.png) + +Para ver todas sus notificaciones, junto con detalles adicionales, puede hacer clic en el botón **Ver todas las Alertas \>**, que abrirá la **Página de Alertas**. + +También puede **Borrar todas las Alertas \>** desde la Lista de Alertas. + +### La Página de Alertas + +La Página de Alertas almacena todas sus Alertas de DefectDojo con detalle adicional. En esta página puede leer las descripciones de cada Alerta en DefectDojo, y eliminarlas de la cola de Alertas una vez que ya no las necesite. + +![image](images/About_In-App_Alerts_2.png) + +Para eliminar una o más Alertas de la Página de Alertas, marque la casilla vacía junto a ella, y luego haga clic en el botón **Eliminar seleccionadas** en la esquina inferior derecha de la Página. + +### Notas sobre las Alertas + +* Leer una Alerta, o abrir la Página de Alertas, no eliminará ninguna Alerta del contador junto al ícono de campana. Esto es para que pueda acceder fácilmente a alertas pasadas y usarlas como recordatorios o como un registro de actividad personal. +* Usar la función **Borrar todas las Alertas \>** en el Menú de Alertas también vaciará por completo la **Página de Alertas**, así que use esta función con cuidado. +* Eliminar una Alerta solo afecta a su propia Lista de Alertas: no afectará a las Alertas de ningún otro usuario. +* Eliminar una Alerta no elimina ningún historial de importación ni registro de actividad de DefectDojo. + +## Reducir las Notificaciones de Solicitud de Revisión (Pro) + +Si se solicita una revisión a todos los revisores elegibles, se notifica a todos los elegibles para ese activo. Eso supone muchos correos para un revisor que solo se ocupa de una parte de su parque de activos. + +En la interfaz de DefectDojo Pro puede reducir sus propias notificaciones de solicitud de revisión. En su página de configuración de notificaciones, bajo **Review Requests**: + +* **Review Request Scope** — *All* (el valor por defecto) le notifica sobre todo lo que puede ver. *Selected* lo limita a los activos y tipos de activo que elija. +* **Review Request Assets** / **Review Request Asset Types** — el subconjunto del parque de activos sobre el que desea recibir información. Una solicitud coincide si se refiere a uno de sus activos seleccionados *o* a uno de sus tipos de activo seleccionados. + +Hay dos cosas que conviene tener claras: + +* Elegir *Selected* y no seleccionar nada significa **ninguno**, no todos. +* Esta reducción suprime la notificación, **no la solicitud**. Usted sigue siendo un revisor solicitado y la solicitud sigue apareciendo en su cola de [Mi Trabajo](/metrics_reports/dashboards/pro__my_work/) bajo **Awaiting My Review**; simplemente no se le notifica al respecto. Esto es intencional: la cola es el registro duradero, las notificaciones son el recordatorio. + +Esta reducción también tiene prioridad sobre la anulación a nivel de sistema descrita a continuación, de modo que un revisor que se ha excluido a sí mismo no recibe notificación aunque `review_requested` esté configurado para primar sobre las preferencias personales. + +La reducción también se puede configurar a través de la API en el endpoint de notificaciones, lo cual es la vía práctica si está configurando muchos revisores a la vez. + +## Notificaciones de Asignación de Trabajo (Pro) + +Cuando se le asignan Hallazgos, la notificación **Work Assigned** le indica cuántos y enlaza a su cola de Mi Trabajo. + +Se agrega por persona en lugar de por Hallazgo: asignar cien Hallazgos envía un solo mensaje, no cien. Al igual que con las solicitudes de revisión, la asignación es visible en su cola tanto si la notificación le llega como si no. + +## Consideraciones sobre código abierto + +### Anulaciones específicas + +La configuración de notificaciones del sistema (scope: system) describe el envío de notificaciones a los superadministradores. La configuración de notificaciones de usuario (scope: personal) describe el envío de notificaciones al usuario específico. + +Sin embargo, existe un caso de uso concreto en el que el usuario decide deshabilitar las notificaciones (para reducir el ruido), pero la configuración del sistema se utiliza para anular este comportamiento. Estas anulaciones se aplican por defecto únicamente a `user_mentioned` y `review_requested`. + +El alcance de esta configuración es personalizable (véase la variable de entorno `DD_NOTIFICATIONS_SYSTEM_LEVEL_TRUMP`). + +Para más información sobre este comportamiento, consulte la [pull request relacionada #9699](https://github.com/DefectDojo/django-DefectDojo/pull/9699/) + +### Webhooks (experimental) + +DefectDojo también admite webhooks que siguen los mismos eventos que otras notificaciones (se le puede notificar en las mismas situaciones). Los detalles sobre la configuración se describen en [la página relacionada](/automation/api/notification_webhooks/). diff --git a/docs/content/admin/notifications/about_notifications.fr.md b/docs/content/admin/notifications/about_notifications.fr.md new file mode 100644 index 00000000000..457f07b3206 --- /dev/null +++ b/docs/content/admin/notifications/about_notifications.fr.md @@ -0,0 +1,103 @@ +--- +title: À propos des notifications et des 🔔 alertes +description: Découvrez les notifications et les alertes intégrées à l'application +aliases: +- /fr/en/customize_dojo/notifications/about_notifications +--- + +DefectDojo vous tient informé de diverses manières. Des notifications peuvent être envoyées pour les Engagements à venir, les [mentions d'utilisateur](/triage_findings/findings_workflows/intro_to_findings/#notes-and-mentions), l'expiration des SLA, et d'autres événements du logiciel. + +Cet article présente un aperçu des notifications aux niveaux Système et Personnel. + +## Types de notification + +DefectDojo gère les notifications de deux manières différentes : + +* Les **Notifications à l'échelle du système** sont envoyées à tous les utilisateurs. +* **Les Notifications personnelles sont définies par chaque utilisateur individuellement, et sont reçues en plus des Notifications à l'échelle du système.** + +Dans les deux cas, les règles de [Contrôle d'accès basé sur les rôles](../../user_management/about_perms_and_roles/) s'appliquent, de sorte que les utilisateurs ne recevront pas de notifications d'activité pour les Produits ou Types de produit (ou leurs objets associés) auxquels ils n'ont pas accès. + +## Méthodes d'envoi des notifications + +Il existe quatre méthodes d'envoi pour les notifications DefectDojo : + +* DefectDojo peut partager des **🔔 Alertes,** stockées sous forme de liste dans l'interface DefectDojo +* DefectDojo peut envoyer des notifications à une adresse **E-mail** +* DefectDojo peut envoyer des notifications à **Slack,** dans un canal partagé ou individuel +* DefectDojo peut également envoyer des notifications à **Microsoft Teams** dans un canal partagé + +Les notifications peuvent être envoyées vers plusieurs destinations simultanément. + +Pour recevoir des notifications Slack et Teams, vous devez disposer d'une intégration fonctionnelle. Pour plus d'informations sur la configuration de cette intégration, consultez notre [Guide](../email_slack_teams). + +## Alertes intégrées à l'application + +Le système d'Alertes de DefectDojo vous tient informé de toute l'activité des Produits ou du système. + +### La Liste des alertes + +La Liste des alertes est toujours visible dans le coin supérieur droit de DefectDojo, et contient une liste compacte des notifications. Cliquer sur chaque Alerte vous amène directement à la page correspondante dans DefectDojo. + +Vous pouvez ouvrir votre Liste des alertes en cliquant sur l'**icône 🔔▼** dans le coin supérieur droit : + +![image](images/About_In-App_Alerts.png) + +Pour voir toutes vos notifications, avec des détails supplémentaires, vous pouvez cliquer sur le bouton **Voir toutes les alertes \>**, qui ouvrira la **Page des alertes**. + +Vous pouvez également **Effacer toutes les alertes \>** depuis la Liste des alertes. + +### La Page des alertes + +La Page des alertes stocke toutes vos Alertes dans DefectDojo avec des détails supplémentaires. Sur cette page, vous pouvez lire la description de chaque Alerte dans DefectDojo, et les retirer de la file d'attente des alertes une fois que vous n'en avez plus besoin. + +![image](images/About_In-App_Alerts_2.png) + +Pour retirer une ou plusieurs Alertes de la Page des alertes, cochez la case vide à côté de celles-ci, puis cliquez sur le bouton **Supprimer la sélection** dans le coin inférieur droit de la Page. + +### Remarques sur les alertes + +* Lire une Alerte, ou ouvrir la Page des alertes, ne retire aucune Alerte du compteur situé à côté de l'icône de cloche. Cela vous permet d'accéder facilement aux alertes passées pour les utiliser comme rappels ou comme journal d'activité personnel. +* L'utilisation de la fonction **Effacer toutes les alertes \>** dans le Menu des alertes efface également entièrement la **Page des alertes**, utilisez donc cette fonctionnalité avec prudence. +* Retirer une Alerte n'affecte que votre propre Liste des alertes \- cela n'affecte pas les Alertes des autres utilisateurs. +* Retirer une Alerte ne supprime aucun historique d'importation ni journal d'activité de DefectDojo. + +## Restreindre les notifications de demande de révision (Pro) + +Si une révision est demandée à tous les réviseurs éligibles, chaque personne éligible sur cet actif est notifiée. Cela représente beaucoup de courrier pour un réviseur qui ne s'occupe que d'une partie de votre parc. + +Dans l'interface DefectDojo Pro, vous pouvez restreindre vos propres notifications de demande de révision. Sur votre page de paramètres de notification, sous **Demandes de révision** : + +* **Portée des demandes de révision** — *Tout* (valeur par défaut) vous notifie de tout ce que vous pouvez voir. *Sélectionné* vous restreint aux actifs et types d'actifs que vous choisissez. +* **Actifs des demandes de révision** / **Types d'actifs des demandes de révision** — la portion du parc dont vous souhaitez être informé. Une demande correspond si elle concerne l'un de vos actifs sélectionnés *ou* l'un de vos types d'actifs sélectionnés. + +Deux points à clarifier : + +* Choisir *Sélectionné* et ne rien sélectionner signifie **aucun**, et non pas tous. +* La restriction supprime la notification, **pas la demande**. Vous restez un réviseur sollicité et la demande continue d'apparaître dans votre file d'attente [Mon travail](/metrics_reports/dashboards/pro__my_work/) sous **En attente de ma révision** — vous n'êtes simplement pas notifié à ce sujet. Ceci est intentionnel : la file d'attente constitue l'enregistrement durable, les notifications ne sont qu'un rappel. + +Cette restriction prévaut également sur la surcharge au niveau système décrite ci-dessous, de sorte qu'un réviseur qui s'est exclu du périmètre n'est pas notifié même lorsque `review_requested` est configuré pour prévaloir sur les préférences personnelles. + +La restriction peut également être configurée via l'API sur le point de terminaison des notifications, ce qui constitue la solution pratique si vous configurez de nombreux réviseurs à la fois. + +## Notifications d'attribution de travail (Pro) + +Lorsque des Constatations vous sont attribuées, la notification **Travail attribué** vous indique leur nombre et renvoie vers votre file d'attente Mon travail. + +Elle est agrégée par personne plutôt que par Constatation : attribuer une centaine de Constatations envoie un seul message, pas cent. Comme pour les demandes de révision, l'attribution est visible dans votre file d'attente, que la notification vous parvienne ou non. + +## Considérations pour la version open source + +### Surcharges spécifiques + +Les paramètres de notification système (portée : system) décrivent l'envoi de notifications aux super-administrateurs. Les paramètres de notification utilisateur (portée : personal) décrivent l'envoi de notifications à un utilisateur spécifique. + +Cependant, il existe un cas d'usage spécifique où l'utilisateur décide de désactiver les notifications (pour réduire le bruit), mais le paramètre système est utilisé pour outrepasser ce comportement. Ces surcharges s'appliquent par défaut uniquement à `user_mentioned` et `review_requested`. + +La portée de ce paramètre est personnalisable (voir la variable d'environnement `DD_NOTIFICATIONS_SYSTEM_LEVEL_TRUMP`). + +Pour plus d'informations sur ce comportement, consultez la [pull request associée #9699](https://github.com/DefectDojo/django-DefectDojo/pull/9699/) + +### Webhooks (expérimental) + +DefectDojo prend également en charge les webhooks, qui suivent les mêmes événements que les autres notifications (vous pouvez être notifié dans les mêmes situations). Les détails de configuration sont décrits sur [la page correspondante](/automation/api/notification_webhooks/). diff --git a/docs/content/admin/notifications/about_notifications.ja.md b/docs/content/admin/notifications/about_notifications.ja.md new file mode 100644 index 00000000000..0f5e01fbe7b --- /dev/null +++ b/docs/content/admin/notifications/about_notifications.ja.md @@ -0,0 +1,103 @@ +--- +title: 通知 & 🔔 アラートについて +description: 通知とアプリ内アラートについて学ぶ +aliases: +- /ja/en/customize_dojo/notifications/about_notifications +--- + +DefectDojoは、さまざまな方法で最新情報を提供します。通知は、今後予定されているエンゲージメント、[ユーザーメンション](/triage_findings/findings_workflows/intro_to_findings/#notes-and-mentions)、SLAの期限切れ、その他ソフトウェア内のイベントに対して送信されます。 + +この記事では、システム全体レベルおよび個人レベルの両方における通知の概要を説明します。 + +## 通知の種類 + +DefectDojoは、通知を2つの異なる方法で処理します:: + +* **システム全体通知**(System-Wide Notifications)はすべてのユーザーに送信されます。 +* **個人通知(Personal Notifications)は個々のユーザーによって設定され、システム全体通知に加えて受信されます。** + +いずれの場合も、[ロールベースアクセス制御](../../user_management/about_perms_and_roles/) のルールが適用されるため、ユーザーはアクセス権のない製品や製品タイプ(またはそれらに関連するオブジェクト)についてのアクティビティ通知を受け取りません。 + +## 通知の配信方法 + +DefectDojoの通知には4つの配信方法があります。 + +* DefectDojoは、DefectDojoインターフェース内に一覧として保存される **🔔 アラート** を共有できます +* DefectDojoは、**メール** アドレスに通知を送信できます +* DefectDojoは、共有チャンネルまたは個人チャンネルのいずれかで **Slack** に通知を送信できます +* DefectDojoは、共有チャンネルで **Microsoft Teams** にも通知を送信できます + +通知は複数の送信先に同時に送信できます。 + +SlackおよびTeamsの通知を受信するには、有効なインテグレーションが必要です。このインテグレーションの設定方法の詳細については、[ガイド](../email_slack_teams) を参照してください。 + +## アプリ内アラート + +DefectDojoのアラートシステムは、すべての製品またはシステムのアクティビティについて最新情報を提供します。 + +### アラート一覧 + +アラート一覧は、DefectDojoの右上に常に表示されており、コンパクトな通知の一覧が含まれています。各アラートをクリックすると、DefectDojo内の該当ページに直接移動します。 + +右上にある **🔔▼ アイコン** をクリックすると、アラート一覧を開くことができます。 + +![image](images/About_In-App_Alerts.png) + +すべての通知を詳細とともに確認するには、**See All Alerts \>** ボタンをクリックすると、**アラートページ** が開きます。 + +アラート一覧から **Clear All Alerts \>** をクリックすることもできます。 + +### アラートページ + +アラートページには、DefectDojo内のすべてのアラートが詳細情報とともに保存されています。このページでは、DefectDojo内の各アラートの説明を確認でき、不要になったものはアラートキューから削除できます。 + +![image](images/About_In-App_Alerts_2.png) + +アラートページから1つ以上のアラートを削除するには、その横にある空のチェックボックスにチェックを入れ、ページの右下にある **Remove selected** ボタンをクリックします。 + +### アラートに関する注意事項 + +* アラートを読んだり、アラートページを開いたりしても、ベルアイコンの横にあるカウントからアラートが削除されることはありません。これは、過去のアラートにリマインダーや個人のアクティビティログとして簡単にアクセスできるようにするためです。 +* アラートメニューの **Clear All Alerts \>** 機能を使用すると、**アラートページ** も完全にクリアされるため、この機能は注意して使用してください。 +* アラートを削除しても、自分のアラート一覧のみに影響し、他のユーザーのアラートには影響しません。 +* アラートを削除しても、DefectDojoからインポート履歴やアクティビティログが削除されることはありません。 + +## レビューリクエスト通知を絞り込む(Pro) + +すべての対象レビュアーからレビューが要求されると、そのアセットに対して対象となる全員に通知が送信されます。これは、あなたの管理対象の一部だけを担当しているレビュアーにとっては、大量のメールになります。 + +DefectDojo Pro のUIでは、自分自身のレビューリクエスト通知を絞り込むことができます。通知設定ページの **Review Requests** の下で: + +* **Review Request Scope** — *All*(デフォルト)は、閲覧可能なすべての事項について通知します。*Selected* は、選択したアセットおよびアセットタイプに絞り込みます。 +* **Review Request Assets** / **Review Request Asset Types** — 通知を受けたい管理対象の範囲です。選択したアセットのいずれか、または選択したアセットタイプのいずれかに該当するリクエストが対象になります。 + +明確にしておくべき点が2つあります。 + +* *Selected* を選択して何も選ばなかった場合、それは「すべて」ではなく **なし** を意味します。 +* 絞り込みは通知を抑制するものであり、**リクエスト自体を抑制するものではありません**。あなたは引き続きレビュアーとしてリクエストされた状態であり、そのリクエストは [My Work](/metrics_reports/dashboards/pro__my_work/) キューの **Awaiting My Review** に表示され続けます — 単に通知が届かなくなるだけです。これは意図的な設計です。キューが正式な記録であり、通知はあくまでリマインダーです。 + +この絞り込みは、以下で説明するシステムレベルのオーバーライドよりも優先されます。そのため、自分自身を対象外に設定したレビュアーは、`review_requested` が個人設定より優先されるよう構成されている場合でも通知を受け取りません。 + +この絞り込みは、notifications エンドポイントを介してAPI経由で設定することもできます。これは、多数のレビュアーを一度に設定する場合の実用的な方法です。 + +## 作業割り当て通知(Pro) + +検出事項があなたに割り当てられると、**Work Assigned** 通知が件数を知らせ、My Work キューへのリンクを提供します。 + +これは検出事項ごとではなく、人ごとに集計されます。100件の検出事項を割り当てても、送信されるメッセージは100件ではなく1件です。レビューリクエストと同様に、割り当ては通知が届くかどうかに関わらず、キューに表示されます。 + +## オープンソース版に関する考慮事項 + +### 特定のオーバーライド + +システム通知設定(scope: system)は、スーパー管理者への通知送信を規定します。ユーザー通知設定(scope: personal)は、特定のユーザーへの通知送信を規定します。 + +ただし、ユーザーが(ノイズを減らすために)通知を無効にすることを選択しても、システム設定によってこの動作がオーバーライドされる特定のユースケースがあります。これらのオーバーライドは、デフォルトでは `user_mentioned` と `review_requested` にのみ適用されます。 + +この設定の範囲はカスタマイズ可能です(環境変数 `DD_NOTIFICATIONS_SYSTEM_LEVEL_TRUMP` を参照してください)。 + +この動作の詳細については、[関連するプルリクエスト #9699](https://github.com/DefectDojo/django-DefectDojo/pull/9699/) を参照してください。 + +### Webhook(実験的機能) + +DefectDojoは、他の通知と同じイベントに従うWebhookもサポートしています(同じ状況で通知を受け取ることができます)。設定の詳細については、[関連ページ](/automation/api/notification_webhooks/) をご覧ください。 diff --git a/docs/content/admin/notifications/configure_personal_notifs.de.md b/docs/content/admin/notifications/configure_personal_notifs.de.md new file mode 100644 index 00000000000..90723c02db4 --- /dev/null +++ b/docs/content/admin/notifications/configure_personal_notifs.de.md @@ -0,0 +1,35 @@ +--- +title: Persönliche Benachrichtigungen festlegen +description: Benachrichtigungen für ein persönliches Konto konfigurieren +aliases: +- /de/en/customize_dojo/notifications/configure_personal_notifs +--- + +## Persönliche Benachrichtigungen konfigurieren + +Persönliche Benachrichtigungen werden zusätzlich zu systemweiten Benachrichtigungen gesendet und gelten für jedes Produkt, jeden Produkttyp und jeden anderen Datentyp, auf den Sie Zugriff haben. Einstellungen für persönliche Benachrichtigungen gelten nur für einen einzelnen Benutzer und können ausschließlich auf dem Konto festgelegt werden, das sie konfiguriert. + +![image](images/Configure_System_&_Personal_Notifications.png) + +Systembenachrichtigungen werden von einem DefectDojo-Superuser festgelegt; einzelne Benutzer können sie nicht abbestellen. + +1. Beginnen Sie auf der Seite „Benachrichtigungen“ (⚙️**Konfiguration \> Benachrichtigungen** in der Seitenleiste). +2. Im Dropdown-Menü **Geltungsbereich** können Sie auswählen, welchen Satz von Benachrichtigungen Sie bearbeiten möchten. +3. Wählen Sie „Persönliche Benachrichtigungen“. +4. Markieren Sie für jeden Benachrichtigungstyp den Zustellweg, den Sie verwenden möchten. Sie können mehrere auswählen. + +Persönliche Benachrichtigungen können nicht über Microsoft Teams gesendet werden, da Teams nur globale Benachrichtigungen in einem einzelnen Kanal veröffentlichen kann. + +### Persönliche Benachrichtigungen für ein bestimmtes Produkt erhalten + +Zusätzlich zu den üblichen persönlichen Benachrichtigungen können DefectDojo-Benutzer auch Benachrichtigungen über Aktivitäten in einem bestimmten Produkt erhalten. Das ist hilfreich, wenn ein Benutzer bestimmte Produkte genauer beobachten muss. + +![image](images/Configure_System_&_Personal_Notifications_3.png) + +Diese Konfiguration können Sie im Abschnitt **Benachrichtigungen** auf der **Produkt**-Seite ändern, z. B. `your-instance.defectdojo.com/product/{id}`. + +Hier können Sie festlegen, ob Sie **🔔 Warnmeldungen**, **Mail**- oder **Slack**-Benachrichtigungen für Aktionen an diesem bestimmten Produkt erhalten möchten. Diese Benachrichtigungen gelten zusätzlich zu allen systemweiten Benachrichtigungen, die Sie bereits erhalten. + +Microsoft Teams kann keinerlei persönliche Benachrichtigungen senden, daher lassen sich Teams-Benachrichtigungen in diesem Menü nicht auswählen. + +Persönliche E-Mail-Benachrichtigungen werden immer an die E-Mail-Adresse gesendet, die mit Ihrem DefectDojo-Login verknüpft ist. Informationen zum Einrichten eines persönlichen Slack-Kontos für den Empfang von Benachrichtigungen finden Sie in unserer [Anleitung](../email_slack_teams/#send-personal-notifications-to-slack). diff --git a/docs/content/admin/notifications/configure_personal_notifs.es.md b/docs/content/admin/notifications/configure_personal_notifs.es.md new file mode 100644 index 00000000000..fddfe9caa37 --- /dev/null +++ b/docs/content/admin/notifications/configure_personal_notifs.es.md @@ -0,0 +1,35 @@ +--- +title: Configurar Notificaciones Personales +description: Configurar notificaciones para una cuenta personal +aliases: +- /es/en/customize_dojo/notifications/configure_personal_notifs +--- + +## Configurar notificaciones Personales + +Las Notificaciones Personales se envían además de las Notificaciones a Nivel de Sistema, y se aplicarán a cualquier Producto, Tipo de Producto u otro tipo de dato al que tenga acceso. Las preferencias de Notificación Personal solo se aplican a un único usuario, y solo se pueden configurar desde la cuenta que las está configurando. + +![image](images/Configure_System_&_Personal_Notifications.png) + +Las notificaciones del sistema las configura un Superusuario de DefectDojo y un usuario individual no puede excluirse de ellas. + +1. Comience desde la página de Notificaciones (⚙️**Configuration \> Notifications** en la barra lateral). +2. En el menú desplegable **Scope**, puede seleccionar el conjunto de notificaciones que desea editar. +3. Seleccione Personal Notifications. +4. Marque el método de notificación que desea usar para cada tipo de notificación. Puede seleccionar más de uno. + +Las Notificaciones Personales no se pueden enviar por Microsoft Teams, ya que Teams solo permite publicar notificaciones Globales en un único canal. + +### Recibir notificaciones Personales de un Producto específico + +Además de las notificaciones personales estándar, los Usuarios de DefectDojo también pueden recibir notificaciones sobre la actividad de un Producto específico. Esto es útil cuando hay determinados Productos que un usuario necesita supervisar más de cerca. + +![image](images/Configure_System_&_Personal_Notifications_3.png) + +Esta configuración se puede cambiar desde la sección **Notifications** de la página del **Producto**: por ejemplo, `your-instance.defectdojo.com/product/{id}`. + +Desde aquí puede establecer si desea recibir notificaciones de **🔔 Alert**, **Mail** o **Slack** por las acciones realizadas en este Producto en particular. Estas notificaciones se aplican además de cualquier notificación a nivel de sistema que ya esté recibiendo. + +Microsoft Teams no puede enviar notificaciones personales de ningún tipo, por lo que las notificaciones de Teams no se pueden elegir en este menú. + +Las notificaciones personales por email siempre se enviarán al correo asociado a su inicio de sesión de DefectDojo. Para configurar una cuenta personal de Slack y recibir notificaciones, consulte nuestra [Guía](../email_slack_teams/#send-personal-notifications-to-slack). diff --git a/docs/content/admin/notifications/configure_personal_notifs.fr.md b/docs/content/admin/notifications/configure_personal_notifs.fr.md new file mode 100644 index 00000000000..cfe123d2815 --- /dev/null +++ b/docs/content/admin/notifications/configure_personal_notifs.fr.md @@ -0,0 +1,35 @@ +--- +title: Configurer les notifications personnelles +description: Configurer les notifications pour un compte personnel +aliases: +- /fr/en/customize_dojo/notifications/configure_personal_notifs +--- + +## Configurer les notifications personnelles + +Les Notifications personnelles sont envoyées en plus des Notifications à l'échelle du système, et s'appliquent à tout Produit, Type de produit ou autre type de données auquel vous avez accès. Les préférences de Notifications personnelles ne s'appliquent qu'à un seul utilisateur, et ne peuvent être définies que sur le compte qui les configure. + +![image](images/Configure_System_&_Personal_Notifications.png) + +Les notifications système sont définies par un Superutilisateur DefectDojo et ne peuvent pas être désactivées par un utilisateur individuel. + +1. Commencez par la page Notifications (⚙️**Configuration \> Notifications** dans la barre latérale). +2. Dans le menu déroulant **Portée**, vous pouvez sélectionner l'ensemble de notifications que vous souhaitez modifier. +3. Sélectionnez Notifications personnelles. +4. Cochez la méthode de notification que vous souhaitez utiliser pour chaque type de notification. Vous pouvez en sélectionner plusieurs. + +Les Notifications personnelles ne peuvent pas être envoyées via Microsoft Teams, car Teams ne permet de publier que des notifications globales dans un canal unique. + +### Recevoir des notifications personnelles pour un Produit spécifique + +En plus des notifications personnelles standard, les Utilisateurs DefectDojo peuvent également recevoir des notifications pour l'activité d'un Produit spécifique. Cela est utile lorsqu'un utilisateur doit surveiller certains Produits de plus près. + +![image](images/Configure_System_&_Personal_Notifications_3.png) + +Cette configuration peut être modifiée depuis la section **Notifications** sur la page **Produit** : par exemple `your-instance.defectdojo.com/product/{id}`. + +À partir de là, vous pouvez définir si vous souhaitez recevoir des notifications **🔔 Alerte**, **E-mail** ou **Slack** pour les actions effectuées sur ce Produit en particulier. Ces notifications s'ajoutent à toute notification à l'échelle du système que vous recevez déjà. + +Microsoft Teams ne peut envoyer aucun type de notification personnelle, les notifications Teams ne peuvent donc pas être choisies depuis ce menu. + +Les notifications personnelles par e-mail seront toujours envoyées à l'adresse e-mail associée à votre identifiant DefectDojo. Pour configurer un compte Slack personnel afin de recevoir des notifications, consultez notre [Guide](../email_slack_teams/#send-personal-notifications-to-slack). diff --git a/docs/content/admin/notifications/configure_personal_notifs.ja.md b/docs/content/admin/notifications/configure_personal_notifs.ja.md new file mode 100644 index 00000000000..3a683c731e0 --- /dev/null +++ b/docs/content/admin/notifications/configure_personal_notifs.ja.md @@ -0,0 +1,35 @@ +--- +title: 個人通知を設定する +description: 個人アカウントの通知を設定する +aliases: +- /ja/en/customize_dojo/notifications/configure_personal_notifs +--- + +## 個人通知を設定する + +個人通知はシステム全体通知に加えて送信され、アクセス権を持つすべての製品、製品タイプ、その他のデータタイプに適用されます。個人通知の設定は単一のユーザーにのみ適用され、設定を行っているアカウント自身でのみ設定できます。 + +![image](images/Configure_System_&_Personal_Notifications.png) + +システム通知はDefectDojoのスーパーユーザーによって設定され、個々のユーザーがオプトアウトすることはできません。 + +1. Notifications ページから開始します(サイドバーの ⚙️**Configuration \> Notifications**)。 +2. **Scope** ドロップダウンメニューから、編集したい通知のセットを選択できます。 +3. Personal Notifications を選択します。 +4. 各種類の通知に使用したい通知方法にチェックを入れます。複数選択できます。 + +個人通知はMicrosoft Teams経由では送信できません。Teamsは単一チャンネルへのグローバル通知の投稿のみを許可しているためです。 + +### 特定の製品について個人通知を受け取る + +標準の個人通知に加えて、DefectDojoのユーザーは特定の製品でのアクティビティについても通知を受け取ることができます。これは、ユーザーがより注意深く監視する必要がある特定の製品がある場合に役立ちます。 + +![image](images/Configure_System_&_Personal_Notifications_3.png) + +この設定は、**Product** ページ内の **Notifications** セクションから変更できます。例: `your-instance.defectdojo.com/product/{id}`。 + +ここから、この特定の製品で行われたアクションについて **🔔 Alert**、**Mail**、または **Slack** の通知を受け取るかどうかを設定できます。これらの通知は、すでに受信しているシステム全体通知に加えて適用されます。 + +Microsoft Teamsはいかなる種類の個人通知も送信できないため、このメニューからTeams通知を選択することはできません。 + +個人メール通知は、常にDefectDojoログインに関連付けられたメールアドレスに送信されます。通知を受け取るための個人Slackアカウントの設定方法については、[ガイド](../email_slack_teams/#send-personal-notifications-to-slack) を参照してください。 diff --git a/docs/content/admin/notifications/configure_system_notifs.de.md b/docs/content/admin/notifications/configure_system_notifs.de.md new file mode 100644 index 00000000000..52c9a8b9cb0 --- /dev/null +++ b/docs/content/admin/notifications/configure_system_notifs.de.md @@ -0,0 +1,44 @@ +--- +title: Systemweite Benachrichtigungen festlegen +description: So konfigurieren Sie persönliche und Systembenachrichtigungen +aliases: +- /de/en/customize_dojo/notifications/configure_system_notifs +--- + +DefectDojo verfügt über zwei verschiedene Arten von Benachrichtigungen: **Persönliche** (werden an ein einzelnes Konto gesendet) und **System** (werden an alle Benutzer gesendet). + +Sowohl die persönlichen Benachrichtigungen eines Kontos als auch die globalen Systembenachrichtigungen können auf derselben Seite konfiguriert werden: **⚙️Konfiguration \> Benachrichtigungen** in der Seitenleiste. + +![image](images/Configure_System_&_Personal_Notifications.png) + +## Systembenachrichtigungen konfigurieren (klassische UI) + +**Zum Ändern systemweiter Benachrichtigungen benötigen Sie Superuser-Zugriff.** + +1. Beginnen Sie auf der Seite „Benachrichtigungen“ (⚙️ **Konfiguration \> Benachrichtigungen** in der Seitenleiste). +2. Im Dropdown-Menü „Geltungsbereich“ wählen Sie aus, welchen Satz von Benachrichtigungen Sie bearbeiten möchten. +3. Wählen Sie „Systembenachrichtigungen“ aus. +4. Aktivieren Sie für jede Art von Benachrichtigung die Zustellmethode, die Sie verwenden möchten. Sie können mehrere auswählen. + +![image](images/Configure_System_&_Personal_Notifications_2.png) + +Wie Sie Ziele für systemweite E-Mail-Benachrichtigungen (E-Mail, Slack oder MS Teams) festlegen, erfahren Sie in unserer [Anleitung](../email_slack_teams). + +## Vorlagen-Benachrichtigungen + +Superuser haben außerdem Zugriff auf ein Formular „Vorlage“. Über das Vorlagen-Formular legen Sie fest, welche persönlichen Benachrichtigungen für neue Benutzer standardmäßig aktiviert sind. + +## Wohin Systembenachrichtigungen gesendet werden + +Systembenachrichtigungen werden gesendet an: +- die einzelne E-Mail-Adresse, die in den Systemeinstellungen angegeben ist (sofern aktiviert) +- alle DefectDojo-Benutzer mit einem Konto und passenden RBAC-Berechtigungen +- das systemweite Slack- oder Teams-Konto. + +Wie jede Benachrichtigung in DefectDojo werden Systembenachrichtigungen nur an Benutzer gesendet, die Zugriff auf die betreffenden Daten haben. Selbst wenn Produktbenachrichtigungen systemweit eingerichtet sind, erhalten Benutzer also nur Benachrichtigungen zu den Produkten, die sie einsehen dürfen. + +Diese Einschränkung gilt nicht für Systembenachrichtigungen, die an eine bestimmte E-Mail-Adresse oder einen bestimmten Slack-Kanal gesendet werden. + +Weitere Informationen zu RBAC und zum Festlegen von Berechtigungen finden Sie in unserer Anleitung zur [rollenbasierten Zugriffskontrolle](../../user_management/about_perms_and_roles/). + +Die verbundenen System-Konten für E-Mail, Slack und Teams können RBAC jedoch nicht anwenden, da sie keinem bestimmten DefectDojo-Benutzer zugeordnet sind. **Alle ausgewählten systemweiten Benachrichtigungen werden an diese Ziele gesendet. Sie sollten daher sicherstellen, dass diese Kanäle nur bestimmten Personen in Ihrer Organisation zugänglich sind.** diff --git a/docs/content/admin/notifications/configure_system_notifs.es.md b/docs/content/admin/notifications/configure_system_notifs.es.md new file mode 100644 index 00000000000..cb5cfdc9da2 --- /dev/null +++ b/docs/content/admin/notifications/configure_system_notifs.es.md @@ -0,0 +1,44 @@ +--- +title: Configurar Notificaciones a Nivel de Sistema +description: Cómo configurar notificaciones Personales y de Sistema +aliases: +- /es/en/customize_dojo/notifications/configure_system_notifs +--- + +DefectDojo tiene dos tipos diferentes de notificaciones: **Personales** (enviadas a una única cuenta) y de **Sistema** (que se envían a todos los usuarios). + +Tanto las Notificaciones Personales de una cuenta como las Notificaciones de Sistema globales se pueden configurar desde la misma página: **⚙️Configuration \> Notifications** en la barra lateral. + +![image](images/Configure_System_&_Personal_Notifications.png) + +## Configurar notificaciones de Sistema (Interfaz Clásica) + +**Necesitará acceso de Superusuario para cambiar las notificaciones a Nivel de Sistema.** + +1. Comience desde la página de Notificaciones (⚙️ **Configuration \> Notifications** en la barra lateral). +2. En el menú desplegable Scope, puede seleccionar el conjunto de notificaciones que desea editar. +3. Seleccione System Notifications. +4. Marque el método de entrega de notificación que desea usar para cada tipo de notificación. Puede seleccionar más de uno. + +![image](images/Configure_System_&_Personal_Notifications_2.png) + +Para configurar destinos para las notificaciones por email a nivel de sistema (Email, Slack o MS Teams), consulte nuestra [Guía](../email_slack_teams). + +## Notificaciones de Plantilla + +Los Superusuarios también tienen acceso a un formulario "Template". El Formulario de Plantilla le permite establecer las Notificaciones Personales por defecto que se habilitan para cualquier usuario nuevo. + +## Dónde se envían las Notificaciones de Sistema + +Las Notificaciones de Sistema se enviarán a: +- la única dirección de email especificada en la Configuración del Sistema (si está habilitada) +- cualquier usuario de DefectDojo con cuenta y los permisos RBAC correspondientes +- la cuenta de Slack o Teams a nivel de sistema. + +Como con cualquier notificación en DefectDojo, las Notificaciones de Sistema solo se enviarán a los usuarios que tengan acceso a los datos correspondientes. Así que, incluso si las Notificaciones de Producto se configuran a Nivel de Sistema, los usuarios solo recibirán notificaciones de los Productos a los que tengan acceso para ver. + +Esta restricción no se aplica a las Notificaciones de Sistema que se envían a un Email o canal de Slack específico. + +Consulte nuestra guía sobre [Control de Acceso Basado en Roles](../../user_management/about_perms_and_roles/) para más información sobre RBAC y la configuración de permisos. + +Sin embargo, las cuentas conectadas de Email, Slack y Teams del Sistema no pueden aplicar RBAC, ya que no están asociadas a un usuario específico de DefectDojo. **Todas las notificaciones a nivel de sistema seleccionadas se enviarán a estas ubicaciones, así que debe asegurarse de que a estos canales solo puedan acceder personas específicas de su organización.** diff --git a/docs/content/admin/notifications/configure_system_notifs.fr.md b/docs/content/admin/notifications/configure_system_notifs.fr.md new file mode 100644 index 00000000000..7425942f1d6 --- /dev/null +++ b/docs/content/admin/notifications/configure_system_notifs.fr.md @@ -0,0 +1,44 @@ +--- +title: Configurer les notifications à l'échelle du système +description: Comment configurer les notifications personnelles et système +aliases: +- /fr/en/customize_dojo/notifications/configure_system_notifs +--- + +DefectDojo dispose de deux types de notifications différents : **Personnelles** (envoyées à un seul compte) et **Système** (envoyées à tous les utilisateurs). + +Les Notifications personnelles d'un compte et les Notifications système globales peuvent être configurées depuis la même page : **⚙️Configuration \> Notifications** dans la barre latérale. + +![image](images/Configure_System_&_Personal_Notifications.png) + +## Configurer les notifications système (interface classique) + +**Vous devez disposer d'un accès Superutilisateur pour modifier les notifications à l'échelle du système.** + +1. Commencez par la page Notifications (⚙️ **Configuration \> Notifications** dans la barre latérale). +2. Dans le menu déroulant Portée, vous pouvez sélectionner l'ensemble de notifications que vous souhaitez modifier. +3. Sélectionnez Notifications système. +4. Cochez la méthode d'envoi de notification que vous souhaitez utiliser pour chaque type de notification. Vous pouvez en sélectionner plusieurs. + +![image](images/Configure_System_&_Personal_Notifications_2.png) + +Pour définir les destinations des notifications par e-mail à l'échelle du système (E-mail, Slack ou MS Teams), consultez notre [Guide](../email_slack_teams). + +## Notifications modèles + +Les Superutilisateurs ont également accès à un formulaire « Modèle ». Le formulaire Modèle vous permet de définir les Notifications personnelles activées par défaut pour tout nouvel utilisateur. + +## Où sont envoyées les notifications système + +Les notifications système sont envoyées à : +- l'adresse e-mail unique spécifiée dans les Paramètres système (si activé) +- tous les utilisateurs DefectDojo disposant d'un compte et des autorisations RBAC appropriées +- le compte Slack ou Teams à l'échelle du système. + +Comme pour toute notification dans DefectDojo, les Notifications système ne seront envoyées qu'aux utilisateurs ayant accès aux données concernées. Ainsi, même si des Notifications de produit sont configurées à l'échelle du système, les utilisateurs ne recevront des notifications que pour les Produits qu'ils sont autorisés à consulter. + +Cette restriction ne s'applique pas aux Notifications système envoyées à une adresse e-mail ou un canal Slack spécifique. + +Consultez notre guide sur le [Contrôle d'accès basé sur les rôles](../../user_management/about_perms_and_roles/) pour plus d'informations sur le RBAC et la définition des autorisations. + +Cependant, les comptes E-mail, Slack et Teams système connectés ne peuvent pas appliquer le RBAC, car ils ne sont associés à aucun utilisateur DefectDojo spécifique. **Toutes les notifications à l'échelle du système sélectionnées seront envoyées à ces emplacements, vous devez donc vous assurer que ces canaux ne sont accessibles qu'à des personnes spécifiques de votre organisation.** diff --git a/docs/content/admin/notifications/configure_system_notifs.ja.md b/docs/content/admin/notifications/configure_system_notifs.ja.md new file mode 100644 index 00000000000..1feb45a32ff --- /dev/null +++ b/docs/content/admin/notifications/configure_system_notifs.ja.md @@ -0,0 +1,44 @@ +--- +title: システム全体通知を設定する +description: 個人通知とシステム通知の設定方法 +aliases: +- /ja/en/customize_dojo/notifications/configure_system_notifs +--- + +DefectDojoには2種類の通知があります: **Personal**(単一のアカウントに送信される)と **System**(すべてのユーザーに送信される)です。 + +アカウントの個人通知とグローバルなシステム通知の両方は、同じページ(サイドバーの **⚙️Configuration \> Notifications**)から設定できます。 + +![image](images/Configure_System_&_Personal_Notifications.png) + +## システム通知を設定する(Classic UI) + +**システム全体通知を変更するには、スーパーユーザーアクセスが必要です。** + +1. Notifications ページから開始します(サイドバーの ⚙️ **Configuration \> Notifications**)。 +2. Scope ドロップダウンメニューから、編集したい通知のセットを選択できます。 +3. System Notifications を選択します。 +4. 各種類の通知に使用したい通知の配信方法にチェックを入れます。複数選択できます。 + +![image](images/Configure_System_&_Personal_Notifications_2.png) + +システム全体のメール通知(Email、Slack、MS Teams)の送信先を設定するには、[ガイド](../email_slack_teams) を参照してください。 + +## テンプレート通知 + +スーパーユーザーは「Template」フォームにもアクセスできます。このTemplateフォームでは、新規ユーザーに対してデフォルトで有効になる個人通知を設定できます。 + +## システム通知の送信先 + +システム通知は以下に送信されます: +- System Settings で指定された単一のメールアドレス(有効な場合) +- 適切なRBAC権限を持つアカウントを持つすべてのDefectDojoユーザー +- システム全体のSlackまたはTeamsアカウント。 + +DefectDojoの他の通知と同様に、システム通知は関連するデータへのアクセス権を持つユーザーにのみ送信されます。そのため、製品通知がシステム全体で設定されている場合でも、ユーザーは自分が閲覧権限を持つ製品についての通知のみを受け取ります。 + +この制限は、特定のメールアドレスやSlackチャンネルに送信されるシステム通知には適用されません。 + +RBACおよび権限設定の詳細については、[ロールベースアクセス制御](../../user_management/about_perms_and_roles/) のガイドを参照してください。 + +ただし、接続されているシステムのメール、Slack、Teamsのアカウントは特定のDefectDojoユーザーに関連付けられていないため、RBACを適用できません。**選択されたすべてのシステム全体通知はこれらの送信先に送信されるため、これらのチャンネルには組織内の特定の人物のみがアクセスできるようにしてください。** diff --git a/docs/content/admin/notifications/email_slack_teams.de.md b/docs/content/admin/notifications/email_slack_teams.de.md new file mode 100644 index 00000000000..557c9f61efb --- /dev/null +++ b/docs/content/admin/notifications/email_slack_teams.de.md @@ -0,0 +1,142 @@ +--- +title: E-Mail-, Slack- oder Teams-Benachrichtigungen einrichten +description: Microsoft Teams für den Empfang von Benachrichtigungen einrichten +aliases: +- /de/en/customize_dojo/notifications/email_slack_teams +--- + +**Für die Seite „Systemeinstellungen“, die für diesen Vorgang erforderlich ist, benötigen Sie Superuser-Zugriff.** + +Benachrichtigungen können an Slack oder Teams gesendet werden, wenn in DefectDojo bestimmte Ereignisse ausgelöst werden. + +## Slack-Benachrichtigungen einrichten + +DefectDojo kann Slack-Benachrichtigungen auf zwei verschiedene Arten senden: + +* Systemweite Benachrichtigungen, die an einen einzelnen Slack-Kanal gesendet werden +* Persönliche Benachrichtigungen, die nur an bestimmte Benutzer gesendet werden. + +Hier ein Beispiel für eine Slack-Benachrichtigung aus DefectDojo: +​ +![image](images/Configure_a_Slack_Integration.png) + +DefectDojo hat keine eigene Slack-App, aber Sie können mit dieser Anleitung ganz einfach eine für Ihren Workspace erstellen. Eine Slack-App ist erforderlich, damit sowohl System- als auch persönliche Benachrichtigungen korrekt gesendet werden. + +### Eine Slack-App erstellen + +Um eine Slack-Verbindung zu DefectDojo einzurichten, müssen Sie eine eigene Slack-App erstellen. + +1. Beginnen Sie auf der Seite mit den Slack-Apps: . +2. Klicken Sie auf ‘**Create New App**’. +3. Wählen Sie ‘**From App Manifest**’. +4. Wählen Sie Ihren Slack-Workspace aus dem Menü aus. +5. Geben Sie Ihr App-Manifest ein \- Sie können diese JSON-Datei kopieren und einfügen; sie enthält alle Berechtigungseinstellungen, die für den Betrieb der Slack-Integration erforderlich sind. +​ +``` +{ + "_metadata": { + "major_version": 1, + "minor_version": 1 + }, + "display_information": { + "name": "DefectDojo", + "description": "Notifications from DefectDojo. See https://docs.defectdojo.com/en/notifications/configure-a-slack-integration/ for configuration steps.", + "background_color": "#0000AA" + }, + "features": { + "bot_user": { + "display_name": "DefectDojo Notifications" + } + }, + "oauth_config": { + "scopes": { + "bot": [ + "chat:write", + "chat:write.customize", + "chat:write.public", + "incoming-webhook", + "users:read", + "users:read.email" + ] + }, + "redirect_urls": [ + "https://slack.com/oauth/v2/authorize" + ] + } + } +``` + +Prüfen Sie die App-Zusammenfassung und klicken Sie anschließend auf „Create App“. Schließen Sie die Installation über die Schaltfläche **Install To Workplace** ab. + +### Slack-Integration in DefectDojo konfigurieren + +Jetzt müssen Sie die Slack-Integration in DefectDojo konfigurieren, um die Einrichtung abzuschließen. + +**Für den Zugriff auf die Seite „Systemeinstellungen“ von DefectDojo benötigen Sie Superuser-Zugriff.** + +1. Öffnen Sie über die Seite „App Information“ Ihrer Slack-App. Das ist die App, die im ersten Abschnitt \- **Eine Slack-App erstellen** \- erstellt wurde. +​ +2. Suchen Sie Ihr OAuth Access Token. Sie finden es in der Slack-Seitenleiste \- **Features / OAuth \& Permissions**. Kopieren Sie das **Bot User OAuth Token. +​** + +![image](images/Configure_a_Slack_Integration_2.png) + +3. Öffnen Sie DefectDojo in einem neuen Tab und navigieren Sie in der Seitenleiste zu **Konfiguration \> Systemeinstellungen**. (In der Pro-UI finden Sie dieses Formular unter **Enterprise-Einstellungen > Systemeinstellungen**.) +4. Aktivieren Sie das Kontrollkästchen **Slack-Benachrichtigungen aktivieren**. +5. Fügen Sie das **Bot User OAuth Token** aus Schritt 1 in das Feld **Slack token** ein. +6. Das Feld **Slack Channel** muss dem Kanal in Ihrem Workspace entsprechen, in dem ein DefectDojo-Bot Ihre Benachrichtigungen schreiben soll. +7. Wenn Sie den Namen des DefectDojo-Bots ändern möchten, können Sie hier einen eigenen Namen eingeben. Andernfalls wird **DefectDojo Notifications** verwendet, wie im Slack-App-Manifest festgelegt. + +Sobald dieser Vorgang abgeschlossen ist, kann DefectDojo systemweite Benachrichtigungen an diesen Kanal senden. Wählen Sie auf der [Seite für Systembenachrichtigungen]() die Benachrichtigungen aus, die gesendet werden sollen. + +![image](images/Configure_a_Slack_Integration_3.png) + +#### Hinweise zu systemweiten Benachrichtigungen in Slack: + +Slack kann auf den von Ihnen erstellten Slack-Kanal keine RBAC-Regeln anwenden. Dort werden daher Benachrichtigungen für das gesamte DefectDojo-System geteilt. In DefectDojo gibt es keine Möglichkeit, systemweite Slack-Benachrichtigungen nach Produkttyp, Produkt oder Engagement zu filtern. + +Wenn Sie Ihre Slack-Nachrichten anhand von RBAC filtern möchten, ist es besser, persönliche Benachrichtigungen für Slack zu aktivieren. + +### Persönliche Benachrichtigungen an Slack senden + +Wenn in Ihrem Team eine Slack-Integration aktiviert ist (über den oben beschriebenen Vorgang), können einzelne Benutzer Benachrichtigungen auch direkt an ihren persönlichen Slackbot-Kanal senden lassen. + +1. Navigieren Sie zunächst zu Ihrer persönlichen Profilseite in DefectDojo. Sie finden sie über das 👤 **Symbol** in der rechten oberen Ecke. Wählen Sie Ihren DefectDojo-Benutzernamen aus der Liste aus. (👤 **paul** in unserem Beispiel) +​ +![image](images/Configure_a_Slack_Integration_4.png) + +2. Legen Sie im Menü Ihre **Slack-E-Mail-Adresse** fest. Dieses Feld befindet sich in DefectDojo unter **Additional Contact Information**. + +Sie können nun [bestimmte Benachrichtigungen](../about_notifications/) an Ihren persönlichen Slackbot-Kanal senden lassen. Andere Benutzer in Ihrem Slack-Kanal erhalten diese Nachrichten nicht. + +## Microsoft Teams-Benachrichtigungen einrichten + +Microsoft Teams kann Benachrichtigungen in einem bestimmten Kanal empfangen. Dazu müssen Sie in dem Kanal, in dem Sie Nachrichten empfangen möchten, **einen eingehenden Webhook einrichten**. + +Bitte beachten Sie, dass die alten [Office-Connector-Webhooks](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook?tabs=newteams%2Cdotnet) von Microsoft abgeschaltet werden. Verwenden Sie stattdessen einen neuen Webhook auf Basis von Power Automate Workflows, wie unten beschrieben. + +1. Führen Sie den in der **[Microsoft Teams-Dokumentation](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498)** beschriebenen Vorgang zum Erstellen eines neuen eingehenden Webhooks aus. Halten Sie Ihren eindeutigen logic.azure.com-Link bereit, da Sie ihn in den nächsten Schritten benötigen. Sie können den Webhook für einen Kanal oder für einen bestimmten Chat erstellen. +​ +![image](images/Configure_a_Microsoft_Teams_Integration.png) +2. Navigieren Sie in DefectDojo in der Seitenleiste zu **Konfiguration \> Systemeinstellungen**. (In der Pro-UI finden Sie dieses Formular unter **Enterprise-Einstellungen > Systemeinstellungen**.) +3. Aktivieren Sie das Kontrollkästchen **Microsoft Teams-Benachrichtigungen aktivieren**. Dadurch wird ein verborgener Abschnitt des Formulars mit der Bezeichnung **‘Msteams url**’ eingeblendet. +​ +![image](images/Configure_a_Microsoft_Teams_Integration_2.png) +4. Fügen Sie die in Schritt 1\) erstellte logic.azure.com-URL in das Feld **Msteams url** ein. Ihre Teams-App wartet nun auf eingehende Benachrichtigungen von DefectDojo und veröffentlicht sie in dem von Ihnen ausgewählten Kanal. + +### Hinweise zur Teams-Integration + +* Slack kann auf den von Ihnen erstellten Teams-Kanal keine RBAC-Regeln anwenden. Dort werden daher Benachrichtigungen für das gesamte DefectDojo-System geteilt. In DefectDojo gibt es keine Möglichkeit, systemweite Teams-Benachrichtigungen nach Produkttyp, Produkt oder Engagement zu filtern. +* DefectDojo kann keine persönlichen Benachrichtigungen an Benutzer in Microsoft Teams senden. + +## Systemweite E-Mail-Benachrichtigungen einrichten + +Benachrichtigungen aus DefectDojo können auch an eine bestimmte E-Mail-Adresse gesendet werden. + +1. Navigieren Sie auf der Seite „Systemeinstellungen“ (**Konfiguration > Systemeinstellungen** in der klassischen UI bzw. **Enterprise-Einstellungen > Systemeinstellungen** in der Pro-UI) zum Abschnitt für E-Mail-Benachrichtigungen. + +2. Aktivieren Sie das Kontrollkästchen **E-Mail-Benachrichtigungen aktivieren** und geben Sie dann die E-Mail-Adresse ein, an die diese Benachrichtigungen gesendet werden sollen (mail notifications to). + +![image](images/notifs_email.png) + +Beachten Sie, dass DefectDojo auf diese E-Mails keine RBAC-Filterung anwenden kann - sie werden für alle Aktivitäten in DefectDojo gesendet. Wenn Sie einen stärker angepassten Satz von E-Mail-Benachrichtigungen versenden möchten, richten Sie besser [persönliche Benachrichtigungen](../configure_personal_notifs) mit einem Benutzer- oder Servicekonto ein, das mit der passenden Adresse verknüpft ist. diff --git a/docs/content/admin/notifications/email_slack_teams.es.md b/docs/content/admin/notifications/email_slack_teams.es.md new file mode 100644 index 00000000000..3bab067dbd1 --- /dev/null +++ b/docs/content/admin/notifications/email_slack_teams.es.md @@ -0,0 +1,142 @@ +--- +title: Configurar notificaciones por correo electrónico, Slack o Teams +description: Configure Microsoft Teams para recibir notificaciones +aliases: +- /es/en/customize_dojo/notifications/email_slack_teams +--- + +**Necesitará acceso de superusuario para usar la página de Configuración del sistema, lo cual es necesario para completar este proceso.** + +Las notificaciones pueden enviarse a Slack o Teams cuando se activan determinados eventos en DefectDojo. + +## Configuración de notificaciones de Slack + +DefectDojo puede publicar notificaciones de Slack de dos formas distintas: + +* Notificaciones a nivel de sistema, que se enviarán a un único canal de Slack +* Notificaciones personales, que solo se enviarán a usuarios específicos. + +A continuación se muestra un ejemplo de una notificación de Slack enviada desde DefectDojo: +​ +![image](images/Configure_a_Slack_Integration.png) + +DefectDojo no cuenta con una aplicación de Slack dedicada, pero puede crear una fácilmente para su espacio de trabajo siguiendo esta guía. Se requiere una aplicación de Slack para que las notificaciones tanto del sistema como personales se envíen correctamente. + +### Crear una aplicación de Slack + +Para configurar una conexión de Slack con DefectDojo, deberá crear una aplicación de Slack personalizada. + +1. Comience este proceso desde la página de aplicaciones de Slack: . +2. Haga clic en «**Create New App**». +3. Seleccione «**From App Manifest**». +4. Seleccione su espacio de trabajo de Slack en el menú. +5. Ingrese su App Manifest: puede copiar y pegar este archivo JSON, que incluye todos los ajustes de permisos necesarios para permitir que la integración de Slack se ejecute. +​ +``` +{ + "_metadata": { + "major_version": 1, + "minor_version": 1 + }, + "display_information": { + "name": "DefectDojo", + "description": "Notifications from DefectDojo. See https://docs.defectdojo.com/en/notifications/configure-a-slack-integration/ for configuration steps.", + "background_color": "#0000AA" + }, + "features": { + "bot_user": { + "display_name": "DefectDojo Notifications" + } + }, + "oauth_config": { + "scopes": { + "bot": [ + "chat:write", + "chat:write.customize", + "chat:write.public", + "incoming-webhook", + "users:read", + "users:read.email" + ] + }, + "redirect_urls": [ + "https://slack.com/oauth/v2/authorize" + ] + } + } +``` + +Revise el App Summary y haga clic en Create App cuando haya terminado. Complete la instalación haciendo clic en el botón **Install To Workplace**. + +### Configurar su integración de Slack en DefectDojo + +Ahora deberá configurar la integración de Slack en DefectDojo para completarla. + +**Necesitará acceso de superusuario para acceder a la página de Configuración del sistema de DefectDojo.** + +1. Navegue a la página App Information de su aplicación de Slack, desde . Esta será la aplicación creada en la primera sección - **Crear una aplicación de Slack**. +​ +2. Busque su OAuth Access Token. Puede encontrarlo en la barra lateral de Slack - **Features / OAuth & Permissions**. Copie el **Bot User OAuth Token. +​** + +![image](images/Configure_a_Slack_Integration_2.png) + +3. Abra DefectDojo en una pestaña nueva y navegue a **Configuration > System Settings** desde la barra lateral. (En la interfaz Pro, este formulario se encuentra en **Enterprise Settings > System Settings**.) +4. Marque la casilla **Enable Slack notifications**. +5. Pegue el **Bot User OAuth Token** del paso 1 en el campo **Slack token**. +6. El campo **Slack Channel** debe corresponder al canal de su espacio de trabajo donde desea que el bot de DefectDojo escriba las notificaciones. +7. Si desea cambiar el nombre del bot de DefectDojo, puede ingresar un nombre personalizado aquí. Si no lo hace, se usará **DefectDojo Notifications**, según lo definido en el App Manifest de Slack. + +Una vez completado este proceso, DefectDojo podrá enviar notificaciones a nivel de sistema a este canal. Seleccione las notificaciones que desea enviar desde la [página de Notificaciones del sistema](). + +![image](images/Configure_a_Slack_Integration_3.png) + +#### Notas sobre las notificaciones a nivel de sistema en Slack: + +Slack no puede aplicar ninguna regla de RBAC al canal de Slack que está creando, por lo que compartirá notificaciones de todo el sistema DefectDojo. No existe ningún método en DefectDojo para filtrar las notificaciones de Slack a nivel de sistema por Tipo de producto, Producto o Compromiso. + +Si desea aplicar un filtrado basado en RBAC a sus mensajes de Slack, habilitar las notificaciones personales de Slack es una mejor opción. + +### Enviar notificaciones personales a Slack + +Si su equipo tiene habilitada una integración de Slack (mediante el proceso anterior), los usuarios individuales también pueden configurar notificaciones para enviarlas directamente a su canal personal de Slackbot. + +1. Comience navegando a su página de Perfil personal en DefectDojo. Encuéntrela haciendo clic en el **icono** 👤 en la esquina superior derecha. Seleccione su nombre de usuario de DefectDojo en la lista. (👤 **paul** en nuestro ejemplo) +​ +![image](images/Configure_a_Slack_Integration_4.png) + +2. Configure su **Slack Email Address** en el menú. Este campo se encuentra anidado dentro de **Additional Contact Information** en DefectDojo. + +Ahora puede [configurar notificaciones específicas](../about_notifications/) para que se envíen a su canal personal de Slackbot. Otros usuarios de su canal de Slack no recibirán estos mensajes. + +## Configuración de notificaciones de Microsoft Teams + +Microsoft Teams puede recibir notificaciones en un canal específico. Para ello, deberá **configurar un webhook entrante** en el canal donde desea recibir los mensajes. + +Tenga en cuenta que Microsoft retirará los antiguos [webhooks de Office Connector](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook?tabs=newteams%2Cdotnet); use un nuevo webhook basado en Power Automate Workflow, como se documenta a continuación. + +1. Complete el proceso indicado en la **[documentación de Microsoft Teams](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498)** para crear un nuevo Incoming Webhook. Tenga a mano su enlace único logic.azure.com, ya que lo necesitará en los pasos siguientes. Puede crear el webhook para un canal o para un chat específico. +​ +![image](images/Configure_a_Microsoft_Teams_Integration.png) +2. En DefectDojo, navegue a **Configuration > System Settings** desde la barra lateral. (En la interfaz Pro, este formulario se encuentra en **Enterprise Settings > System Settings**.) +3. Marque la casilla **Enable Microsoft Teams notifications**. Esto abrirá una sección oculta del formulario, etiquetada «**Msteams url**». +​ +![image](images/Configure_a_Microsoft_Teams_Integration_2.png) +4. Pegue la URL de logic.azure.com (creada en el paso 1) en el cuadro **Msteams url**. Su aplicación de Teams ahora escuchará las notificaciones entrantes de DefectDojo y las publicará en el canal que seleccionó. + +### Notas sobre la integración con Teams + +* Slack no puede aplicar ninguna regla de RBAC al canal de Teams que está creando, por lo que compartirá notificaciones de todo el sistema DefectDojo. No existe ningún método en DefectDojo para filtrar las notificaciones de Teams a nivel de sistema por Tipo de producto, Producto o Compromiso. +* DefectDojo no puede enviar notificaciones personales a usuarios en Microsoft Teams. + +## Configuración de notificaciones por correo electrónico a nivel de sistema + +Las notificaciones de DefectDojo también pueden enviarse a una dirección de correo electrónico específica. + +1. Desde la página de Configuración del sistema (**Configuration > System Settings** en la interfaz clásica, o **Enterprise Settings > System Settings** en la interfaz Pro), navegue hasta Enable Mail (email) Notifications. + +2. Marque la casilla **Enable mail notifications** y luego ingrese la dirección de correo electrónico a la que desea que se envíen estas notificaciones (mail notifications to). + +![image](images/notifs_email.png) + +Tenga en cuenta que DefectDojo no puede aplicar filtrado RBAC a estos correos electrónicos: se enviarán para toda la actividad en DefectDojo. Si prefiere enviar un conjunto más personalizado de notificaciones por correo electrónico, es mejor configurar [Notificaciones personales](../configure_personal_notifs) con un usuario o cuenta de servicio vinculada a la dirección correspondiente. diff --git a/docs/content/admin/notifications/email_slack_teams.fr.md b/docs/content/admin/notifications/email_slack_teams.fr.md new file mode 100644 index 00000000000..d41da27cdc0 --- /dev/null +++ b/docs/content/admin/notifications/email_slack_teams.fr.md @@ -0,0 +1,142 @@ +--- +title: Configurer les notifications Email, Slack ou Teams +description: Configurer Microsoft Teams pour recevoir des notifications +aliases: +- /fr/en/customize_dojo/notifications/email_slack_teams +--- + +**Vous aurez besoin d'un accès Superuser pour utiliser la page System Settings, requise pour effectuer cette procédure.** + +Des notifications peuvent être envoyées vers Slack ou Teams lorsque certains événements se déclenchent dans DefectDojo. + +## Configuration des notifications Slack + +DefectDojo peut publier des notifications Slack de deux manières différentes : + +* Des notifications à l'échelle du système, qui seront envoyées à un seul canal Slack +* Des notifications personnelles, qui ne seront envoyées qu'à des utilisateurs spécifiques. + +Voici un exemple de notification Slack envoyée depuis DefectDojo : +​ +![image](images/Configure_a_Slack_Integration.png) + +DefectDojo ne dispose pas d'une application Slack dédiée, mais il est facile d'en créer une pour votre espace de travail en suivant ce guide. Une application Slack est nécessaire pour que les notifications Système et Personnelles soient envoyées correctement. + +### Créer une application Slack + +Pour configurer une connexion Slack à DefectDojo, vous devrez créer une application Slack personnalisée. + +1. Commencez cette procédure depuis la page Slack Apps : . +2. Cliquez sur '**Create New App**'. +3. Sélectionnez '**From App Manifest**'. +4. Sélectionnez votre espace de travail Slack dans le menu. +5. Saisissez votre App Manifest \- vous pouvez copier\-coller ce fichier JSON, qui inclut tous les paramètres d'autorisation nécessaires au bon fonctionnement de l'intégration Slack. +​ +``` +{ + "_metadata": { + "major_version": 1, + "minor_version": 1 + }, + "display_information": { + "name": "DefectDojo", + "description": "Notifications from DefectDojo. See https://docs.defectdojo.com/en/notifications/configure-a-slack-integration/ for configuration steps.", + "background_color": "#0000AA" + }, + "features": { + "bot_user": { + "display_name": "DefectDojo Notifications" + } + }, + "oauth_config": { + "scopes": { + "bot": [ + "chat:write", + "chat:write.customize", + "chat:write.public", + "incoming-webhook", + "users:read", + "users:read.email" + ] + }, + "redirect_urls": [ + "https://slack.com/oauth/v2/authorize" + ] + } + } +``` + +Vérifiez l'App Summary, puis cliquez sur Create App une fois terminé. Terminez l'installation en cliquant sur le bouton **Install To Workplace**. + +### Configurer votre intégration Slack dans DefectDojo + +Vous devez maintenant configurer l'intégration Slack sur DefectDojo pour terminer l'intégration. + +**Vous aurez besoin d'un accès Superuser pour accéder à la page System Settings de DefectDojo.** + +1. Accédez à la page App Information de votre application Slack, depuis . Il s'agit de l'application créée dans la première section \- **Create a Slack application**. +​ +2. Trouvez votre OAuth Access Token. Vous le trouverez dans la barre latérale Slack \- **Features / OAuth \& Permissions**. Copiez le **Bot User OAuth Token. +​** + +![image](images/Configure_a_Slack_Integration_2.png) + +3. Ouvrez DefectDojo dans un nouvel onglet, et accédez à **Configuration \> System Settings** depuis la barre latérale. (Dans l'interface Pro, ce formulaire se trouve sous **Enterprise Settings > System Settings**.) +4. Cochez la case **Enable Slack notifications**. +5. Collez le **Bot User OAuth Token** obtenu à l'étape 1 dans le champ **Slack token**. +6. Le champ **Slack Channel** doit correspondre au canal de votre espace de travail dans lequel vous souhaitez que les notifications soient publiées par un bot DefectDojo. +7. Si vous souhaitez changer le nom du bot DefectDojo, vous pouvez saisir un nom personnalisé ici. Sinon, il utilisera **DefectDojo Notifications**, tel que défini dans le Slack App Manifest. + +Une fois cette procédure terminée, DefectDojo peut envoyer des notifications à l'échelle du système vers ce canal. Sélectionnez les notifications que vous souhaitez envoyer depuis la [page System Notifications](). + +![image](images/Configure_a_Slack_Integration_3.png) + +#### Remarques sur les notifications à l'échelle du système dans Slack\: + +Slack ne peut appliquer aucune règle RBAC au canal Slack que vous créez, et partagera donc les notifications pour l'ensemble du système DefectDojo. DefectDojo ne propose aucun moyen de filtrer les notifications Slack à l'échelle du système par Product Type, Produit ou Engagement. + +Si vous souhaitez appliquer un filtrage basé sur le RBAC à vos messages Slack, il est préférable d'activer les notifications personnelles depuis Slack. + +### Envoyer des notifications personnelles à Slack + +Si votre équipe a activé une intégration Slack (via la procédure ci\-dessus), chaque utilisateur peut également configurer des notifications à envoyer directement vers son canal Slackbot personnel. + +1. Commencez par accéder à votre page de profil personnelle sur DefectDojo. Vous la trouverez en cliquant sur l'**icône** 👤 en haut à droite. Sélectionnez votre nom d'utilisateur DefectDojo dans la liste. (👤 **paul** dans notre exemple) +​ +![image](images/Configure_a_Slack_Integration_4.png) + +2. Définissez votre **Slack Email Address** dans le menu. Ce champ se trouve sous **Additional Contact Information** dans DefectDojo. + +Vous pouvez maintenant [définir des notifications spécifiques](../about_notifications/) à envoyer vers votre canal Slackbot personnel. Les autres utilisateurs de votre canal Slack ne recevront pas ces messages. + +## Configuration des notifications Microsoft Teams + +Microsoft Teams peut recevoir des notifications sur un canal spécifique. Pour cela, vous devrez **configurer un webhook entrant** sur le canal où vous souhaitez recevoir les messages. + +Notez que les anciens [webhooks Office Connector](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook?tabs=newteams%2Cdotnet) seront retirés par Microsoft ; utilisez un nouveau webhook basé sur un Power Automate Workflow, comme indiqué ci\-dessous. + +1. Suivez la procédure décrite dans la **[documentation Microsoft Teams](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498)** pour créer un nouveau Incoming Webhook. Gardez votre lien logic.azure.com unique à portée de main, car vous en aurez besoin dans les étapes suivantes. Vous pouvez créer un webhook pour un canal ou pour une discussion spécifique. +​ +![image](images/Configure_a_Microsoft_Teams_Integration.png) +2. Dans DefectDojo, accédez à **Configuration \> System Settings** depuis la barre latérale. (Dans l'interface Pro, ce formulaire se trouve sous **Enterprise Settings > System Settings**.) +3. Cochez la case **Enable Microsoft Teams notifications**. Cela ouvrira une section masquée du formulaire, intitulée **'Msteams url**'. +​ +![image](images/Configure_a_Microsoft_Teams_Integration_2.png) +4. Collez l'URL logic.azure.com (créée à l'étape 1\) dans le champ **Msteams url**. Votre application Teams écoutera désormais les notifications entrantes de DefectDojo et les publiera dans le canal que vous avez sélectionné. + +### Remarques sur l'intégration Teams + +* Slack ne peut appliquer aucune règle RBAC au canal Teams que vous créez, et partagera donc les notifications pour l'ensemble du système DefectDojo. DefectDojo ne propose aucun moyen de filtrer les notifications Teams à l'échelle du système par Product Type, Produit ou Engagement. +* DefectDojo ne peut pas envoyer de notifications personnelles aux utilisateurs sur Microsoft Teams. + +## Configuration des notifications par e-mail à l'échelle du système + +Les notifications de DefectDojo peuvent également être envoyées à une adresse e\-mail spécifique. + +1. Depuis la page System Settings (**Configuration > System Settings** dans l'interface Classic, ou **Enterprise Settings > System Settings** dans l'interface Pro) accédez à Enable Mail (email) Notifications. + +2. Cochez la case **Enable mail notifications**, puis saisissez l'adresse e\-mail à laquelle vous souhaitez que ces notifications soient envoyées (mail notifications to). + +![image](images/notifs_email.png) + +Notez que DefectDojo ne peut pas appliquer de filtrage RBAC à ces e\-mails \- ils seront envoyés pour toute l'activité de DefectDojo. Si vous préférez envoyer un ensemble plus personnalisé de notifications par e\-mail, il est préférable de configurer des [Notifications personnelles](../configure_personal_notifs) avec un utilisateur ou un compte de service lié à l'adresse appropriée. diff --git a/docs/content/admin/notifications/email_slack_teams.ja.md b/docs/content/admin/notifications/email_slack_teams.ja.md new file mode 100644 index 00000000000..b1ae9c54cea --- /dev/null +++ b/docs/content/admin/notifications/email_slack_teams.ja.md @@ -0,0 +1,142 @@ +--- +title: メール、Slack、Teams通知の設定 +description: Microsoft Teamsで通知を受信するための設定 +aliases: +- /ja/en/customize_dojo/notifications/email_slack_teams +--- + +**このプロセスを完了するには、システム設定ページを使用するためのスーパーユーザー権限が必要です。** + +DefectDojoで特定のイベントがトリガーされると、SlackまたはTeamsに通知をプッシュできます。 + +## Slack通知の設定 + +DefectDojoは、2つの異なる方法でSlack通知を投稿できます。 + +* システム全体の通知：単一のSlackチャンネルに送信されます +* 個人通知：特定のユーザーにのみ送信されます + +DefectDojoから送信されたSlack通知の例を以下に示します。 +​ +![image](images/Configure_a_Slack_Integration.png) + +DefectDojoには専用のSlackアプリはありませんが、このガイドに従うことでワークスペース用に簡単に作成できます。システム通知と個人通知の両方を正しく送信するには、Slackアプリが必要です。 + +### Slackアプリケーションを作成する + +DefectDojoとのSlack連携を設定するには、カスタムSlackアプリを作成する必要があります。 + +1. Slack Appsページからこのプロセスを開始します: 。 +2. 「**Create New App**」をクリックします。 +3. 「**From App Manifest**」を選択します。 +4. メニューからSlackワークスペースを選択します。 +5. App Manifestを入力します。Slack連携の実行に必要なすべての権限設定を含む、このJSONファイルをコピー&ペーストできます。 +​ +``` +{ + "_metadata": { + "major_version": 1, + "minor_version": 1 + }, + "display_information": { + "name": "DefectDojo", + "description": "Notifications from DefectDojo. See https://docs.defectdojo.com/en/notifications/configure-a-slack-integration/ for configuration steps.", + "background_color": "#0000AA" + }, + "features": { + "bot_user": { + "display_name": "DefectDojo Notifications" + } + }, + "oauth_config": { + "scopes": { + "bot": [ + "chat:write", + "chat:write.customize", + "chat:write.public", + "incoming-webhook", + "users:read", + "users:read.email" + ] + }, + "redirect_urls": [ + "https://slack.com/oauth/v2/authorize" + ] + } + } +``` + +App Summaryを確認し、完了したらCreate Appをクリックします。**Install To Workplace**ボタンをクリックしてインストールを完了します。 + +### DefectDojoでSlack連携を設定する + +連携を完了するには、DefectDojo側でSlack連携を設定する必要があります。 + +**DefectDojoのシステム設定ページにアクセスするには、スーパーユーザー権限が必要です。** + +1. から、SlackアプリのApp Informationページに移動します。これは最初のセクション「**Slackアプリケーションを作成する**」で作成したアプリです。 +​ +2. OAuthアクセストークンを見つけます。これはSlackのサイドバーの「**Features / OAuth & Permissions**」にあります。**Bot User OAuth Token**をコピーします。 +​ + +![image](images/Configure_a_Slack_Integration_2.png) + +3. 新しいタブでDefectDojoを開き、サイドバーから**Configuration > System Settings**に移動します。（Pro UIでは、このフォームは**Enterprise Settings > System Settings**にあります。） +4. **Enable Slack notifications**チェックボックスをオンにします。 +5. 手順1の**Bot User OAuth Token**を**Slack token**フィールドに貼り付けます。 +6. **Slack Channel**フィールドには、DefectDojoボットに通知を投稿させたいワークスペース内のチャンネルを指定します。 +7. DefectDojoボットの名前を変更したい場合は、ここにカスタム名を入力できます。指定しない場合は、Slack App Manifestで定義された**DefectDojo Notifications**が使用されます。 + +このプロセスが完了すると、DefectDojoはこのチャンネルにシステム全体の通知を送信できるようになります。送信したい通知は[System Notificationsページ]()から選択してください。 + +![image](images/Configure_a_Slack_Integration_3.png) + +#### Slackにおけるシステム全体通知に関する注意事項: + +Slackは、作成したSlackチャンネルにRBACルールを適用できないため、DefectDojoシステム全体の通知が共有されることになります。DefectDojoには、システム全体のSlack通知を製品タイプ、製品、またはエンゲージメントでフィルタリングする方法はありません。 + +SlackメッセージにRBACベースのフィルタリングを適用したい場合は、Slackの個人通知を有効にする方が適しています。 + +### Slackへの個人通知の送信 + +チームで（上記のプロセスにより）Slack連携が有効になっている場合、各ユーザーは自分専用のSlackbotチャンネルに直接通知を送るよう設定することもできます。 + +1. まず、DefectDojoの個人用Profileページに移動します。右上隅の👤**アイコン**をクリックして見つけます。リストからご自身のDefectDojoユーザー名を選択します。（この例では👤**paul**） +​ +![image](images/Configure_a_Slack_Integration_4.png) + +2. メニューで**Slack Email Address**を設定します。このフィールドは、DefectDojoの**Additional Contact Information**の下に配置されています。 + +これで、自分専用のSlackbotチャンネルに送信する[特定の通知を設定](../about_notifications/)できるようになります。同じSlackチャンネルの他のユーザーには、これらのメッセージは届きません。 + +## Microsoft Teams通知の設定 + +Microsoft Teamsは、特定のチャンネルで通知を受信できます。これを行うには、メッセージを受信したいチャンネルで**受信Webhookを設定**する必要があります。 + +旧来の[Office Connector webhooks](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook?tabs=newteams%2Cdotnet)はMicrosoftによって廃止される予定であるため、以下で説明する新しいPower Automate Workflowベースのwebhookを使用してください。 + +1. 新しいIncoming Webhookを作成するために、**[Microsoft Teams Documentation](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498)**に記載されている手順を完了します。後の手順で必要になるため、固有のlogic.azure.comリンクを手元に控えておいてください。webhookはチャンネル単位でも特定のチャット単位でも作成できます。 +​ +![image](images/Configure_a_Microsoft_Teams_Integration.png) +2. DefectDojoで、サイドバーから**Configuration > System Settings**に移動します。（Pro UIでは、このフォームは**Enterprise Settings > System Settings**にあります。） +3. **Enable Microsoft Teams notifications**チェックボックスをオンにします。これにより、フォームの隠れたセクション「**Msteams url**」が表示されます。 +​ +![image](images/Configure_a_Microsoft_Teams_Integration_2.png) +4. 手順1で作成したlogic.azure.com URLを**Msteams url**ボックスに貼り付けます。これで、TeamsアプリはDefectDojoからの受信通知をリッスンし、選択したチャンネルに投稿するようになります。 + +### Teams連携に関する注意事項 + +* Slackは、作成したTeamsチャンネルにRBACルールを適用できないため、DefectDojoシステム全体の通知が共有されることになります。DefectDojoには、システム全体のTeams通知を製品タイプ、製品、またはエンゲージメントでフィルタリングする方法はありません。 +* DefectDojoは、Microsoft Teams上のユーザーに個人通知を送信することはできません。 + +## システム全体のメール通知の設定 + +DefectDojoからの通知は、特定のメールアドレスに送信することもできます。 + +1. System Settingsページ（Classic UIでは**Configuration > System Settings**、Pro UIでは**Enterprise Settings > System Settings**）から、Enable Mail (email) Notificationsに移動します。 + +2. **Enable mail notifications**チェックボックスをオンにし、これらの通知を送信したいメールアドレス（mail notifications to）を入力します。 + +![image](images/notifs_email.png) + +DefectDojoはこれらのメールにRBACフィルタリングを適用できない点に注意してください。DefectDojo内のすべてのアクティビティについて送信されます。よりカスタマイズされたメール通知のセットを送信したい場合は、適切なアドレスに紐づいたユーザーまたはサービスアカウントで[個人通知](../configure_personal_notifs)を設定する方が良いでしょう。 diff --git a/docs/content/admin/sso/PRO__auth0.de.md b/docs/content/admin/sso/PRO__auth0.de.md new file mode 100644 index 00000000000..a0c870fb5f1 --- /dev/null +++ b/docs/content/admin/sso/PRO__auth0.de.md @@ -0,0 +1,33 @@ +--- +title: Auth0 +description: Konfigurieren Sie Auth0 SSO in DefectDojo Pro +weight: 3 +audience: pro +--- + +DefectDojo Pro unterstützt die Anmeldung über Auth0. Open-Source-DefectDojo enthält kein SSO — siehe [Authorized Users](/admin/user_management/os__authorized_users/) für die Zugriffskontrolle in der Open-Source-Version. + +## Voraussetzungen + +Führen Sie die folgenden Schritte in Ihrem Auth0-Dashboard aus, bevor Sie DefectDojo konfigurieren: + +1. Erstellen Sie eine neue Anwendung: **Applications > Create Application > Single Page Web Application**. + +2. Konfigurieren Sie die Anwendung: + - **Name:** `DefectDojo` + - **Allowed Callback URLs:** `https://your-instance.cloud.defectdojo.com/complete/auth0/` + +3. Notieren Sie sich die folgenden Werte — Sie benötigen sie in DefectDojo: + - **Domain** + - **Client ID** + - **Client Secret** + +## Konfiguration + +Gehen Sie in DefectDojo zu **Enterprise Settings > OAuth Settings**, wählen Sie **Auth0** aus und füllen Sie das Formular aus: + +- **Auth0 OAuth Key** — geben Sie Ihre **Client ID** ein +- **Auth0 OAuth Secret** — geben Sie Ihr **Client Secret** ein +- **Auth0 Domain** — geben Sie Ihre **Domain** ein + +Aktivieren Sie **Enable Auth0 OAuth**, um der DefectDojo-Anmeldeseite eine Schaltfläche **Login With Auth0** hinzuzufügen. diff --git a/docs/content/admin/sso/PRO__auth0.es.md b/docs/content/admin/sso/PRO__auth0.es.md new file mode 100644 index 00000000000..adb686e6e8e --- /dev/null +++ b/docs/content/admin/sso/PRO__auth0.es.md @@ -0,0 +1,33 @@ +--- +title: Auth0 +description: Configure el SSO de Auth0 en DefectDojo Pro +weight: 3 +audience: pro +--- + +DefectDojo Pro admite el inicio de sesión mediante Auth0. DefectDojo de código abierto no incluye SSO — consulte [Authorized Users](/admin/user_management/os__authorized_users/) para el control de acceso de código abierto. + +## Requisitos previos + +Complete los siguientes pasos en su panel de Auth0 antes de configurar DefectDojo: + +1. Cree una nueva aplicación: **Applications > Create Application > Single Page Web Application**. + +2. Configure la aplicación: + - **Name:** `DefectDojo` + - **Allowed Callback URLs:** `https://your-instance.cloud.defectdojo.com/complete/auth0/` + +3. Anote los siguientes valores — los necesitará en DefectDojo: + - **Domain** + - **Client ID** + - **Client Secret** + +## Configuración + +En DefectDojo, vaya a **Enterprise Settings > OAuth Settings**, seleccione **Auth0** y complete el formulario: + +- **Auth0 OAuth Key** — introduzca su **Client ID** +- **Auth0 OAuth Secret** — introduzca su **Client Secret** +- **Auth0 Domain** — introduzca su **Domain** + +Marque **Enable Auth0 OAuth** para añadir un botón **Login With Auth0** a la página de inicio de sesión de DefectDojo. diff --git a/docs/content/admin/sso/PRO__auth0.fr.md b/docs/content/admin/sso/PRO__auth0.fr.md new file mode 100644 index 00000000000..b295beb2aec --- /dev/null +++ b/docs/content/admin/sso/PRO__auth0.fr.md @@ -0,0 +1,33 @@ +--- +title: Auth0 +description: Configurer le SSO Auth0 dans DefectDojo Pro +weight: 3 +audience: pro +--- + +DefectDojo Pro prend en charge la connexion via Auth0. DefectDojo open source n'inclut pas le SSO — voir [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +## Prérequis + +Effectuez les étapes suivantes dans votre tableau de bord Auth0 avant de configurer DefectDojo : + +1. Créez une nouvelle application : **Applications > Create Application > Single Page Web Application**. + +2. Configurez l'application : + - **Name:** `DefectDojo` + - **Allowed Callback URLs:** `https://your-instance.cloud.defectdojo.com/complete/auth0/` + +3. Notez les valeurs suivantes — vous en aurez besoin dans DefectDojo : + - **Domain** + - **Client ID** + - **Client Secret** + +## Configuration + +Dans DefectDojo, accédez à **Enterprise Settings > OAuth Settings**, sélectionnez **Auth0**, et remplissez le formulaire : + +- **Auth0 OAuth Key** — saisissez votre **Client ID** +- **Auth0 OAuth Secret** — saisissez votre **Client Secret** +- **Auth0 Domain** — saisissez votre **Domain** + +Cochez **Enable Auth0 OAuth** pour ajouter un bouton **Login With Auth0** à la page de connexion de DefectDojo. diff --git a/docs/content/admin/sso/PRO__auth0.ja.md b/docs/content/admin/sso/PRO__auth0.ja.md new file mode 100644 index 00000000000..b7d868f273f --- /dev/null +++ b/docs/content/admin/sso/PRO__auth0.ja.md @@ -0,0 +1,33 @@ +--- +title: Auth0 +description: DefectDojo ProでAuth0 SSOを設定する +weight: 3 +audience: pro +--- + +DefectDojo ProはAuth0によるログインをサポートしています。オープンソース版のDefectDojoにはSSOは含まれていません。オープンソース版のアクセス制御については[Authorized Users](/admin/user_management/os__authorized_users/)を参照してください。 + +## Prerequisites + +DefectDojoを設定する前に、Auth0ダッシュボードで以下の手順を完了してください。 + +1. Create a new application: **Applications > Create Application > Single Page Web Application**. + +2. Configure the application: + - **Name:** `DefectDojo` + - **Allowed Callback URLs:** `https://your-instance.cloud.defectdojo.com/complete/auth0/` + +3. 以下の値を控えておきます。DefectDojo側で必要になります。 + - **Domain** + - **Client ID** + - **Client Secret** + +## Configuration + +DefectDojoで**Enterprise Settings > OAuth Settings**に移動し、**Auth0**を選択してフォームに入力します。 + +- **Auth0 OAuth Key** — **Client ID**を入力します +- **Auth0 OAuth Secret** — **Client Secret**を入力します +- **Auth0 Domain** — **Domain**を入力します + +**Enable Auth0 OAuth**をチェックすると、DefectDojoのログインページに**Login With Auth0**ボタンが追加されます。 diff --git a/docs/content/admin/sso/PRO__authorization_connectors.de.md b/docs/content/admin/sso/PRO__authorization_connectors.de.md new file mode 100644 index 00000000000..9efb31ec512 --- /dev/null +++ b/docs/content/admin/sso/PRO__authorization_connectors.de.md @@ -0,0 +1,81 @@ +--- +title: Authorization Connectors +description: 'Sehen Sie alle Identitätsanbieter auf einer Seite: welche konfiguriert + sind, welche aktiviert sind und welches Protokoll jeder verwendet' +weight: 1 +audience: pro +--- + +Authorization Connectors ist eine einzige Seite, die jeden von DefectDojo Pro unterstützten Identitätsanbieter auflistet, mit dem Status, in dem sich jeder befindet, und dem Protokoll, das er verwendet. Bevor es diese Seite gab, hatte jeder Anbieter sein eigenes Einstellungsformular, und es gab keine Möglichkeit zu beantworten, „was ist auf dieser Instanz eingerichtet?", ohne alle einzeln zu öffnen. + +Authorization Connectors ist eine **DefectDojo Pro**-Funktion. Sie finden sie unter **Connect > Authorization**. Nur ein **Superuser** kann die Konfiguration von Identitätsanbietern einsehen oder ändern. + +![Authorization Connectors](images/authorization_connectors.png) + +## Wie die Seite aufgebaut ist + +Die Anbieter sind in zwei Abschnitte unterteilt, und jeder Abschnitt ist alphabetisch sortiert mit einer Anzahl neben seiner Überschrift: + +* **Configured Providers** — Anbieter, die auf dieser Instanz eingerichtet wurden, unabhängig davon, ob sie derzeit aktiviert sind. +* **Available Providers** — Anbieter, die unterstützt werden, aber noch nicht eingerichtet sind. + +Die Unterteilung erfolgt bewusst nach *konfiguriert*, nicht nach *aktiviert*. Ein Anbieter, der eingerichtet und anschließend deaktiviert wurde, bleibt unter Configured Providers, da genau dort die Person, die ihn eingerichtet hat, danach suchen wird. Sein Status wird stattdessen auf der Kachel angezeigt. + +Jede Kachel zeigt: + +| | | +| --- | --- | +| **Logo und Name** | Der Anbieter, benannt ohne sein Protokoll | +| **Protokoll-Tag** | `SAML 2.0`, `OAuth 2.0`, `OpenID Connect` oder `LDAP` | +| **Status-Tag** | `Enabled`, `Disabled` oder `Not configured` | +| **`BETA`-Tag** | Vorhanden bei Anbietern, die sich noch in der Beta-Phase befinden | +| **Aktion** | **Manage Configuration** für einen konfigurierten Anbieter, **Configure** für einen verfügbaren | + +Beide Abschnitte verfügen über ein Suchfeld, das nach Anbietername und Protokoll sucht, sodass eine Suche nach `oauth` die Seite auf die OAuth-Anbieter eingrenzt. + +![Available providers](images/authorization_available.png) + +## Eine Konfiguration pro Anbieter + +Die Einstellungen eines Identitätsanbieters bestehen aus einem einzigen Satz von Werten pro Anbieter und Instanz — eine Okta-Anwendung, ein SAML-Identitätsanbieter, ein LDAP-Verzeichnis. Die Kacheln weisen darauf hin, und es gibt kein „weiteren hinzufügen": Um zu ändern, wie ein Anbieter eingerichtet ist, bearbeiten Sie die bereits vorhandene Konfiguration. + +Dadurch unterscheidet sich Authorization Connectors von den [Connector-Galerien](/connectors/upstream/about/), bei denen ein Tool viele Konfigurationen nebeneinander haben kann. + +## Die drei Status und ihre Bedeutung + +| Status | Bedeutung | Nächster Schritt | +| --- | --- | --- | +| **Enabled** | Konfiguriert und akzeptiert Anmeldungen | Nichts | +| **Disabled** | Konfiguriert, aber deaktiviert — die Schaltfläche erscheint nicht auf der Anmeldeseite | Über die Konfiguration wieder aktivieren, wenn Sie sie zurückhaben möchten | +| **Not configured** | Unterstützt, aber noch nichts ausgefüllt | **Configure**, um sie einzurichten | + +Die Auswahl eines Anbieters öffnet direkt dessen eigenes Einstellungsformular. Es gibt keine zwischengeschaltete Anbieterauswahl. + +## Unterstützte Anbieter + +| Anbieter | Protokoll | Einrichtungsanleitung | +| --- | --- | --- | +| Auth0 | OAuth 2.0 | [Auth0](/admin/sso/pro__auth0/) | +| GitHub Enterprise | OAuth 2.0 | [GitHub Enterprise](/admin/sso/pro__github_enterprise/) | +| GitLab | OAuth 2.0 | [GitLab](/admin/sso/pro__gitlab/) | +| Google | OAuth 2.0 | [Google](/admin/sso/pro__google/) | +| Keycloak | OAuth 2.0 | [KeyCloak](/admin/sso/pro__keycloak/) | +| LDAP | LDAP | [LDAP](/admin/sso/pro__ldap/) | +| Microsoft Entra ID | OAuth 2.0 | [Azure Active Directory](/admin/sso/pro__azure_ad/) | +| Okta | OAuth 2.0 | [Okta](/admin/sso/pro__okta/) | +| OpenID Connect | OpenID Connect | [OIDC](/admin/sso/pro__oidc/) | +| SAML | SAML 2.0 | [SAML](/admin/sso/pro__saml/) | + +Die Seite zeigt an, welchen Konfigurations*status* ein Anbieter hat. Sie gibt niemals die Geheimnisse der Konfiguration zurück — Client Secrets, Bind-Passwörter und Zertifikate sind nicht Teil der Daten hinter dieser Seite und lassen sich daraus nicht wieder auslesen. + +## Wenn sich ein Anbieter nicht verbinden lässt + +Authorization Connectors zeigt Ihnen, was konfiguriert ist; es zeigt Ihnen keine fehlgeschlagenen Anmeldungen. Diese werden in [Diagnostics](/admin/diagnostics/pro__diagnostics/) protokolliert, wo SSO, SAML und LDAP jeweils ihre eigenen Versuche mit dem Grund der Ablehnung melden — eine ungültige Assertion-Signatur, ein abgelehnter Bind, ein nicht übereinstimmendes Attribut. Diese Einträge sind instanzweit und daher nur für Superuser sichtbar. + +Behalten Sie mindestens ein Superuser-Konto mit Benutzername und Passwort als Rückfallebene, und denken Sie daran, dass `/login?force_login_form` das Standard-Anmeldeformular zurückgibt, falls ein Identitätsanbieter nicht mehr funktioniert. Siehe [Single Sign-On](/admin/sso/) für beides. + +## Verwandte Themen + +* [Single Sign-On](/admin/sso/) — die anbieterspezifischen Einrichtungsanleitungen und Anmeldeeinstellungen +* [Diagnostics](/admin/diagnostics/pro__diagnostics/) — warum ein Anmeldeversuch fehlgeschlagen ist +* [Connectors](/connectors/upstream/about/) — die vorgelagerte Galerie, an der sich diese Seite orientiert diff --git a/docs/content/admin/sso/PRO__authorization_connectors.es.md b/docs/content/admin/sso/PRO__authorization_connectors.es.md new file mode 100644 index 00000000000..bfaa1ec026a --- /dev/null +++ b/docs/content/admin/sso/PRO__authorization_connectors.es.md @@ -0,0 +1,81 @@ +--- +title: Authorization Connectors +description: 'Vea todos los proveedores de identidad en una sola página: cuáles están + configurados, cuáles están activados y qué protocolo utiliza cada uno' +weight: 1 +audience: pro +--- + +Authorization Connectors es una única página que enumera todos los proveedores de identidad que admite DefectDojo Pro, en qué estado se encuentra cada uno y qué protocolo utiliza. Antes de que existiera, cada proveedor vivía en su propio formulario de configuración y no había forma de responder a "¿qué está configurado en esta instancia?" sin abrirlos todos. + +Authorization Connectors es una función de **DefectDojo Pro**. Encuéntrela en **Connect > Authorization**. Solo un **Superuser** puede ver o cambiar la configuración de los proveedores de identidad. + +![Conectores de autorización](images/authorization_connectors.png) + +## Cómo está organizada la página + +Los proveedores se dividen en dos secciones, y cada sección aparece en orden alfabético con un contador junto a su encabezado: + +* **Configured Providers** — proveedores que se han configurado en esta instancia, estén o no activados actualmente. +* **Available Providers** — proveedores que son compatibles pero que aún no se han configurado. + +La división se hace deliberadamente según lo *configurado*, no lo *activado*. Un proveedor que se configuró y después se desactivó permanece en Configured Providers, porque ahí es donde lo buscará la persona que lo configuró. Su estado se muestra en la propia tarjeta. + +Cada tarjeta muestra: + +| | | +| --- | --- | +| **Logotipo y nombre** | El proveedor, indicado sin su protocolo | +| **Etiqueta de protocolo** | `SAML 2.0`, `OAuth 2.0`, `OpenID Connect`, o `LDAP` | +| **Etiqueta de estado** | `Enabled`, `Disabled`, o `Not configured` | +| **Etiqueta `BETA`** | Presente en proveedores que aún están en fase beta | +| **Acción** | **Manage Configuration** para un proveedor configurado, **Configure** para uno disponible | + +Ambas secciones tienen un cuadro de búsqueda que coincide con el nombre del proveedor y con el protocolo, de modo que buscar `oauth` reduce la página a los proveedores OAuth. + +![Proveedores disponibles](images/authorization_available.png) + +## Una configuración por proveedor + +La configuración del proveedor de identidad es un único conjunto de valores por proveedor y por instancia — una aplicación de Okta, un proveedor de identidad SAML, un directorio LDAP. Las tarjetas lo indican así, y no existe la opción de "añadir otro": para cambiar cómo está configurado un proveedor, se edita la configuración que ya existe. + +Esto es lo que diferencia a Authorization Connectors de las [galerías de conectores](/connectors/upstream/about/), donde una herramienta puede tener muchas configuraciones en paralelo. + +## Los tres estados, y qué significan + +| Status | Meaning | What to do next | +| --- | --- | --- | +| **Enabled** | Configurado y aceptando inicios de sesión | Nada | +| **Disabled** | Configurado, pero desactivado — su botón no aparecerá en la página de inicio de sesión | Vuelva a activarlo desde su configuración cuando quiera recuperarlo | +| **Not configured** | Compatible, pero aún no se ha rellenado nada | **Configure** para configurarlo | + +Al seleccionar un proveedor se abre directamente el propio formulario de configuración de ese proveedor. No hay un selector de proveedores intermedio. + +## Proveedores compatibles + +| Provider | Protocol | Setup guide | +| --- | --- | --- | +| Auth0 | OAuth 2.0 | [Auth0](/admin/sso/pro__auth0/) | +| GitHub Enterprise | OAuth 2.0 | [GitHub Enterprise](/admin/sso/pro__github_enterprise/) | +| GitLab | OAuth 2.0 | [GitLab](/admin/sso/pro__gitlab/) | +| Google | OAuth 2.0 | [Google](/admin/sso/pro__google/) | +| Keycloak | OAuth 2.0 | [KeyCloak](/admin/sso/pro__keycloak/) | +| LDAP | LDAP | [LDAP](/admin/sso/pro__ldap/) | +| Microsoft Entra ID | OAuth 2.0 | [Azure Active Directory](/admin/sso/pro__azure_ad/) | +| Okta | OAuth 2.0 | [Okta](/admin/sso/pro__okta/) | +| OpenID Connect | OpenID Connect | [OIDC](/admin/sso/pro__oidc/) | +| SAML | SAML 2.0 | [SAML](/admin/sso/pro__saml/) | + +La página informa de cuál es el *estado* de configuración de un proveedor. Nunca devuelve los secretos de la configuración — los secretos de cliente, las contraseñas de bind y los certificados no forman parte de los datos que hay detrás de esta página, y no se pueden extraer de ella. + +## Cuando un proveedor no se conecta + +Authorization Connectors le indica qué está configurado; no le muestra los inicios de sesión fallidos. Estos quedan registrados en [Diagnostics](/admin/diagnostics/pro__diagnostics/), donde SSO, SAML y LDAP informan cada uno de sus propios intentos con el motivo por el que fueron rechazados — una firma de aserción incorrecta, un bind rechazado, un atributo no coincidente. Esas filas son a nivel de instancia y, por tanto, exclusivas para superusuarios. + +Mantenga al menos una cuenta de superusuario con nombre de usuario y contraseña como respaldo, y recuerde que `/login?force_login_form` devuelve el formulario de inicio de sesión estándar si un proveedor de identidad deja de funcionar. Consulte [Single Sign-On](/admin/sso/) para ambos casos. + +## Relacionado + +* [Single Sign-On](/admin/sso/) — las guías de configuración por proveedor y la configuración de inicio de sesión +* [Diagnostics](/admin/diagnostics/pro__diagnostics/) — por qué falló un intento de inicio de sesión +* [Connectors](/connectors/upstream/about/) — la galería de conectores upstream en la que se basa esta página diff --git a/docs/content/admin/sso/PRO__authorization_connectors.fr.md b/docs/content/admin/sso/PRO__authorization_connectors.fr.md new file mode 100644 index 00000000000..552e30069d9 --- /dev/null +++ b/docs/content/admin/sso/PRO__authorization_connectors.fr.md @@ -0,0 +1,81 @@ +--- +title: Connecteurs d'autorisation +description: 'Visualisez tous les fournisseurs d''identité sur une seule page : lesquels + sont configurés, lesquels sont activés, et quel protocole chacun utilise' +weight: 1 +audience: pro +--- + +Authorization Connectors est une page unique répertoriant chaque fournisseur d'identité pris en charge par DefectDojo Pro, l'état de chacun et le protocole qu'il utilise. Avant son existence, chaque fournisseur vivait dans son propre formulaire de paramètres, et il n'y avait aucun moyen de répondre à la question « qu'est-ce qui est configuré sur cette instance ? » sans tous les ouvrir. + +Authorization Connectors est une fonctionnalité de **DefectDojo Pro**. Vous la trouverez sous **Connect > Authorization**. Seul un **Superuser** peut consulter ou modifier la configuration des fournisseurs d'identité. + +![Authorization Connectors](images/authorization_connectors.png) + +## Comment la page est organisée + +Les fournisseurs sont répartis en deux sections, chacune triée par ordre alphabétique avec un compteur à côté de son titre : + +* **Configured Providers** — les fournisseurs qui ont été mis en place sur cette instance, qu'ils soient actuellement activés ou non. +* **Available Providers** — les fournisseurs pris en charge mais pas encore mis en place. + +Cette répartition se fait délibérément selon *configuré*, et non *activé*. Un fournisseur qui a été configuré puis désactivé reste dans Configured Providers, car c'est là que la personne qui l'a mis en place ira le chercher. Son état est indiqué sur la vignette à la place. + +Chaque vignette affiche : + +| | | +| --- | --- | +| **Logo et nom** | Le fournisseur, nommé sans son protocole | +| **Étiquette de protocole** | `SAML 2.0`, `OAuth 2.0`, `OpenID Connect`, ou `LDAP` | +| **Étiquette de statut** | `Enabled`, `Disabled`, ou `Not configured` | +| **Étiquette `BETA`** | Présente sur les fournisseurs encore en bêta | +| **Action** | **Manage Configuration** pour un fournisseur configuré, **Configure** pour un fournisseur disponible | + +Les deux sections disposent d'un champ de recherche qui filtre sur le nom du fournisseur et sur le protocole ; ainsi, rechercher `oauth` limite la page aux fournisseurs OAuth. + +![Available providers](images/authorization_available.png) + +## Une seule configuration par fournisseur + +Les paramètres d'un fournisseur d'identité forment un ensemble unique de valeurs par fournisseur et par instance — une seule application Okta, un seul fournisseur d'identité SAML, un seul annuaire LDAP. Les vignettes l'indiquent, et il n'y a pas d'option « en ajouter un autre » : pour modifier la façon dont un fournisseur est configuré, vous modifiez la configuration déjà existante. + +C'est ce qui distingue Authorization Connectors des [galeries de connecteurs](/connectors/upstream/about/), où un même outil peut avoir plusieurs configurations côte à côte. + +## Les trois états, et ce qu'ils signifient + +| Statut | Signification | Que faire ensuite | +| --- | --- | --- | +| **Enabled** | Configuré et accepte les connexions | Rien | +| **Disabled** | Configuré, mais désactivé — son bouton n'apparaîtra pas sur la page de connexion | Réactivez-le depuis sa configuration quand vous le souhaitez | +| **Not configured** | Pris en charge, rien n'est encore renseigné | **Configure** pour le mettre en place | + +Sélectionner un fournisseur ouvre directement le formulaire de paramètres propre à ce fournisseur. Il n'y a pas de sélecteur de fournisseur intermédiaire. + +## Fournisseurs pris en charge + +| Provider | Protocol | Setup guide | +| --- | --- | --- | +| Auth0 | OAuth 2.0 | [Auth0](/admin/sso/pro__auth0/) | +| GitHub Enterprise | OAuth 2.0 | [GitHub Enterprise](/admin/sso/pro__github_enterprise/) | +| GitLab | OAuth 2.0 | [GitLab](/admin/sso/pro__gitlab/) | +| Google | OAuth 2.0 | [Google](/admin/sso/pro__google/) | +| Keycloak | OAuth 2.0 | [KeyCloak](/admin/sso/pro__keycloak/) | +| LDAP | LDAP | [LDAP](/admin/sso/pro__ldap/) | +| Microsoft Entra ID | OAuth 2.0 | [Azure Active Directory](/admin/sso/pro__azure_ad/) | +| Okta | OAuth 2.0 | [Okta](/admin/sso/pro__okta/) | +| OpenID Connect | OpenID Connect | [OIDC](/admin/sso/pro__oidc/) | +| SAML | SAML 2.0 | [SAML](/admin/sso/pro__saml/) | + +La page indique quel est l'état de configuration d'un fournisseur. Elle ne renvoie jamais les secrets de la configuration — les secrets clients, les mots de passe de liaison et les certificats ne font pas partie des données derrière cette page, et ne peuvent pas en être extraits. + +## Quand un fournisseur ne se connecte pas + +Authorization Connectors indique ce qui est configuré ; la page ne montre pas les échecs de connexion. Ceux-ci sont enregistrés dans [Diagnostics](/admin/diagnostics/pro__diagnostics/), où le SSO, le SAML et le LDAP consignent chacun leurs propres tentatives avec la raison du rejet — une signature d'assertion invalide, une liaison rejetée, un attribut incohérent. Ces lignes sont propres à l'instance et donc réservées aux superutilisateurs. + +Conservez au moins un compte superutilisateur avec un nom d'utilisateur et un mot de passe en secours, et rappelez-vous que `/login?force_login_form` renvoie le formulaire de connexion standard si un fournisseur d'identité cesse de fonctionner. Voir [Single Sign-On](/admin/sso/) pour les deux. + +## Voir aussi + +* [Single Sign-On](/admin/sso/) — les guides de configuration par fournisseur et les paramètres de connexion +* [Diagnostics](/admin/diagnostics/pro__diagnostics/) — pourquoi une tentative de connexion a échoué +* [Connectors](/connectors/upstream/about/) — la galerie amont sur laquelle cette page est modelée diff --git a/docs/content/admin/sso/PRO__authorization_connectors.ja.md b/docs/content/admin/sso/PRO__authorization_connectors.ja.md new file mode 100644 index 00000000000..5ae182225bb --- /dev/null +++ b/docs/content/admin/sso/PRO__authorization_connectors.ja.md @@ -0,0 +1,80 @@ +--- +title: Authorization Connectors +description: '1つのページですべてのIDプロバイダーを確認: 設定済みか、有効か、どのプロトコルを使用しているか' +weight: 1 +audience: pro +--- + +Authorization Connectorsは、DefectDojo Proが対応するすべてのIDプロバイダーと、それぞれの状態、使用しているプロトコルを1つのページにまとめて表示します。これが存在する前は、各プロバイダーはそれぞれ独自の設定フォームに存在しており、すべてを開かない限り「このインスタンスで何が設定されているか」に答える方法がありませんでした。 + +Authorization Connectorsは**DefectDojo Pro**の機能です。**Connect > Authorization**にあります。IDプロバイダーの設定を表示・変更できるのは**スーパーユーザー**のみです。 + +![Authorization Connectors](images/authorization_connectors.png) + +## How the page is organised + +プロバイダーは2つのセクションに分かれており、それぞれ見出しの横に件数が表示され、アルファベット順に並んでいます。 + +* **Configured Providers**(設定済みプロバイダー) — 現在オンになっているかどうかにかかわらず、このインスタンスで設定済みのプロバイダー +* **Available Providers**(利用可能なプロバイダー) — サポートされているが、まだ設定されていないプロバイダー + +この区分はあえて*enabled*(有効)ではなく*configured*(設定済み)を基準にしています。設定した後にオフに切り替えられたプロバイダーはConfigured Providersに残ります。設定した本人がそこを探すはずだからです。状態はタイル上に表示されます。 + +各タイルには次の情報が表示されます。 + +| | | +| --- | --- | +| **Logo and name** | プロトコル名を含まない、プロバイダーの名称 | +| **Protocol tag** | `SAML 2.0`、`OAuth 2.0`、`OpenID Connect`、`LDAP`のいずれか | +| **Status tag** | `Enabled`、`Disabled`、`Not configured`のいずれか | +| **`BETA` tag** | まだベータ版であるプロバイダーに表示 | +| **Action** | 設定済みプロバイダーには**Manage Configuration**、未設定のプロバイダーには**Configure** | + +どちらのセクションにも、プロバイダー名とプロトコルの両方に一致する検索ボックスがあります。たとえば`oauth`で検索すると、OAuthプロバイダーだけに絞り込まれます。 + +![Available providers](images/authorization_available.png) + +## One configuration per provider + +IDプロバイダーの設定は、インスタンスごと・プロバイダーごとに1組の値です。Oktaアプリケーションは1つ、SAML IDプロバイダーは1つ、LDAPディレクトリは1つです。タイルにもそのように表示され、「追加」という操作はありません。プロバイダーの設定方法を変更するには、既存の設定を編集します。 + +この点が、1つのツールについて複数の設定を並べて持てる[コネクタギャラリー](/connectors/upstream/about/)とAuthorization Connectorsの違いです。 + +## The three states, and what they mean + +| Status | Meaning | What to do next | +| --- | --- | --- | +| **Enabled** | 設定済みでサインインを受け付けている | 対応不要 | +| **Disabled** | 設定済みだがオフに切り替えられている — ログインページにボタンは表示されない | 元に戻したい場合は設定画面から再度有効化 | +| **Not configured** | サポートされているが、まだ何も入力されていない | **Configure**で設定を行う | + +プロバイダーを選択すると、そのプロバイダー自体の設定フォームが直接開きます。中間的なプロバイダー選択画面はありません。 + +## Supported providers + +| Provider | Protocol | Setup guide | +| --- | --- | --- | +| Auth0 | OAuth 2.0 | [Auth0](/admin/sso/pro__auth0/) | +| GitHub Enterprise | OAuth 2.0 | [GitHub Enterprise](/admin/sso/pro__github_enterprise/) | +| GitLab | OAuth 2.0 | [GitLab](/admin/sso/pro__gitlab/) | +| Google | OAuth 2.0 | [Google](/admin/sso/pro__google/) | +| Keycloak | OAuth 2.0 | [KeyCloak](/admin/sso/pro__keycloak/) | +| LDAP | LDAP | [LDAP](/admin/sso/pro__ldap/) | +| Microsoft Entra ID | OAuth 2.0 | [Azure Active Directory](/admin/sso/pro__azure_ad/) | +| Okta | OAuth 2.0 | [Okta](/admin/sso/pro__okta/) | +| OpenID Connect | OpenID Connect | [OIDC](/admin/sso/pro__oidc/) | +| SAML | SAML 2.0 | [SAML](/admin/sso/pro__saml/) | + +このページはプロバイダーの設定の*状態*のみを表示します。設定内のシークレット、すなわちクライアントシークレット、バインドパスワード、証明書はこのページの背後にあるデータには含まれず、読み出すこともできません。 + +## When a provider will not connect + +Authorization Connectorsは何が設定されているかを示しますが、失敗したサインインは表示しません。それらは[Diagnostics](/admin/diagnostics/pro__diagnostics/)に記録されており、SSO、SAML、LDAPがそれぞれ、拒否された理由(不正なアサーション署名、拒否されたバインド、一致しない属性など)とともに自身の試行を報告します。これらの行はインスタンスレベルの情報であるため、スーパーユーザーのみが閲覧できます。 + +フォールバックとして、ユーザー名とパスワードを持つスーパーユーザーアカウントを少なくとも1つ維持してください。また、IDプロバイダーが動作しなくなった場合は`/login?force_login_form`で標準のログインフォームに戻れることを覚えておいてください。両方について[Single Sign-On](/admin/sso/)を参照してください。 + +## Related + +* [Single Sign-On](/admin/sso/) — プロバイダーごとのセットアップガイドとログイン設定 +* [Diagnostics](/admin/diagnostics/pro__diagnostics/) — サインインの試行が失敗した理由 +* [Connectors](/connectors/upstream/about/) — このページのモデルとなったアップストリームギャラリー diff --git a/docs/content/admin/sso/PRO__azure_ad.de.md b/docs/content/admin/sso/PRO__azure_ad.de.md new file mode 100644 index 00000000000..c78a064fa03 --- /dev/null +++ b/docs/content/admin/sso/PRO__azure_ad.de.md @@ -0,0 +1,58 @@ +--- +title: Azure Active Directory +description: Konfigurieren Sie Azure AD SSO und Gruppenzuordnung in DefectDojo Pro +weight: 5 +audience: pro +--- + +DefectDojo Pro unterstützt die Anmeldung über Azure Active Directory (Azure AD), einschließlich der automatischen Synchronisierung von Benutzergruppen. Open-Source-DefectDojo enthält kein SSO — siehe [Authorized Users](/admin/user_management/os__authorized_users/) für die Zugriffskontrolle in der Open-Source-Version. + +## Voraussetzungen + +Führen Sie die folgenden Schritte im Azure-Portal aus, bevor Sie DefectDojo konfigurieren: + +1. [Registrieren Sie eine neue App](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) in Azure Active Directory. + +2. Notieren Sie sich die folgenden Werte aus der registrierten App: + - **Application (client) ID** + - **Directory (tenant) ID** + - Erstellen Sie unter **Certificates & Secrets** ein neues **Client Secret** und notieren Sie dessen Wert + - **Application ID URI** + +3. Fügen Sie unter **Authentication > Redirect URIs** eine URI vom Typ **Web** hinzu: + `https://your-instance.cloud.defectdojo.com/complete/azuread-tenant-oauth2/` + +## Konfiguration + +Gehen Sie in DefectDojo zu **Enterprise Settings > OAuth Settings**, wählen Sie **Azure AD** aus und füllen Sie das Formular aus: + +- **Azure AD OAuth Key** — geben Sie Ihre **Application (client) ID** ein +- **Azure AD OAuth Secret** — geben Sie Ihr **Client Secret** ein +- **Azure AD Resource** — Standardwert ist `https://graph.microsoft.com/`. Dies ist die URI, über die DefectDojo zusätzliche Informationen (wie Gruppennamen) aus der [Microsoft Graph Web API](https://docs.azure.cn/en-us/entra/identity-platform/security-best-practices-for-app-registration#application-id-uri) liest. Ändern Sie dies nur, wenn Ihre Gruppennamen auf einer anderen API-Ressource gespeichert sind. +- **Azure AD Tenant ID** — geben Sie Ihre **Directory (tenant) ID** ein +- **Azure AD Groups Filter** — geben Sie optional einen Regex-String ein, um einzuschränken, welche Benutzergruppen importiert werden (siehe [Group Mapping](#group-mapping) unten) + +Aktivieren Sie **Enable Azure AD OAuth** und senden Sie das Formular ab. Auf der Anmeldeseite erscheint eine Schaltfläche **Login With Azure AD**. + +## Group Mapping + +Group Mapping ermöglicht es DefectDojo, die [Benutzergruppen](../../user_management/create_user_group/)-Mitgliedschaft aus Azure AD zu importieren. Benutzergruppen steuern in DefectDojo den Zugriff auf Produkte und Produkttypen über [RBAC](../../user_management/set_user_permissions/). + +Aktivieren Sie **Enable Azure AD OAuth Grouping**, um diese Funktion zu aktivieren. Bei der Anmeldung gleicht DefectDojo die Azure-AD-Gruppen des Benutzers mit bestehenden DefectDojo-Gruppen ab. Gruppen, die in DefectDojo nicht gefunden werden, werden automatisch erstellt. + +Um nur eine Teilmenge der Gruppen zu importieren, geben Sie einen Regex in das Feld **Azure AD Groups Filter** ein. Zum Beispiel: +- `^team-.*` — entspricht jeder Gruppe, die mit `team-` beginnt +- `teamA|teamB|groupC` — entspricht bestimmten benannten Gruppen + +### Azure AD für das Senden von Gruppen konfigurieren + +Das Azure-AD-Token muss so konfiguriert werden, dass es Gruppen-IDs enthält. Ohne dies sind im Token keine Gruppeninformationen vorhanden. + +So konfigurieren Sie dies: +1. Fügen Sie in der Azure-AD-Token-Konfiguration einen [Group Claim](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) hinzu. Wählen Sie im Zweifelsfall, welcher Gruppentyp ausgewählt werden soll, **All Groups**. +2. Aktivieren Sie **nicht** die Option **Emit groups as role claims**. +3. Aktualisieren Sie die API-Berechtigungen der Anwendung so, dass sie `GroupMember.Read.All` oder `Group.Read.All` enthalten. `GroupMember.Read.All` wird empfohlen, da es weniger Berechtigungen gewährt. + +### Group Cleaning + +Wenn **Enable Azure AD OAuth Group Cleaning** aktiviert ist, werden über die Azure-AD-Synchronisierung erstellte DefectDojo-Gruppen automatisch entfernt, sobald sie keine Mitglieder mehr haben. Wird ein Benutzer in Azure AD aus einer Gruppe entfernt, wird er auch aus der entsprechenden Gruppe in DefectDojo entfernt. diff --git a/docs/content/admin/sso/PRO__azure_ad.es.md b/docs/content/admin/sso/PRO__azure_ad.es.md new file mode 100644 index 00000000000..4878e3735b1 --- /dev/null +++ b/docs/content/admin/sso/PRO__azure_ad.es.md @@ -0,0 +1,59 @@ +--- +title: Azure Active Directory +description: Configure el SSO de Azure AD y la asignación de grupos en DefectDojo + Pro +weight: 5 +audience: pro +--- + +DefectDojo Pro admite el inicio de sesión mediante Azure Active Directory (Azure AD), incluida la sincronización automática de Grupos de usuarios. DefectDojo de código abierto no incluye SSO — consulte [Authorized Users](/admin/user_management/os__authorized_users/) para el control de acceso de código abierto. + +## Requisitos previos + +Complete los siguientes pasos en el portal de Azure antes de configurar DefectDojo: + +1. [Registre una nueva aplicación](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) en Azure Active Directory. + +2. Anote los siguientes valores de la aplicación registrada: + - **Application (client) ID** + - **Directory (tenant) ID** + - En **Certificates & Secrets**, cree un nuevo **Client Secret** y anote su valor + - **Application ID URI** + +3. En **Authentication > Redirect URIs**, añada un URI de tipo **Web**: + `https://your-instance.cloud.defectdojo.com/complete/azuread-tenant-oauth2/` + +## Configuración + +En DefectDojo, vaya a **Enterprise Settings > OAuth Settings**, seleccione **Azure AD** y complete el formulario: + +- **Azure AD OAuth Key** — introduzca su **Application (client) ID** +- **Azure AD OAuth Secret** — introduzca su **Client Secret** +- **Azure AD Resource** — el valor predeterminado es `https://graph.microsoft.com/`. Este es el URI que utiliza DefectDojo para leer información adicional (como los nombres de grupo) de la [Microsoft Graph Web API](https://docs.azure.cn/en-us/entra/identity-platform/security-best-practices-for-app-registration#application-id-uri). Cambie esto solo si los nombres de sus grupos se almacenan en un recurso de API diferente. +- **Azure AD Tenant ID** — introduzca su **Directory (tenant) ID** +- **Azure AD Groups Filter** — opcionalmente, introduzca una expresión regular para restringir qué Grupos de usuarios se importan (consulte [Group Mapping](#group-mapping) más abajo) + +Marque **Enable Azure AD OAuth** y envíe el formulario. Aparecerá un botón **Login With Azure AD** en la página de inicio de sesión. + +## Group Mapping + +La asignación de grupos permite que DefectDojo importe la pertenencia a [User Group](../../user_management/create_user_group/) desde Azure AD. Los Grupos de usuarios en DefectDojo rigen el acceso a productos y tipos de producto mediante [RBAC](../../user_management/set_user_permissions/). + +Marque **Enable Azure AD OAuth Grouping** para activar esta función. Al iniciar sesión, DefectDojo hará coincidir los grupos de Azure AD del usuario con los grupos existentes en DefectDojo. Cualquier grupo que no se encuentre en DefectDojo se creará automáticamente. + +Para importar solo un subconjunto de grupos, introduzca una expresión regular en el campo **Azure AD Groups Filter**. Por ejemplo: +- `^team-.*` — coincide con cualquier grupo que empiece por `team-` +- `teamA|teamB|groupC` — coincide con grupos concretos por nombre + +### Configurar Azure AD para enviar grupos + +El token de Azure AD debe configurarse para incluir los ID de grupo. Sin esto, no habrá información de grupo presente en el token. + +Para configurarlo: +1. Añada un [Group Claim](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) en la configuración del token de Azure AD. Si no está seguro de qué tipo de grupo seleccionar, elija **All Groups**. +2. **No** habilite **Emit groups as role claims**. +3. Actualice los permisos de la API de la aplicación para incluir `GroupMember.Read.All` o `Group.Read.All`. Se recomienda `GroupMember.Read.All`, ya que concede menos permisos. + +### Limpieza de grupos + +Si **Enable Azure AD OAuth Group Cleaning** está habilitado, los grupos de DefectDojo creados mediante la sincronización de Azure AD se eliminarán automáticamente cuando no les queden miembros. Cuando se elimina a un usuario de un grupo en Azure AD, también se le elimina del grupo correspondiente en DefectDojo. diff --git a/docs/content/admin/sso/PRO__azure_ad.fr.md b/docs/content/admin/sso/PRO__azure_ad.fr.md new file mode 100644 index 00000000000..a86951e80e0 --- /dev/null +++ b/docs/content/admin/sso/PRO__azure_ad.fr.md @@ -0,0 +1,58 @@ +--- +title: Azure Active Directory +description: Configurer le SSO Azure AD et le mappage de groupes dans DefectDojo Pro +weight: 5 +audience: pro +--- + +DefectDojo Pro prend en charge la connexion via Azure Active Directory (Azure AD), y compris la synchronisation automatique des groupes d'utilisateurs. DefectDojo open source n'inclut pas le SSO — voir [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +## Prerequisites + +Effectuez les étapes suivantes dans le portail Azure avant de configurer DefectDojo : + +1. [Enregistrez une nouvelle application](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) dans Azure Active Directory. + +2. Notez les valeurs suivantes depuis l'application enregistrée : + - **Application (client) ID** + - **Directory (tenant) ID** + - Sous **Certificates & Secrets**, créez un nouveau **Client Secret** et notez sa valeur + - **Application ID URI** + +3. Sous **Authentication > Redirect URIs**, ajoutez un URI de type **Web** : + `https://your-instance.cloud.defectdojo.com/complete/azuread-tenant-oauth2/` + +## Configuration + +Dans DefectDojo, accédez à **Enterprise Settings > OAuth Settings**, sélectionnez **Azure AD**, et remplissez le formulaire : + +- **Azure AD OAuth Key** — saisissez votre **Application (client) ID** +- **Azure AD OAuth Secret** — saisissez votre **Client Secret** +- **Azure AD Resource** — la valeur par défaut est `https://graph.microsoft.com/`. Il s'agit de l'URI que DefectDojo utilise pour lire des informations supplémentaires (comme les noms de groupes) depuis la [Microsoft Graph Web API](https://docs.azure.cn/en-us/entra/identity-platform/security-best-practices-for-app-registration#application-id-uri). Ne modifiez ceci que si vos noms de groupes sont stockés sur une autre ressource API. +- **Azure AD Tenant ID** — saisissez votre **Directory (tenant) ID** +- **Azure AD Groups Filter** — saisissez éventuellement une expression régulière pour restreindre les groupes d'utilisateurs importés (voir [Group Mapping](#group-mapping) ci-dessous) + +Cochez **Enable Azure AD OAuth** et validez le formulaire. Un bouton **Login With Azure AD** apparaîtra sur la page de connexion. + +## Group Mapping + +Le mappage de groupes permet à DefectDojo d'importer l'appartenance à un [groupe d'utilisateurs](../../user_management/create_user_group/) depuis Azure AD. Les groupes d'utilisateurs dans DefectDojo régissent l'accès aux produits et aux types de produits via [RBAC](../../user_management/set_user_permissions/). + +Cochez **Enable Azure AD OAuth Grouping** pour activer cette fonctionnalité. Lors de la connexion, DefectDojo fera correspondre les groupes Azure AD de l'utilisateur aux groupes DefectDojo existants. Tout groupe introuvable dans DefectDojo sera créé automatiquement. + +Pour n'importer qu'un sous-ensemble de groupes, saisissez une expression régulière dans le champ **Azure AD Groups Filter**. Par exemple : +- `^team-.*` — correspond à tout groupe commençant par `team-` +- `teamA|teamB|groupC` — correspond à des groupes nommés spécifiques + +### Configuring Azure AD to send groups + +Le jeton Azure AD doit être configuré pour inclure les identifiants de groupe. Sans cela, aucune information de groupe ne sera présente dans le jeton. + +Pour configurer cela : +1. Ajoutez une [revendication de groupe](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) dans la configuration du jeton Azure AD. En cas de doute sur le type de groupe à sélectionner, choisissez **All Groups**. +2. N'activez **pas** l'option **Emit groups as role claims**. +3. Mettez à jour les autorisations API de l'application pour inclure `GroupMember.Read.All` ou `Group.Read.All`. `GroupMember.Read.All` est recommandé car il accorde moins d'autorisations. + +### Group Cleaning + +Si **Enable Azure AD OAuth Group Cleaning** est activé, les groupes DefectDojo créés via la synchronisation Azure AD seront automatiquement supprimés lorsqu'ils n'ont plus aucun membre. Lorsqu'un utilisateur est retiré d'un groupe dans Azure AD, il est également retiré du groupe correspondant dans DefectDojo. diff --git a/docs/content/admin/sso/PRO__azure_ad.ja.md b/docs/content/admin/sso/PRO__azure_ad.ja.md new file mode 100644 index 00000000000..42f3c696c6f --- /dev/null +++ b/docs/content/admin/sso/PRO__azure_ad.ja.md @@ -0,0 +1,58 @@ +--- +title: Azure Active Directory +description: DefectDojo ProでAzure AD SSOとグループマッピングを設定する +weight: 5 +audience: pro +--- + +DefectDojo ProはAzure Active Directory(Azure AD)によるログインをサポートしており、ユーザーグループの自動同期も含まれます。オープンソース版のDefectDojoにはSSOは含まれていません。オープンソース版のアクセス制御については[Authorized Users](/admin/user_management/os__authorized_users/)を参照してください。 + +## Prerequisites + +DefectDojoを設定する前に、Azureポータルで以下の手順を完了してください。 + +1. Azure Active Directoryで[新しいアプリを登録](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app)します。 + +2. 登録したアプリから以下の値を控えます。 + - **Application (client) ID** + - **Directory (tenant) ID** + - **Certificates & Secrets**で新しい**Client Secret**を作成し、その値を控えます + - **Application ID URI** + +3. **Authentication > Redirect URIs**で、**Web**タイプのURIを追加します。 + `https://your-instance.cloud.defectdojo.com/complete/azuread-tenant-oauth2/` + +## Configuration + +DefectDojoで**Enterprise Settings > OAuth Settings**に移動し、**Azure AD**を選択してフォームに入力します。 + +- **Azure AD OAuth Key** — **Application (client) ID**を入力します +- **Azure AD OAuth Secret** — **Client Secret**を入力します +- **Azure AD Resource** — デフォルトは`https://graph.microsoft.com/`です。これはDefectDojoが[Microsoft Graph Web API](https://docs.azure.cn/en-us/entra/identity-platform/security-best-practices-for-app-registration#application-id-uri)から追加情報(グループ名など)を読み取るために使用するURIです。グループ名が別のAPIリソースに保存されている場合のみ変更してください。 +- **Azure AD Tenant ID** — **Directory (tenant) ID**を入力します +- **Azure AD Groups Filter** — 必要に応じて正規表現を入力し、インポートするユーザーグループを制限します(下記の[Group Mapping](#group-mapping)を参照) + +**Enable Azure AD OAuth**をチェックしてフォームを送信します。ログインページに**Login With Azure AD**ボタンが表示されます。 + +## Group Mapping + +グループマッピングを使うと、DefectDojoはAzure ADから[User Group](../../user_management/create_user_group/)のメンバーシップをインポートできます。DefectDojoのユーザーグループは、[RBAC](../../user_management/set_user_permissions/)を通じて製品と製品タイプへのアクセスを管理します。 + +**Enable Azure AD OAuth Grouping**をチェックするとこの機能が有効になります。ログイン時、DefectDojoはユーザーのAzure ADグループを既存のDefectDojoグループと照合します。DefectDojoに見つからないグループは自動的に作成されます。 + +一部のグループのみをインポートするには、**Azure AD Groups Filter**フィールドに正規表現を入力します。例: +- `^team-.*` — `team-`で始まるすべてのグループに一致 +- `teamA|teamB|groupC` — 特定の名前のグループに一致 + +### Configuring Azure AD to send groups + +Azure ADトークンには、グループIDを含めるよう設定する必要があります。これがないと、トークンにグループ情報が含まれません。 + +設定手順: +1. Azure ADのトークン設定で[Group Claim](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims)を追加します。どのグループタイプを選ぶべきか分からない場合は**All Groups**を選択してください。 +2. **Emit groups as role claims**は有効に**しないで**ください。 +3. アプリケーションのAPI権限に`GroupMember.Read.All`または`Group.Read.All`を追加します。付与される権限が少ない`GroupMember.Read.All`が推奨されます。 + +### Group Cleaning + +**Enable Azure AD OAuth Group Cleaning**が有効な場合、Azure AD同期によって作成されたDefectDojoグループは、メンバーがいなくなると自動的に削除されます。Azure ADでユーザーがグループから削除されると、DefectDojo上の対応するグループからも削除されます。 diff --git a/docs/content/admin/sso/PRO__github_enterprise.de.md b/docs/content/admin/sso/PRO__github_enterprise.de.md new file mode 100644 index 00000000000..ff4c88c63e6 --- /dev/null +++ b/docs/content/admin/sso/PRO__github_enterprise.de.md @@ -0,0 +1,32 @@ +--- +title: GitHub Enterprise +description: Konfigurieren Sie GitHub Enterprise SSO in DefectDojo Pro +weight: 7 +audience: pro +--- + +DefectDojo Pro unterstützt die Anmeldung über GitHub Enterprise. Open-Source-DefectDojo enthält kein SSO — siehe [Authorized Users](/admin/user_management/os__authorized_users/) für die Zugriffskontrolle in der Open-Source-Version. + +## Voraussetzungen + +Führen Sie die folgenden Schritte in GitHub Enterprise aus, bevor Sie DefectDojo konfigurieren: + +1. [Erstellen Sie eine neue OAuth-App](https://docs.github.com/en/enterprise-server/developers/apps/building-oauth-apps/creating-an-oauth-app) in Ihrem GitHub Enterprise Server. + +2. Wählen Sie einen Namen für die Anwendung, z. B. `DefectDojo`. + +3. Legen Sie die **Redirect URI** fest: + `https://your-instance.cloud.defectdojo.com/complete/github-enterprise/` + +4. Notieren Sie sich **Client ID** und **Client Secret** der App. + +## Konfiguration + +Gehen Sie in DefectDojo zu **Enterprise Settings > OAuth Settings**, wählen Sie **GitHub Enterprise** aus und füllen Sie das Formular aus: + +- **GitHub Enterprise OAuth Key** — geben Sie Ihre **Client ID** ein +- **GitHub Enterprise OAuth Secret** — geben Sie Ihr **Client Secret** ein +- **GitHub Enterprise URL** — geben Sie die GitHub-URL Ihrer Organisation ein, z. B. `https://github.yourcompany.com/` +- **GitHub Enterprise API URL** — geben Sie die GitHub-API-URL Ihrer Organisation ein, z. B. `https://github.yourcompany.com/api/v3/` + +Aktivieren Sie **Enable GitHub Enterprise OAuth** und senden Sie das Formular ab. Auf der Anmeldeseite erscheint eine Schaltfläche **Login With GitHub**. diff --git a/docs/content/admin/sso/PRO__github_enterprise.es.md b/docs/content/admin/sso/PRO__github_enterprise.es.md new file mode 100644 index 00000000000..f7542de9ccf --- /dev/null +++ b/docs/content/admin/sso/PRO__github_enterprise.es.md @@ -0,0 +1,32 @@ +--- +title: GitHub Enterprise +description: Configure el SSO de GitHub Enterprise en DefectDojo Pro +weight: 7 +audience: pro +--- + +DefectDojo Pro admite el inicio de sesión mediante GitHub Enterprise. DefectDojo de código abierto no incluye SSO — consulte [Authorized Users](/admin/user_management/os__authorized_users/) para el control de acceso de código abierto. + +## Requisitos previos + +Complete los siguientes pasos en GitHub Enterprise antes de configurar DefectDojo: + +1. [Cree una nueva OAuth App](https://docs.github.com/en/enterprise-server/developers/apps/building-oauth-apps/creating-an-oauth-app) en su GitHub Enterprise Server. + +2. Elija un nombre para la aplicación, por ejemplo `DefectDojo`. + +3. Configure el **Redirect URI**: + `https://your-instance.cloud.defectdojo.com/complete/github-enterprise/` + +4. Anote el **Client ID** y el **Client Secret** de la aplicación. + +## Configuración + +En DefectDojo, vaya a **Enterprise Settings > OAuth Settings**, seleccione **GitHub Enterprise** y complete el formulario: + +- **GitHub Enterprise OAuth Key** — introduzca su **Client ID** +- **GitHub Enterprise OAuth Secret** — introduzca su **Client Secret** +- **GitHub Enterprise URL** — introduzca la URL de GitHub de su organización, por ejemplo `https://github.yourcompany.com/` +- **GitHub Enterprise API URL** — introduzca la URL de la API de GitHub de su organización, por ejemplo `https://github.yourcompany.com/api/v3/` + +Marque **Enable GitHub Enterprise OAuth** y envíe el formulario. Aparecerá un botón **Login With GitHub** en la página de inicio de sesión. diff --git a/docs/content/admin/sso/PRO__github_enterprise.fr.md b/docs/content/admin/sso/PRO__github_enterprise.fr.md new file mode 100644 index 00000000000..5205c46d227 --- /dev/null +++ b/docs/content/admin/sso/PRO__github_enterprise.fr.md @@ -0,0 +1,32 @@ +--- +title: GitHub Enterprise +description: Configurer le SSO GitHub Enterprise dans DefectDojo Pro +weight: 7 +audience: pro +--- + +DefectDojo Pro prend en charge la connexion via GitHub Enterprise. DefectDojo open source n'inclut pas le SSO — voir [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +## Prérequis + +Effectuez les étapes suivantes dans GitHub Enterprise avant de configurer DefectDojo : + +1. [Créez une nouvelle application OAuth](https://docs.github.com/en/enterprise-server/developers/apps/building-oauth-apps/creating-an-oauth-app) dans votre GitHub Enterprise Server. + +2. Choisissez un nom pour l'application, par exemple `DefectDojo`. + +3. Définissez l'**URI de redirection** : + `https://your-instance.cloud.defectdojo.com/complete/github-enterprise/` + +4. Notez le **Client ID** et le **Client Secret** de l'application. + +## Configuration + +Dans DefectDojo, accédez à **Enterprise Settings > OAuth Settings**, sélectionnez **GitHub Enterprise**, et remplissez le formulaire : + +- **GitHub Enterprise OAuth Key** — saisissez votre **Client ID** +- **GitHub Enterprise OAuth Secret** — saisissez votre **Client Secret** +- **GitHub Enterprise URL** — saisissez l'URL GitHub de votre organisation, par exemple `https://github.yourcompany.com/` +- **GitHub Enterprise API URL** — saisissez l'URL de l'API GitHub de votre organisation, par exemple `https://github.yourcompany.com/api/v3/` + +Cochez **Enable GitHub Enterprise OAuth** et validez le formulaire. Un bouton **Login With GitHub** apparaîtra sur la page de connexion. diff --git a/docs/content/admin/sso/PRO__github_enterprise.ja.md b/docs/content/admin/sso/PRO__github_enterprise.ja.md new file mode 100644 index 00000000000..faa029919f6 --- /dev/null +++ b/docs/content/admin/sso/PRO__github_enterprise.ja.md @@ -0,0 +1,32 @@ +--- +title: GitHub Enterprise +description: DefectDojo ProでGitHub Enterprise SSOを設定する +weight: 7 +audience: pro +--- + +DefectDojo ProはGitHub Enterpriseによるログインをサポートしています。オープンソース版のDefectDojoにはSSOは含まれていません。オープンソース版のアクセス制御については[Authorized Users](/admin/user_management/os__authorized_users/)を参照してください。 + +## Prerequisites + +DefectDojoを設定する前に、GitHub Enterpriseで以下の手順を完了してください。 + +1. GitHub Enterprise Serverで[新しいOAuthアプリを作成](https://docs.github.com/en/enterprise-server/developers/apps/building-oauth-apps/creating-an-oauth-app)します。 + +2. アプリケーションの名前を選びます(例: `DefectDojo`)。 + +3. **Redirect URI**を設定します。 + `https://your-instance.cloud.defectdojo.com/complete/github-enterprise/` + +4. アプリから**Client ID**と**Client Secret**を控えます。 + +## Configuration + +DefectDojoで**Enterprise Settings > OAuth Settings**に移動し、**GitHub Enterprise**を選択してフォームに入力します。 + +- **GitHub Enterprise OAuth Key** — **Client ID**を入力します +- **GitHub Enterprise OAuth Secret** — **Client Secret**を入力します +- **GitHub Enterprise URL** — 組織のGitHub URLを入力します(例: `https://github.yourcompany.com/`) +- **GitHub Enterprise API URL** — 組織のGitHub API URLを入力します(例: `https://github.yourcompany.com/api/v3/`) + +**Enable GitHub Enterprise OAuth**をチェックしてフォームを送信します。ログインページに**Login With GitHub**ボタンが表示されます。 diff --git a/docs/content/admin/sso/PRO__gitlab.de.md b/docs/content/admin/sso/PRO__gitlab.de.md new file mode 100644 index 00000000000..1a831007838 --- /dev/null +++ b/docs/content/admin/sso/PRO__gitlab.de.md @@ -0,0 +1,32 @@ +--- +title: GitLab +description: Konfigurieren Sie GitLab SSO in DefectDojo Pro +weight: 9 +audience: pro +--- + +DefectDojo Pro unterstützt die Anmeldung über GitLab. Open-Source-DefectDojo enthält kein SSO — siehe [Authorized Users](/admin/user_management/os__authorized_users/) für die Zugriffskontrolle in der Open-Source-Version. + +## Voraussetzungen + +Führen Sie die folgenden Schritte in GitLab aus, bevor Sie DefectDojo konfigurieren: + +1. Navigieren Sie zur Applications-Seite Ihres GitLab-Profils: + - GitLab.com: `https://gitlab.com/profile/applications` + - Selbst gehostet: `https://your-gitlab-host/profile/applications` + +2. Erstellen Sie eine neue Anwendung: + - **Name:** `DefectDojo` + - **Redirect URI:** `https://your-dojo-instance.cloud.defectdojo.com/complete/gitlab/` + +3. Notieren Sie sich **Application ID** und **Secret** der Anwendung. + +## Konfiguration + +Gehen Sie in DefectDojo zu **Enterprise Settings > OAuth Settings**, wählen Sie **GitLab** aus und füllen Sie das Formular aus: + +- **GitLab OAuth Key** — geben Sie Ihre **Application ID** ein +- **GitLab OAuth Secret** — geben Sie Ihr **Secret** ein +- **GitLab API URL** — geben Sie die Basis-URL Ihrer GitLab-Instanz ein, z. B. `https://gitlab.com` + +Aktivieren Sie **Enable GitLab OAuth** und senden Sie das Formular ab. Auf der Anmeldeseite erscheint eine Schaltfläche **Login With GitLab**. diff --git a/docs/content/admin/sso/PRO__gitlab.es.md b/docs/content/admin/sso/PRO__gitlab.es.md new file mode 100644 index 00000000000..48a11c4a6b5 --- /dev/null +++ b/docs/content/admin/sso/PRO__gitlab.es.md @@ -0,0 +1,32 @@ +--- +title: GitLab +description: Configure el SSO de GitLab en DefectDojo Pro +weight: 9 +audience: pro +--- + +DefectDojo Pro admite el inicio de sesión mediante GitLab. DefectDojo de código abierto no incluye SSO — consulte [Authorized Users](/admin/user_management/os__authorized_users/) para el control de acceso de código abierto. + +## Requisitos previos + +Complete los siguientes pasos en GitLab antes de configurar DefectDojo: + +1. Navegue a la página de Applications de su perfil de GitLab: + - GitLab.com: `https://gitlab.com/profile/applications` + - Autoalojado: `https://your-gitlab-host/profile/applications` + +2. Cree una nueva aplicación: + - **Name:** `DefectDojo` + - **Redirect URI:** `https://your-dojo-instance.cloud.defectdojo.com/complete/gitlab/` + +3. Anote el **Application ID** y el **Secret** de la aplicación. + +## Configuración + +En DefectDojo, vaya a **Enterprise Settings > OAuth Settings**, seleccione **GitLab** y complete el formulario: + +- **GitLab OAuth Key** — introduzca su **Application ID** +- **GitLab OAuth Secret** — introduzca su **Secret** +- **GitLab API URL** — introduzca la URL base de su instancia de GitLab, por ejemplo `https://gitlab.com` + +Marque **Enable GitLab OAuth** y envíe el formulario. Aparecerá un botón **Login With GitLab** en la página de inicio de sesión. diff --git a/docs/content/admin/sso/PRO__gitlab.fr.md b/docs/content/admin/sso/PRO__gitlab.fr.md new file mode 100644 index 00000000000..ac93b4a667e --- /dev/null +++ b/docs/content/admin/sso/PRO__gitlab.fr.md @@ -0,0 +1,32 @@ +--- +title: GitLab +description: Configurer le SSO GitLab dans DefectDojo Pro +weight: 9 +audience: pro +--- + +DefectDojo Pro prend en charge la connexion via GitLab. DefectDojo open source n'inclut pas le SSO — voir [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +## Prérequis + +Effectuez les étapes suivantes dans GitLab avant de configurer DefectDojo : + +1. Accédez à la page Applications de votre profil GitLab : + - GitLab.com : `https://gitlab.com/profile/applications` + - Auto-hébergé : `https://your-gitlab-host/profile/applications` + +2. Créez une nouvelle application : + - **Name:** `DefectDojo` + - **Redirect URI:** `https://your-dojo-instance.cloud.defectdojo.com/complete/gitlab/` + +3. Notez l'**Application ID** et le **Secret** de l'application. + +## Configuration + +Dans DefectDojo, accédez à **Enterprise Settings > OAuth Settings**, sélectionnez **GitLab**, et remplissez le formulaire : + +- **GitLab OAuth Key** — saisissez votre **Application ID** +- **GitLab OAuth Secret** — saisissez votre **Secret** +- **GitLab API URL** — saisissez l'URL de base de votre instance GitLab, par exemple `https://gitlab.com` + +Cochez **Enable GitLab OAuth** et validez le formulaire. Un bouton **Login With GitLab** apparaîtra sur la page de connexion. diff --git a/docs/content/admin/sso/PRO__gitlab.ja.md b/docs/content/admin/sso/PRO__gitlab.ja.md new file mode 100644 index 00000000000..ca63b8606ea --- /dev/null +++ b/docs/content/admin/sso/PRO__gitlab.ja.md @@ -0,0 +1,32 @@ +--- +title: GitLab +description: DefectDojo ProでGitLab SSOを設定する +weight: 9 +audience: pro +--- + +DefectDojo ProはGitLabによるログインをサポートしています。オープンソース版のDefectDojoにはSSOは含まれていません。オープンソース版のアクセス制御については[Authorized Users](/admin/user_management/os__authorized_users/)を参照してください。 + +## Prerequisites + +DefectDojoを設定する前に、GitLabで以下の手順を完了してください。 + +1. GitLabプロフィールのApplicationsページに移動します。 + - GitLab.com: `https://gitlab.com/profile/applications` + - セルフホスト: `https://your-gitlab-host/profile/applications` + +2. 新しいアプリケーションを作成します。 + - **Name:** `DefectDojo` + - **Redirect URI:** `https://your-dojo-instance.cloud.defectdojo.com/complete/gitlab/` + +3. アプリケーションから**Application ID**と**Secret**を控えます。 + +## Configuration + +DefectDojoで**Enterprise Settings > OAuth Settings**に移動し、**GitLab**を選択してフォームに入力します。 + +- **GitLab OAuth Key** — **Application ID**を入力します +- **GitLab OAuth Secret** — **Secret**を入力します +- **GitLab API URL** — GitLabインスタンスのベースURLを入力します(例: `https://gitlab.com`) + +**Enable GitLab OAuth**をチェックしてフォームを送信します。ログインページに**Login With GitLab**ボタンが表示されます。 diff --git a/docs/content/admin/sso/PRO__google.de.md b/docs/content/admin/sso/PRO__google.de.md new file mode 100644 index 00000000000..8a111d5c17e --- /dev/null +++ b/docs/content/admin/sso/PRO__google.de.md @@ -0,0 +1,38 @@ +--- +title: Google Auth +description: Konfigurieren Sie Google OAuth in DefectDojo Pro +weight: 11 +audience: pro +--- + +DefectDojo Pro unterstützt die Anmeldung über Google-Konten. Neue Benutzer werden bei der ersten Anmeldung automatisch erstellt, sofern sie noch nicht existieren. Bestehende DefectDojo-Benutzer werden anhand des Benutzernamens (dem Teil vor dem `@` in ihrer Google-E-Mail-Adresse) mit Google-Konten abgeglichen. Open-Source-DefectDojo enthält kein SSO — siehe [Authorized Users](/admin/user_management/os__authorized_users/) für die Zugriffskontrolle in der Open-Source-Version. + +## Voraussetzungen + +Führen Sie die folgenden Schritte in der Google Cloud Console aus, bevor Sie DefectDojo konfigurieren: + +1. Melden Sie sich bei der [Google Developers Console](https://console.developers.google.com) an. + +2. Gehen Sie zu **Credentials > Create Credentials > OAuth Client ID**. + + ![image](images/google_1.png) + +3. Wählen Sie **Web Application** aus und vergeben Sie einen aussagekräftigen Namen (z. B. `DefectDojo`). + +4. Fügen Sie unter **Authorized Redirect URIs** Folgendes hinzu: + `https://your-instance.cloud.defectdojo.com/complete/google-oauth2/` + +5. Notieren Sie sich **Client ID** und **Client Secret Key**. + +## Konfiguration + +Gehen Sie in DefectDojo zu **Enterprise Settings > OAuth Settings**, wählen Sie **Google** aus und füllen Sie das Formular aus: + +- **Google OAuth Key** — geben Sie Ihre **Client ID** ein +- **Google OAuth Secret** — geben Sie Ihren **Client Secret Key** ein +- **Whitelisted Domains** — geben Sie die Domain Ihrer Organisation ein (z. B. `yourcompany.com`), um jedem Benutzer mit dieser Domain die Anmeldung zu erlauben +- **Whitelisted E-mail Addresses** — geben Sie alternativ bestimmte zulässige E-Mail-Adressen ein (z. B. `user1@yourcompany.com, user2@yourcompany.com`) + +Sie müssen mindestens eine zugelassene Domain oder E-Mail-Adresse festlegen, sonst kann sich kein Benutzer über Google anmelden. + +Aktivieren Sie **Enable Google OAuth** und senden Sie das Formular ab. Auf der Anmeldeseite erscheint eine Schaltfläche **Login With Google**. diff --git a/docs/content/admin/sso/PRO__google.es.md b/docs/content/admin/sso/PRO__google.es.md new file mode 100644 index 00000000000..40f6fba62c7 --- /dev/null +++ b/docs/content/admin/sso/PRO__google.es.md @@ -0,0 +1,38 @@ +--- +title: Google Auth +description: Configure el OAuth de Google en DefectDojo Pro +weight: 11 +audience: pro +--- + +DefectDojo Pro admite el inicio de sesión mediante cuentas de Google. Los usuarios nuevos se crean automáticamente en el primer inicio de sesión si aún no existen. Los usuarios ya existentes de DefectDojo se emparejan con las cuentas de Google por nombre de usuario (la parte anterior a la `@` en su correo de Google). DefectDojo de código abierto no incluye SSO — consulte [Authorized Users](/admin/user_management/os__authorized_users/) para el control de acceso de código abierto. + +## Requisitos previos + +Complete los siguientes pasos en Google Cloud Console antes de configurar DefectDojo: + +1. Inicie sesión en [Google Developers Console](https://console.developers.google.com). + +2. Vaya a **Credentials > Create Credentials > OAuth Client ID**. + + ![imagen](images/google_1.png) + +3. Seleccione **Web Application** y asígnele un nombre descriptivo (por ejemplo, `DefectDojo`). + +4. En **Authorized Redirect URIs**, añada: + `https://your-instance.cloud.defectdojo.com/complete/google-oauth2/` + +5. Anote el **Client ID** y la **Client Secret Key**. + +## Configuración + +En DefectDojo, vaya a **Enterprise Settings > OAuth Settings**, seleccione **Google** y complete el formulario: + +- **Google OAuth Key** — introduzca su **Client ID** +- **Google OAuth Secret** — introduzca su **Client Secret Key** +- **Whitelisted Domains** — introduzca el dominio de su organización (por ejemplo, `yourcompany.com`) para permitir que inicie sesión cualquier usuario con ese dominio +- **Whitelisted E-mail Addresses** — alternativamente, introduzca direcciones de correo específicas para permitir (por ejemplo, `user1@yourcompany.com, user2@yourcompany.com`) + +Debe establecer al menos un dominio o dirección de correo en la lista blanca, o ningún usuario podrá iniciar sesión mediante Google. + +Marque **Enable Google OAuth** y envíe el formulario. Aparecerá un botón **Login With Google** en la página de inicio de sesión. diff --git a/docs/content/admin/sso/PRO__google.fr.md b/docs/content/admin/sso/PRO__google.fr.md new file mode 100644 index 00000000000..31200b1f86c --- /dev/null +++ b/docs/content/admin/sso/PRO__google.fr.md @@ -0,0 +1,38 @@ +--- +title: Authentification Google +description: Configurer OAuth Google dans DefectDojo Pro +weight: 11 +audience: pro +--- + +DefectDojo Pro prend en charge la connexion via des comptes Google. Les nouveaux utilisateurs sont créés automatiquement lors de leur première connexion s'ils n'existent pas déjà. Les utilisateurs DefectDojo existants sont associés à des comptes Google par nom d'utilisateur (la partie avant le `@` dans leur adresse e-mail Google). DefectDojo open source n'inclut pas le SSO — voir [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +## Prérequis + +Effectuez les étapes suivantes dans la Google Cloud Console avant de configurer DefectDojo : + +1. Connectez-vous à la [Google Developers Console](https://console.developers.google.com). + +2. Accédez à **Credentials > Create Credentials > OAuth Client ID**. + + ![image](images/google_1.png) + +3. Sélectionnez **Web Application** et donnez-lui un nom descriptif (par exemple `DefectDojo`). + +4. Sous **Authorized Redirect URIs**, ajoutez : + `https://your-instance.cloud.defectdojo.com/complete/google-oauth2/` + +5. Notez le **Client ID** et la **Client Secret Key**. + +## Configuration + +Dans DefectDojo, accédez à **Enterprise Settings > OAuth Settings**, sélectionnez **Google**, et remplissez le formulaire : + +- **Google OAuth Key** — saisissez votre **Client ID** +- **Google OAuth Secret** — saisissez votre **Client Secret Key** +- **Whitelisted Domains** — saisissez le domaine de votre organisation (par exemple `yourcompany.com`) pour permettre à tout utilisateur de ce domaine de se connecter +- **Whitelisted E-mail Addresses** — vous pouvez aussi saisir des adresses e-mail spécifiques à autoriser (par exemple `user1@yourcompany.com, user2@yourcompany.com`) + +Vous devez définir au moins un domaine ou une adresse e-mail autorisé, sinon aucun utilisateur ne pourra se connecter via Google. + +Cochez **Enable Google OAuth** et validez le formulaire. Un bouton **Login With Google** apparaîtra sur la page de connexion. diff --git a/docs/content/admin/sso/PRO__google.ja.md b/docs/content/admin/sso/PRO__google.ja.md new file mode 100644 index 00000000000..36220e7722a --- /dev/null +++ b/docs/content/admin/sso/PRO__google.ja.md @@ -0,0 +1,38 @@ +--- +title: Google Auth +description: DefectDojo ProでGoogle OAuthを設定する +weight: 11 +audience: pro +--- + +DefectDojo ProはGoogleアカウントによるログインをサポートしています。新規ユーザーは、初回ログイン時にまだ存在しない場合は自動的に作成されます。既存のDefectDojoユーザーは、Googleメールアドレスの`@`より前の部分(ユーザー名)によってGoogleアカウントと照合されます。オープンソース版のDefectDojoにはSSOは含まれていません。オープンソース版のアクセス制御については[Authorized Users](/admin/user_management/os__authorized_users/)を参照してください。 + +## Prerequisites + +DefectDojoを設定する前に、Google Cloud Consoleで以下の手順を完了してください。 + +1. [Google Developers Console](https://console.developers.google.com)にサインインします。 + +2. **Credentials > Create Credentials > OAuth Client ID**に移動します。 + + ![image](images/google_1.png) + +3. **Web Application**を選択し、分かりやすい名前(例: `DefectDojo`)を付けます。 + +4. **Authorized Redirect URIs**に以下を追加します。 + `https://your-instance.cloud.defectdojo.com/complete/google-oauth2/` + +5. **Client ID**と**Client Secret Key**を控えます。 + +## Configuration + +DefectDojoで**Enterprise Settings > OAuth Settings**に移動し、**Google**を選択してフォームに入力します。 + +- **Google OAuth Key** — **Client ID**を入力します +- **Google OAuth Secret** — **Client Secret Key**を入力します +- **Whitelisted Domains** — 組織のドメイン(例: `yourcompany.com`)を入力すると、そのドメインを持つすべてのユーザーがログインできるようになります +- **Whitelisted E-mail Addresses** — あるいは、許可する特定のメールアドレス(例: `user1@yourcompany.com, user2@yourcompany.com`)を入力します + +ホワイトリストのドメインまたはメールアドレスを少なくとも1つ設定する必要があります。設定しないと、Google経由でログインできるユーザーがいなくなります。 + +**Enable Google OAuth**をチェックしてフォームを送信します。ログインページに**Login With Google**ボタンが表示されます。 diff --git a/docs/content/admin/sso/PRO__keycloak.de.md b/docs/content/admin/sso/PRO__keycloak.de.md new file mode 100644 index 00000000000..bc78d601b92 --- /dev/null +++ b/docs/content/admin/sso/PRO__keycloak.de.md @@ -0,0 +1,53 @@ +--- +title: KeyCloak +description: Konfigurieren Sie KeyCloak SSO in DefectDojo Pro +weight: 13 +audience: pro +--- + +DefectDojo Pro unterstützt die Anmeldung über KeyCloak. Open-Source-DefectDojo enthält kein SSO — siehe [Authorized Users](/admin/user_management/os__authorized_users/) für die Zugriffskontrolle in der Open-Source-Version. + +Diese Anleitung setzt voraus, dass bereits ein KeyCloak Realm eingerichtet ist. Falls nicht, siehe die [KeyCloak-Dokumentation](https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/realms/create.html). + +## Voraussetzungen + +Führen Sie die folgenden Schritte in Ihrem KeyCloak-Realm aus, bevor Sie DefectDojo konfigurieren: + +1. Fügen Sie einen neuen Client vom Typ `openid-connect` hinzu. Notieren Sie sich die Client-ID. + +2. In den Client-Einstellungen: + - Setzen Sie **Access Type** auf `confidential` + - Fügen Sie unter **Valid Redirect URIs** Ihre DefectDojo-URL hinzu, z. B. `https://yourorganization.cloud.defectdojo.com` oder `https://your-dojo-host/*` + - Fügen Sie unter **Web Origins** dieselbe URL hinzu (oder `+`) + - Unter **Fine Grained OpenID Connect Configuration**: + - Setzen Sie **User Info Signed Response Algorithm** auf `RS256` + - Setzen Sie **Request Object Signature Algorithm** auf `RS256` + - Speichern Sie die Einstellungen. + +3. Setzen Sie unter **Scope** die Option **Full Scope Allowed** auf `off`. + +4. Fügen Sie unter **Mappers** einen benutzerdefinierten Mapper hinzu: + - **Name:** `aud` + - **Mapper Type:** `audience` + - **Included Audience:** wählen Sie Ihre Client-ID aus + - **Add ID to Token:** `off` + - **Add Access to Token:** `on` + +5. Kopieren Sie unter **Credentials** das **Secret**. + +6. Kopieren Sie unter **Realm Settings > Keys** den **Public Key** (Signaturschlüssel). + +7. Öffnen Sie unter **Realm Settings > General > Endpoints** die OpenID-Endpunktkonfiguration und kopieren Sie die URLs der **Authorization**- und **Token**-Endpunkte. + +## Konfiguration + +Gehen Sie in DefectDojo zu **Enterprise Settings > OAuth Settings**, wählen Sie **KeyCloak** aus und füllen Sie das Formular aus: + +- **KeyCloak OAuth Key** — geben Sie Ihren Clientnamen ein (aus Schritt 1) +- **KeyCloak OAuth Secret** — geben Sie das Secret der Client-Anmeldedaten ein (aus Schritt 5) +- **KeyCloak Public Key** — geben Sie den Public Key aus Ihren Realm-Einstellungen ein (aus Schritt 6) +- **KeyCloak Resource** — geben Sie die URL des Authorization-Endpunkts ein (aus Schritt 7) +- **KeyCloak Group Limiter** — geben Sie die URL des Token-Endpunkts ein (aus Schritt 7) +- **KeyCloak OAuth Login Button Text** — wählen Sie den Text für die DefectDojo-Anmeldeschaltfläche + +Aktivieren Sie **Enable KeyCloak OAuth** und senden Sie das Formular ab. Auf der Anmeldeseite erscheint eine Anmeldeschaltfläche mit dem von Ihnen konfigurierten Text. diff --git a/docs/content/admin/sso/PRO__keycloak.es.md b/docs/content/admin/sso/PRO__keycloak.es.md new file mode 100644 index 00000000000..ed5f0af5c6b --- /dev/null +++ b/docs/content/admin/sso/PRO__keycloak.es.md @@ -0,0 +1,53 @@ +--- +title: KeyCloak +description: Configure el SSO de KeyCloak en DefectDojo Pro +weight: 13 +audience: pro +--- + +DefectDojo Pro admite el inicio de sesión mediante KeyCloak. DefectDojo de código abierto no incluye SSO — consulte [Authorized Users](/admin/user_management/os__authorized_users/) para el control de acceso de código abierto. + +Esta guía asume que ya tiene un Realm de KeyCloak configurado. Si no es así, consulte la [documentación de KeyCloak](https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/realms/create.html). + +## Requisitos previos + +Complete los siguientes pasos en su realm de KeyCloak antes de configurar DefectDojo: + +1. Añada un nuevo cliente de tipo `openid-connect`. Anote el ID de cliente. + +2. En la configuración del cliente: + - Establezca **Access Type** en `confidential` + - En **Valid Redirect URIs**, añada la URL de su DefectDojo, por ejemplo `https://yourorganization.cloud.defectdojo.com` o `https://your-dojo-host/*` + - En **Web Origins**, añada la misma URL (o `+`) + - En **Fine Grained OpenID Connect Configuration**: + - Establezca **User Info Signed Response Algorithm** en `RS256` + - Establezca **Request Object Signature Algorithm** en `RS256` + - Guarde la configuración. + +3. En **Scope**, establezca **Full Scope Allowed** en `off`. + +4. En **Mappers**, añada un mapper personalizado: + - **Name:** `aud` + - **Mapper Type:** `audience` + - **Included Audience:** seleccione su ID de cliente + - **Add ID to Token:** `off` + - **Add Access to Token:** `on` + +5. En **Credentials**, copie el **Secret**. + +6. En **Realm Settings > Keys**, copie la **Public Key** (clave de firma). + +7. En **Realm Settings > General > Endpoints**, abra la configuración del endpoint de OpenID y copie las URL de los endpoints **Authorization** y **Token**. + +## Configuración + +En DefectDojo, vaya a **Enterprise Settings > OAuth Settings**, seleccione **KeyCloak** y complete el formulario: + +- **KeyCloak OAuth Key** — introduzca el nombre de su cliente (del paso 1) +- **KeyCloak OAuth Secret** — introduzca el secreto de credenciales de su cliente (del paso 5) +- **KeyCloak Public Key** — introduzca la Public Key de la configuración de su realm (del paso 6) +- **KeyCloak Resource** — introduzca la URL del Authorization Endpoint (del paso 7) +- **KeyCloak Group Limiter** — introduzca la URL del Token Endpoint (del paso 7) +- **KeyCloak OAuth Login Button Text** — elija el texto para el botón de inicio de sesión de DefectDojo + +Marque **Enable KeyCloak OAuth** y envíe el formulario. Aparecerá un botón de inicio de sesión en la página de inicio de sesión con el texto que haya configurado. diff --git a/docs/content/admin/sso/PRO__keycloak.fr.md b/docs/content/admin/sso/PRO__keycloak.fr.md new file mode 100644 index 00000000000..1ec811126a0 --- /dev/null +++ b/docs/content/admin/sso/PRO__keycloak.fr.md @@ -0,0 +1,53 @@ +--- +title: KeyCloak +description: Configurer le SSO KeyCloak dans DefectDojo Pro +weight: 13 +audience: pro +--- + +DefectDojo Pro prend en charge la connexion via KeyCloak. DefectDojo open source n'inclut pas le SSO — voir [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +Ce guide suppose que vous disposez déjà d'un Realm KeyCloak configuré. Si ce n'est pas le cas, consultez la [documentation KeyCloak](https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/realms/create.html). + +## Prérequis + +Effectuez les étapes suivantes dans votre realm KeyCloak avant de configurer DefectDojo : + +1. Ajoutez un nouveau client de type `openid-connect`. Notez l'ID du client. + +2. Dans les paramètres du client : + - Définissez **Access Type** sur `confidential` + - Sous **Valid Redirect URIs**, ajoutez votre URL DefectDojo, par exemple `https://yourorganization.cloud.defectdojo.com` ou `https://your-dojo-host/*` + - Sous **Web Origins**, ajoutez la même URL (ou `+`) + - Sous **Fine Grained OpenID Connect Configuration** : + - Définissez **User Info Signed Response Algorithm** sur `RS256` + - Définissez **Request Object Signature Algorithm** sur `RS256` + - Enregistrez les paramètres. + +3. Sous **Scope**, définissez **Full Scope Allowed** sur `off`. + +4. Sous **Mappers**, ajoutez un mapper personnalisé : + - **Name:** `aud` + - **Mapper Type:** `audience` + - **Included Audience:** sélectionnez l'ID de votre client + - **Add ID to Token:** `off` + - **Add Access to Token:** `on` + +5. Sous **Credentials**, copiez le **Secret**. + +6. Dans **Realm Settings > Keys**, copiez la **Public Key** (clé de signature). + +7. Dans **Realm Settings > General > Endpoints**, ouvrez la configuration du point de terminaison OpenID et copiez les URL des points de terminaison **Authorization** et **Token**. + +## Configuration + +Dans DefectDojo, accédez à **Enterprise Settings > OAuth Settings**, sélectionnez **KeyCloak**, et remplissez le formulaire : + +- **KeyCloak OAuth Key** — saisissez le nom de votre client (issu de l'étape 1) +- **KeyCloak OAuth Secret** — saisissez le secret des identifiants de votre client (issu de l'étape 5) +- **KeyCloak Public Key** — saisissez la Public Key de vos paramètres de realm (issue de l'étape 6) +- **KeyCloak Resource** — saisissez l'URL du point de terminaison Authorization (issue de l'étape 7) +- **KeyCloak Group Limiter** — saisissez l'URL du point de terminaison Token (issue de l'étape 7) +- **KeyCloak OAuth Login Button Text** — choisissez le texte du bouton de connexion DefectDojo + +Cochez **Enable KeyCloak OAuth** et validez le formulaire. Un bouton de connexion apparaîtra sur la page de connexion avec le texte que vous avez configuré. diff --git a/docs/content/admin/sso/PRO__keycloak.ja.md b/docs/content/admin/sso/PRO__keycloak.ja.md new file mode 100644 index 00000000000..e4090aca1cf --- /dev/null +++ b/docs/content/admin/sso/PRO__keycloak.ja.md @@ -0,0 +1,53 @@ +--- +title: KeyCloak +description: DefectDojo ProでKeyCloak SSOを設定する +weight: 13 +audience: pro +--- + +DefectDojo ProはKeyCloakによるログインをサポートしています。オープンソース版のDefectDojoにはSSOは含まれていません。オープンソース版のアクセス制御については[Authorized Users](/admin/user_management/os__authorized_users/)を参照してください。 + +このガイドは、KeyCloak Realmがすでに設定済みであることを前提としています。未設定の場合は[KeyCloak documentation](https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/realms/create.html)を参照してください。 + +## Prerequisites + +DefectDojoを設定する前に、KeyCloak Realmで以下の手順を完了してください。 + +1. タイプ`openid-connect`で新しいクライアントを追加します。クライアントIDを控えます。 + +2. クライアント設定で以下を行います。 + - **Access Type**を`confidential`に設定します + - **Valid Redirect URIs**にDefectDojoのURL(例: `https://yourorganization.cloud.defectdojo.com`または`https://your-dojo-host/*`)を追加します + - **Web Origins**に同じURL(または`+`)を追加します + - **Fine Grained OpenID Connect Configuration**で以下を設定します。 + - **User Info Signed Response Algorithm**を`RS256`に設定 + - **Request Object Signature Algorithm**を`RS256`に設定 + - 設定を保存します。 + +3. **Scope**で**Full Scope Allowed**を`off`に設定します。 + +4. **Mappers**でカスタムマッパーを追加します。 + - **Name:** `aud` + - **Mapper Type:** `audience` + - **Included Audience:** クライアントIDを選択 + - **Add ID to Token:** `off` + - **Add Access to Token:** `on` + +5. **Credentials**で**Secret**をコピーします。 + +6. **Realm Settings > Keys**で**Public Key**(署名鍵)をコピーします。 + +7. **Realm Settings > General > Endpoints**でOpenIDエンドポイント設定を開き、**Authorization**エンドポイントと**Token**エンドポイントのURLをコピーします。 + +## Configuration + +DefectDojoで**Enterprise Settings > OAuth Settings**に移動し、**KeyCloak**を選択してフォームに入力します。 + +- **KeyCloak OAuth Key** — クライアント名(手順1)を入力します +- **KeyCloak OAuth Secret** — クライアントクレデンシャルのシークレット(手順5)を入力します +- **KeyCloak Public Key** — Realm設定のPublic Key(手順6)を入力します +- **KeyCloak Resource** — Authorization EndpointのURL(手順7)を入力します +- **KeyCloak Group Limiter** — Token EndpointのURL(手順7)を入力します +- **KeyCloak OAuth Login Button Text** — DefectDojoのログインボタンに表示するテキストを選びます + +**Enable KeyCloak OAuth**をチェックしてフォームを送信します。ログインページに、設定したテキストのログインボタンが表示されます。 diff --git a/docs/content/admin/sso/PRO__ldap.de.md b/docs/content/admin/sso/PRO__ldap.de.md new file mode 100644 index 00000000000..72048969ede --- /dev/null +++ b/docs/content/admin/sso/PRO__ldap.de.md @@ -0,0 +1,76 @@ +--- +title: LDAP Authentication +description: Konfigurieren Sie die LDAP-Authentifizierung in DefectDojo Pro +weight: 20 +audience: pro +aliases: +- /de/en/open_source/ldap-authentication +--- + +DefectDojo Pro unterstützt die LDAP-Authentifizierung über die Benutzeroberfläche der **Enterprise Settings** — es sind keine benutzerdefinierten Docker-Images oder Konfigurationsdateien erforderlich. + +Anders als die übrigen Anbieter auf dieser Seite basiert LDAP nicht auf einem Redirect-Flow. Benutzer melden sich über das übliche DefectDojo-Formular für Benutzername und Passwort an, und ihre Anmeldedaten werden gegen Ihr Verzeichnis geprüft. Es gibt keine zusätzliche Anmeldeschaltfläche. + +## Konfiguration + +Öffnen Sie **Enterprise Settings > LDAP Settings**. + +![image](images/sso_ldap_settings.png) + +1. **Server URI** — das Verzeichnis, mit dem eine Verbindung hergestellt wird, z. B. `ldaps://ldap.example.com:636`. + Bevorzugen Sie `ldaps://`. Falls Sie ein einfaches `ldap://` verwenden müssen, aktivieren Sie unten **Use StartTLS**, damit die Verbindung verschlüsselt wird, bevor Anmeldedaten gesendet werden. +2. **Bind DN** — der Distinguished Name des Dienstkontos, das zur Suche nach Benutzern verwendet wird. + Lassen Sie das Feld für einen anonymen Bind leer. +3. **Bind Password** — das Passwort für dieses Dienstkonto. Der gespeicherte Wert wird niemals an den Browser zurückgegeben; lassen Sie das Feld leer, um das bereits gespeicherte Passwort beizubehalten. +4. **User Search Base** — der DN, unterhalb dessen nach Benutzereinträgen gesucht wird, z. B. + `ou=people,dc=example,dc=com`. +5. **User Search Filter** — der Filter, mit dem der Benutzer gefunden wird. Er **muss** den literalen Platzhalter `%(user)s` enthalten, der durch den eingegebenen Benutzernamen ersetzt wird. Übliche Werte sind `(uid=%(user)s)` für OpenLDAP und `(sAMAccountName=%(user)s)` für Active Directory. +6. **User Attribute Mapping** — siehe unten. +7. Aktivieren Sie **Enable LDAP**, um es zu aktivieren. + +Verwenden Sie **Validate Config**, um die Einstellungen zu prüfen, ohne sie zu speichern. Es meldet, ob die Einstellungen vollständig sind, ob der Server erreichbar ist, ob der Bind erfolgreich ist, ob sich die Such-Basen auflösen lassen und ob die Attributzuordnung brauchbar erscheint. + +## User Attribute Mapping + +Jede Zeile ordnet ein **LDAP Attribute** dem **DefectDojo Field** zu, das es befüllen soll. Verwenden Sie **Add Attribute Mapping** für weitere Zeilen und das Papierkorbsymbol, um eine zu entfernen. + +![image](images/sso_ldap_attribute_mapping.png) + +- **LDAP Attribute** ist Freitext und muss dem Attribut entsprechen, das Ihr Verzeichnis tatsächlich zurückgibt — zum Beispiel `uid`, `givenName`, `sn`, `mail` bei OpenLDAP oder `sAMAccountName`, `givenName`, `sn`, `mail` bei Active Directory. +- **DefectDojo Field** wird aus einer Liste ausgewählt: **Username**, **First Name**, **Last Name** und **Email**. +- Es wird dringend empfohlen, ein Attribut auf **Email** zu mappen: DefectDojo verwendet die E-Mail-Adresse für Benachrichtigungen. +- Dasselbe Attribut kann mehr als ein Feld befüllen. Jedes DefectDojo-Feld kann jedoch nur von einem einzigen Attribut befüllt werden. +- Ohne jegliche Zuordnung werden Konten ohne Namen oder E-Mail-Adresse erstellt. + +**Always Update User** legt fest, wann die Zuordnung angewendet wird. Ist die Option aktiviert (Standard), werden die zugeordneten Attribute bei jeder Anmeldung aus dem Verzeichnis aktualisiert, sodass eine Namens- oder E-Mail-Änderung in LDAP auch DefectDojo erreicht. Ist sie deaktiviert, werden sie nur bei der erstmaligen Erstellung des Kontos angewendet. + +## Group Mapping + +DefectDojo kann die LDAP-Gruppen eines Benutzers bei der Anmeldung in DefectDojo-Gruppen spiegeln. Aktivieren Sie **Enable Group Mapping**, um die Einstellungen anzuzeigen. + +![image](images/sso_ldap_group_mapping.png) + +- **Group Search Base** — der DN, unterhalb dessen nach Gruppeneinträgen gesucht wird, z. B. + `ou=groups,dc=example,dc=com`. Erforderlich, wenn Group Mapping aktiviert ist. +- **Group Type** — wie Ihr Verzeichnis Mitgliedschaften modelliert. Wählen Sie **groupOfNames** für OpenLDAP und Active Directory, **groupOfUniqueNames** oder **posixGroup**. +- **Group Limiter Regex Expression** — nur Gruppen, deren Name diesem Ausdruck entspricht, werden gespiegelt. Verwenden Sie `.*`, um alle zuzulassen, oder ein Präfix wie `^dd-`, um nur die Gruppen zu spiegeln, die DefectDojo verwalten soll. + +Gruppen werden bei der ersten Verwendung erstellt, falls sie noch nicht existieren. Eine neu erstellte Gruppe hat keine Berechtigungen, bis ein Superuser diese konfiguriert — siehe +[User Groups](../../user_management/create_user_group/). + +## Weitere Optionen + +* **Use StartTLS** — verschlüsselt eine einfache `ldap://`-Verbindung mit TLS, bevor der Bind erfolgt. Nicht erforderlich, wenn die URI bereits `ldaps://` lautet. +* **Always Update User** — aktualisiert die zugeordneten Attribute bei jeder Anmeldung aus dem Verzeichnis. + +## Fehlerbehebung + +Führen Sie zuerst **Validate Config** aus — meist wird das Problem direkt benannt. Darüber hinaus: + +**Jede Anmeldung schlägt fehl, obwohl das Verzeichnis erreichbar ist.** Prüfen Sie, ob der **User Search Filter** `%(user)s` enthält und ob das darin enthaltene Attribut dem entspricht, was Benutzer tatsächlich eingeben. Ein Filter wie `(uid=%(user)s)` passt niemals, wenn sich Ihre Benutzer mit einem Active-Directory-`sAMAccountName` anmelden. + +**Anmeldungen gelingen, aber Konten haben keinen Namen oder keine E-Mail-Adresse.** Das **User Attribute Mapping** ist leer, oder die LDAP-Attributnamen auf der linken Seite entsprechen nicht dem, was Ihr Verzeichnis zurückgibt. + +**Ein Name wurde in LDAP geändert, aber nicht in DefectDojo.** **Always Update User** ist deaktiviert, sodass die Zuordnung nur bei der Erstellung des Kontos angewendet wurde. + +**Anmeldeversuche hängen oder sind langsam.** Verbindungen und Suchvorgänge sind durch ein Timeout begrenzt, sodass ein nicht erreichbares Verzeichnis fehlschlägt, statt unbegrenzt zu blockieren. Prüfen Sie **Server Reachability** in **Validate Config** und stellen Sie sicher, dass der Port vom DefectDojo-Host aus erreichbar ist. diff --git a/docs/content/admin/sso/PRO__ldap.es.md b/docs/content/admin/sso/PRO__ldap.es.md new file mode 100644 index 00000000000..a530f10180b --- /dev/null +++ b/docs/content/admin/sso/PRO__ldap.es.md @@ -0,0 +1,74 @@ +--- +title: LDAP Authentication +description: Configure la autenticación LDAP en DefectDojo Pro +weight: 20 +audience: pro +aliases: +- /es/en/open_source/ldap-authentication +--- + +DefectDojo Pro admite la autenticación LDAP desde la interfaz de **Enterprise Settings** — no se necesitan imágenes de Docker personalizadas ni archivos de configuración. + +A diferencia de los demás proveedores de esta página, LDAP no es un flujo basado en redirección. Los usuarios inician sesión con el formulario estándar de nombre de usuario y contraseña de DefectDojo, y sus credenciales se verifican contra su directorio. No hay ningún botón de inicio de sesión adicional. + +## Configuración + +Abra **Enterprise Settings > LDAP Settings**. + +![imagen](images/sso_ldap_settings.png) + +1. **Server URI** — el directorio al que conectarse, por ejemplo `ldaps://ldap.example.com:636`. + Prefiera `ldaps://`. Si debe usar `ldap://` sin cifrar, habilite **Use StartTLS** más abajo para que la conexión se actualice a un canal cifrado antes de enviar las credenciales. +2. **Bind DN** — el nombre distintivo de la cuenta de servicio usada para buscar usuarios. + Déjelo en blanco para un bind anónimo. +3. **Bind Password** — la contraseña de esa cuenta de servicio. El valor almacenado nunca se devuelve al navegador; deje el campo en blanco para conservar la contraseña que ya guardó. +4. **User Search Base** — el DN bajo el cual buscar las entradas de usuario, por ejemplo + `ou=people,dc=example,dc=com`. +5. **User Search Filter** — el filtro usado para localizar al usuario. **Debe** contener el marcador de posición literal `%(user)s`, que se sustituye por el nombre de usuario introducido. Los valores habituales son `(uid=%(user)s)` para OpenLDAP y `(sAMAccountName=%(user)s)` para Active Directory. +6. **User Attribute Mapping** — vea más abajo. +7. Marque **Enable LDAP** para activarlo. + +Use **Validate Config** para comprobar la configuración sin guardarla. Informa sobre si la configuración está completa, si el servidor es accesible, si el bind se realiza correctamente, si las bases de búsqueda se resuelven, y si la asignación de atributos parece utilizable. + +## User Attribute Mapping + +Cada fila asigna un **LDAP Attribute** al **DefectDojo Field** que debe rellenar. Use **Add Attribute Mapping** para añadir más filas y el icono de papelera para eliminar una. + +![imagen](images/sso_ldap_attribute_mapping.png) + +- **LDAP Attribute** es texto libre y debe coincidir con el atributo que realmente devuelve su directorio — por ejemplo `uid`, `givenName`, `sn`, `mail` en OpenLDAP, o `sAMAccountName`, `givenName`, `sn`, `mail` en Active Directory. +- **DefectDojo Field** se elige de una lista: **Username**, **First Name**, **Last Name** y **Email**. +- Se recomienda encarecidamente asignar un atributo a **Email**: DefectDojo usa la dirección de correo para las notificaciones. +- El mismo atributo puede alimentar más de un campo. Cada campo de DefectDojo solo puede asignarse desde un único atributo. +- Sin ninguna asignación, las cuentas se crean sin nombre ni dirección de correo. + +**Always Update User** controla cuándo se aplica la asignación. Cuando está habilitado (el valor predeterminado), los atributos asignados se actualizan desde el directorio en cada inicio de sesión, de modo que un cambio de nombre o correo en LDAP llega a DefectDojo. Cuando está deshabilitado, solo se aplican cuando se crea la cuenta por primera vez. + +## Group Mapping + +DefectDojo puede reflejar los grupos LDAP de un usuario en grupos de DefectDojo al iniciar sesión. Marque **Enable Group Mapping** para mostrar la configuración. + +![imagen](images/sso_ldap_group_mapping.png) + +- **Group Search Base** — el DN bajo el cual buscar las entradas de grupo, por ejemplo `ou=groups,dc=example,dc=com`. Obligatorio cuando la asignación de grupos está habilitada. +- **Group Type** — cómo modela la pertenencia su directorio. Elija **groupOfNames** para OpenLDAP y Active Directory, **groupOfUniqueNames**, o **posixGroup**. +- **Group Limiter Regex Expression** — solo se reflejan los grupos cuyo nombre coincide con esta expresión. Use `.*` para permitir todos, o un prefijo como `^dd-` para reflejar solo los grupos que DefectDojo debe gestionar. + +Los grupos se crean en el primer uso si aún no existen. Un grupo recién creado no tiene permisos hasta que un Superuser los configura — consulte [User Groups](../../user_management/create_user_group/). + +## Additional Options + +* **Use StartTLS** — actualiza una conexión `ldap://` sin cifrar a TLS antes de realizar el bind. No es necesario cuando el URI ya es `ldaps://`. +* **Always Update User** — actualiza los atributos asignados desde el directorio en cada inicio de sesión. + +## Solución de problemas + +Ejecute primero **Validate Config** — normalmente indicará el problema directamente. Más allá de eso: + +**Todos los inicios de sesión fallan, pero el directorio es accesible.** Compruebe que el **User Search Filter** contiene `%(user)s` y que el atributo que contiene coincide con lo que los usuarios realmente escriben. Un filtro `(uid=%(user)s)` nunca coincidirá si sus usuarios inician sesión con un `sAMAccountName` de Active Directory. + +**Los inicios de sesión funcionan pero las cuentas no tienen nombre ni correo.** El **User Attribute Mapping** está vacío, o los nombres de atributo LDAP de la izquierda no coinciden con lo que devuelve su directorio. + +**Un nombre cambió en LDAP pero no en DefectDojo.** **Always Update User** está deshabilitado, por lo que la asignación solo se aplicó cuando se creó la cuenta. + +**Los intentos de inicio de sesión se quedan colgados o son lentos.** Las conexiones y búsquedas están limitadas por un tiempo de espera, de modo que un directorio inaccesible falla en lugar de bloquearse indefinidamente. Compruebe **Server Reachability** en **Validate Config** y confirme que el puerto está abierto desde el host de DefectDojo. diff --git a/docs/content/admin/sso/PRO__ldap.fr.md b/docs/content/admin/sso/PRO__ldap.fr.md new file mode 100644 index 00000000000..00de2452865 --- /dev/null +++ b/docs/content/admin/sso/PRO__ldap.fr.md @@ -0,0 +1,108 @@ +--- +title: Authentification LDAP +description: Configurer l'authentification LDAP dans DefectDojo Pro +weight: 20 +audience: pro +aliases: +- /fr/en/open_source/ldap-authentication +--- + +DefectDojo Pro prend en charge l'authentification LDAP depuis l'interface **Enterprise Settings** — aucune image Docker personnalisée +ni fichier de configuration n'est nécessaire. + +Contrairement aux autres fournisseurs de cette page, LDAP ne fonctionne pas par redirection. Les utilisateurs se connectent +avec le formulaire standard de nom d'utilisateur et de mot de passe de DefectDojo, et leurs identifiants sont vérifiés +auprès de votre annuaire. Il n'y a pas de bouton de connexion supplémentaire. + +## Configuration + +Ouvrez **Enterprise Settings > LDAP Settings**. + +![image](images/sso_ldap_settings.png) + +1. **Server URI** — l'annuaire auquel se connecter, par exemple `ldaps://ldap.example.com:636`. + Privilégiez `ldaps://`. Si vous devez utiliser `ldap://` en clair, activez **Use StartTLS** ci-dessous afin que la + connexion soit mise à niveau avant l'envoi des identifiants. +2. **Bind DN** — le nom distinctif du compte de service utilisé pour rechercher les utilisateurs. + Laissez vide pour une liaison anonyme. +3. **Bind Password** — le mot de passe de ce compte de service. La valeur enregistrée n'est jamais + renvoyée au navigateur ; laissez le champ vide pour conserver le mot de passe déjà enregistré. +4. **User Search Base** — le DN sous lequel rechercher les entrées utilisateur, par exemple + `ou=people,dc=example,dc=com`. +5. **User Search Filter** — le filtre utilisé pour localiser l'utilisateur. Il **doit** contenir le + paramètre littéral `%(user)s`, qui est remplacé par le nom d'utilisateur saisi. Les valeurs + courantes sont `(uid=%(user)s)` pour OpenLDAP et `(sAMAccountName=%(user)s)` pour Active + Directory. +6. **User Attribute Mapping** — voir ci-dessous. +7. Cochez **Enable LDAP** pour l'activer. + +Utilisez **Validate Config** pour vérifier les paramètres sans les enregistrer. Cela indique si les paramètres sont +complets, si le serveur est accessible, si la liaison réussit, si les bases de recherche se résolvent, et si le +mappage des attributs semble utilisable. + +## User Attribute Mapping + +Chaque ligne associe un **LDAP Attribute** au **DefectDojo Field** qu'il doit renseigner. Utilisez +**Add Attribute Mapping** pour ajouter des lignes supplémentaires et l'icône de corbeille pour en supprimer une. + +![image](images/sso_ldap_attribute_mapping.png) + +- **LDAP Attribute** est un champ de texte libre qui doit correspondre à l'attribut réellement + renvoyé par votre annuaire — par exemple `uid`, `givenName`, `sn`, `mail` sur OpenLDAP, ou `sAMAccountName`, + `givenName`, `sn`, `mail` sur Active Directory. +- **DefectDojo Field** se choisit dans une liste : **Username**, **First Name**, **Last Name** et + **Email**. +- Il est fortement recommandé de mapper un attribut vers **Email** : DefectDojo utilise l'adresse e-mail + pour les notifications. +- Un même attribut peut alimenter plusieurs champs. Chaque champ DefectDojo ne peut être mappé + qu'à partir d'un seul attribut. +- Sans aucun mappage, les comptes sont créés sans nom ni adresse e-mail. + +**Always Update User** détermine quand le mappage est appliqué. Lorsqu'il est activé (par défaut), les +attributs mappés sont actualisés depuis l'annuaire à chaque connexion, si bien qu'un changement de nom ou d'e-mail +dans LDAP se répercute dans DefectDojo. Lorsqu'il est désactivé, ils ne sont appliqués qu'à la création du +compte. + +## Group Mapping + +DefectDojo peut refléter les groupes LDAP d'un utilisateur dans les groupes DefectDojo à la connexion. Cochez **Enable +Group Mapping** pour afficher les paramètres. + +![image](images/sso_ldap_group_mapping.png) + +- **Group Search Base** — le DN sous lequel rechercher les entrées de groupe, par exemple + `ou=groups,dc=example,dc=com`. Requis lorsque le mappage de groupes est activé. +- **Group Type** — la façon dont votre annuaire modélise l'appartenance. Choisissez **groupOfNames** pour + OpenLDAP et Active Directory, **groupOfUniqueNames**, ou **posixGroup**. +- **Group Limiter Regex Expression** — seuls les groupes dont le nom correspond à cette expression sont + reflétés. Utilisez `.*` pour tous les autoriser, ou un préfixe tel que `^dd-` pour ne refléter que les groupes + que vous souhaitez voir gérés par DefectDojo. + +Les groupes sont créés à la première utilisation s'ils n'existent pas déjà. Un groupe nouvellement créé n'a aucune +permission tant qu'un superutilisateur ne les configure pas — voir +[Groupes d'utilisateurs](../../user_management/create_user_group/). + +## Options supplémentaires + +* **Use StartTLS** — met à niveau vers TLS une connexion `ldap://` en clair avant la liaison. Non nécessaire + lorsque l'URI est déjà `ldaps://`. +* **Always Update User** — actualise les attributs mappés depuis l'annuaire à chaque connexion. + +## Dépannage + +Exécutez d'abord **Validate Config** — cela identifie généralement le problème directement. Au-delà de cela : + +**Toutes les connexions échouent, mais l'annuaire est accessible.** Vérifiez que le **User Search Filter** +contient `%(user)s` et que l'attribut qu'il contient correspond à ce que les utilisateurs saisissent réellement. Un filtre +du type `(uid=%(user)s)` ne correspondra jamais si vos utilisateurs se connectent avec un +`sAMAccountName` Active Directory. + +**Les connexions réussissent mais les comptes n'ont ni nom ni e-mail.** Le **User Attribute Mapping** est +vide, ou les noms d'attributs LDAP à gauche ne correspondent pas à ce que renvoie votre annuaire. + +**Un nom a changé dans LDAP mais pas dans DefectDojo.** **Always Update User** est désactivé, si bien que le +mappage ne s'est appliqué qu'à la création du compte. + +**Les tentatives de connexion se bloquent ou sont lentes.** Les connexions et les recherches sont limitées par un +délai d'expiration, de sorte qu'un annuaire inaccessible échoue au lieu de bloquer indéfiniment. Vérifiez **Server Reachability** +dans **Validate Config** et confirmez que le port est ouvert depuis l'hôte DefectDojo. diff --git a/docs/content/admin/sso/PRO__ldap.ja.md b/docs/content/admin/sso/PRO__ldap.ja.md new file mode 100644 index 00000000000..b6ad647015c --- /dev/null +++ b/docs/content/admin/sso/PRO__ldap.ja.md @@ -0,0 +1,73 @@ +--- +title: LDAP認証 +description: DefectDojo ProでLDAP認証を設定する +weight: 20 +audience: pro +aliases: +- /ja/en/open_source/ldap-authentication +--- + +DefectDojo Proは**Enterprise Settings**のUIからLDAP認証をサポートしています。カスタムのDockerイメージや設定ファイルは不要です。 + +このページの他のプロバイダーと異なり、LDAPはリダイレクト方式のフローではありません。ユーザーは標準のDefectDojoのユーザー名・パスワードフォームでサインインし、その資格情報がディレクトリと照合されます。追加のログインボタンはありません。 + +## Configuration + +**Enterprise Settings > LDAP Settings**を開きます。 + +![image](images/sso_ldap_settings.png) + +1. **Server URI** — 接続先のディレクトリ(例: `ldaps://ldap.example.com:636`)。 + `ldaps://`の使用を推奨します。平文の`ldap://`を使わざるを得ない場合は、資格情報を送信する前に接続をアップグレードするよう、下記の**Use StartTLS**を有効にしてください。 +2. **Bind DN** — ユーザーの検索に使用するサービスアカウントの識別名(DN)。 + 匿名バインドの場合は空欄のままにします。 +3. **Bind Password** — そのサービスアカウントのパスワード。保存済みの値がブラウザに返されることはありません。すでに保存したパスワードを維持する場合は、このフィールドを空欄のままにします。 +4. **User Search Base** — ユーザーエントリを検索する起点となるDN(例: `ou=people,dc=example,dc=com`)。 +5. **User Search Filter** — ユーザーを特定するために使用するフィルタ。送信されたユーザー名に置き換えられるプレースホルダ`%(user)s`を、リテラルとして**必ず**含める必要があります。一般的な値は、OpenLDAPでは`(uid=%(user)s)`、Active Directoryでは`(sAMAccountName=%(user)s)`です。 +6. **User Attribute Mapping** — 下記を参照してください。 +7. **Enable LDAP**をチェックして有効化します。 + +**Validate Config**を使うと、設定を保存せずに確認できます。設定の完全性、サーバーへの到達可否、バインドの成否、検索ベースが解決するかどうか、属性マッピングが使用可能に見えるかどうかを報告します。 + +## User Attribute Mapping + +各行は、1つの**LDAP Attribute**を、それが値を設定すべき**DefectDojo Field**にマッピングします。行を追加するには**Add Attribute Mapping**を、削除するにはゴミ箱アイコンを使用します。 + +![image](images/sso_ldap_attribute_mapping.png) + +- **LDAP Attribute**は自由入力のテキストで、ディレクトリが実際に返す属性と一致している必要があります。たとえばOpenLDAPでは`uid`、`givenName`、`sn`、`mail`、Active Directoryでは`sAMAccountName`、`givenName`、`sn`、`mail`です。 +- **DefectDojo Field**は一覧から選択します: **Username**、**First Name**、**Last Name**、**Email**。 +- ある属性を**Email**にマッピングすることを強く推奨します。DefectDojoは通知にメールアドレスを使用します。 +- 同じ属性を複数のフィールドに使うことができます。各DefectDojoフィールドにマッピングできる属性は1つだけです。 +- マッピングをまったく行わない場合、アカウントは名前やメールアドレスなしで作成されます。 + +**Always Update User**は、マッピングがいつ適用されるかを制御します。有効な場合(デフォルト)、マッピングされた属性はログインのたびにディレクトリから再取得されるため、LDAP側での名前やメールアドレスの変更がDefectDojoに反映されます。無効な場合、アカウントの初回作成時にのみ適用されます。 + +## グループマッピング + +DefectDojoは、ログイン時にユーザーのLDAPグループをDefectDojoグループにミラーリングできます。**Enable Group Mapping**をチェックすると設定が表示されます。 + +![image](images/sso_ldap_group_mapping.png) + +- **Group Search Base** — グループエントリを検索する起点となるDN(例: `ou=groups,dc=example,dc=com`)。グループマッピングが有効な場合は必須です。 +- **Group Type** — ディレクトリがメンバーシップをどのようにモデル化しているか。OpenLDAPとActive Directoryには**groupOfNames**、その他**groupOfUniqueNames**や**posixGroup**から選択します。 +- **Group Limiter Regex Expression** — この式に名前が一致するグループのみがミラーリングされます。すべて許可する場合は`.*`を、DefectDojoに管理させたいグループのみをミラーリングする場合は`^dd-`のようなプレフィックスを使用します。 + +グループがまだ存在しない場合は、初回使用時に作成されます。新しく作成されたグループには、スーパーユーザーが設定するまで権限がありません。[User Groups](../../user_management/create_user_group/)を参照してください。 + +## その他のオプション + +* **Use StartTLS** — バインドの前に、平文の`ldap://`接続をTLSにアップグレードします。URIがすでに`ldaps://`の場合は不要です。 +* **Always Update User** — マッピングされた属性を、ログインのたびにディレクトリから再取得します。 + +## トラブルシューティング + +まず**Validate Config**を実行してください。多くの場合、問題を直接特定できます。それ以外に、以下のようなケースがあります。 + +**すべてのログインが失敗するが、ディレクトリには到達できる。** **User Search Filter**に`%(user)s`が含まれていること、そこで使われている属性がユーザーが実際に入力するものと一致していることを確認してください。`(uid=%(user)s)`というフィルタは、ユーザーがActive Directoryの`sAMAccountName`でログインしている場合には決して一致しません。 + +**ログインは成功するが、アカウントに名前やメールアドレスがない。** **User Attribute Mapping**が空であるか、左側のLDAP属性名がディレクトリの返す値と一致していません。 + +**LDAP側で名前が変わったが、DefectDojoには反映されない。** **Always Update User**が無効になっているため、マッピングはアカウント作成時にのみ適用されています。 + +**ログイン試行がハングする、または遅い。** 接続と検索にはタイムアウトが設定されているため、到達できないディレクトリは無期限にブロックされるのではなく失敗します。**Validate Config**の**Server Reachability**を確認し、DefectDojoホストからポートが開いていることを確認してください。 diff --git a/docs/content/admin/sso/PRO__oidc.de.md b/docs/content/admin/sso/PRO__oidc.de.md new file mode 100644 index 00000000000..1ac545704c2 --- /dev/null +++ b/docs/content/admin/sso/PRO__oidc.de.md @@ -0,0 +1,62 @@ +--- +title: OIDC +description: OpenID Connect (OIDC) SSO in DefectDojo Pro konfigurieren +weight: 17 +audience: pro +--- + +DefectDojo Pro unterstützt die Anmeldung über einen generischen OpenID-Connect-Anbieter (OIDC). Open-Source-DefectDojo enthält kein SSO — siehe [Autorisierte Benutzer](/admin/user_management/os__authorized_users/) für die Open-Source-Zugriffskontrolle. + +## Konfiguration + +Gehen Sie in DefectDojo zu **Enterprise Settings > OIDC Settings**. + +![image](images/oidc_pro.png) + +Füllen Sie das Formular aus: + +1. **Endpoint** — die Basis-URL Ihres OIDC-Anbieters. Fügen Sie `/.well-known/openid-configuration` nicht hinzu. +2. **Client ID** — Ihre OIDC-Client-ID. +3. **Client Secret** — Ihr OIDC-Client-Secret. +4. Konfigurieren Sie optional **Claim Mapping** und **Group Mapping** — siehe unten. +5. Aktivieren Sie **Enable OIDC**. + +Senden Sie das Formular ab. Auf der DefectDojo-Anmeldeseite erscheint dann eine Schaltfläche **Log In With OIDC**. + +Verwenden Sie jederzeit **Validate Config**, um die Einstellungen zu überprüfen, ohne sie zu speichern. Dabei wird das Discovery-Dokument abgerufen, werden die Signaturschlüssel und der Aussteller überprüft, die exakte Redirect-URI angezeigt, die bei Ihrem Anbieter registriert werden muss, und Ihre Claim- und Gruppen-Zuordnungen mit den vom Anbieter angebotenen Claims abgeglichen. + +## Claim Mapping + +Jede Zeile ordnet einen **OIDC Claim** dem **DefectDojo-Feld** zu, das er befüllen soll. Verwenden Sie **Add Claim Mapping**, um weitere Zeilen hinzuzufügen, und das Papierkorb-Symbol, um eine zu entfernen. + +![image](images/sso_oidc_claim_mapping.png) + +Ein Feld ohne Zeile behält seinen Standard-Claim, daher ist dieser Abschnitt nur nötig, wenn Ihr Anbieter Dinge anders benennt. Die Standard-Claims sind: + +| DefectDojo-Feld | Standard-Claim | +| --- | --- | +| Username | `preferred_username` | +| Email | `email` | +| First Name | `given_name` | +| Last Name | `family_name` | + +Hinweise: + +- Eine nicht konfigurierte Instanz startet mit diesen vier bereits ausgefüllten Zeilen, sodass Sie sehen können, was OIDC tut, bevor Sie etwas ändern. +- Derselbe Claim kann mehr als ein Feld befüllen. Jedes DefectDojo-Feld kann nur von einem Claim zugeordnet werden. +- Claims werden sowohl aus dem ID-Token als auch aus der Userinfo-Antwort gelesen, sodass ein Claim, den Ihr Anbieter nur in einem der beiden bereitstellt, trotzdem funktioniert. +- Fehlt ein zugeordneter Claim für einen bestimmten Benutzer oder ist er leer, behält das Feld seinen Standardwert, anstatt geleert zu werden. + +## Group Mapping + +DefectDojo kann die von Ihrem Anbieter gemeldeten Gruppen bei jeder Anmeldung in DefectDojo-Gruppen spiegeln. Aktivieren Sie **Enable Group Mapping**, um die Einstellungen anzuzeigen. + +![image](images/sso_oidc_group_mapping.png) + +- **Group Claim Name** — der Claim, der die Gruppen des Benutzers enthält. **Die meisten Anbieter geben standardmäßig keinen aus** und benötigen einen explizit konfigurierten Mapper; in Keycloak fügen Sie beispielsweise dem Client einen *Group Membership*-Mapper hinzu. Beachten Sie, dass ein *User Realm Role*-Mapper Realm-**Rollen** sendet, keine Gruppen. +- **Group Limiter Regex Expression** — nur Gruppen, die diesem Ausdruck entsprechen, werden gespiegelt. Verwenden Sie `.*`, um alle zuzulassen. +- **Remove Stale Group Memberships** — wenn aktiviert, werden Mitgliedschaften in von OIDC bereitgestellten Gruppen, die der Anbieter nicht mehr meldet, bei der nächsten Anmeldung entfernt. Nur von OIDC erstellte Gruppen sind betroffen; von Hand zugewiesene Gruppen sowie von einem anderen Anbieter wie SAML bereitgestellte Gruppen werden nie angetastet. + +Gruppen werden bei der ersten Verwendung erstellt und genau so benannt, wie sie der Anbieter meldet. Wenn Ihr Anbieter vollständige Gruppenpfade sendet (Keycloaks *Group Membership*-Mapper tut dies, wenn **Full group path** aktiviert ist), wird die DefectDojo-Gruppe `/Group A` genannt statt `Group A`. Deaktivieren Sie diese Option, wenn die Namen mit Gruppen übereinstimmen sollen, die von einem anderen Anbieter kommen, da Sie sonst am Ende zwei DefectDojo-Gruppen für dieselbe logische Gruppe haben. + +Wenn das Group Mapping scheinbar nichts bewirkt, führen Sie **Validate Config** aus: Es zeigt an, ob der von Ihnen benannte Claim einer ist, den der Anbieter anbietet. diff --git a/docs/content/admin/sso/PRO__oidc.es.md b/docs/content/admin/sso/PRO__oidc.es.md new file mode 100644 index 00000000000..17f85209061 --- /dev/null +++ b/docs/content/admin/sso/PRO__oidc.es.md @@ -0,0 +1,63 @@ +--- +title: OIDC +description: Configura el inicio de sesión único (SSO) mediante OpenID Connect (OIDC) + en DefectDojo Pro +weight: 17 +audience: pro +--- + +DefectDojo Pro admite el inicio de sesión mediante un proveedor genérico de OpenID Connect (OIDC). DefectDojo de código abierto no incluye SSO — consulte [Usuarios autorizados](/admin/user_management/os__authorized_users/) para conocer el control de acceso en código abierto. + +## Configuración + +En DefectDojo, vaya a **Enterprise Settings > OIDC Settings**. + +![image](images/oidc_pro.png) + +Complete el formulario: + +1. **Endpoint** — la URL base de su proveedor de OIDC. No incluya `/.well-known/openid-configuration`. +2. **Client ID** — el ID de cliente de su OIDC. +3. **Client Secret** — el secreto de cliente de su OIDC. +4. Opcionalmente, configure **Claim Mapping** y **Group Mapping** — consulte a continuación. +5. Marque **Enable OIDC**. + +Envíe el formulario. Aparecerá un botón **Log In With OIDC** en la página de inicio de sesión de DefectDojo. + +Use **Validate Config** en cualquier momento para comprobar la configuración sin guardarla. Obtiene el documento de descubrimiento, verifica las claves de firma y el emisor, muestra el URI de redirección exacto que debe registrarse en su proveedor, y contrasta sus asignaciones de notificaciones y de grupos con las notificaciones que anuncia el proveedor. + +## Asignación de notificaciones + +Cada fila asigna una **OIDC Claim** al **DefectDojo Field** que debe completar. Use **Add Claim Mapping** para agregar más filas y el icono de papelera para eliminar una. + +![image](images/sso_oidc_claim_mapping.png) + +Un campo sin fila conserva su notificación estándar, por lo que esta sección solo es necesaria cuando su proveedor nombra las cosas de forma diferente. Las notificaciones estándar son: + +| DefectDojo Field | Standard claim | +| --- | --- | +| Nombre de usuario | `preferred_username` | +| Correo electrónico | `email` | +| Nombre | `given_name` | +| Apellido | `family_name` | + +Notas: + +- Una instancia sin configurar se abre con esas cuatro filas ya completadas, para que pueda ver qué hace OIDC antes de cambiar nada. +- La misma notificación puede alimentar más de un campo. Cada campo de DefectDojo solo puede asignarse desde una notificación. +- Las notificaciones se leen tanto del token de ID como de la respuesta de userinfo, por lo que una notificación que su proveedor solo entrega en una de las dos sigue funcionando. +- Si a una notificación asignada le falta valor o está vacía para un usuario determinado, ese campo conserva su valor estándar en lugar de quedar en blanco. + +## Asignación de grupos + +DefectDojo puede reflejar los grupos que reporta su proveedor en grupos de DefectDojo en cada inicio de sesión. Marque **Enable Group Mapping** para mostrar la configuración. + +![image](images/sso_oidc_group_mapping.png) + +- **Group Claim Name** — la notificación que contiene los grupos del usuario. **La mayoría de los proveedores no emiten una por defecto** y necesitan un mapper configurado explícitamente; en Keycloak, por ejemplo, agregue un mapper de *Group Membership* al cliente. Tenga en cuenta que un mapper de *User Realm Role* envía **roles** del realm, no grupos. +- **Group Limiter Regex Expression** — solo se reflejan los grupos que coinciden con esta expresión. Use `.*` para permitir todos. +- **Remove Stale Group Memberships** — cuando está habilitado, las membresías en grupos aprovisionados por OIDC que el proveedor ya no reporta se eliminan en el siguiente inicio de sesión. Solo se ven afectados los grupos creados por OIDC; los grupos que usted asignó manualmente, y los grupos aprovisionados por otro proveedor como SAML, nunca se modifican. + +Los grupos se crean en el primer uso y se nombran exactamente como los reporta el proveedor. Si su proveedor envía rutas de grupo completas (el mapper *Group Membership* de Keycloak hace esto cuando **Full group path** está habilitado), el grupo de DefectDojo se llama `/Group A` en lugar de `Group A`. Desactive esa opción si desea que los nombres coincidan con los grupos que llegan de otro proveedor; de lo contrario, terminará con dos grupos de DefectDojo para el mismo grupo lógico. + +Si la asignación de grupos parece no hacer nada, ejecute **Validate Config**: indica si la notificación que usted indicó es una de las que anuncia el proveedor. diff --git a/docs/content/admin/sso/PRO__oidc.fr.md b/docs/content/admin/sso/PRO__oidc.fr.md new file mode 100644 index 00000000000..0aedea967c2 --- /dev/null +++ b/docs/content/admin/sso/PRO__oidc.fr.md @@ -0,0 +1,63 @@ +--- +title: OIDC +description: Configurez l'authentification unique (SSO) OpenID Connect (OIDC) dans + DefectDojo Pro +weight: 17 +audience: pro +--- + +DefectDojo Pro prend en charge la connexion via un fournisseur OpenID Connect (OIDC) générique. La version open source de DefectDojo n'inclut pas l'authentification unique (SSO) — consultez [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +## Configuration + +Dans DefectDojo, accédez à **Enterprise Settings > OIDC Settings**. + +![image](images/oidc_pro.png) + +Remplissez le formulaire : + +1. **Endpoint** — l'URL de base de votre fournisseur OIDC. N'incluez pas `/.well-known/openid-configuration`. +2. **Client ID** — l'ID client de votre fournisseur OIDC. +3. **Client Secret** — le secret client de votre fournisseur OIDC. +4. Configurez éventuellement **Claim Mapping** et **Group Mapping** — voir ci-dessous. +5. Cochez **Enable OIDC**. + +Envoyez le formulaire. Un bouton **Log In With OIDC** apparaîtra sur la page de connexion de DefectDojo. + +Utilisez **Validate Config** à tout moment pour vérifier les paramètres sans les enregistrer. Cette fonction récupère le document de découverte, vérifie les clés de signature et l'émetteur, affiche l'URI de redirection exacte à enregistrer chez votre fournisseur, et vérifie vos mappages de revendications et de groupes par rapport aux revendications annoncées par le fournisseur. + +## Claim Mapping + +Chaque ligne associe une **OIDC Claim** au **DefectDojo Field** qu'elle doit renseigner. Utilisez **Add Claim Mapping** pour ajouter des lignes supplémentaires et l'icône de corbeille pour en supprimer une. + +![image](images/sso_oidc_claim_mapping.png) + +Un champ sans ligne associée conserve sa revendication standard ; cette section n'est donc nécessaire que si votre fournisseur nomme les choses différemment. Les revendications standard sont les suivantes : + +| DefectDojo Field | Revendication standard | +| --- | --- | +| Username | `preferred_username` | +| Email | `email` | +| First Name | `given_name` | +| Last Name | `family_name` | + +Notes : + +- Une instance non configurée s'ouvre avec ces quatre lignes déjà renseignées, afin que vous puissiez voir ce que fait OIDC avant de modifier quoi que ce soit. +- Une même revendication peut alimenter plusieurs champs. Chaque champ DefectDojo ne peut être associé qu'à une seule revendication. +- Les revendications sont lues à la fois dans le jeton d'ID et dans la réponse userinfo ; une revendication que votre fournisseur ne renvoie que dans l'un des deux fonctionne donc quand même. +- Si une revendication associée est absente ou vide pour un utilisateur donné, le champ conserve sa valeur standard au lieu d'être vidé. + +## Group Mapping + +DefectDojo peut reproduire les groupes signalés par votre fournisseur sous forme de groupes DefectDojo à chaque connexion. Cochez **Enable Group Mapping** pour afficher les paramètres. + +![image](images/sso_oidc_group_mapping.png) + +- **Group Claim Name** — la revendication contenant les groupes de l'utilisateur. **La plupart des fournisseurs n'en émettent pas par défaut** et nécessitent la configuration explicite d'un mapper ; dans Keycloak, par exemple, ajoutez un mapper *Group Membership* au client. Notez qu'un mapper *User Realm Role* envoie des **rôles** de realm, et non des groupes. +- **Group Limiter Regex Expression** — seuls les groupes correspondant à cette expression sont reproduits. Utilisez `.*` pour tous les autoriser. +- **Remove Stale Group Memberships** — lorsque cette option est activée, les appartenances aux groupes provisionnés par OIDC que le fournisseur ne signale plus sont supprimées à la connexion suivante. Seuls les groupes créés par OIDC sont concernés ; les groupes que vous avez attribués manuellement, ainsi que les groupes provisionnés par un autre fournisseur tel que SAML, ne sont jamais modifiés. + +Les groupes sont créés lors de leur première utilisation et nommés exactement comme le fournisseur les signale. Si votre fournisseur envoie des chemins de groupe complets (c'est le cas du mapper *Group Membership* de Keycloak lorsque **Full group path** est activé), le groupe DefectDojo est nommé `/Group A` plutôt que `Group A`. Désactivez cette option si vous voulez que les noms correspondent aux groupes provenant d'un autre fournisseur, sinon vous vous retrouverez avec deux groupes DefectDojo pour un même groupe logique. + +Si le mappage des groupes semble ne rien faire, exécutez **Validate Config** : il indique si la revendication que vous avez indiquée fait partie de celles annoncées par le fournisseur. diff --git a/docs/content/admin/sso/PRO__oidc.ja.md b/docs/content/admin/sso/PRO__oidc.ja.md new file mode 100644 index 00000000000..808a3c8516b --- /dev/null +++ b/docs/content/admin/sso/PRO__oidc.ja.md @@ -0,0 +1,62 @@ +--- +title: OIDC +description: DefectDojo Pro で OpenID Connect (OIDC) SSO を設定する +weight: 17 +audience: pro +--- + +DefectDojo Pro は、汎用の OpenID Connect (OIDC) プロバイダーを介したログインをサポートしています。オープンソース版の DefectDojo には SSO は含まれていません。オープンソース版のアクセス制御については [Authorized Users](/admin/user_management/os__authorized_users/) を参照してください。 + +## Configuration + +DefectDojo で **Enterprise Settings > OIDC Settings** に移動します。 + +![image](images/oidc_pro.png) + +フォームに入力します。 + +1. **Endpoint** — OIDC プロバイダーのベース URL です。`/.well-known/openid-configuration` は含めないでください。 +2. **Client ID** — OIDC クライアント ID です。 +3. **Client Secret** — OIDC クライアントシークレットです。 +4. 必要に応じて **Claim Mapping** と **Group Mapping** を設定します。詳細は後述します。 +5. **Enable OIDC** をチェックします。 + +フォームを送信します。DefectDojo のログインページに **Log In With OIDC** ボタンが表示されます。 + +いつでも **Validate Config** を使用して、設定を保存せずに確認できます。これはディスカバリードキュメントを取得し、署名鍵と発行者を検証し、プロバイダー側に登録すべき正確なリダイレクト URI を表示し、クレームおよびグループのマッピングをプロバイダーが公開しているクレームと突き合わせます。 + +## Claim Mapping + +各行は、1 つの **OIDC Claim** を、それが値を設定する **DefectDojo Field** にマッピングします。行を追加するには **Add Claim Mapping** を使用し、削除するにはゴミ箱アイコンを使用します。 + +![image](images/sso_oidc_claim_mapping.png) + +行が設定されていないフィールドは標準のクレームを使用するため、このセクションはプロバイダーが異なる名前を使用している場合にのみ必要です。標準のクレームは次のとおりです。 + +| DefectDojo Field | Standard claim | +| --- | --- | +| Username | `preferred_username` | +| Email | `email` | +| First Name | `given_name` | +| Last Name | `family_name` | + +メモ: + +- 未設定のインスタンスでは、これら 4 つの行があらかじめ入力された状態で開くため、変更を加える前に OIDC がどのように動作するかを確認できます。 +- 同じクレームを複数のフィールドに使用できます。ただし、各 DefectDojo フィールドにマッピングできるクレームは 1 つだけです。 +- クレームは ID トークンと userinfo レスポンスの両方から読み取られるため、プロバイダーがどちらか一方でしか公開していないクレームでも機能します。 +- マッピングされたクレームが特定のユーザーで欠落または空の場合、そのフィールドは空にされるのではなく標準の値を保持します。 + +## Group Mapping + +DefectDojo は、ログインのたびにプロバイダーが報告するグループを DefectDojo のグループにミラーリングできます。設定を表示するには **Enable Group Mapping** をチェックします。 + +![image](images/sso_oidc_group_mapping.png) + +- **Group Claim Name** — ユーザーのグループを含むクレームです。**多くのプロバイダーはデフォルトではこれを発行しない**ため、明示的にマッパーを設定する必要があります。たとえば Keycloak では、クライアントに *Group Membership* マッパーを追加します。なお、*User Realm Role* マッパーはグループではなくレルムの**ロール**を送信する点に注意してください。 +- **Group Limiter Regex Expression** — この式に一致するグループのみがミラーリングされます。すべてを許可するには `.*` を使用します。 +- **Remove Stale Group Memberships** — 有効にすると、プロバイダーが報告しなくなった OIDC プロビジョニングのグループのメンバーシップは、次回のログイン時に削除されます。影響を受けるのは OIDC によって作成されたグループのみです。手動で割り当てたグループや、SAML など別のプロバイダーによってプロビジョニングされたグループが変更されることはありません。 + +グループは初回使用時に作成され、プロバイダーが報告する名前がそのまま使用されます。プロバイダーが完全なグループパスを送信する場合(Keycloak の *Group Membership* マッパーで **Full group path** を有効にするとこうなります)、DefectDojo のグループ名は `Group A` ではなく `/Group A` になります。別のプロバイダーから届くグループと名前を一致させたい場合は、このオプションをオフにしてください。そうしないと、同じ論理グループに対して 2 つの DefectDojo グループができてしまいます。 + +グループマッピングが何も行っていないように見える場合は、**Validate Config** を実行してください。指定したクレームがプロバイダーによって公開されているかどうかが報告されます。 diff --git a/docs/content/admin/sso/PRO__okta.de.md b/docs/content/admin/sso/PRO__okta.de.md new file mode 100644 index 00000000000..42505bac770 --- /dev/null +++ b/docs/content/admin/sso/PRO__okta.de.md @@ -0,0 +1,46 @@ +--- +title: Okta +description: Okta SSO in DefectDojo Pro konfigurieren +weight: 15 +audience: pro +--- + +DefectDojo Pro unterstützt die Anmeldung über Okta. Open-Source-DefectDojo enthält kein SSO — siehe [Autorisierte Benutzer](/admin/user_management/os__authorized_users/) für die Open-Source-Zugriffskontrolle. + +## Voraussetzungen + +Führen Sie die folgenden Schritte in Okta aus, bevor Sie DefectDojo konfigurieren: + +1. Melden Sie sich bei [Okta](https://www.okta.com/developer/signup/) an oder erstellen Sie ein Konto. + +2. Gehen Sie zu **Applications** und klicken Sie auf **Add Application**. + + ![image](images/okta_1.png) + +3. Wählen Sie **Web Applications**. + + ![image](images/okta_2.png) + +4. Fügen Sie unter **Login Redirect URLs** Ihre DefectDojo-Callback-URL hinzu. Aktivieren Sie außerdem das Kontrollkästchen **Implicit**. + + ![image](images/okta_3.png) + +5. Klicken Sie auf **Done**. + +6. Notieren Sie sich im **Dashboard** die **Org-URL**. + + ![image](images/okta_4.png) + +7. Öffnen Sie die neu erstellte Anwendung und notieren Sie sich **Client ID** und **Client Secret**. + + ![image](images/okta_5.png) + +## Konfiguration + +Gehen Sie in DefectDojo zu **Enterprise Settings > OAuth Settings**, wählen Sie **Okta** und füllen Sie das Formular aus: + +- **Okta OAuth Key** — geben Sie Ihre **Client ID** ein +- **Okta OAuth Secret** — geben Sie Ihr **Client Secret** ein +- **Okta Tenant ID** — geben Sie Ihre Org-URL im Format `https://your-org-url/oauth2` ein + +Aktivieren Sie **Enable Okta OAuth** und senden Sie das Formular ab. Auf der Anmeldeseite erscheint dann eine Schaltfläche **Login With Okta**. diff --git a/docs/content/admin/sso/PRO__okta.es.md b/docs/content/admin/sso/PRO__okta.es.md new file mode 100644 index 00000000000..5138365bf72 --- /dev/null +++ b/docs/content/admin/sso/PRO__okta.es.md @@ -0,0 +1,46 @@ +--- +title: Okta +description: Configura el SSO de Okta en DefectDojo Pro +weight: 15 +audience: pro +--- + +DefectDojo Pro admite el inicio de sesión mediante Okta. DefectDojo de código abierto no incluye SSO — consulte [Usuarios autorizados](/admin/user_management/os__authorized_users/) para conocer el control de acceso en código abierto. + +## Requisitos previos + +Complete los siguientes pasos en Okta antes de configurar DefectDojo: + +1. Inicie sesión o cree una cuenta en [Okta](https://www.okta.com/developer/signup/). + +2. Vaya a **Applications** y haga clic en **Add Application**. + + ![image](images/okta_1.png) + +3. Seleccione **Web Applications**. + + ![image](images/okta_2.png) + +4. En **Login Redirect URLs**, agregue la URL de retorno (callback) de su DefectDojo. Marque también la casilla **Implicit**. + + ![image](images/okta_3.png) + +5. Haga clic en **Done**. + +6. En el **Dashboard**, anote la **Org-URL**. + + ![image](images/okta_4.png) + +7. Abra la aplicación recién creada y anote el **Client ID** y el **Client Secret**. + + ![image](images/okta_5.png) + +## Configuración + +En DefectDojo, vaya a **Enterprise Settings > OAuth Settings**, seleccione **Okta** y complete el formulario: + +- **Okta OAuth Key** — ingrese su **Client ID** +- **Okta OAuth Secret** — ingrese su **Client Secret** +- **Okta Tenant ID** — ingrese su Org-URL con el formato `https://your-org-url/oauth2` + +Marque **Enable Okta OAuth** y envíe el formulario. Aparecerá un botón **Login With Okta** en la página de inicio de sesión. diff --git a/docs/content/admin/sso/PRO__okta.fr.md b/docs/content/admin/sso/PRO__okta.fr.md new file mode 100644 index 00000000000..3f5355f3ae1 --- /dev/null +++ b/docs/content/admin/sso/PRO__okta.fr.md @@ -0,0 +1,46 @@ +--- +title: Okta +description: Configurez l'authentification unique (SSO) Okta dans DefectDojo Pro +weight: 15 +audience: pro +--- + +DefectDojo Pro prend en charge la connexion via Okta. La version open source de DefectDojo n'inclut pas l'authentification unique (SSO) — consultez [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +## Prérequis + +Effectuez les étapes suivantes dans Okta avant de configurer DefectDojo : + +1. Connectez-vous ou créez un compte sur [Okta](https://www.okta.com/developer/signup/). + +2. Accédez à **Applications** et cliquez sur **Add Application**. + + ![image](images/okta_1.png) + +3. Sélectionnez **Web Applications**. + + ![image](images/okta_2.png) + +4. Sous **Login Redirect URLs**, ajoutez l'URL de rappel (callback) de votre instance DefectDojo. Cochez également la case **Implicit**. + + ![image](images/okta_3.png) + +5. Cliquez sur **Done**. + +6. Depuis le **Dashboard**, notez l'**Org-URL**. + + ![image](images/okta_4.png) + +7. Ouvrez l'application nouvellement créée et notez le **Client ID** et le **Client Secret**. + + ![image](images/okta_5.png) + +## Configuration + +Dans DefectDojo, accédez à **Enterprise Settings > OAuth Settings**, sélectionnez **Okta**, puis remplissez le formulaire : + +- **Okta OAuth Key** — saisissez votre **Client ID** +- **Okta OAuth Secret** — saisissez votre **Client Secret** +- **Okta Tenant ID** — saisissez votre Org-URL au format `https://your-org-url/oauth2` + +Cochez **Enable Okta OAuth** et envoyez le formulaire. Un bouton **Login With Okta** apparaîtra sur la page de connexion. diff --git a/docs/content/admin/sso/PRO__okta.ja.md b/docs/content/admin/sso/PRO__okta.ja.md new file mode 100644 index 00000000000..ac0a84dc3c5 --- /dev/null +++ b/docs/content/admin/sso/PRO__okta.ja.md @@ -0,0 +1,46 @@ +--- +title: Okta +description: DefectDojo Pro で Okta SSO を設定する +weight: 15 +audience: pro +--- + +DefectDojo Pro は Okta 経由のログインをサポートしています。オープンソース版の DefectDojo には SSO は含まれていません。オープンソース版のアクセス制御については [Authorized Users](/admin/user_management/os__authorized_users/) を参照してください。 + +## Prerequisites + +DefectDojo を設定する前に、Okta 側で以下の手順を完了してください。 + +1. [Okta](https://www.okta.com/developer/signup/) にサインインするか、アカウントを作成します。 + +2. **Applications** に移動し、**Add Application** をクリックします。 + + ![image](images/okta_1.png) + +3. **Web Applications** を選択します。 + + ![image](images/okta_2.png) + +4. **Login Redirect URLs** に DefectDojo のコールバック URL を追加します。また、**Implicit** のチェックボックスをオンにします。 + + ![image](images/okta_3.png) + +5. **Done** をクリックします。 + +6. **Dashboard** で **Org-URL** を確認します。 + + ![image](images/okta_4.png) + +7. 新しく作成されたアプリケーションを開き、**Client ID** と **Client Secret** を確認します。 + + ![image](images/okta_5.png) + +## Configuration + +DefectDojo で **Enterprise Settings > OAuth Settings** に移動し、**Okta** を選択して、フォームに入力します。 + +- **Okta OAuth Key** — **Client ID** を入力します +- **Okta OAuth Secret** — **Client Secret** を入力します +- **Okta Tenant ID** — `https://your-org-url/oauth2` の形式で Org-URL を入力します + +**Enable Okta OAuth** をチェックしてフォームを送信します。ログインページに **Login With Okta** ボタンが表示されます。 diff --git a/docs/content/admin/sso/PRO__saml.de.md b/docs/content/admin/sso/PRO__saml.de.md new file mode 100644 index 00000000000..b63cf9c68a5 --- /dev/null +++ b/docs/content/admin/sso/PRO__saml.de.md @@ -0,0 +1,155 @@ +--- +title: SAML-Konfiguration +description: SAML in DefectDojo Pro konfigurieren +weight: 1 +audience: pro +--- + +DefectDojo Pro unterstützt die SAML-Authentifizierung über die Benutzeroberfläche **Enterprise Settings**. Open-Source-DefectDojo enthält kein SSO – siehe [Autorisierte Benutzer](/admin/user_management/os__authorized_users/) für die Zugriffskontrolle in Open-Source-DefectDojo. + +## ACS-URL (Assertion Consumer Service) + +Ihr Identity Provider muss wissen, wohin er die SAML-Antwort nach der Authentifizierung eines Benutzers per POST senden soll. Die ACS-URL von DefectDojo lautet: + +``` +https://.cloud.defectdojo.com/saml2/acs/ +``` + +Ein paar Dinge, die Sie zu diesem Endpunkt wissen sollten: + +- **Der Endpunkt akzeptiert nur `POST`-Anfragen.** Wenn Sie die ACS-URL direkt im Browser öffnen, wird ein GET ausgelöst und es wird **HTTP 405 Method Not Allowed** zurückgegeben. Das ist erwartetes Verhalten – es bedeutet nicht, dass SAML fehlerhaft oder falsch konfiguriert ist. Der Endpunkt ist dafür vorgesehen, von Ihrem IdP im Rahmen des SAML-Redirect-Ablaufs aufgerufen zu werden, nicht durch Eingabe der URL in einem Browser. +- **Die ACS-URL ist auf Ihrer DefectDojo-Cloud-Instanz jederzeit verfügbar** – Sie müssen SAML in DefectDojo nicht zuerst aktivieren, bevor Sie Ihren IdP darauf verweisen. Sie können die IdP-Seite und die DefectDojo-Seite in beliebiger Reihenfolge konfigurieren. + +## Einrichtung + +1. Öffnen Sie **Enterprise Settings > SAML Settings**. + + ![image](images/sso_betaui_1.png) + +2. Legen Sie eine **Entity ID** fest – eine Bezeichnung oder URL, mit der Ihr SAML Identity Provider DefectDojo identifiziert. Dieses Feld ist erforderlich. + +3. Legen Sie optional den **Login Button Text** fest – den Text, der auf der Schaltfläche angezeigt wird, über die Benutzer die SAML-Anmeldung starten. + +4. Legen Sie optional eine **Logout URL** fest, zu der Benutzer nach dem Abmelden von DefectDojo weitergeleitet werden. + +5. Wählen Sie ein **Name ID Format**: + - **Persistent** – Benutzer werden über SAML sitzungsübergreifend konsistent identifiziert. + - **Transient** – Benutzer erhalten bei jeder Anmeldung eine andere SAML-ID. + - **Entity** – alle Benutzer teilen sich eine einzige SAML-NameID. + - **Encrypted** – die NameID jedes Benutzers wird verschlüsselt. + +6. **Required Attributes** – legen Sie fest, welche Attribute DefectDojo aus der SAML-Antwort benötigt. + +7. **Attribute Mapping** – ordnen Sie die von Ihrem IdP gesendeten Attribute den DefectDojo-Benutzerfeldern zu, die sie befüllen sollen. Jede Zeile verknüpft ein **SAML Attribute** mit einem **DefectDojo Field**; verwenden Sie **Add Attribute Mapping** für weitere Zeilen und das Papierkorb-Symbol, um eine Zeile zu entfernen. + + ![image](images/sso_saml_attribute_mapping.png) + + - **SAML Attribute** ist Freitext und muss genau dem Attributnamen entsprechen, den Ihr IdP tatsächlich sendet. Manche IdPs (z. B. Entra ID / Azure AD) senden vollqualifizierte Claim-URIs wie `http://schemas.microsoft.com/identity/claims/emailaddress` anstelle von benutzerfreundlichen Namen. Wenn Sie nicht sicher sind, was Ihr IdP sendet, aktivieren Sie **Enable SAML Debugging** (siehe [Troubleshooting](#troubleshooting)) und prüfen Sie die Assertion in den Logs. + - **DefectDojo Field** wird aus einer Liste ausgewählt: **Username**, **First Name**, **Last Name** und **Email**. + - Ordnen Sie mindestens das Attribut zu, das **Username** entspricht. DefectDojo sucht Benutzer anhand des Benutzernamens, wenn SAML-Anmeldungen bestehenden Konten zugeordnet werden. + - Es wird dringend empfohlen, ein Attribut auf **Email** zu mappen: DefectDojo verwendet die E-Mail-Adresse für Benachrichtigungen und um eine eingehende Anmeldung anhand der E-Mail-Adresse einem bestehenden Konto zuzuordnen. + - Dasselbe Attribut kann mehrere Felder speisen – zum Beispiel ein E-Mail-Claim, der sowohl für **Email** als auch für **Username** verwendet wird. Umgekehrt ist das nicht zulässig: Jedes DefectDojo-Feld darf nur von einem Attribut zugeordnet werden. + - Eine Zeile, bei der nur eine Hälfte ausgefüllt ist, wird beim Speichern abgelehnt, und die betroffene Zelle wird hervorgehoben. Zeilen, die Sie hinzufügen, aber nie ausfüllen, werden verworfen und nicht als Fehler behandelt. + +8. **Remote SAML Metadata** – die URL, unter der die Metadaten Ihres SAML Identity Providers gehostet werden. + +9. Aktivieren Sie **Enable SAML** am unteren Rand des Formulars, um die SAML-Anmeldung zu aktivieren. Auf der DefectDojo-Anmeldeseite erscheint dann eine Schaltfläche **Login With SAML**. + + ![image](images/sso_saml_login.png). + +## Weitere Optionen + +* **Create Unknown User** – erstellt automatisch einen neuen DefectDojo-Benutzer, wenn dieser in der SAML-Antwort nicht gefunden wird. +* **Allow Unknown Attributes** – erlaubt die Anmeldung für Benutzer, deren Attribute nicht im Attribute Mapping aufgeführt sind. +* **Sign Assertions/Responses** – verlangt, dass alle eingehenden SAML-Antworten signiert sind. +* **Sign Logout Requests** – signiert alle von DefectDojo gesendeten Logout-Anfragen. +* **Force Authentication** – verlangt, dass sich Benutzer bei jeder Anmeldung erneut beim Identity Provider authentifizieren, unabhängig von bestehenden Sitzungen. +* **Enable SAML Debugging** – protokolliert detaillierte SAML-Ausgaben zur Fehlerbehebung. Siehe [Troubleshooting → SAML Debugging output](#saml-debugging-output), wo diese Log-Ausgabe erscheint. + +## SAML-Gruppenzuordnung + +DefectDojo kann die SAML-Assertion nutzen, um Benutzer automatisch [Benutzergruppen](../../user_management/create_user_group/) zuzuweisen. Gruppen in DefectDojo weisen allen ihren Mitgliedern Berechtigungen zu, sodass Sie mit Group Mapping Berechtigungen im großen Stil verwalten können. Dies ist der einzige Weg, Berechtigungen über SAML festzulegen. + +**Group Mapping ist optional.** Obwohl die Felder **Group Name Attribute** und **Group Limiter Regex Expression** in der Benutzeroberfläche mit einem Pflichtfeld-Sternchen (`*`) versehen sind, kann das SAML-Formular auch ohne sie abgeschickt werden, und die SAML-Anmeldung funktioniert auch ohne Group Mapping. Sie müssen in Ihrem IdP (z. B. Azure-AD-Anwendungsrollen) keine Gruppen oder Rollen vorab anlegen, bevor Sie SAML aktivieren – Sie müssen diese Felder nur konfigurieren, wenn DefectDojo die Gruppenmitgliedschaft tatsächlich aus der Assertion auslesen soll. Wenn Sie kein Group Mapping konfigurieren, haben neu erstellte SSO-Benutzer standardmäßig keine Berechtigungen; siehe [Standardzugriff für per SSO bereitgestellte Benutzer](#default-access-for-sso-provisioned-users) weiter unten. + +Das Feld **Group Name Attribute** legt fest, welches Attribut in der SAML-Assertion die Gruppenmitgliedschaften des Benutzers enthält. Wenn sich ein Benutzer anmeldet, liest DefectDojo dieses Attribut aus und weist den Benutzer allen passenden Gruppen zu. Um einzuschränken, welche Gruppen aus der Assertion berücksichtigt werden, verwenden Sie das Feld **Group Limiter Regex Expression** – ein regulärer Ausdruck, der auf die Gruppennamen aus der Assertion angewendet wird, um zu filtern, welche davon DefectDojo berücksichtigen soll. + +Der Wert muss exakt dem Attributnamen entsprechen, den Ihr Identity Provider in der Assertion sendet, einschließlich eines eventuellen Namespace-Präfixes. Ein kurzer, benutzerfreundlicher Name wie `groups` funktioniert nur, wenn Ihr IdP so konfiguriert ist, dass er genau diesen Attributnamen sendet – viele IdPs verwenden stattdessen eine vollqualifizierte Claim-URI. + +### Group Name Attribute je Identity Provider + +| Identity Provider | Zu verwendender Standard-Attributname | +|---|---| +| **Entra ID / Azure AD** | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | +| **Okta** | `groups` (der Attributname, den Sie im Group Attribute Statement der SAML-App konfiguriert haben) | +| **Keycloak** | `groups` (oder der Wert, den Sie als „SAML Attribute Name" im Group-List-Mapper festgelegt haben) | +| **PingFederate / generisch** | Der Wert, den Sie auf der IdP-Seite konfiguriert haben – prüfen Sie die Assertion Ihres IdP, bevor Sie `groups` annehmen | + +Wenn Group Mapping scheinbar nichts bewirkt – Benutzer melden sich erfolgreich an, aber es werden keine Gruppen erstellt oder zugewiesen – siehe [Troubleshooting → SAML group mapping does nothing](#saml-group-mapping-does-nothing--users-log-in-but-no-groups-are-assigned) weiter unten. + +Wenn keine Gruppe mit passendem Namen existiert, erstellt DefectDojo automatisch eine und weist ihren Mitgliedern die Rolle **Reader** zu. Beachten Sie, dass diese Reader-Rolle den Zugriff des Mitglieds *auf die Gruppe selbst* regelt – sie gewährt keinen Zugriff auf zugrunde liegende Produkte, Produkttypen oder andere organisatorische Objekte. Diese Berechtigungen werden separat konfiguriert, und eine neu automatisch erstellte Gruppe hat zunächst keine davon, bis ein Superuser der Gruppe eine Rolle für die betreffenden Produkte oder Produkttypen zuweist. + +Um Group Mapping zu aktivieren, aktivieren Sie das Kontrollkästchen **Enable Group Mapping** am unteren Rand des Formulars. + +## Standardzugriff für per SSO bereitgestellte Benutzer + +Wenn ein neuer Benutzer über SAML (oder einen anderen Social-Auth-Provider) erstellt und über kein SAML Group Mapping einer Gruppe hinzugefügt wird, landet er auf einer DefectDojo-Instanz **ohne Berechtigungen**. Er sieht nach der Anmeldung keine Produkttypen, keine Produkte und keine Engagements – das Dashboard erscheint leer. + +Um jedem neu bereitgestellten SSO-Benutzer eine sinnvolle Ausgangsbasis zu geben, konfigurieren Sie auf der Seite System Settings eine **Default group** + **Default group role**: + +1. Öffnen Sie **⚙️ Configuration → System Settings** (nur Superuser). +2. Setzen Sie **Default group** auf die [Benutzergruppe](../../user_management/create_user_group/), der neu erstellte Benutzer beitreten sollen. +3. Setzen Sie **Default group role** auf die Rolle, die sie in dieser Gruppe innehaben sollen (z. B. **Reader**). +4. Legen Sie optional **Default group email pattern** als regulären Ausdruck fest (z. B. `.*@yourcompany\.com$`), damit die Standardgruppe nur auf Benutzer angewendet wird, deren E-Mail-Adresse übereinstimmt. +5. Speichern. + +Sowohl **Default group** als auch **Default group role** müssen gesetzt sein – ist eines der beiden leer, wird die Standardgruppe nicht angewendet. + +Diese Einstellung gilt für **jeden neu erstellten Benutzer**, einschließlich Benutzern, die über SAML, OAuth und andere Social-Auth-Provider erstellt wurden, da sie auf Djangos User-Creation-Signal basiert und nicht innerhalb eines bestimmten Authentifizierungs-Backends läuft. + +> **Bestehende Benutzer sind nicht betroffen.** Die Standardgruppe wird nur bei der erstmaligen Erstellung eines Benutzers angewendet. Bestehende DefectDojo-Benutzer behalten ihre aktuellen Gruppenmitgliedschaften, auch wenn Sie diese Einstellung später ändern. + +## Unterschiede zwischen Cloud und On-Premise + +DefectDojo Cloud bietet nicht denselben Grad an SAML-Anpassung wie DefectDojo On-Prem. Die einzigen Variablen, die gesetzt werden können, laufen über die Benutzeroberfläche. Hier sind einige der wichtigsten Unterschiede: + +| Funktion | Cloud | On-Premise | +|---|---|---| +| **Username-Abgleich** | Nur NameID | Nur NameID (die Umgebungsvariable `SAML_USE_NAME_ID_AS_USERNAME` gilt nur für Open Source, nicht für Pro) | +| **Verschlüsselung der SAML-Assertion** | Derzeit nicht unterstützt | Derzeit nicht unterstützt | +| **SAML-Anmeldeprotokolle** | In der Benutzeroberfläche nicht verfügbar. Wenden Sie sich an den Support, um Protokolle anzufordern. | Verfügbar über die Anwendungs-Container-Logs (`docker logs dojo`) | +| **Konfigurationsmethode** | Nur Enterprise-Settings-UI | Enterprise-Settings-UI, Django Admin oder Django Shell | +| **Umgebungsvariablen** | Können von Kunden nicht direkt gesetzt werden. Wenden Sie sich für Änderungen an den Support. | Können über `dojo-compose-cli environment add` gesetzt werden | + +Wenn Sie Benutzer anhand eines anderen Attributs als NameID abgleichen müssen (z. B. `uid` oder `email`), konfigurieren Sie Ihren Identity Provider so, dass er den gewünschten Wert als NameID sendet, anstatt die DefectDojo-Einstellungen anzupassen. + +## Fehlerbehebung + +### SAML-Debug-Ausgabe + +Wenn **Enable SAML Debugging** (unter [Weitere Optionen](#additional-options)) aktiviert ist, schreibt DefectDojo detaillierte Ausgaben zur SAML-Verarbeitung – einschließlich der vom IdP empfangenen Rohattribute – auf der Stufe `DEBUG` unter dem Logger `saml2` in die Anwendungsprotokolle. + +| Betriebsumgebung | Wo die Debug-Ausgabe zu finden ist | +|---|---| +| **DefectDojo Cloud** | Das SAML-Debug-Log ist in der Benutzeroberfläche nicht sichtbar. Wenden Sie sich an den DefectDojo-Support, um die Logs für einen bestimmten Zeitraum anzufordern. | +| **On-Premise (einzelner Container)** | `docker logs dojo` (oder Ihre Helm-/K8s-Log-Aggregation) | +| **On-Premise (Helm/K8s)** | `kubectl logs deployment/defectdojo-django -c uwsgi` (oder der Log-Aggregator Ihres Clusters) | + +Schalten Sie diese Option nach Abschluss der Fehlerbehebung wieder **aus** – SAML-Debug-Logs sind ausführlich und können sensible Attributwerte Ihres IdP enthalten. + +### Benutzer erhalten nach erfolgreicher IdP-Anmeldung die Fehlermeldung „User not found" oder „Permission denied" + +Wenn die SAML-Assertion erfolgreich verarbeitet wird (keine XML- oder Signaturfehler), DefectDojo die Anmeldung aber verweigert, liegt die häufigste Ursache in einer **Diskrepanz beim Benutzernamen** zwischen IdP und DefectDojo. + +DefectDojo sucht den Benutzer **anhand des Benutzernamens**, wenn eine SAML-Anmeldung einem bestehenden Konto zugeordnet wird. Wenn der Wert, den Ihr IdP als Attribut `username` sendet, nicht dem Benutzernamen eines bestehenden DefectDojo-Benutzers entspricht, schlägt die Suche fehl – auch wenn der Rest der Assertion gültig ist. + +Zwei Abhilfen, wählen Sie diejenige, die zu Ihrer Umgebung passt: + +- **Entfernen Sie `username` aus dem Attribute Mapping** und lassen Sie DefectDojo stattdessen auf die SAML-`NameID` als Benutzername zurückgreifen. Das ist sinnvoll, wenn Ihre DefectDojo-Benutzernamen bereits dem NameID-Format entsprechen, das Ihr IdP sendet. +- **Gleichen Sie die Benutzernamen an.** Stellen Sie sicher, dass die Benutzernamen in DefectDojo genau dem entsprechen, was Ihr IdP im Claim `username` sendet. Für die meisten Organisationen ist es am einfachsten, die DefectDojo-Benutzernamen der E-Mail-Adresse des Benutzers entsprechen zu lassen und den IdP die E-Mail-Adresse als `username`-Claim senden zu lassen. + +Wenn Sie nicht sicher sind, was der IdP tatsächlich sendet, aktivieren Sie **Enable SAML Debugging** (siehe oben) und prüfen Sie die verarbeiteten Attribute in den Logs. + +### SAML Group Mapping bewirkt nichts – Benutzer melden sich an, aber es werden keine Gruppen zugewiesen + +Die häufigste Ursache ist eine Diskrepanz zwischen dem Feld **Group Name Attribute** und dem Attributnamen, den Ihr IdP tatsächlich sendet. Siehe die Tabelle [Group Name Attribute by Identity Provider](#group-name-attribute-by-identity-provider) weiter oben, und aktivieren Sie **Enable SAML Debugging**, um die vom IdP zurückgesendeten Rohattribute zu sehen. diff --git a/docs/content/admin/sso/PRO__saml.es.md b/docs/content/admin/sso/PRO__saml.es.md new file mode 100644 index 00000000000..59ced6fe806 --- /dev/null +++ b/docs/content/admin/sso/PRO__saml.es.md @@ -0,0 +1,155 @@ +--- +title: Configuración de SAML +description: Configura SAML en DefectDojo Pro +weight: 1 +audience: pro +--- + +DefectDojo Pro admite la autenticación SAML mediante la interfaz de **Enterprise Settings**. DefectDojo de código abierto no incluye SSO — consulte [Usuarios autorizados](/admin/user_management/os__authorized_users/) para conocer el control de acceso en código abierto. + +## URL de ACS (Assertion Consumer Service) + +Su proveedor de identidad necesita saber a dónde enviar (POST) la respuesta SAML después de que un usuario se autentica. La URL de ACS de DefectDojo es: + +``` +https://.cloud.defectdojo.com/saml2/acs/ +``` + +Algunas cosas que debe saber sobre este endpoint: + +- **El endpoint solo acepta solicitudes `POST`.** Abrir la URL de ACS directamente en un navegador emite un GET y devolverá un **HTTP 405 Method Not Allowed**. Este es el comportamiento esperado — no significa que SAML esté roto o mal configurado. El endpoint está diseñado para ser invocado por su IdP como parte del flujo de redirección SAML, no por un navegador que escribe la URL. +- **La URL de ACS está disponible en su instancia de DefectDojo Cloud en todo momento** — no necesita habilitar SAML en DefectDojo antes de configurarlo en su IdP. Puede configurar el lado del IdP y el lado de DefectDojo en cualquier orden. + +## Configuración inicial + +1. Abra **Enterprise Settings > SAML Settings**. + + ![image](images/sso_betaui_1.png) + +2. Establezca un **Entity ID** — una etiqueta o URL que su proveedor de identidad SAML usa para identificar a DefectDojo. Este campo es obligatorio. + +3. Opcionalmente, establezca **Login Button Text** — el texto que se muestra en el botón en el que los usuarios hacen clic para iniciar el inicio de sesión SAML. + +4. Opcionalmente, establezca una **Logout URL** para redirigir a los usuarios después de que cierren sesión en DefectDojo. + +5. Elija un **Name ID Format**: + - **Persistent** — los usuarios se identifican de forma consistente mediante SAML entre sesiones. + - **Transient** — los usuarios reciben un ID SAML diferente en cada inicio de sesión. + - **Entity** — todos los usuarios comparten un único NameID de SAML. + - **Encrypted** — el NameID de cada usuario está cifrado. + +6. **Required Attributes** — especifique los atributos que DefectDojo requiere de la respuesta SAML. + +7. **Attribute Mapping** — asigne los atributos que envía su IdP a los campos de usuario de DefectDojo que deben completar. Cada fila empareja un **SAML Attribute** con un **DefectDojo Field**; use **Add Attribute Mapping** para agregar más filas y el icono de papelera para eliminar una. + + ![image](images/sso_saml_attribute_mapping.png) + + - **SAML Attribute** es texto libre y debe coincidir con el nombre de atributo que realmente emite su IdP. Algunos IdP (por ejemplo, Entra ID / Azure AD) envían URI de notificación completamente calificados, como `http://schemas.microsoft.com/identity/claims/emailaddress`, en lugar de nombres descriptivos. Si no está seguro de qué envía su IdP, habilite **Enable SAML Debugging** (consulte [Solución de problemas](#troubleshooting)) e inspeccione la aserción en los registros. + - **DefectDojo Field** se elige de una lista: **Username**, **First Name**, **Last Name** y **Email**. + - Como mínimo, asigne el atributo que corresponde a **Username**. DefectDojo busca a los usuarios por nombre de usuario al hacer coincidir los inicios de sesión SAML con las cuentas existentes. + - Se recomienda encarecidamente asignar un atributo a **Email**: DefectDojo usa la dirección de correo electrónico para las notificaciones y para hacer coincidir un inicio de sesión entrante con una cuenta existente por correo electrónico. + - El mismo atributo puede alimentar más de un campo; por ejemplo, una notificación de correo electrónico usada tanto para **Email** como para **Username**. Lo contrario no está permitido: cada campo de DefectDojo solo puede asignarse desde un atributo. + - Una fila con solo una mitad completada se rechaza al guardar, y la celda correspondiente se resalta. Las filas que agrega pero nunca completa se descartan en lugar de tratarse como errores. + +8. **Remote SAML Metadata** — la URL donde está alojado el metadato de su proveedor de identidad SAML. + +9. Marque **Enable SAML** en la parte inferior del formulario para activar el inicio de sesión SAML. Aparecerá un botón **Login With SAML** en la página de inicio de sesión de DefectDojo. + + ![image](images/sso_saml_login.png). + +## Opciones adicionales + +* **Create Unknown User** — crea automáticamente un nuevo usuario de DefectDojo si no se encuentra en la respuesta SAML. +* **Allow Unknown Attributes** — permite el inicio de sesión de usuarios que tienen atributos no listados en Attribute Mapping. +* **Sign Assertions/Responses** — requiere que todas las respuestas SAML entrantes estén firmadas. +* **Sign Logout Requests** — firma todas las solicitudes de cierre de sesión enviadas por DefectDojo. +* **Force Authentication** — requiere que los usuarios se autentiquen con el proveedor de identidad en cada inicio de sesión, independientemente de las sesiones existentes. +* **Enable SAML Debugging** — registra información detallada de SAML para solución de problemas. Consulte [Solución de problemas → Salida de depuración de SAML](#saml-debugging-output) para saber dónde aparece la salida del registro. + +## Asignación de grupos SAML + +DefectDojo puede usar la aserción SAML para asignar usuarios automáticamente a [Grupos de usuarios](../../user_management/create_user_group/). Los grupos en DefectDojo asignan permisos a todos sus miembros, por lo que la asignación de grupos le permite gestionar permisos de forma masiva. Esta es la única forma de establecer permisos mediante SAML. + +**La asignación de grupos es opcional.** Aunque los campos **Group Name Attribute** y **Group Limiter Regex Expression** aparecen con un asterisco de campo obligatorio (`*`) en la interfaz, el formulario SAML se enviará sin ellos, y el inicio de sesión SAML funcionará sin la asignación de grupos. No necesita crear previamente grupos o roles en su IdP (por ejemplo, roles de aplicación de Azure AD) antes de habilitar SAML — solo necesita configurar estos campos cuando realmente desee que DefectDojo lea la membresía de grupo desde la aserción. Si no configura la asignación de grupos, los nuevos usuarios SSO creados no tendrán permisos por defecto; consulte [Acceso predeterminado para usuarios aprovisionados por SSO](#default-access-for-sso-provisioned-users) más abajo. + +El campo **Group Name Attribute** especifica qué atributo en la aserción SAML contiene las membresías de grupo del usuario. Cuando un usuario inicia sesión, DefectDojo lee este atributo y asigna al usuario a los grupos coincidentes. Para limitar qué grupos de la aserción se consideran, use el campo **Group Limiter Regex Expression** — esta es una expresión regular aplicada a los nombres de grupo de la aserción, usada para filtrar sobre cuáles debe actuar DefectDojo. + +El valor debe coincidir exactamente con el nombre de atributo que emite su proveedor de identidad en la aserción, incluido cualquier prefijo de espacio de nombres. Un nombre corto y descriptivo como `groups` solo funcionará si su IdP está configurado para emitir ese nombre de atributo literal — muchos IdP usan en su lugar un URI de notificación completamente calificado. + +### Atributo de nombre de grupo por proveedor de identidad + +| Identity Provider | Default attribute name to use | +|---|---| +| **Entra ID / Azure AD** | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | +| **Okta** | `groups` (el nombre de atributo que configuró en el Group Attribute Statement de la aplicación SAML) | +| **Keycloak** | `groups` (o lo que haya establecido como "SAML Attribute Name" en el mapper Group List) | +| **PingFederate / genérico** | El valor que haya configurado en el lado del IdP — verifique la aserción de su IdP antes de asumir `groups` | + +Si la asignación de grupos parece no hacer nada — los usuarios inician sesión correctamente pero no se crean ni asignan grupos — consulte [Solución de problemas → La asignación de grupos SAML no hace nada](#saml-group-mapping-does-nothing--users-log-in-but-no-groups-are-assigned) más abajo. + +Si no existe ningún grupo con un nombre coincidente, DefectDojo creará uno automáticamente y asignará a sus miembros el rol **Reader**. Tenga en cuenta que este rol Reader rige el acceso del miembro *al grupo en sí* — no otorga ningún acceso a los Productos, Tipos de producto u otros activos organizativos subyacentes. Esos permisos se configuran por separado, y un grupo recién creado automáticamente todavía no tiene ninguno de ellos hasta que un Superusuario le asigna un rol sobre los Productos o Tipos de producto relevantes. + +Para activar la asignación de grupos, marque la casilla **Enable Group Mapping** en la parte inferior del formulario. + +## Acceso predeterminado para usuarios aprovisionados por SSO + +Cuando se crea un nuevo usuario mediante SAML (o cualquier proveedor de autenticación social) y no se lo agrega a ningún grupo mediante la asignación de grupos SAML, llegará a una instancia de DefectDojo **sin permisos**. Al iniciar sesión verá cero Tipos de producto, cero Productos y cero Compromisos — el panel aparecerá vacío. + +Para dar a cada nuevo usuario SSO aprovisionado una base razonable, configure un **Default group** + **Default group role** en la página de Configuración del sistema: + +1. Abra **⚙️ Configuration → System Settings** (solo Superusuario). +2. Establezca **Default group** en el [Grupo de usuarios](../../user_management/create_user_group/) al que deben unirse los usuarios recién creados. +3. Establezca **Default group role** en el rol que deben tener en ese grupo (por ejemplo, **Reader**). +4. Opcionalmente, establezca **Default group email pattern** en una expresión regular (por ejemplo, `.*@yourcompany\.com$`) para que el grupo predeterminado solo se aplique a los usuarios cuyo correo electrónico coincida. +5. Guarde. + +Tanto **Default group** como **Default group role** deben estar establecidos — si alguno está vacío, el grupo predeterminado no se aplica. + +Esta configuración se aplica a **todos los usuarios recién creados**, incluidos los creados mediante SAML, OAuth y otros proveedores de autenticación social, porque se ejecuta en la señal de creación de usuario de Django en lugar de dentro de un backend de autenticación específico. + +> **Los usuarios existentes no se ven afectados.** El grupo predeterminado solo se aplica cuando se crea un usuario por primera vez. Los usuarios existentes de DefectDojo conservarán sus membresías de grupo actuales incluso si cambia esta configuración más tarde. + +## Diferencias entre Cloud y On-Premise + +DefectDojo Cloud no tiene el mismo nivel de personalización de SAML que DefectDojo On-Prem. Las únicas variables que se pueden establecer son a través de la interfaz. Estas son algunas de las diferencias clave: + +| Capability | Cloud | On-Premise | +|---|---|---| +| **Coincidencia de nombre de usuario** | Solo NameID | Solo NameID (la variable de entorno `SAML_USE_NAME_ID_AS_USERNAME` se aplica solo a Código abierto, no a Pro) | +| **Cifrado de aserciones SAML** | No compatible actualmente | No compatible actualmente | +| **Registros de inicio de sesión SAML** | No disponible en la interfaz. Contacte a Soporte para solicitar los registros. | Disponible mediante los registros del contenedor de la aplicación (`docker logs dojo`) | +| **Método de configuración** | Solo interfaz de Enterprise Settings | Interfaz de Enterprise Settings, Django Admin o Django Shell | +| **Variables de entorno** | Los clientes no pueden establecerlas directamente. Contacte a Soporte para cambios. | Se pueden establecer mediante `dojo-compose-cli environment add` | + +Si necesita hacer coincidir usuarios en un atributo distinto de NameID (como `uid` o `email`), configure su proveedor de identidad para enviar el valor deseado como NameID en lugar de ajustar la configuración de DefectDojo. + +## Solución de problemas + +### Salida de depuración de SAML + +Cuando **Enable SAML Debugging** (en [Opciones adicionales](#additional-options)) está marcado, DefectDojo escribe información detallada del procesamiento SAML — incluidos los atributos sin procesar recibidos del IdP — en los registros de la aplicación al nivel `DEBUG` bajo el logger `saml2`. + +| Where you're running | Where to read the debug output | +|---|---| +| **DefectDojo Cloud** | El registro de depuración SAML no está expuesto en la interfaz. Contacte a DefectDojo Support para solicitar los registros de una ventana de tiempo específica. | +| **On-Premise (contenedor único)** | `docker logs dojo` (o su agregación de registros de Helm/K8s) | +| **On-Premise (Helm/K8s)** | `kubectl logs deployment/defectdojo-django -c uwsgi` (o el agregador de registros de su clúster) | + +Desactive esta opción después de terminar de solucionar problemas — los registros de depuración de SAML son extensos y pueden contener valores de atributos sensibles de su IdP. + +### Los usuarios reciben un error de "User not found" o "Permission denied" después de iniciar sesión correctamente en el IdP + +Si la aserción SAML se analiza correctamente (sin errores de XML o de firma) pero DefectDojo rechaza el inicio de sesión, la causa más común es una **discrepancia de nombre de usuario** entre el IdP y DefectDojo. + +DefectDojo busca al usuario **por nombre de usuario** al hacer coincidir un inicio de sesión SAML con una cuenta existente. Si el valor que su IdP envía como atributo `username` no coincide con el nombre de usuario de un usuario existente de DefectDojo, la búsqueda falla — aunque el resto de la aserción sea válida. + +Hay dos soluciones; elija la que mejor se adapte a su entorno: + +- **Elimine `username` de Attribute Mapping** y deje que DefectDojo recurra a usar el `NameID` de SAML como nombre de usuario. Esto es apropiado si los nombres de usuario de DefectDojo ya coinciden con el formato de NameID que emite su IdP. +- **Alinee los nombres de usuario.** Asegúrese de que los nombres de usuario en DefectDojo sean exactamente lo que su IdP envía en la notificación `username`. Para la mayoría de las organizaciones, la convención más sencilla es hacer que los nombres de usuario de DefectDojo sean iguales a la dirección de correo electrónico del usuario, y que el IdP envíe el correo electrónico como la notificación `username`. + +Si no está seguro de qué está enviando realmente el IdP, habilite **Enable SAML Debugging** (arriba) e inspeccione los atributos analizados en los registros. + +### La asignación de grupos SAML no hace nada — los usuarios inician sesión pero no se asigna ningún grupo + +La causa más común es una discrepancia entre el campo **Group Name Attribute** y el nombre de atributo que su IdP realmente está enviando. Consulte la tabla [Atributo de nombre de grupo por proveedor de identidad](#group-name-attribute-by-identity-provider) más arriba, y habilite **Enable SAML Debugging** para ver los atributos sin procesar que devuelve el IdP. diff --git a/docs/content/admin/sso/PRO__saml.fr.md b/docs/content/admin/sso/PRO__saml.fr.md new file mode 100644 index 00000000000..9c0d9306276 --- /dev/null +++ b/docs/content/admin/sso/PRO__saml.fr.md @@ -0,0 +1,155 @@ +--- +title: Configuration SAML +description: Configurez SAML dans DefectDojo Pro +weight: 1 +audience: pro +--- + +DefectDojo Pro prend en charge l'authentification SAML via l'interface **Enterprise Settings**. La version open source de DefectDojo n'inclut pas l'authentification unique (SSO) — consultez [Utilisateurs autorisés](/admin/user_management/os__authorized_users/) pour le contrôle d'accès en open source. + +## URL ACS (Assertion Consumer Service) + +Votre fournisseur d'identité doit savoir où envoyer (POST) la réponse SAML après l'authentification d'un utilisateur. L'URL ACS de DefectDojo est : + +``` +https://.cloud.defectdojo.com/saml2/acs/ +``` + +Quelques points à connaître sur ce point de terminaison : + +- **Ce point de terminaison n'accepte que les requêtes `POST`.** Ouvrir l'URL ACS directement dans un navigateur émet une requête GET et renverra une erreur **HTTP 405 Method Not Allowed**. Il s'agit d'un comportement attendu — cela ne signifie pas que SAML est cassé ou mal configuré. Ce point de terminaison est conçu pour être appelé par votre IdP dans le cadre du flux de redirection SAML, et non en saisissant l'URL dans un navigateur. +- **L'URL ACS est disponible en permanence sur votre instance DefectDojo Cloud** — vous n'avez pas besoin d'activer SAML dans DefectDojo avant de la renseigner dans votre IdP. Vous pouvez configurer le côté IdP et le côté DefectDojo dans l'ordre de votre choix. + +## Configuration + +1. Ouvrez **Enterprise Settings > SAML Settings**. + + ![image](images/sso_betaui_1.png) + +2. Définissez un **Entity ID** — une étiquette ou une URL que votre fournisseur d'identité SAML utilise pour identifier DefectDojo. Ce champ est obligatoire. + +3. Définissez éventuellement **Login Button Text** — le texte affiché sur le bouton sur lequel les utilisateurs cliquent pour démarrer la connexion SAML. + +4. Définissez éventuellement une **Logout URL** vers laquelle rediriger les utilisateurs après leur déconnexion de DefectDojo. + +5. Choisissez un **Name ID Format** : + - **Persistent** — les utilisateurs sont identifiés de manière cohérente par SAML d'une session à l'autre. + - **Transient** — les utilisateurs reçoivent un ID SAML différent à chaque connexion. + - **Entity** — tous les utilisateurs partagent un seul NameID SAML. + - **Encrypted** — le NameID de chaque utilisateur est chiffré. + +6. **Required Attributes** — indiquez les attributs que DefectDojo exige dans la réponse SAML. + +7. **Attribute Mapping** — associez les attributs envoyés par votre IdP aux champs utilisateur DefectDojo qu'ils doivent renseigner. Chaque ligne associe un **SAML Attribute** à un **DefectDojo Field** ; utilisez **Add Attribute Mapping** pour ajouter des lignes supplémentaires et l'icône de corbeille pour en supprimer une. + + ![image](images/sso_saml_attribute_mapping.png) + + - **SAML Attribute** est un champ libre qui doit correspondre exactement au nom d'attribut réellement émis par votre IdP. Certains IdP (par exemple Entra ID / Azure AD) envoient des URI de revendication complètes telles que `http://schemas.microsoft.com/identity/claims/emailaddress` plutôt que des noms conviviaux. Si vous ne savez pas ce que votre IdP envoie, activez **Enable SAML Debugging** (voir [Dépannage](#troubleshooting)) et examinez l'assertion dans les journaux. + - **DefectDojo Field** est choisi dans une liste : **Username**, **First Name**, **Last Name** et **Email**. + - Au minimum, associez l'attribut correspondant à **Username**. DefectDojo recherche les utilisateurs par nom d'utilisateur pour faire correspondre les connexions SAML aux comptes existants. + - Il est fortement recommandé d'associer un attribut à **Email** : DefectDojo utilise l'adresse e-mail pour les notifications, et pour faire correspondre une connexion entrante à un compte existant par e-mail. + - Un même attribut peut alimenter plusieurs champs — par exemple une revendication d'e-mail utilisée à la fois pour **Email** et **Username**. L'inverse n'est pas autorisé : chaque champ DefectDojo ne peut être associé qu'à un seul attribut. + - Une ligne dont une seule moitié est renseignée est rejetée à l'enregistrement, et la cellule en cause est mise en évidence. Les lignes que vous ajoutez sans jamais les remplir sont ignorées plutôt que traitées comme des erreurs. + +8. **Remote SAML Metadata** — l'URL où sont hébergées les métadonnées de votre fournisseur d'identité SAML. + +9. Cochez **Enable SAML** en bas du formulaire pour activer la connexion SAML. Un bouton **Login With SAML** apparaîtra sur la page de connexion de DefectDojo. + + ![image](images/sso_saml_login.png). + +## Options supplémentaires + +* **Create Unknown User** — crée automatiquement un nouvel utilisateur DefectDojo s'il n'est pas trouvé dans la réponse SAML. +* **Allow Unknown Attributes** — autorise la connexion des utilisateurs disposant d'attributs non répertoriés dans l'Attribute Mapping. +* **Sign Assertions/Responses** — exige que toutes les réponses SAML entrantes soient signées. +* **Sign Logout Requests** — signe toutes les demandes de déconnexion envoyées par DefectDojo. +* **Force Authentication** — exige que les utilisateurs s'authentifient auprès du fournisseur d'identité à chaque connexion, indépendamment des sessions existantes. +* **Enable SAML Debugging** — journalise une sortie SAML détaillée à des fins de dépannage. Voir [Dépannage → Sortie de débogage SAML](#saml-debugging-output) pour savoir où apparaît cette sortie. + +## Mappage des groupes SAML + +DefectDojo peut utiliser l'assertion SAML pour attribuer automatiquement des utilisateurs à des [Groupes d'utilisateurs](../../user_management/create_user_group/). Les groupes dans DefectDojo attribuent des permissions à tous leurs membres ; le Group Mapping permet donc de gérer les permissions en masse. C'est le seul moyen de définir des permissions via SAML. + +**Le mappage des groupes est facultatif.** Bien que les champs **Group Name Attribute** et **Group Limiter Regex Expression** apparaissent avec un astérisque de champ obligatoire (`*`) dans l'interface, le formulaire SAML s'enregistre sans eux, et la connexion SAML fonctionne sans mappage de groupes. Vous n'avez pas besoin de préconstruire des groupes ou des rôles dans votre IdP (par exemple les rôles d'application Azure AD) avant d'activer SAML — vous ne devez configurer ces champs que si vous voulez réellement que DefectDojo lise l'appartenance aux groupes à partir de l'assertion. Si vous ne configurez pas le mappage des groupes, les nouveaux utilisateurs SSO créés n'auront aucune permission par défaut ; voir [Accès par défaut pour les utilisateurs provisionnés par SSO](#default-access-for-sso-provisioned-users) ci-dessous. + +Le champ **Group Name Attribute** indique quel attribut de l'assertion SAML contient les appartenances aux groupes de l'utilisateur. Lorsqu'un utilisateur se connecte, DefectDojo lit cet attribut et affecte l'utilisateur aux groupes correspondants. Pour limiter les groupes de l'assertion pris en compte, utilisez le champ **Group Limiter Regex Expression** — il s'agit d'une expression régulière appliquée aux noms de groupes de l'assertion, utilisée pour filtrer ceux sur lesquels DefectDojo doit agir. + +La valeur doit correspondre exactement au nom d'attribut émis par votre fournisseur d'identité dans l'assertion, y compris tout préfixe d'espace de noms. Un nom court et convivial comme `groups` ne fonctionnera que si votre IdP est configuré pour émettre ce nom d'attribut littéral — de nombreux IdP utilisent à la place une URI de revendication complète. + +### Attribut Group Name Attribute par fournisseur d'identité + +| Fournisseur d'identité | Nom d'attribut par défaut à utiliser | +|---|---| +| **Entra ID / Azure AD** | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | +| **Okta** | `groups` (le nom d'attribut que vous avez configuré dans le Group Attribute Statement de l'application SAML) | +| **Keycloak** | `groups` (ou la valeur que vous avez définie comme « SAML Attribute Name » sur le mapper Group List) | +| **PingFederate / générique** | La valeur que vous avez configurée côté IdP — vérifiez l'assertion de votre IdP avant de supposer `groups` | + +Si le mappage des groupes semble ne rien faire — les utilisateurs se connectent avec succès mais aucun groupe n'est créé ni attribué — voir [Dépannage → Le mappage des groupes SAML ne fait rien](#saml-group-mapping-does-nothing--users-log-in-but-no-groups-are-assigned) ci-dessous. + +Si aucun groupe portant un nom correspondant n'existe, DefectDojo en crée un automatiquement et attribue à ses membres le rôle **Reader**. Notez que ce rôle Reader régit l'accès du membre *au groupe lui-même* — il n'accorde aucun accès aux Produits, Types de produits ou autres ressources organisationnelles sous-jacents. Ces permissions sont configurées séparément, et un groupe nouvellement créé automatiquement n'en possède aucune tant qu'un Superuser ne lui a pas attribué un rôle sur les Produits ou Types de produits concernés. + +Pour activer le mappage des groupes, cochez la case **Enable Group Mapping** en bas du formulaire. + +## Accès par défaut pour les utilisateurs provisionnés par SSO + +Lorsqu'un nouvel utilisateur est créé via SAML (ou tout autre fournisseur social-auth) et n'est ajouté à aucun groupe via le SAML Group Mapping, il se retrouve sur une instance DefectDojo **sans aucune permission**. Il ne verra aucun Type de produit, aucun Produit et aucun Engagement lors de sa connexion — le tableau de bord apparaîtra vide. + +Pour donner à chaque nouvel utilisateur SSO provisionné une base raisonnable, configurez un **Default group** + **Default group role** sur la page System Settings : + +1. Ouvrez **⚙️ Configuration → System Settings** (réservé aux Superusers). +2. Définissez **Default group** sur le [Groupe d'utilisateurs](../../user_management/create_user_group/) que les nouveaux utilisateurs créés doivent rejoindre. +3. Définissez **Default group role** sur le rôle qu'ils doivent détenir dans ce groupe (par exemple **Reader**). +4. Définissez éventuellement **Default group email pattern** avec une expression régulière (par exemple `.*@yourcompany\.com$`) afin que le groupe par défaut ne s'applique qu'aux utilisateurs dont l'e-mail correspond. +5. Enregistrez. + +**Default group** et **Default group role** doivent tous deux être définis — si l'un des deux est vide, le groupe par défaut n'est pas appliqué. + +Ce paramètre s'applique à **chaque nouvel utilisateur créé**, y compris les utilisateurs créés via SAML, OAuth et d'autres fournisseurs social-auth, car il s'exécute sur le signal de création d'utilisateur de Django plutôt qu'à l'intérieur d'un backend d'authentification spécifique. + +> **Les utilisateurs existants ne sont pas concernés.** Le groupe par défaut n'est appliqué que lors de la création initiale d'un utilisateur. Les utilisateurs DefectDojo existants conserveront leurs appartenances aux groupes actuelles même si vous modifiez ce paramètre ultérieurement. + +## Différences entre Cloud et On-Premise + +DefectDojo Cloud n'offre pas le même niveau de personnalisation SAML que DefectDojo On-Prem. Les seules variables modifiables le sont via l'interface utilisateur. Voici quelques-unes des différences clés : + +| Fonctionnalité | Cloud | On-Premise | +|---|---|---| +| **Correspondance des noms d'utilisateur** | NameID uniquement | NameID uniquement (la variable d'environnement `SAML_USE_NAME_ID_AS_USERNAME` s'applique uniquement à l'Open Source, pas à Pro) | +| **Chiffrement des assertions SAML** | Non pris en charge actuellement | Non pris en charge actuellement | +| **Journaux de connexion SAML** | Non disponibles dans l'interface. Contactez le support pour demander les journaux. | Disponibles via les journaux du conteneur applicatif (`docker logs dojo`) | +| **Méthode de configuration** | Interface Enterprise Settings uniquement | Interface Enterprise Settings, Django Admin, ou Django Shell | +| **Variables d'environnement** | Ne peuvent pas être définies directement par les clients. Contactez le support pour toute modification. | Peuvent être définies via `dojo-compose-cli environment add` | + +Si vous devez faire correspondre les utilisateurs sur un attribut autre que NameID (comme `uid` ou `email`), configurez votre fournisseur d'identité pour qu'il envoie la valeur souhaitée en tant que NameID plutôt que d'ajuster les paramètres de DefectDojo. + +## Dépannage + +### Sortie de débogage SAML + +Lorsque **Enable SAML Debugging** (dans [Options supplémentaires](#additional-options)) est coché, DefectDojo écrit une sortie détaillée du traitement SAML — y compris les attributs bruts reçus de l'IdP — dans les journaux de l'application, au niveau `DEBUG`, sous le logger `saml2`. + +| Où vous exécutez DefectDojo | Où lire la sortie de débogage | +|---|---| +| **DefectDojo Cloud** | Le journal de débogage SAML n'est pas exposé dans l'interface. Contactez le support DefectDojo pour demander les journaux d'une période donnée. | +| **On-Premise (conteneur unique)** | `docker logs dojo` (ou votre agrégation de journaux Helm/K8s) | +| **On-Premise (Helm/K8s)** | `kubectl logs deployment/defectdojo-django -c uwsgi` (ou l'agrégateur de journaux de votre cluster) | + +Désactivez cette option une fois le dépannage terminé — les journaux de débogage SAML sont verbeux et peuvent contenir des valeurs d'attributs sensibles provenant de votre IdP. + +### Les utilisateurs reçoivent une erreur « User not found » ou « Permission denied » après une connexion IdP réussie + +Si l'assertion SAML est analysée avec succès (aucune erreur XML ou de signature) mais que DefectDojo refuse la connexion, la cause la plus fréquente est une **incohérence de nom d'utilisateur** entre l'IdP et DefectDojo. + +DefectDojo recherche l'utilisateur **par nom d'utilisateur** pour faire correspondre une connexion SAML à un compte existant. Si la valeur envoyée par votre IdP dans l'attribut `username` ne correspond au nom d'utilisateur d'aucun utilisateur DefectDojo existant, la recherche échoue — même si le reste de l'assertion est valide. + +Deux solutions possibles, choisissez celle qui convient à votre environnement : + +- **Supprimez `username` de l'Attribute Mapping** et laissez DefectDojo utiliser par défaut le `NameID` SAML comme nom d'utilisateur. Cela convient si vos noms d'utilisateur DefectDojo correspondent déjà au format de NameID émis par votre IdP. +- **Alignez les noms d'utilisateur.** Assurez-vous que les noms d'utilisateur dans DefectDojo correspondent exactement à ce que votre IdP envoie dans la revendication `username`. Pour la plupart des organisations, la convention la plus simple consiste à faire correspondre les noms d'utilisateur DefectDojo à l'adresse e-mail de l'utilisateur, et à faire envoyer l'e-mail par l'IdP dans la revendication `username`. + +Si vous ne savez pas exactement ce que l'IdP envoie, activez **Enable SAML Debugging** (ci-dessus) et examinez les attributs analysés dans les journaux. + +### Le mappage des groupes SAML ne fait rien — les utilisateurs se connectent mais aucun groupe n'est attribué + +La cause la plus fréquente est une incohérence entre le champ **Group Name Attribute** et le nom d'attribut réellement envoyé par votre IdP. Consultez le tableau [Attribut Group Name Attribute par fournisseur d'identité](#group-name-attribute-by-identity-provider) ci-dessus, et activez **Enable SAML Debugging** pour voir les attributs bruts renvoyés par l'IdP. diff --git a/docs/content/admin/sso/PRO__saml.ja.md b/docs/content/admin/sso/PRO__saml.ja.md new file mode 100644 index 00000000000..bb18144f750 --- /dev/null +++ b/docs/content/admin/sso/PRO__saml.ja.md @@ -0,0 +1,155 @@ +--- +title: SAML の設定 +description: DefectDojo Pro で SAML を設定する +weight: 1 +audience: pro +--- + +DefectDojo Pro は **Enterprise Settings** UI 経由での SAML 認証をサポートしています。オープンソース版の DefectDojo には SSO は含まれていません。オープンソース版のアクセス制御については [Authorized Users](/admin/user_management/os__authorized_users/) を参照してください。 + +## ACS URL (Assertion Consumer Service) + +ユーザーが認証された後、SAML レスポンスをどこに POST すればよいかを ID プロバイダーが把握している必要があります。DefectDojo の ACS URL は次のとおりです。 + +``` +https://.cloud.defectdojo.com/saml2/acs/ +``` + +このエンドポイントについて知っておくべき点がいくつかあります。 + +- **このエンドポイントは `POST` リクエストのみを受け付けます。** ACS URL をブラウザで直接開くと GET リクエストが発行され、**HTTP 405 Method Not Allowed** が返されます。これは想定された動作であり、SAML が壊れている、または設定を誤っていることを意味するものではありません。このエンドポイントは、ブラウザに URL を直接入力して呼び出すものではなく、SAML リダイレクトフローの一部として IdP から呼び出されるように設計されています。 +- **ACS URL は DefectDojo Cloud インスタンス上で常に利用可能です。** IdP をこの URL に向ける前に、DefectDojo で SAML を有効にしておく必要はありません。IdP 側と DefectDojo 側の設定はどちらを先に行っても構いません。 + +## Setup + +1. **Enterprise Settings > SAML Settings** を開きます。 + + ![image](images/sso_betaui_1.png) + +2. **Entity ID** を設定します。これは、SAML ID プロバイダーが DefectDojo を識別するために使用するラベルまたは URL です。このフィールドは必須です。 + +3. 必要に応じて **Login Button Text** を設定します。これは、ユーザーが SAML ログインを開始するためにクリックするボタンに表示されるテキストです。 + +4. 必要に応じて、ユーザーが DefectDojo からログアウトした後にリダイレクトする **Logout URL** を設定します。 + +5. **Name ID Format** を選択します。 + - **Persistent** — ユーザーはセッションをまたいで一貫した SAML ID で識別されます。 + - **Transient** — ユーザーはログインのたびに異なる SAML ID を受け取ります。 + - **Entity** — すべてのユーザーが単一の SAML NameID を共有します。 + - **Encrypted** — 各ユーザーの NameID が暗号化されます。 + +6. **Required Attributes** — DefectDojo が SAML レスポンスから要求する属性を指定します。 + +7. **Attribute Mapping** — IdP が送信する属性を、それが値を設定すべき DefectDojo のユーザーフィールドにマッピングします。各行は 1 つの **SAML Attribute** と 1 つの **DefectDojo Field** をペアにします。行を追加するには **Add Attribute Mapping** を使用し、削除するにはゴミ箱アイコンを使用します。 + + ![image](images/sso_saml_attribute_mapping.png) + + - **SAML Attribute** は自由入力欄で、IdP が実際に発行する属性名と一致させる必要があります。一部の IdP(Entra ID / Azure AD など)は、わかりやすい名前ではなく `http://schemas.microsoft.com/identity/claims/emailaddress` のような完全修飾クレーム URI を送信します。IdP が何を送信しているかわからない場合は、**Enable SAML Debugging** を有効にし([トラブルシューティング](#troubleshooting) を参照)、ログでアサーションを確認してください。 + - **DefectDojo Field** は、**Username**、**First Name**、**Last Name**、**Email** のリストから選択します。 + - 少なくとも **Username** に対応する属性はマッピングしてください。DefectDojo は、SAML ログインを既存のアカウントに照合する際、ユーザー名でユーザーを検索します。 + - **Email** への属性のマッピングを強く推奨します。DefectDojo は通知にメールアドレスを使用するほか、受信したログインをメールアドレスで既存のアカウントに照合する際にも使用します。 + - 同じ属性を複数のフィールドに使用できます。たとえば、メールのクレームを **Email** と **Username** の両方に使用できます。ただし逆は許可されません。各 DefectDojo フィールドにマッピングできる属性は 1 つだけです。 + - 片方のみが入力された行は保存時に拒否され、該当するセルがハイライトされます。追加したものの入力しなかった行は、エラーとして扱われるのではなく破棄されます。 + +8. **Remote SAML Metadata** — SAML ID プロバイダーのメタデータがホストされている URL です。 + +9. フォームの下部にある **Enable SAML** をチェックして、SAML ログインを有効にします。DefectDojo のログインページに **Login With SAML** ボタンが表示されます。 + + ![image](images/sso_saml_login.png). + +## Additional Options + +* **Create Unknown User** — SAML レスポンスにユーザーが見つからない場合、新しい DefectDojo ユーザーを自動的に作成します。 +* **Allow Unknown Attributes** — Attribute Mapping に記載されていない属性を持つユーザーのログインを許可します。 +* **Sign Assertions/Responses** — 受信するすべての SAML レスポンスに署名を必須にします。 +* **Sign Logout Requests** — DefectDojo が送信するすべてのログアウトリクエストに署名します。 +* **Force Authentication** — 既存のセッションの有無にかかわらず、ログインのたびに ID プロバイダーでの認証をユーザーに要求します。 +* **Enable SAML Debugging** — トラブルシューティング用に詳細な SAML 出力をログに記録します。ログ出力がどこに表示されるかについては、[トラブルシューティング → SAML Debugging output](#saml-debugging-output) を参照してください。 + +## SAML Group Mapping + +DefectDojo は SAML アサーションを使用して、ユーザーを [User Groups](../../user_management/create_user_group/) に自動的に割り当てることができます。DefectDojo のグループはすべてのメンバーに権限を付与するため、Group Mapping を使えば権限をまとめて管理できます。これは SAML 経由で権限を設定する唯一の方法です。 + +**グループマッピングは任意です。** UI 上では **Group Name Attribute** と **Group Limiter Regex Expression** のフィールドに必須項目を示すアスタリスク(`*`)が表示されますが、これらを入力しなくても SAML フォームは送信でき、グループマッピングなしでも SAML ログインは機能します。SAML を有効にする前に、IdP 側(Azure AD のアプリケーションロールなど)でグループやロールを事前に構築しておく必要はありません。DefectDojo にアサーションからグループメンバーシップを読み取らせたい場合にのみ、これらのフィールドを設定してください。グループマッピングを設定しない場合、新しく作成された SSO ユーザーにはデフォルトで権限が付与されません。詳細は下記の [Default access for SSO-provisioned users](#default-access-for-sso-provisioned-users) を参照してください。 + +**Group Name Attribute** フィールドは、SAML アサーション内のどの属性にユーザーのグループメンバーシップが含まれているかを指定します。ユーザーがログインすると、DefectDojo はこの属性を読み取り、一致するグループにユーザーを割り当てます。アサーションから考慮するグループを制限するには、**Group Limiter Regex Expression** フィールドを使用します。これはアサーションのグループ名に適用される正規表現で、DefectDojo が処理対象とするグループを絞り込むために使用されます。 + +この値は、名前空間のプレフィックスを含め、ID プロバイダーがアサーション内で発行する属性名と正確に一致している必要があります。`groups` のような短くわかりやすい名前は、IdP がその文字どおりの属性名を発行するように設定されている場合にのみ機能します。多くの IdP は代わりに完全修飾クレーム URI を使用します。 + +### Group Name Attribute by Identity Provider + +| Identity Provider | Default attribute name to use | +|---|---| +| **Entra ID / Azure AD** | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | +| **Okta** | `groups`(SAML アプリの Group Attribute Statement で設定した属性名) | +| **Keycloak** | `groups`(または Group List マッパーの「SAML Attribute Name」に設定した値) | +| **PingFederate / generic** | IdP 側で設定した値。`groups` だと決めつける前に IdP のアサーションを確認してください | + +グループマッピングが何も行っていないように見える場合(ユーザーは正常にログインできるが、グループが作成または割り当てられない場合)は、下記の [Troubleshooting → SAML group mapping does nothing](#saml-group-mapping-does-nothing--users-log-in-but-no-groups-are-assigned) を参照してください。 + +一致する名前のグループが存在しない場合、DefectDojo は自動的にグループを作成し、そのメンバーに **Reader** ロールを割り当てます。この Reader ロールは、メンバーの*グループ自体へのアクセス*を管理するものであり、配下の製品、製品タイプ、その他の組織アセットへのアクセスを付与するものではない点に注意してください。それらの権限は別途設定する必要があり、Superuser が該当する製品または製品タイプに対してグループにロールを割り当てるまで、新しく自動作成されたグループにはそれらの権限は一切ありません。 + +グループマッピングを有効にするには、フォームの下部にある **Enable Group Mapping** チェックボックスをオンにします。 + +## Default access for SSO-provisioned users + +SAML(または他のソーシャル認証プロバイダー)経由で新しいユーザーが作成され、SAML Group Mapping によってどのグループにも追加されなかった場合、そのユーザーは**権限が一切ない**状態で DefectDojo インスタンスにアクセスすることになります。ログインすると、製品タイプ、製品、エンゲージメントがいずれもゼロ件と表示され、ダッシュボードは空に見えます。 + +新しくプロビジョニングされるすべての SSO ユーザーに適切なベースラインを与えるには、System Settings ページで **Default group** と **Default group role** を設定します。 + +1. **⚙️ Configuration → System Settings**(Superuser のみ)を開きます。 +2. **Default group** に、新しく作成されたユーザーが参加すべき [User Group](../../user_management/create_user_group/) を設定します。 +3. **Default group role** に、そのグループでユーザーが持つべきロール(例: **Reader**)を設定します。 +4. 必要に応じて、**Default group email pattern** に正規表現(例: `.*@yourcompany\.com$`)を設定し、メールアドレスが一致するユーザーにのみデフォルトグループが適用されるようにします。 +5. 保存します。 + +**Default group** と **Default group role** の両方を設定する必要があります。どちらかが空の場合、デフォルトグループは適用されません。 + +この設定は Django のユーザー作成シグナル上で動作するため、特定の認証バックエンドの内部だけでなく、SAML、OAuth、その他のソーシャル認証プロバイダー経由で作成されたユーザーを含む**新しく作成されたすべてのユーザー**に適用されます。 + +> **既存のユーザーには影響しません。** デフォルトグループは、ユーザーが最初に作成されたときにのみ適用されます。この設定を後で変更しても、既存の DefectDojo ユーザーは現在のグループメンバーシップを維持します。 + +## Cloud vs On-Premise Differences + +DefectDojo Cloud は、DefectDojo On-Prem と同レベルの SAML カスタマイズをサポートしていません。設定できる変数は UI 経由のもののみです。主な違いは次のとおりです。 + +| Capability | Cloud | On-Premise | +|---|---|---| +| **ユーザー名のマッチング** | NameID のみ | NameID のみ(`SAML_USE_NAME_ID_AS_USERNAME` 環境変数はオープンソース版にのみ適用され、Pro には適用されません) | +| **SAML アサーションの暗号化** | 現在サポートされていません | 現在サポートされていません | +| **SAML ログインログ** | UI では利用できません。ログの取得はサポートにお問い合わせください。 | アプリケーションコンテナのログ(`docker logs dojo`)から利用可能です | +| **設定方法** | Enterprise Settings UI のみ | Enterprise Settings UI、Django Admin、または Django Shell | +| **環境変数** | 顧客が直接設定することはできません。変更が必要な場合はサポートにお問い合わせください。 | `dojo-compose-cli environment add` で設定可能です | + +NameID 以外の属性(`uid` や `email` など)でユーザーを照合する必要がある場合は、DefectDojo の設定を調整するのではなく、目的の値を NameID として送信するように ID プロバイダー側を設定してください。 + +## Troubleshooting + +### SAML Debugging output + +([Additional Options](#additional-options) の)**Enable SAML Debugging** をチェックすると、DefectDojo は IdP から受信した生の属性を含む詳細な SAML 処理の出力を、`saml2` ロガー配下の `DEBUG` レベルでアプリケーションログに書き込みます。 + +| Where you're running | Where to read the debug output | +|---|---| +| **DefectDojo Cloud** | SAML デバッグログは UI では公開されていません。特定の期間のログが必要な場合は DefectDojo サポートにお問い合わせください。 | +| **On-Premise(単一コンテナ)** | `docker logs dojo`(または Helm/K8s のログ集約) | +| **On-Premise(Helm/K8s)** | `kubectl logs deployment/defectdojo-django -c uwsgi`(またはクラスターのログアグリゲーター) | + +トラブルシューティングが終わったら、このオプションは**オフ**にしてください。SAML デバッグログは詳細であり、IdP からの機密性の高い属性値が含まれる場合があります。 + +### Users get a "User not found" or "Permission denied" error after a successful IdP login + +SAML アサーションの解析は成功している(XML や署名のエラーがない)にもかかわらず DefectDojo がログインを拒否する場合、最も多い原因は IdP と DefectDojo の間の**ユーザー名の不一致**です。 + +DefectDojo は、SAML ログインを既存のアカウントに照合する際、**ユーザー名で**ユーザーを検索します。IdP が `username` 属性として送信する値が、既存の DefectDojo ユーザーのユーザー名と一致しない場合、アサーションの他の部分が有効であっても検索は失敗します。 + +対処法は 2 つあります。環境に合ったほうを選んでください。 + +- **Attribute Mapping から `username` を削除する** — DefectDojo が代わりに SAML の `NameID` をユーザー名として使用するようにフォールバックさせます。DefectDojo のユーザー名が、IdP が発行する NameID の形式とすでに一致している場合に適しています。 +- **ユーザー名を一致させる。** DefectDojo のユーザー名が、IdP が `username` クレームで送信する値と正確に一致するようにします。ほとんどの組織にとって最も簡単な方法は、DefectDojo のユーザー名をユーザーのメールアドレスと同じにし、IdP がそのメールアドレスを `username` クレームとして送信するようにすることです。 + +IdP が実際に何を送信しているかわからない場合は、(上記の)**Enable SAML Debugging** を有効にして、ログで解析済みの属性を確認してください。 + +### SAML group mapping does nothing — users log in but no groups are assigned + +最も多い原因は、**Group Name Attribute** フィールドと、IdP が実際に送信している属性名との不一致です。上記の [Group Name Attribute by Identity Provider](#group-name-attribute-by-identity-provider) の表を参照し、**Enable SAML Debugging** を有効にして IdP から返される生の属性を確認してください。 diff --git a/docs/content/admin/sso/PRO__scim.de.md b/docs/content/admin/sso/PRO__scim.de.md new file mode 100644 index 00000000000..181f9fa1e4d --- /dev/null +++ b/docs/content/admin/sso/PRO__scim.de.md @@ -0,0 +1,148 @@ +--- +title: SCIM-Provisionierung +description: DefectDojo Pro-Benutzer über Ihren Identity Provider bereitstellen und + deaktivieren +weight: 19 +audience: pro +--- + +DefectDojo Pro unterstützt SCIM 2.0, wodurch Ihr Identity Provider DefectDojo-Benutzer direkt erstellen, aktualisieren und deaktivieren kann. Ohne SCIM erfährt DefectDojo erst dann von einem Benutzer, wenn sich dieser anmeldet. Entfernen Sie jemanden aus Ihrem Identity Provider, werden also künftige Anmeldungen verhindert, das DefectDojo-Konto bleibt jedoch aktiv. + +SCIM ist von Single Sign-On getrennt und ergänzt es. SSO entscheidet, wer sich anmelden darf; SCIM hält die Kontoliste selbst mit Ihrem Verzeichnis synchron. Die meisten Kunden konfigurieren beides: SAML oder OIDC für die Authentifizierung, SCIM für die Provisionierung. + +Die SCIM-Konfiguration kann nur von einem **Superuser** vorgenommen werden. + +## Was SCIM in DefectDojo bewirkt + +Wenn Sie einen Identity Provider über SCIM verbinden, kann dieser: + +* DefectDojo-Benutzer erstellen, wenn jemandem die Anwendung zugewiesen wird +* Namen und E-Mail-Adressen aktualisieren, wenn sie sich im Verzeichnis ändern +* Benutzer deaktivieren, wenn ihnen die Zuweisung entzogen wird oder sie die Organisation verlassen +* Gruppen erstellen sowie deren Mitglieder hinzufügen und entfernen + +Das Deaktivieren eines Benutzers über SCIM bewirkt zwei Dinge gleichzeitig. Das Konto wird als inaktiv markiert, sodass sich der Benutzer nicht mehr anmelden kann, und die DefectDojo-API-Tokens des Benutzers werden gelöscht. Offboarding schließt damit beide Türen in einem einzigen Schritt – das ist der Hauptgrund, SCIM zu verwenden, statt sich allein auf Ihren Identity Provider zu verlassen. + +Der Benutzerdatensatz selbst bleibt erhalten. Befunde, Notizen und der Verlauf verweisen auf die Personen, die sie erstellt haben, daher deaktiviert DefectDojo das Konto, anstatt es zu löschen. Kehrt dieselbe Person zurück, stellt die Reaktivierung über Ihren Identity Provider den Zugriff wieder her, ohne diesen Verlauf zu beeinträchtigen. + +## Einrichtung + +1. Öffnen Sie **Connect > Authorization** und wählen Sie **SCIM Provisioning**. SCIM wird zusammen mit Ihren Login-Providern aufgeführt, da es sich mit demselben Identity Provider verbindet, und ist mit **Provisioning** gekennzeichnet, um es von den Providern zu unterscheiden, die eine Schaltfläche auf der Anmeldeseite anzeigen. + +2. Aktivieren Sie **Enable SCIM Provisioning** und übernehmen Sie die Änderung. Solange dies deaktiviert ist, verhalten sich die SCIM-Endpunkte so, als würden sie nicht existieren, sodass ein Verbindungstest von Ihrem Identity Provider die Adresse als nicht gefunden meldet. + +3. Kopieren Sie die auf der Seite angezeigte **Tenant URL**. Sie sieht folgendermaßen aus: + + ``` + https://.cloud.defectdojo.com/scim/v2 + ``` + +4. Geben Sie dem Token im Bereich **SCIM Tokens** einen Namen, der angibt, wo es verwendet wird, zum Beispiel „Okta production", und wählen Sie dann **Generate Token**. + +5. Kopieren Sie das Token aus dem Dialog und fügen Sie es in Ihren Identity Provider ein. DefectDojo speichert nur einen Hash des Tokens, sodass es nicht erneut angezeigt werden kann. Falls Sie es verlieren, generieren Sie ein neues und widerrufen Sie das alte. + +Sie können mehrere Tokens gleichzeitig aktiv halten. Um ein Token zu rotieren, generieren Sie ein neues, aktualisieren Sie Ihren Identity Provider und widerrufen Sie anschließend das alte. Es gibt keinen Zeitraum, in dem die Provisionierung nicht funktioniert. + +Das Token-Panel zeichnet auf, wann jedes Token zuletzt verwendet wurde – eine schnelle Möglichkeit zu prüfen, ob Ihr Identity Provider DefectDojo tatsächlich erreicht. + +## Okta + +1. Gehen Sie in der Okta Admin Console zu **Applications > Browse App Catalog** und fügen Sie **SCIM 2.0 Test App (Header Auth)** hinzu. Wenn Sie bereits eine SAML-Anwendung für DefectDojo haben, können Sie die Provisionierung stattdessen für diese Anwendung aktivieren. + +2. Öffnen Sie den Tab **Provisioning** und wählen Sie **Configure API Integration**. + +3. Setzen Sie **SCIM 2.0 Base Url** auf die oben kopierte Tenant URL. + +4. Setzen Sie **API Token** auf `Bearer `, einschließlich des Worts `Bearer` und eines einzelnen Leerzeichens. Dieser Anwendungstyp sendet den Wert unverändert als Authorization-Header. + +5. Wählen Sie **Test API Credentials** und speichern Sie anschließend. + +6. Aktivieren Sie unter **Provisioning > To App** die Optionen **Create Users**, **Update User Attributes** und **Deactivate Users**. + +7. Weisen Sie der Anwendung Personen oder Gruppen zu. Okta sucht jede Person zunächst anhand des Benutzernamens in DefectDojo und erstellt nur dann ein Konto, wenn keines gefunden wird. Wer bereits ein DefectDojo-Konto hat, wird also verknüpft statt dupliziert. + +Um auch Gruppen zu übertragen, öffnen Sie den Tab **Push Groups** und fügen Sie die Gruppen hinzu, die DefectDojo spiegeln soll. Siehe [Gruppen](#groups) weiter unten für das, was DefectDojo damit macht. + +## Microsoft Entra ID + +1. Gehen Sie im Entra Admin Center zu **Enterprise applications > New application > Create your own application** und wählen Sie die Non-Gallery-Option. Wenn Sie bereits eine Anwendung für DefectDojo haben, verwenden Sie diese. + +2. Öffnen Sie **Provisioning** und setzen Sie **Provisioning Mode** auf **Automatic**. + +3. Setzen Sie **Tenant URL** auf die oben kopierte Tenant URL. + +4. Setzen Sie **Secret Token** auf Ihr SCIM-Token. Entra sendet es als Bearer-Token, fügen Sie hier also nicht das Wort `Bearer` hinzu. + +5. Wählen Sie **Test Connection** und speichern Sie anschließend. + +6. Weisen Sie unter **Users and groups** Benutzer und Gruppen zu und starten Sie die Provisionierung. + +Entra provisioniert in einem Zyklus von etwa 40 Minuten. Während der Einrichtung wendet **Provision on demand** einen einzelnen Benutzer oder eine Gruppe sofort an, was die Überprüfung der Konfiguration erheblich beschleunigt. + +## Was DefectDojo speichert + +DefectDojo ordnet eine kleine Menge an SCIM-Attributen zu und ignoriert den Rest. + +| SCIM-Attribut | DefectDojo-Feld | +|---|---| +| `userName` | Username | +| `name.givenName` | First name | +| `name.familyName` | Last name | +| `emails` | Email address | +| `active` | Ob das Konto aktiviert ist | +| `externalId` | Wird gespeichert, damit Ihr Identity Provider den Datensatz später zuordnen kann | + +Attribute, die DefectDojo nicht abbildet, darunter Telefonnummern, Jobtitel und die SCIM Enterprise Extension, werden akzeptiert und ignoriert statt abgelehnt. Das Mappen zusätzlicher Attribute in Ihrem Identity Provider ist unbedenklich. + +Zwei Attribute verdienen besondere Aufmerksamkeit: + +**Username.** DefectDojo erlaubt in einem Benutzernamen Buchstaben, Ziffern und die Zeichen `@ . + - _`. Wenn Ihr Identity Provider einen Benutzernamen mit anderen Zeichen sendet, lehnt DefectDojo diesen Benutzer mit einer Fehlermeldung ab, die das Problem benennt, statt stillschweigend einen abweichenden Benutzernamen zu speichern. Das Speichern eines veränderten Benutzernamens würde die Fähigkeit Ihres Providers beeinträchtigen, das Konto später wiederzufinden. + +**Email address.** SCIM erfordert keine E-Mail-Adresse, und DefectDojo erstellt den Benutzer auch ohne sie. Bedenken Sie, dass DefectDojo-Benachrichtigungen, einschließlich geplanter Berichte und Alarme, für einen Benutzer ohne E-Mail-Adresse ins Leere laufen. Mappen Sie das Attribut `emails`, sofern Sie keinen Grund haben, dies nicht zu tun. + +SCIM setzt niemals Passwörter und gewährt niemals Superuser- oder Staff-Status. Wenn Ihr Identity Provider so konfiguriert ist, dass er Passwörter sendet, ignoriert DefectDojo diese. Auf diese Weise bereitgestellte Benutzer melden sich über SSO an. + +## Gruppen + +SCIM verwaltet nur die Gruppen, die es selbst erstellt hat. Gruppen, die Sie in der DefectDojo-Benutzeroberfläche angelegt haben oder die über SAML- oder Azure-AD-Group-Mapping entstanden sind, sind für SCIM unsichtbar und können von Ihrem Identity Provider weder umbenannt noch geleert oder gelöscht werden. + +Das ist wichtig, weil Group Push seiner Natur nach ein vollständiger Ersatz ist. Könnte ein Identity Provider eine bestehende Gruppe übernehmen, würde seine nächste Synchronisierung die sorgfältig gewählte Mitgliedschaft dieser Gruppe durch das ersetzen, was im Verzeichnis steht. Das Übertragen einer Gruppe, deren Name bereits vergeben ist, schlägt daher mit einer Meldung fehl, die den Konflikt erklärt. Um eine bestehende Gruppe an Ihren Identity Provider zu übergeben, benennen Sie entweder eine der beiden um, oder löschen Sie die DefectDojo-Gruppe und lassen Sie den Provider sie neu erstellen. + +Innerhalb einer von SCIM verwalteten Gruppe gehört die Mitgliedschaft Ihrem Identity Provider, die Rollen gehören DefectDojo: + +* Ein neu hinzugefügtes Mitglied erhält die Rolle **Reader**. +* Wenn Sie jemanden in DefectDojo zu einer höheren Rolle befördern, lassen spätere Synchronisierungen diese Rolle unangetastet. +* Wer von Hand zu einer von SCIM verwalteten Gruppe hinzugefügt wird, wird bei der nächsten Synchronisierung wieder entfernt, da der Identity Provider die maßgebliche Quelle dafür ist, wer dazugehört. + +Das Löschen einer Gruppe über SCIM entfernt die Gruppe und ihre Mitgliedschaften. Die Personen, die darin waren, werden dabei nie gelöscht. + +## Schutz des Administratorzugriffs + +Standardmäßig deaktiviert SCIM kein Superuser-Konto. Der häufigste Fehler bei jeder Provisionierungseinrichtung ist ein Identity Provider, dessen Geltungsbereich weiter gefasst ist als beabsichtigt, und Superuser sind der Weg, um bei Problemen wieder Zugriff auf DefectDojo zu erhalten. + +Wenn Ihr Identity Provider auch Superuser verwalten soll, aktivieren Sie **Allow SCIM to deactivate superusers** auf der SCIM-Einstellungsseite. Selbst dann weigert sich DefectDojo, den letzten verbleibenden aktiven Superuser zu deaktivieren, sodass die Provisionierung die Instanz nicht ohne Administrator zurücklassen kann. + +## Einschränkungen + +* Ein Identity Provider pro DefectDojo-Instanz. +* Filterung wird für `userName`, `displayName`, `externalId` und `id` mit einem einzelnen Gleichheitsvergleich unterstützt. Das deckt ab, was Okta und Entra beim Abgleich von Datensätzen senden. Komplexere Filter werden mit einer entsprechenden Fehlermeldung abgelehnt. +* Bulk-Operationen, Sortierung und der `/Me`-Endpunkt sind nicht implementiert. +* Gruppenmitgliedschaften werden über den Groups-Endpunkt verwaltet. Das Senden der Gruppenmitgliedschaft in einem Benutzerdatensatz hat keine Wirkung, was dem Verhalten beider Provider entspricht. + +## Fehlerbehebung + +**Der Verbindungstest meldet „not found".** SCIM ist deaktiviert, oder die Instanz ist nicht dafür lizenziert. Prüfen Sie, ob **Enable SCIM Provisioning** aktiviert ist und Ihr Abonnement SSO enthält. Solange nicht beides zutrifft, verhält sich die gesamte SCIM-Adresse so, als würde sie nicht existieren. + +**Der Verbindungstest meldet einen Authentifizierungsfehler.** Das Token ist falsch oder wurde widerrufen. Generieren Sie ein neues und aktualisieren Sie Ihren Identity Provider. Prüfen Sie in Okta, dass der Wert mit `Bearer ` und einem Leerzeichen beginnt; prüfen Sie in Entra, dass dies nicht der Fall ist. + +**Ein Benutzer kann nicht mit einer Fehlermeldung zum Benutzernamen provisioniert werden.** Der Benutzername enthält Zeichen, die DefectDojo nicht zulässt. Ändern Sie das Attribut, das Ihr Identity Provider auf `userName` mappt, meist auf die E-Mail-Adresse oder den User Principal Name des Benutzers. + +**Eine Gruppe kann nicht übertragen werden, mit der Meldung, dass eine Gruppe dieses Namens bereits existiert.** Eine DefectDojo-Gruppe mit diesem Namen wurde an anderer Stelle erstellt. Siehe [Gruppen](#groups) weiter oben. + +**Ein Gruppenmitglied kann nicht provisioniert werden.** Die Person wurde noch nicht für DefectDojo provisioniert. Weisen Sie sie der Anwendung zu; die Mitgliedschaft wird beim nächsten Zyklus erfolgreich übernommen. + +**Beginnen Sie mit Diagnostics.** Abgelehnte SCIM-Anfragen werden unter **Connect > Diagnostics** aufgezeichnet, mit dem Endpunkt, dem Status und der von DefectDojo zurückgesendeten Meldung. Das ist meist schneller, als das Log Ihres Identity Providers zu lesen, und es ist die einzige Stelle, die beide Seiten des Austauschs zeigt. Erfolgreiche Provisionierung wird dort nicht aufgezeichnet; Änderungen an Benutzern und Gruppen erscheinen stattdessen im Audit-Verlauf. + +**Alles meldet Erfolg, aber in DefectDojo erscheint nichts.** Prüfen Sie, dass die Tenant URL auf `/scim/v2` endet, ohne abschließenden Schrägstrich, und dass Ihr Identity Provider Ihre Instanz tatsächlich erreicht. Die Spalte **Last Used** im SCIM-Tokens-Panel zeigt, ob überhaupt eine Anfrage eingegangen ist. + +**DefectDojo-Pro-Benutzer:** Wenn Ihre Instanz den Zugriff nach IP-Adresse einschränkt, fügen Sie die Adressen Ihres Identity Providers vor der Konfiguration von SCIM zur Firewall-Allowlist hinzu. Siehe [Firewall-Regeln](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings). diff --git a/docs/content/admin/sso/PRO__scim.es.md b/docs/content/admin/sso/PRO__scim.es.md new file mode 100644 index 00000000000..bc53cc3b1f7 --- /dev/null +++ b/docs/content/admin/sso/PRO__scim.es.md @@ -0,0 +1,148 @@ +--- +title: Aprovisionamiento SCIM +description: Aprovisiona y desaprovisiona usuarios de DefectDojo Pro desde su proveedor + de identidad +weight: 19 +audience: pro +--- + +DefectDojo Pro admite SCIM 2.0, lo que permite que su proveedor de identidad cree, actualice y desactive usuarios de DefectDojo directamente. Sin esto, DefectDojo solo se entera de un usuario cuando ese usuario inicia sesión, por lo que eliminar a alguien de su proveedor de identidad detiene los inicios de sesión futuros pero deja su cuenta de DefectDojo activa. + +SCIM es independiente del inicio de sesión único y lo complementa. El SSO decide quién puede iniciar sesión; SCIM mantiene la lista de cuentas en sí sincronizada con su directorio. La mayoría de los clientes configuran ambos: SAML u OIDC para la autenticación, SCIM para el aprovisionamiento. + +La configuración de SCIM solo puede realizarla un **Superusuario**. + +## Qué hace SCIM en DefectDojo + +Cuando conecta un proveedor de identidad mediante SCIM, este puede: + +* crear usuarios de DefectDojo cuando se asigna la aplicación a alguien +* actualizar nombres y direcciones de correo electrónico cuando cambian en el directorio +* desactivar usuarios cuando se les retira la asignación o dejan la organización +* crear grupos, y agregar y eliminar sus miembros + +Desactivar un usuario mediante SCIM hace dos cosas a la vez. La cuenta se marca como inactiva, por lo que el usuario ya no puede iniciar sesión, y se eliminan los tokens de API de DefectDojo del usuario. Por lo tanto, la baja cierra ambas puertas en un solo paso, que es la razón principal para usar SCIM en lugar de depender únicamente de su proveedor de identidad. + +Se conserva el registro del usuario en sí. Los hallazgos, las notas y el historial hacen referencia a las personas que los crearon, por lo que DefectDojo desactiva la cuenta en lugar de eliminarla. Si la misma persona regresa, reactivarla mediante su proveedor de identidad restaura el acceso sin alterar ese historial. + +## Configuración + +1. Abra **Connect > Authorization** y seleccione **SCIM Provisioning**. SCIM aparece junto a sus proveedores de inicio de sesión porque se conecta al mismo proveedor de identidad, y está etiquetado como **Provisioning** para distinguirlo de los proveedores que colocan un botón en la página de inicio de sesión. + +2. Marque **Enable SCIM Provisioning** y envíe. Mientras esto esté desactivado, los endpoints de SCIM se comportan como si no existieran, por lo que una prueba de conexión desde su proveedor de identidad reporta la dirección como no encontrada. + +3. Copie la **Tenant URL** que se muestra en la página. Se ve así: + + ``` + https://.cloud.defectdojo.com/scim/v2 + ``` + +4. En el panel **SCIM Tokens**, asigne al token un nombre que indique dónde se usará, por ejemplo "Okta production", y luego seleccione **Generate Token**. + +5. Copie el token del cuadro de diálogo y péguelo en su proveedor de identidad. DefectDojo solo almacena un hash del token, por lo que no se puede volver a mostrar. Si lo pierde, genere otro y revoque el anterior. + +Puede mantener más de un token activo a la vez. Para rotarlos, genere un token nuevo, actualice su proveedor de identidad y luego revoque el anterior. No hay ninguna ventana en la que el aprovisionamiento deje de funcionar. + +El panel de tokens registra cuándo se usó cada token por última vez, lo cual es una forma rápida de confirmar que su proveedor de identidad realmente está llegando a DefectDojo. + +## Okta + +1. En Okta Admin Console, vaya a **Applications > Browse App Catalog** y agregue **SCIM 2.0 Test App (Header Auth)**. Si ya tiene una aplicación SAML para DefectDojo, puede habilitar el aprovisionamiento en esa aplicación en su lugar. + +2. Abra la pestaña **Provisioning** y seleccione **Configure API Integration**. + +3. Establezca **SCIM 2.0 Base Url** en la Tenant URL que copió anteriormente. + +4. Establezca **API Token** en `Bearer `, incluida la palabra `Bearer` y un único espacio. Este tipo de aplicación envía el valor literalmente como encabezado de Authorization. + +5. Seleccione **Test API Credentials** y luego guarde. + +6. En **Provisioning > To App**, habilite **Create Users**, **Update User Attributes** y **Deactivate Users**. + +7. Asigne personas o grupos a la aplicación. Okta busca primero a cada persona en DefectDojo por nombre de usuario y solo crea una cuenta cuando no encuentra ninguna, por lo que cualquiera que ya tenga una cuenta de DefectDojo se vincula en lugar de duplicarse. + +Para enviar también grupos, abra la pestaña **Push Groups** y agregue los grupos que desea que DefectDojo refleje. Consulte [Grupos](#groups) más abajo para saber qué hace DefectDojo con ellos. + +## Microsoft Entra ID + +1. En el centro de administración de Entra, vaya a **Enterprise applications > New application > Create your own application**, y elija la opción "non-gallery". Si ya tiene una aplicación para DefectDojo, use esa. + +2. Abra **Provisioning** y establezca **Provisioning Mode** en **Automatic**. + +3. Establezca **Tenant URL** en la Tenant URL que copió anteriormente. + +4. Establezca **Secret Token** en su token de SCIM. Entra lo envía como token bearer, por lo que no agregue aquí la palabra `Bearer`. + +5. Seleccione **Test Connection** y luego guarde. + +6. Asigne usuarios y grupos en **Users and groups**, e inicie el aprovisionamiento. + +Entra aprovisiona en un ciclo de aproximadamente 40 minutos. Mientras configura todo, **Provision on demand** aplica un solo usuario o grupo de inmediato, lo que hace mucho más rápido confirmar que la configuración funciona. + +## Qué almacena DefectDojo + +DefectDojo asigna un pequeño conjunto de atributos SCIM e ignora el resto. + +| SCIM attribute | DefectDojo field | +|---|---| +| `userName` | Nombre de usuario | +| `name.givenName` | Nombre | +| `name.familyName` | Apellido | +| `emails` | Dirección de correo electrónico | +| `active` | Si la cuenta está habilitada | +| `externalId` | Se conserva para que su proveedor de identidad pueda hacer coincidir el registro más adelante | + +Los atributos que DefectDojo no modela, incluidos los números de teléfono, los cargos y la extensión empresarial de SCIM, se aceptan y se ignoran en lugar de rechazarse. Asignar atributos adicionales en su proveedor de identidad es inofensivo. + +Dos atributos merecen especial atención: + +**Nombre de usuario.** DefectDojo permite letras, dígitos y los caracteres `@ . + - _` en un nombre de usuario. Si su proveedor de identidad envía un nombre de usuario que contiene cualquier otra cosa, DefectDojo rechaza a ese usuario con un error que indica el problema, en lugar de almacenar silenciosamente un nombre de usuario diferente. Almacenar un nombre de usuario alterado impediría que su proveedor pudiera encontrar la cuenta más adelante. + +**Dirección de correo electrónico.** SCIM no requiere una, y DefectDojo creará el usuario sin ella. Tenga en cuenta que las notificaciones de DefectDojo, incluidos los informes programados y las alertas, no tienen adónde ir para un usuario sin dirección de correo electrónico. Asigne el atributo `emails` a menos que tenga una razón para no hacerlo. + +SCIM nunca establece contraseñas, ni otorga nunca el estado de superusuario o de staff. Si su proveedor de identidad está configurado para enviar contraseñas, DefectDojo las ignora. Los usuarios aprovisionados de esta manera inician sesión mediante SSO. + +## Grupos + +SCIM gestiona solo los grupos que creó. Los grupos que usted creó en la interfaz de DefectDojo, o que llegaron mediante la asignación de grupos de SAML o Azure AD, son invisibles para SCIM y su proveedor de identidad no puede renombrarlos, vaciarlos ni eliminarlos. + +Esto importa porque el envío de grupos es, por naturaleza, un reemplazo completo. Si un proveedor de identidad pudiera adoptar un grupo existente, su próxima sincronización reemplazaría la membresía cuidadosamente elegida de ese grupo por lo que contenga el directorio. Por lo tanto, enviar un grupo cuyo nombre ya está en uso falla con un mensaje que explica el conflicto. Para entregar un grupo existente a su proveedor de identidad, renombre uno de los dos, o elimine el grupo de DefectDojo y deje que el proveedor lo vuelva a crear. + +Dentro de un grupo gestionado por SCIM, la membresía pertenece a su proveedor de identidad y los roles pertenecen a DefectDojo: + +* A un miembro recién agregado se le asigna el rol **Reader**. +* Si asciende a alguien a un rol superior en DefectDojo, las sincronizaciones posteriores dejan ese rol sin cambios. +* Cualquier persona agregada manualmente a un grupo gestionado por SCIM se elimina en la siguiente sincronización, porque el proveedor de identidad es la fuente de verdad sobre quién pertenece. + +Eliminar un grupo mediante SCIM elimina el grupo y sus membresías. Nunca elimina a las personas que estaban en él. + +## Protección del acceso de administrador + +Por defecto, SCIM no desactivará una cuenta de superusuario. El fallo común en cualquier configuración de aprovisionamiento es un proveedor de identidad con un alcance más amplio del previsto, y los superusuarios son la forma de volver a entrar en DefectDojo cuando algo sale mal. + +Si desea que su proveedor de identidad también gestione superusuarios, habilite **Allow SCIM to deactivate superusers** en la página de configuración de SCIM. Aun así, DefectDojo se niega a desactivar el último superusuario activo restante, por lo que el aprovisionamiento no puede dejar la instancia sin un administrador. + +## Limitaciones + +* Un proveedor de identidad por instancia de DefectDojo. +* El filtrado es compatible en `userName`, `displayName`, `externalId` e `id`, usando una única comparación de igualdad. Esto cubre lo que envían Okta y Entra cuando hacen coincidir registros. Los filtros más complejos se rechazan con un error que lo indica. +* Las operaciones masivas, la ordenación y el endpoint `/Me` no están implementados. +* Las membresías de grupo se gestionan mediante el endpoint Groups. Enviar la membresía de grupo en un registro de usuario no tiene efecto, lo cual coincide con el comportamiento de ambos proveedores. + +## Solución de problemas + +**La prueba de conexión reporta "not found".** SCIM está desactivado, o la instancia no tiene licencia para él. Verifique que **Enable SCIM Provisioning** esté activado y que su suscripción incluya SSO. Toda la dirección de SCIM se comporta como si no existiera hasta que ambas condiciones se cumplan. + +**La prueba de conexión reporta un error de autenticación.** El token es incorrecto, o se ha revocado. Genere uno nuevo y actualice su proveedor de identidad. En Okta, verifique que el valor comience con `Bearer ` y un espacio; en Entra, verifique que no sea así. + +**Un usuario no logra aprovisionarse con un error sobre el nombre de usuario.** El nombre de usuario contiene caracteres que DefectDojo no permite. Cambie el atributo que su proveedor de identidad asigna a `userName`, normalmente a la dirección de correo electrónico del usuario o al nombre principal de usuario. + +**Un grupo no logra enviarse, reportando que ya existe un grupo con ese nombre.** Se creó un grupo de DefectDojo con ese nombre en otro lugar. Consulte [Grupos](#groups) más arriba. + +**Un miembro de grupo no logra aprovisionarse.** La persona aún no ha sido aprovisionada en DefectDojo. Asígnela a la aplicación, y la membresía se completará en el siguiente ciclo. + +**Comience con Diagnostics.** Las solicitudes SCIM rechazadas se registran en **Connect > Diagnostics**, con el endpoint, el estado y el mensaje que envió DefectDojo. Esto suele ser más rápido que leer el registro de su proveedor de identidad, y es el único lugar que muestra ambos lados del intercambio. El aprovisionamiento exitoso no se registra allí; los cambios en usuarios y grupos aparecen en el historial de auditoría en su lugar. + +**Todo reporta éxito, pero nada aparece en DefectDojo.** Verifique que la Tenant URL termine en `/scim/v2` sin barra diagonal final, y que su proveedor de identidad realmente esté llegando a su instancia. La columna **Last Used** en el panel de SCIM Tokens muestra si ha llegado alguna solicitud. + +**Usuarios de DefectDojo Pro:** si su instancia restringe el acceso por dirección IP, agregue las direcciones de su proveedor de identidad a la lista blanca del firewall antes de configurar SCIM. Consulte [Reglas de firewall](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings). diff --git a/docs/content/admin/sso/PRO__scim.fr.md b/docs/content/admin/sso/PRO__scim.fr.md new file mode 100644 index 00000000000..05b1c853a49 --- /dev/null +++ b/docs/content/admin/sso/PRO__scim.fr.md @@ -0,0 +1,148 @@ +--- +title: Provisionnement SCIM +description: Provisionnez et déprovisionnez les utilisateurs de DefectDojo Pro depuis + votre fournisseur d'identité +weight: 19 +audience: pro +--- + +DefectDojo Pro prend en charge SCIM 2.0, ce qui permet à votre fournisseur d'identité de créer, mettre à jour et désactiver directement les utilisateurs DefectDojo. Sans cela, DefectDojo ne découvre un utilisateur que lorsque celui-ci se connecte ; supprimer quelqu'un de votre fournisseur d'identité empêche donc les connexions futures mais laisse son compte DefectDojo actif. + +SCIM est distinct de l'authentification unique (SSO) et la complète. Le SSO détermine qui peut se connecter ; SCIM maintient la liste des comptes elle-même synchronisée avec votre annuaire. La plupart des clients configurent les deux : SAML ou OIDC pour l'authentification, SCIM pour le provisionnement. + +La configuration de SCIM ne peut être effectuée que par un **Superuser**. + +## Ce que SCIM fait dans DefectDojo + +Lorsque vous connectez un fournisseur d'identité via SCIM, celui-ci peut : + +* créer des utilisateurs DefectDojo lorsqu'une personne se voit attribuer l'application +* mettre à jour les noms et adresses e-mail lorsqu'ils changent dans l'annuaire +* désactiver les utilisateurs lorsqu'ils ne sont plus attribués ou quittent l'organisation +* créer des groupes, et ajouter ou supprimer leurs membres + +La désactivation d'un utilisateur via SCIM effectue deux actions à la fois. Le compte est marqué comme inactif, de sorte que l'utilisateur ne peut plus se connecter, et les jetons API DefectDojo de l'utilisateur sont supprimés. Le départ d'un utilisateur ferme donc les deux portes en une seule étape, ce qui est la principale raison d'utiliser SCIM plutôt que de se fier uniquement à votre fournisseur d'identité. + +La fiche utilisateur elle-même est conservée. Les Constatations, notes et historiques font référence aux personnes qui les ont créés ; DefectDojo désactive donc le compte plutôt que de le supprimer. Si la même personne revient, la réactiver via votre fournisseur d'identité restaure l'accès sans perturber cet historique. + +## Configuration + +1. Ouvrez **Connect > Authorization** et sélectionnez **SCIM Provisioning**. SCIM figure aux côtés de vos fournisseurs de connexion car il se connecte au même fournisseur d'identité, et est étiqueté **Provisioning** pour le distinguer des fournisseurs qui ajoutent un bouton sur la page de connexion. + +2. Cochez **Enable SCIM Provisioning** et envoyez le formulaire. Tant que cette option est désactivée, les points de terminaison SCIM se comportent comme s'ils n'existaient pas ; un test de connexion depuis votre fournisseur d'identité signale donc que l'adresse est introuvable. + +3. Copiez la **Tenant URL** affichée sur la page. Elle se présente ainsi : + + ``` + https://.cloud.defectdojo.com/scim/v2 + ``` + +4. Dans le panneau **SCIM Tokens**, donnez au jeton un nom indiquant où il sera utilisé, par exemple « Okta production », puis sélectionnez **Generate Token**. + +5. Copiez le jeton depuis la boîte de dialogue et collez-le dans votre fournisseur d'identité. DefectDojo ne stocke qu'un hachage du jeton, qui ne peut donc plus être réaffiché. Si vous le perdez, générez-en un autre et révoquez l'ancien. + +Vous pouvez conserver plusieurs jetons actifs simultanément. Pour effectuer une rotation, générez un nouveau jeton, mettez à jour votre fournisseur d'identité, puis révoquez l'ancien. Il n'y a aucune période pendant laquelle le provisionnement cesse de fonctionner. + +Le panneau des jetons enregistre la dernière utilisation de chaque jeton, ce qui permet de vérifier rapidement que votre fournisseur d'identité atteint bien DefectDojo. + +## Okta + +1. Dans la console d'administration Okta, accédez à **Applications > Browse App Catalog** et ajoutez **SCIM 2.0 Test App (Header Auth)**. Si vous avez déjà une application SAML pour DefectDojo, vous pouvez activer le provisionnement sur cette application à la place. + +2. Ouvrez l'onglet **Provisioning** et sélectionnez **Configure API Integration**. + +3. Définissez **SCIM 2.0 Base Url** avec la Tenant URL copiée ci-dessus. + +4. Définissez **API Token** avec `Bearer `, en incluant le mot `Bearer` et un seul espace. Ce type d'application envoie la valeur telle quelle dans l'en-tête Authorization. + +5. Sélectionnez **Test API Credentials**, puis enregistrez. + +6. Sous **Provisioning > To App**, activez **Create Users**, **Update User Attributes** et **Deactivate Users**. + +7. Attribuez des personnes ou des groupes à l'application. Okta recherche d'abord chaque personne dans DefectDojo par nom d'utilisateur et ne crée un compte que s'il n'en trouve aucun ; toute personne disposant déjà d'un compte DefectDojo est donc liée plutôt que dupliquée. + +Pour également pousser des groupes, ouvrez l'onglet **Push Groups** et ajoutez les groupes que vous voulez que DefectDojo reproduise. Voir [Groupes](#groups) ci-dessous pour savoir ce que DefectDojo en fait. + +## Microsoft Entra ID + +1. Dans le centre d'administration Entra, accédez à **Enterprise applications > New application > Create your own application**, et choisissez l'option non-gallery. Si vous avez déjà une application pour DefectDojo, utilisez celle-ci. + +2. Ouvrez **Provisioning** et définissez **Provisioning Mode** sur **Automatic**. + +3. Définissez **Tenant URL** avec la Tenant URL copiée ci-dessus. + +4. Définissez **Secret Token** avec votre jeton SCIM. Entra l'envoie sous forme de jeton bearer ; n'ajoutez donc pas le mot `Bearer` ici. + +5. Sélectionnez **Test Connection**, puis enregistrez. + +6. Attribuez des utilisateurs et des groupes sous **Users and groups**, puis démarrez le provisionnement. + +Entra provisionne selon un cycle d'environ 40 minutes. Pendant la configuration, **Provision on demand** applique immédiatement un seul utilisateur ou groupe, ce qui permet de vérifier bien plus rapidement que la configuration fonctionne. + +## Ce que DefectDojo stocke + +DefectDojo associe un petit ensemble d'attributs SCIM et ignore le reste. + +| Attribut SCIM | Champ DefectDojo | +|---|---| +| `userName` | Username | +| `name.givenName` | First name | +| `name.familyName` | Last name | +| `emails` | Email address | +| `active` | Indique si le compte est activé | +| `externalId` | Conservé pour que votre fournisseur d'identité puisse retrouver la fiche ultérieurement | + +Les attributs que DefectDojo ne modélise pas, notamment les numéros de téléphone, les intitulés de poste et l'extension enterprise de SCIM, sont acceptés et ignorés plutôt que rejetés. Mapper des attributs supplémentaires dans votre fournisseur d'identité est sans danger. + +Deux attributs méritent une attention particulière : + +**Username.** DefectDojo autorise les lettres, les chiffres et les caractères `@ . + - _` dans un nom d'utilisateur. Si votre fournisseur d'identité envoie un nom d'utilisateur contenant autre chose, DefectDojo rejette cet utilisateur avec une erreur nommant le problème plutôt que de stocker discrètement un nom d'utilisateur différent. Stocker un nom d'utilisateur modifié empêcherait ensuite votre fournisseur de retrouver le compte. + +**Email address.** SCIM ne l'exige pas, et DefectDojo créera l'utilisateur sans elle. Gardez à l'esprit que les notifications DefectDojo, y compris les rapports planifiés et les alertes, n'ont nulle part où aller pour un utilisateur sans adresse e-mail. Mappez l'attribut `emails` sauf raison contraire. + +SCIM ne définit jamais de mots de passe et n'accorde jamais de statut superuser ou staff. Si votre fournisseur d'identité est configuré pour envoyer des mots de passe, DefectDojo les ignore. Les utilisateurs provisionnés de cette manière se connectent via le SSO. + +## Groupes + +SCIM ne gère que les groupes qu'il a créés. Les groupes que vous avez créés dans l'interface DefectDojo, ou qui proviennent d'un mappage de groupes SAML ou Azure AD, sont invisibles pour SCIM et ne peuvent pas être renommés, vidés ou supprimés par votre fournisseur d'identité. + +Cela importe car le push de groupe est par nature un remplacement complet. Si un fournisseur d'identité pouvait adopter un groupe existant, sa prochaine synchronisation remplacerait la composition soigneusement choisie de ce groupe par le contenu de l'annuaire. Pousser un groupe dont le nom est déjà pris échoue donc avec un message expliquant le conflit. Pour confier un groupe existant à votre fournisseur d'identité, renommez l'un des deux, ou supprimez le groupe DefectDojo et laissez le fournisseur le recréer. + +Au sein d'un groupe géré par SCIM, l'appartenance appartient à votre fournisseur d'identité et les rôles appartiennent à DefectDojo : + +* Un membre nouvellement ajouté se voit attribuer le rôle **Reader**. +* Si vous promouvez quelqu'un à un rôle supérieur dans DefectDojo, les synchronisations suivantes laissent ce rôle inchangé. +* Toute personne ajoutée manuellement à un groupe géré par SCIM est supprimée lors de la synchronisation suivante, car le fournisseur d'identité fait foi pour déterminer qui en fait partie. + +Supprimer un groupe via SCIM supprime le groupe et ses appartenances. Cela ne supprime jamais les personnes qui en faisaient partie. + +## Protection de l'accès administrateur + +Par défaut, SCIM ne désactivera pas un compte superuser. Le problème courant dans toute configuration de provisionnement est un fournisseur d'identité dont le périmètre est plus large que prévu, et les superusers constituent le moyen de retrouver l'accès à DefectDojo lorsque quelque chose tourne mal. + +Si vous voulez que votre fournisseur d'identité gère aussi les superusers, activez **Allow SCIM to deactivate superusers** sur la page des paramètres SCIM. Même dans ce cas, DefectDojo refuse de désactiver le dernier superuser actif restant, afin que le provisionnement ne puisse pas laisser l'instance sans administrateur. + +## Limitations + +* Un seul fournisseur d'identité par instance DefectDojo. +* Le filtrage est pris en charge sur `userName`, `displayName`, `externalId` et `id`, à l'aide d'une seule comparaison d'égalité. Cela couvre ce qu'Okta et Entra envoient lorsqu'ils font correspondre des fiches. Les filtres plus complexes sont rejetés avec une erreur qui l'indique. +* Les opérations en masse, le tri et le point de terminaison `/Me` ne sont pas implémentés. +* Les appartenances aux groupes sont gérées via le point de terminaison Groups. Envoyer une appartenance de groupe sur une fiche utilisateur n'a aucun effet, ce qui correspond au comportement des deux fournisseurs. + +## Dépannage + +**Le test de connexion signale « not found ».** SCIM est désactivé, ou l'instance n'est pas licenciée pour cela. Vérifiez que **Enable SCIM Provisioning** est activé et que votre abonnement inclut le SSO. L'ensemble de l'adresse SCIM se comporte comme si elle n'existait pas tant que les deux conditions ne sont pas réunies. + +**Le test de connexion signale un échec d'authentification.** Le jeton est incorrect, ou il a été révoqué. Générez-en un nouveau et mettez à jour votre fournisseur d'identité. Dans Okta, vérifiez que la valeur commence par `Bearer ` et un espace ; dans Entra, vérifiez que ce n'est pas le cas. + +**Un utilisateur ne parvient pas à être provisionné, avec une erreur concernant le nom d'utilisateur.** Le nom d'utilisateur contient des caractères que DefectDojo n'autorise pas. Modifiez l'attribut que votre fournisseur d'identité mappe sur `userName`, le plus souvent vers l'adresse e-mail de l'utilisateur ou son user principal name. + +**Un groupe ne parvient pas à être poussé, avec un message indiquant qu'un groupe de ce nom existe déjà.** Un groupe DefectDojo portant ce nom a été créé ailleurs. Voir [Groupes](#groups) ci-dessus. + +**Un membre de groupe ne parvient pas à être provisionné.** La personne n'a pas encore été provisionnée dans DefectDojo. Attribuez-lui l'application, et l'appartenance réussira lors du cycle suivant. + +**Commencez par Diagnostics.** Les requêtes SCIM refusées sont enregistrées sous **Connect > Diagnostics**, avec le point de terminaison, le statut et le message renvoyé par DefectDojo. C'est généralement plus rapide que de lire le journal de votre fournisseur d'identité, et c'est le seul endroit qui montre les deux côtés de l'échange. Le provisionnement réussi n'y est pas enregistré ; les modifications apportées aux utilisateurs et aux groupes apparaissent dans l'historique d'audit. + +**Tout est signalé comme réussi, mais rien n'apparaît dans DefectDojo.** Vérifiez que la Tenant URL se termine par `/scim/v2` sans barre oblique finale, et que votre fournisseur d'identité atteint bien votre instance. La colonne **Last Used** du panneau SCIM Tokens indique si une requête est déjà arrivée. + +**Utilisateurs DefectDojo Pro :** si votre instance restreint l'accès par adresse IP, ajoutez les adresses de votre fournisseur d'identité à la liste blanche du pare-feu avant de configurer SCIM. Voir [Règles de pare-feu](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings). diff --git a/docs/content/admin/sso/PRO__scim.ja.md b/docs/content/admin/sso/PRO__scim.ja.md new file mode 100644 index 00000000000..a52ff103652 --- /dev/null +++ b/docs/content/admin/sso/PRO__scim.ja.md @@ -0,0 +1,147 @@ +--- +title: SCIM プロビジョニング +description: ID プロバイダーから DefectDojo Pro ユーザーをプロビジョニングおよびデプロビジョニングする +weight: 19 +audience: pro +--- + +DefectDojo Pro は SCIM 2.0 をサポートしており、ID プロバイダーから DefectDojo ユーザーを直接作成、更新、無効化できます。SCIM がない場合、DefectDojo はユーザーがサインインしたときにのみそのユーザーの存在を把握するため、ID プロバイダーから誰かを削除しても以降のログインは止まりますが、DefectDojo のアカウント自体は有効なまま残ります。 + +SCIM はシングルサインオンとは別の仕組みであり、それを補完します。SSO は誰がサインインできるかを決定し、SCIM はアカウント一覧自体をディレクトリと同期させます。ほとんどの顧客は両方を設定します。認証には SAML または OIDC を、プロビジョニングには SCIM を使用します。 + +SCIM の設定は **Superuser** のみが行えます。 + +## What SCIM does in DefectDojo + +SCIM 経由で ID プロバイダーを接続すると、次のことが可能になります。 + +* アプリケーションが割り当てられたときに DefectDojo ユーザーを作成する +* ディレクトリで名前やメールアドレスが変更されたときに更新する +* 割り当てが解除されたり組織を離れたりしたユーザーを無効化する +* グループを作成し、そのメンバーの追加や削除を行う + +SCIM 経由でユーザーを無効化すると、同時に 2 つのことが行われます。アカウントが非アクティブとしてマークされ、ユーザーはサインインできなくなり、そのユーザーの DefectDojo API トークンが削除されます。そのため、オフボーディングは 1 つの操作で両方の入り口を閉じることができ、これが ID プロバイダーだけに頼るのではなく SCIM を使用する主な理由です。 + +ユーザーレコード自体は保持されます。検出事項、メモ、履歴はそれらを作成した人物を参照しているため、DefectDojo はアカウントを削除するのではなく無効化します。同じ人物が戻ってきた場合、ID プロバイダー経由で再度有効化すれば、履歴を乱すことなくアクセスを復元できます。 + +## Setup + +1. **Connect > Authorization** を開き、**SCIM Provisioning** を選択します。SCIM は同じ ID プロバイダーに接続するため、ログインプロバイダーと並んで表示され、ログインページにボタンを追加するプロバイダーと区別するために **Provisioning** というタグが付けられています。 + +2. **Enable SCIM Provisioning** をチェックして送信します。これがオフの間、SCIM のエンドポイントは存在しないかのように振る舞うため、ID プロバイダーからの接続テストではアドレスが見つからないと報告されます。 + +3. ページに表示されている **Tenant URL** をコピーします。次のような形式です。 + + ``` + https://.cloud.defectdojo.com/scim/v2 + ``` + +4. **SCIM Tokens** パネルで、たとえば「Okta production」のように、どこで使用するかがわかる名前をトークンに付け、**Generate Token** を選択します。 + +5. ダイアログに表示されたトークンをコピーし、ID プロバイダーに貼り付けます。DefectDojo はトークンのハッシュのみを保存するため、再度表示することはできません。トークンを紛失した場合は、新しいトークンを生成し、古いトークンを失効させてください。 + +複数のトークンを同時に有効な状態で保持できます。ローテーションするには、新しいトークンを生成して ID プロバイダーを更新し、その後古いトークンを失効させます。プロビジョニングが機能しなくなる期間はありません。 + +トークンパネルには各トークンが最後に使用された日時が記録されており、ID プロバイダーが実際に DefectDojo に到達しているかどうかを手早く確認できます。 + +## Okta + +1. Okta の管理コンソールで、**Applications > Browse App Catalog** に移動し、**SCIM 2.0 Test App (Header Auth)** を追加します。すでに DefectDojo 用の SAML アプリケーションがある場合は、代わりにそのアプリケーションでプロビジョニングを有効にできます。 + +2. **Provisioning** タブを開き、**Configure API Integration** を選択します。 + +3. **SCIM 2.0 Base Url** に、上でコピーした Tenant URL を設定します。 + +4. **API Token** に、`Bearer` という単語と半角スペース 1 つを含めて `Bearer ` を設定します。このアプリケーションタイプは、値をそのまま Authorization ヘッダーとして送信します。 + +5. **Test API Credentials** を選択し、保存します。 + +6. **Provisioning > To App** で、**Create Users**、**Update User Attributes**、**Deactivate Users** を有効にします。 + +7. 人物またはグループをアプリケーションに割り当てます。Okta はまず DefectDojo 内でユーザー名により各人物を検索し、見つからない場合にのみアカウントを作成するため、すでに DefectDojo アカウントを持っている人物が重複作成されることはなく、既存のアカウントにリンクされます。 + +グループもプッシュするには、**Push Groups** タブを開き、DefectDojo にミラーリングさせたいグループを追加します。DefectDojo がそれらのグループをどのように扱うかについては、下記の [Groups](#groups) を参照してください。 + +## Microsoft Entra ID + +1. Entra の管理センターで、**Enterprise applications > New application > Create your own application** に移動し、non-gallery のオプションを選択します。すでに DefectDojo 用のアプリケーションがある場合は、それを使用してください。 + +2. **Provisioning** を開き、**Provisioning Mode** を **Automatic** に設定します。 + +3. **Tenant URL** に、上でコピーした Tenant URL を設定します。 + +4. **Secret Token** に SCIM トークンを設定します。Entra はこれをベアラートークンとして送信するため、ここに `Bearer` という単語を追加しないでください。 + +5. **Test Connection** を選択し、保存します。 + +6. **Users and groups** でユーザーとグループを割り当て、プロビジョニングを開始します。 + +Entra は約 40 分周期でプロビジョニングを行います。設定作業中は、**Provision on demand** を使用すると単一のユーザーまたはグループを即座に適用できるため、設定が正しく機能しているかをはるかに素早く確認できます。 + +## What DefectDojo stores + +DefectDojo は少数の SCIM 属性のみをマッピングし、それ以外は無視します。 + +| SCIM attribute | DefectDojo field | +|---|---| +| `userName` | Username | +| `name.givenName` | First name | +| `name.familyName` | Last name | +| `emails` | Email address | +| `active` | アカウントが有効かどうか | +| `externalId` | ID プロバイダーが後でレコードを照合できるように保持されます | + +電話番号、役職、SCIM のエンタープライズ拡張など、DefectDojo がモデル化していない属性は、拒否されるのではなく受け入れられて無視されます。ID プロバイダー側で余分な属性をマッピングしても問題ありません。 + +特に注意すべき属性が 2 つあります。 + +**Username。** DefectDojo は、ユーザー名に文字、数字、および `@ . + - _` の文字を許可します。ID プロバイダーがそれ以外の文字を含むユーザー名を送信すると、DefectDojo は別のユーザー名を黙って保存するのではなく、問題を示すエラーとともにそのユーザーを拒否します。変更されたユーザー名を保存してしまうと、後で ID プロバイダーがアカウントを見つけられなくなってしまいます。 + +**Email address。** SCIM ではメールアドレスは必須ではなく、DefectDojo はメールアドレスなしでもユーザーを作成します。ただし、スケジュールされたレポートやアラートを含む DefectDojo の通知は、メールアドレスのないユーザーには送り先がなくなる点に注意してください。特別な理由がない限り、`emails` 属性はマッピングしてください。 + +SCIM がパスワードを設定することはなく、superuser や staff のステータスを付与することもありません。ID プロバイダーがパスワードを送信するように設定されていても、DefectDojo はそれを無視します。この方法でプロビジョニングされたユーザーは SSO 経由でサインインします。 + +## Groups + +SCIM は自身が作成したグループのみを管理します。DefectDojo の UI で作成したグループや、SAML や Azure AD のグループマッピング経由で届いたグループは SCIM からは見えず、ID プロバイダーによって名前を変更したり、空にしたり、削除したりすることはできません。 + +これが重要なのは、グループのプッシュが本質的に完全な置き換えだからです。もし ID プロバイダーが既存のグループを引き継げてしまうと、次回の同期でそのグループの慎重に選ばれたメンバーシップが、ディレクトリの内容にそのまま置き換えられてしまいます。そのため、すでに使用されている名前のグループをプッシュすると、競合を説明するメッセージとともに失敗します。既存のグループを ID プロバイダーに引き渡すには、どちらか一方の名前を変更するか、DefectDojo 側のグループを削除してプロバイダーに再作成させてください。 + +SCIM が管理するグループ内では、メンバーシップは ID プロバイダーに属し、ロールは DefectDojo に属します。 + +* 新しく追加されたメンバーには **Reader** ロールが与えられます。 +* DefectDojo で誰かをより上位のロールに昇格させた場合、その後の同期でそのロールが変更されることはありません。 +* SCIM が管理するグループに手動で追加された人物は、次回の同期で削除されます。誰が所属すべきかについては ID プロバイダーが正となるためです。 + +SCIM 経由でグループを削除すると、そのグループとメンバーシップが削除されます。所属していた人物自体が削除されることはありません。 + +## Protecting administrator access + +デフォルトでは、SCIM は superuser アカウントを無効化しません。プロビジョニング設定でよくある失敗は、ID プロバイダーの適用範囲が意図したより広くなってしまうことであり、superuser は何か問題が起きたときに DefectDojo に再びアクセスするための手段です。 + +ID プロバイダーに superuser も管理させたい場合は、SCIM 設定ページで **Allow SCIM to deactivate superusers** を有効にします。それでも、DefectDojo は残っている最後のアクティブな superuser を無効化することを拒否するため、プロビジョニングによってインスタンスに管理者が一人もいなくなることはありません。 + +## Limitations + +* DefectDojo インスタンスごとに ID プロバイダーは 1 つのみです。 +* フィルタリングは `userName`、`displayName`、`externalId`、`id` に対して、単一の等価比較でサポートされています。これは Okta と Entra がレコードを照合する際に送信する内容をカバーしています。より複雑なフィルターは、その旨を示すエラーとともに拒否されます。 +* 一括操作、ソート、`/Me` エンドポイントは実装されていません。 +* グループメンバーシップは Groups エンドポイント経由で管理されます。ユーザーレコードにグループメンバーシップを送信しても効果はなく、これは両プロバイダーの動作と一致しています。 + +## Troubleshooting + +**接続テストで「not found」と表示される。** SCIM がオフになっているか、インスタンスがそのライセンスを持っていません。**Enable SCIM Provisioning** がオンになっていること、およびサブスクリプションに SSO が含まれていることを確認してください。両方が満たされるまで、SCIM のアドレス全体が存在しないかのように振る舞います。 + +**接続テストで認証エラーが表示される。** トークンが間違っているか、失効しています。新しいトークンを生成し、ID プロバイダーを更新してください。Okta の場合は値が `Bearer ` とスペースで始まっていることを確認し、Entra の場合はそうなっていないことを確認してください。 + +**ユーザー名に関するエラーでユーザーのプロビジョニングが失敗する。** ユーザー名に DefectDojo が許可していない文字が含まれています。ID プロバイダーが `userName` にマッピングしている属性を変更してください。多くの場合、ユーザーのメールアドレスまたはユーザープリンシパル名に変更します。 + +**その名前のグループがすでに存在すると報告され、グループのプッシュが失敗する。** その名前の DefectDojo グループが他の場所で作成されています。上記の [Groups](#groups) を参照してください。 + +**グループメンバーのプロビジョニングが失敗する。** その人物がまだ DefectDojo にプロビジョニングされていません。アプリケーションに割り当てれば、次のサイクルでメンバーシップが成功します。 + +**まず Diagnostics を確認してください。** 拒否された SCIM リクエストは、エンドポイント、ステータス、DefectDojo が返したメッセージとともに **Connect > Diagnostics** に記録されます。通常、ID プロバイダーのログを読むより速く確認でき、やり取りの両側を確認できる唯一の場所です。成功したプロビジョニングはここには記録されず、ユーザーやグループの変更は代わりに監査履歴に表示されます。 + +**すべて成功と表示されるのに、DefectDojo に何も反映されない。** Tenant URL が末尾にスラッシュを付けずに `/scim/v2` で終わっていること、および ID プロバイダーが実際にインスタンスに到達していることを確認してください。SCIM Tokens パネルの **Last Used** 列で、リクエストが届いているかどうかを確認できます。 + +**DefectDojo Pro をご利用の場合:** インスタンスが IP アドレスによるアクセス制限を行っている場合は、SCIM を設定する前に、ID プロバイダーのアドレスをファイアウォールの許可リストに追加してください。詳細は [Firewall Rules](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings) を参照してください。 diff --git a/docs/content/admin/sso/_index.de.md b/docs/content/admin/sso/_index.de.md new file mode 100644 index 00000000000..96f97d9ae56 --- /dev/null +++ b/docs/content/admin/sso/_index.de.md @@ -0,0 +1,76 @@ +--- +title: Single Sign-On +description: DefectDojo Pro unterstützt SAML und eine Reihe von OAuth-Anbietern für + Single Sign-On +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2026-04-30 00:00:00+00:00 +draft: false +weight: 8 +collapsed: true +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +aliases: +- /de/admin/user_management/configure_sso/ +- /de/admin/sso/os__saml/ +- /de/admin/sso/os__auth0/ +- /de/admin/sso/os__azure_ad/ +- /de/admin/sso/os__github_enterprise/ +- /de/admin/sso/os__gitlab/ +- /de/admin/sso/os__google/ +- /de/admin/sso/os__keycloak/ +- /de/admin/sso/os__oidc/ +- /de/admin/sso/os__okta/ +- /de/admin/sso/os__remote_user/ +--- + +Single Sign-On ist eine Funktion von **DefectDojo Pro**. Seit DefectDojo 3.0 ist der SSO-Funktionsumfang – SAML, OIDC und die mitgelieferten OAuth-Provider – nur in DefectDojo Pro verfügbar. Open-Source-DefectDojo verwendet die lokale Benutzername/Passwort-Anmeldung und den Passwort-Reset-Ablauf. + +Wenn Sie Open-Source-DefectDojo betreiben und SSO nutzen möchten, müssen Sie zu [DefectDojo Pro](https://defectdojo.com) wechseln; die Migration wird in den [3.0-Upgrade-Hinweisen](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only) beschrieben. Bestehende Benutzerkonten und Gruppenmitgliedschaften bleiben beim Upgrade erhalten. Informationen zur Zugriffskontrolle in Open-Source-DefectDojo finden Sie auf der Seite [Autorisierte Benutzer](/admin/user_management/os__authorized_users/). + +## Anzeigen der aktuellen Konfiguration + +**[Authorization Connectors](/admin/sso/pro__authorization_connectors/)** listet alle unterstützten Provider auf einer Seite auf – welche konfiguriert sind, welche aktiviert sind und welches Protokoll jeder verwendet – und führt Sie direkt zum Einstellungsformular für jeden von ihnen. Beginnen Sie dort, wenn Sie den Status dieser Instanz kennen möchten, statt einen bestimmten Provider einzurichten. + +## Unterstützte SSO-Provider (DefectDojo Pro) + +DefectDojo Pro unterstützt SAML und die folgenden OAuth-Provider. Jede Anleitung führt durch die Einrichtung auf Provider-Seite und die entsprechende Konfiguration in der Pro-Benutzeroberfläche **Enterprise Settings**. + +* **[Auth0](/admin/sso/pro__auth0/)** +* **[Azure Active Directory](/admin/sso/pro__azure_ad/)** +* **[GitHub Enterprise](/admin/sso/pro__github_enterprise/)** +* **[GitLab](/admin/sso/pro__gitlab/)** +* **[Google](/admin/sso/pro__google/)** +* **[KeyCloak](/admin/sso/pro__keycloak/)** +* **[Okta](/admin/sso/pro__okta/)** +* **[OIDC (OpenID Connect)](/admin/sso/pro__oidc/)** +* **[SAML](/admin/sso/pro__saml/)** +* **[LDAP](/admin/sso/pro__ldap/)** + +## Bereitstellung von Benutzern aus Ihrem Verzeichnis (DefectDojo Pro) + +Die oben genannten Provider entscheiden, wer sich anmelden darf. **[SCIM Provisioning](/admin/sso/pro__scim/)** hält die Kontoliste selbst mit Ihrem Verzeichnis synchron, sodass Benutzer bei ihrem Eintritt erstellt, bei Änderungen ihrer Daten aktualisiert und beim Austritt (zusammen mit ihren API-Tokens) deaktiviert werden. + +Die SSO-Konfiguration in DefectDojo Pro kann nur von einem **Superuser** vorgenommen werden. + +**DefectDojo-Pro-Benutzer:** Fügen Sie die IP-Adressen Ihrer SAML- oder SSO-Dienste vor der Einrichtung von SSO zur Firewall-Whitelist hinzu. Weitere Informationen finden Sie unter [Firewall-Regeln](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings). + +## Deaktivieren der Benutzername-/Passwort-Anmeldung + +Sobald SSO in DefectDojo Pro konfiguriert ist, möchten Sie möglicherweise das klassische Anmeldeformular mit Benutzername/Passwort deaktivieren. Deaktivieren Sie **Allow Login via Username and Password** unter **Enterprise Settings > Login Settings**. + +![image](images/pro_login_settings.png) + +### Anmelde-Fallback + +Wenn Ihre SSO-Integration nicht mehr funktioniert, können Sie jederzeit zum Standard-Anmeldeformular zurückkehren, indem Sie Folgendes an Ihre DefectDojo-URL anhängen: + +`/login?force_login_form` + +Wir empfehlen, mindestens ein Admin-Konto mit konfiguriertem Benutzernamen und Passwort als Fallback beizubehalten. diff --git a/docs/content/admin/sso/_index.es.md b/docs/content/admin/sso/_index.es.md new file mode 100644 index 00000000000..2c17e211a3f --- /dev/null +++ b/docs/content/admin/sso/_index.es.md @@ -0,0 +1,76 @@ +--- +title: Inicio de sesión único +description: DefectDojo Pro admite SAML y una variedad de proveedores de OAuth para + el inicio de sesión único +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2026-04-30 00:00:00+00:00 +draft: false +weight: 8 +collapsed: true +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +aliases: +- /es/admin/user_management/configure_sso/ +- /es/admin/sso/os__saml/ +- /es/admin/sso/os__auth0/ +- /es/admin/sso/os__azure_ad/ +- /es/admin/sso/os__github_enterprise/ +- /es/admin/sso/os__gitlab/ +- /es/admin/sso/os__google/ +- /es/admin/sso/os__keycloak/ +- /es/admin/sso/os__oidc/ +- /es/admin/sso/os__okta/ +- /es/admin/sso/os__remote_user/ +--- + +El inicio de sesión único es una función de **DefectDojo Pro**. A partir de DefectDojo 3.0, la superficie de SSO — SAML, OIDC y los proveedores de OAuth incluidos — está disponible únicamente en DefectDojo Pro. DefectDojo de código abierto usa el inicio de sesión local con nombre de usuario/contraseña y el flujo de restablecimiento de contraseña. + +Si está ejecutando DefectDojo de código abierto y desea SSO, deberá cambiar a [DefectDojo Pro](https://defectdojo.com); la migración se describe en las [notas de actualización de la versión 3.0](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only). Las cuentas de usuario y las membresías de grupo existentes se conservan durante la actualización. Para conocer el control de acceso en DefectDojo de código abierto, consulte la página [Usuarios autorizados](/admin/user_management/os__authorized_users/). + +## Ver lo que está configurado + +**[Authorization Connectors](/admin/sso/pro__authorization_connectors/)** enumera todos los proveedores compatibles en una sola página — cuáles están configurados, cuáles están habilitados y qué protocolo habla cada uno — y lo lleva directamente al formulario de configuración de cualquiera de ellos. Comience allí si desea conocer el estado de esta instancia en lugar de configurar un proveedor específico. + +## Proveedores de SSO compatibles (DefectDojo Pro) + +DefectDojo Pro admite SAML y los siguientes proveedores de OAuth. Cada guía explica la configuración del lado del proveedor y la configuración correspondiente en la interfaz de **Enterprise Settings** de Pro. + +* **[Auth0](/admin/sso/pro__auth0/)** +* **[Azure Active Directory](/admin/sso/pro__azure_ad/)** +* **[GitHub Enterprise](/admin/sso/pro__github_enterprise/)** +* **[GitLab](/admin/sso/pro__gitlab/)** +* **[Google](/admin/sso/pro__google/)** +* **[KeyCloak](/admin/sso/pro__keycloak/)** +* **[Okta](/admin/sso/pro__okta/)** +* **[OIDC (OpenID Connect)](/admin/sso/pro__oidc/)** +* **[SAML](/admin/sso/pro__saml/)** +* **[LDAP](/admin/sso/pro__ldap/)** + +## Aprovisionamiento de usuarios desde su directorio (DefectDojo Pro) + +Los proveedores anteriores deciden quién puede iniciar sesión. **[SCIM Provisioning](/admin/sso/pro__scim/)** mantiene la lista de cuentas en sí sincronizada con su directorio, de modo que los usuarios se crean cuando se incorporan, se actualizan cuando cambian sus datos, y se desactivan (junto con sus tokens de API) cuando se van. + +La configuración de SSO en DefectDojo Pro solo puede realizarla un **Superusuario**. + +**Usuarios de DefectDojo Pro:** agregue las direcciones IP de sus servicios SAML o SSO a la lista blanca del firewall antes de configurar SSO. Consulte [Reglas de firewall](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings) para obtener más información. + +## Deshabilitar el inicio de sesión con nombre de usuario/contraseña + +Una vez que SSO esté configurado en DefectDojo Pro, es posible que desee deshabilitar el formulario tradicional de inicio de sesión con nombre de usuario/contraseña. Desmarque **Allow Login via Username and Password** en **Enterprise Settings > Login Settings**. + +![image](images/pro_login_settings.png) + +### Alternativa de inicio de sesión + +Si su integración de SSO deja de funcionar, siempre puede volver al formulario de inicio de sesión estándar agregando lo siguiente a la URL de su DefectDojo: + +`/login?force_login_form` + +Recomendamos mantener al menos una cuenta de administrador con un nombre de usuario y una contraseña configurados como alternativa. diff --git a/docs/content/admin/sso/_index.fr.md b/docs/content/admin/sso/_index.fr.md new file mode 100644 index 00000000000..33b6bf04cec --- /dev/null +++ b/docs/content/admin/sso/_index.fr.md @@ -0,0 +1,76 @@ +--- +title: Authentification unique +description: DefectDojo Pro prend en charge SAML et une gamme de fournisseurs OAuth + pour l'authentification unique +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2026-04-30 00:00:00+00:00 +draft: false +weight: 8 +collapsed: true +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +aliases: +- /fr/admin/user_management/configure_sso/ +- /fr/admin/sso/os__saml/ +- /fr/admin/sso/os__auth0/ +- /fr/admin/sso/os__azure_ad/ +- /fr/admin/sso/os__github_enterprise/ +- /fr/admin/sso/os__gitlab/ +- /fr/admin/sso/os__google/ +- /fr/admin/sso/os__keycloak/ +- /fr/admin/sso/os__oidc/ +- /fr/admin/sso/os__okta/ +- /fr/admin/sso/os__remote_user/ +--- + +L'authentification unique est une fonctionnalité de **DefectDojo Pro**. Depuis DefectDojo 3.0, l'ensemble du périmètre SSO — SAML, OIDC et les fournisseurs OAuth intégrés — n'est disponible que dans DefectDojo Pro. La version open source de DefectDojo utilise une connexion locale par nom d'utilisateur/mot de passe et le flux de réinitialisation de mot de passe. + +Si vous utilisez la version open source de DefectDojo et souhaitez le SSO, vous devrez passer à [DefectDojo Pro](https://defectdojo.com) ; la migration est décrite dans les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only). Les comptes utilisateur et les appartenances aux groupes existants sont préservés lors de la mise à niveau. Pour le contrôle d'accès sur la version open source de DefectDojo, consultez la page [Utilisateurs autorisés](/admin/user_management/os__authorized_users/). + +## Voir ce qui est configuré + +**[Authorization Connectors](/admin/sso/pro__authorization_connectors/)** répertorie tous les fournisseurs pris en charge sur une seule page — lesquels sont configurés, lesquels sont activés, et quel protocole chacun utilise — et vous mène directement au formulaire de paramètres de chacun d'eux. Commencez ici si vous voulez connaître l'état de cette instance plutôt que configurer un fournisseur spécifique. + +## Fournisseurs SSO pris en charge (DefectDojo Pro) + +DefectDojo Pro prend en charge SAML ainsi que les fournisseurs OAuth suivants. Chaque guide détaille la configuration côté fournisseur et la configuration correspondante dans l'interface **Enterprise Settings** de Pro. + +* **[Auth0](/admin/sso/pro__auth0/)** +* **[Azure Active Directory](/admin/sso/pro__azure_ad/)** +* **[GitHub Enterprise](/admin/sso/pro__github_enterprise/)** +* **[GitLab](/admin/sso/pro__gitlab/)** +* **[Google](/admin/sso/pro__google/)** +* **[KeyCloak](/admin/sso/pro__keycloak/)** +* **[Okta](/admin/sso/pro__okta/)** +* **[OIDC (OpenID Connect)](/admin/sso/pro__oidc/)** +* **[SAML](/admin/sso/pro__saml/)** +* **[LDAP](/admin/sso/pro__ldap/)** + +## Provisionnement des utilisateurs depuis votre annuaire (DefectDojo Pro) + +Les fournisseurs ci-dessus déterminent qui peut se connecter. **[SCIM Provisioning](/admin/sso/pro__scim/)** maintient la liste des comptes elle-même synchronisée avec votre annuaire, de sorte que les utilisateurs sont créés à leur arrivée, mis à jour lorsque leurs informations changent, et désactivés (avec leurs jetons API) à leur départ. + +La configuration du SSO dans DefectDojo Pro ne peut être effectuée que par un **Superuser**. + +**Utilisateurs DefectDojo Pro :** Ajoutez les adresses IP de vos services SAML ou SSO à la liste blanche du pare-feu avant de configurer le SSO. Voir [Règles de pare-feu](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings) pour plus d'informations. + +## Désactivation de la connexion par nom d'utilisateur / mot de passe + +Une fois le SSO configuré dans DefectDojo Pro, vous voudrez peut-être désactiver le formulaire de connexion traditionnel par nom d'utilisateur/mot de passe. Décochez **Allow Login via Username and Password** sous **Enterprise Settings > Login Settings**. + +![image](images/pro_login_settings.png) + +### Solution de repli pour la connexion + +Si votre intégration SSO cesse de fonctionner, vous pouvez toujours revenir au formulaire de connexion standard en ajoutant ce qui suit à l'URL de votre DefectDojo : + +`/login?force_login_form` + +Nous recommandons de conserver au moins un compte administrateur avec un nom d'utilisateur et un mot de passe configurés en secours. diff --git a/docs/content/admin/sso/_index.ja.md b/docs/content/admin/sso/_index.ja.md new file mode 100644 index 00000000000..1a372a72f3f --- /dev/null +++ b/docs/content/admin/sso/_index.ja.md @@ -0,0 +1,75 @@ +--- +title: シングルサインオン +description: DefectDojo Pro はシングルサインオンのために SAML と幅広い OAuth プロバイダーをサポートしています +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2026-04-30 00:00:00+00:00 +draft: false +weight: 8 +collapsed: true +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +aliases: +- /ja/admin/user_management/configure_sso/ +- /ja/admin/sso/os__saml/ +- /ja/admin/sso/os__auth0/ +- /ja/admin/sso/os__azure_ad/ +- /ja/admin/sso/os__github_enterprise/ +- /ja/admin/sso/os__gitlab/ +- /ja/admin/sso/os__google/ +- /ja/admin/sso/os__keycloak/ +- /ja/admin/sso/os__oidc/ +- /ja/admin/sso/os__okta/ +- /ja/admin/sso/os__remote_user/ +--- + +シングルサインオンは **DefectDojo Pro** の機能です。DefectDojo 3.0 以降、SAML、OIDC、バンドルされた OAuth プロバイダーを含む SSO 機能一式は DefectDojo Pro でのみ利用可能です。オープンソース版の DefectDojo は、ローカルのユーザー名/パスワードによるログインとパスワードリセットのフローを使用します。 + +オープンソース版の DefectDojo を使用していて SSO が必要な場合は、[DefectDojo Pro](https://defectdojo.com) への切り替えが必要です。移行手順については [3.0 upgrade notes](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only) を参照してください。アップグレード時、既存のユーザーアカウントとグループメンバーシップは維持されます。オープンソース版 DefectDojo のアクセス制御については、[Authorized Users](/admin/user_management/os__authorized_users/) ページを参照してください。 + +## Seeing what is configured + +**[Authorization Connectors](/admin/sso/pro__authorization_connectors/)** は、サポートされているすべてのプロバイダーを 1 つのページに一覧表示し、どれが設定済みか、どれが有効か、それぞれがどのプロトコルを話すかを示すとともに、各プロバイダーの設定フォームに直接移動できます。特定のプロバイダーを設定するのではなく、このインスタンスの状態を確認したい場合はここから始めてください。 + +## Supported SSO providers (DefectDojo Pro) + +DefectDojo Pro は SAML と、次の OAuth プロバイダーをサポートしています。各ガイドでは、プロバイダー側の設定手順と、それに対応する Pro の **Enterprise Settings** UI での設定を説明しています。 + +* **[Auth0](/admin/sso/pro__auth0/)** +* **[Azure Active Directory](/admin/sso/pro__azure_ad/)** +* **[GitHub Enterprise](/admin/sso/pro__github_enterprise/)** +* **[GitLab](/admin/sso/pro__gitlab/)** +* **[Google](/admin/sso/pro__google/)** +* **[KeyCloak](/admin/sso/pro__keycloak/)** +* **[Okta](/admin/sso/pro__okta/)** +* **[OIDC (OpenID Connect)](/admin/sso/pro__oidc/)** +* **[SAML](/admin/sso/pro__saml/)** +* **[LDAP](/admin/sso/pro__ldap/)** + +## Provisioning users from your directory (DefectDojo Pro) + +上記のプロバイダーは、誰がサインインできるかを決定します。**[SCIM Provisioning](/admin/sso/pro__scim/)** はアカウント一覧自体をディレクトリと同期させ、ユーザーが加入したときに作成し、詳細が変更されたときに更新し、離脱したときに(API トークンとともに)無効化します。 + +DefectDojo Pro における SSO の設定は **Superuser** のみが行えます。 + +**DefectDojo Pro をご利用の場合:** SSO を設定する前に、SAML または SSO サービスの IP アドレスをファイアウォールのホワイトリストに追加してください。詳細は [Firewall Rules](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings) を参照してください。 + +## Disabling Username / Password login + +DefectDojo Pro で SSO を設定したら、従来のユーザー名/パスワードのログインフォームを無効にしたい場合があります。**Enterprise Settings > Login Settings** で **Allow Login via Username and Password** のチェックを外してください。 + +![image](images/pro_login_settings.png) + +### Login fallback + +SSO の連携が機能しなくなった場合でも、DefectDojo の URL に以下を追加することで、常に標準のログインフォームに戻ることができます。 + +`/login?force_login_form` + +フォールバックとして、ユーザー名とパスワードを設定した管理者アカウントを少なくとも 1 つ保持しておくことをお勧めします。 diff --git a/docs/content/admin/user_management/OS__audit_logging.de.md b/docs/content/admin/user_management/OS__audit_logging.de.md new file mode 100644 index 00000000000..30a12813291 --- /dev/null +++ b/docs/content/admin/user_management/OS__audit_logging.de.md @@ -0,0 +1,17 @@ +--- +title: Audit-Protokolle +description: Rufen Sie Audit-Protokolle für DefectDojo-Objekte auf +weight: 1 +audience: opensource +aliases: +- /de/en/customize_dojo/user_management/audit_logging +--- + +Audit-Protokolle für DefectDojo können auf verschiedene Arten aufgerufen werden. + +## Einzelne Objektprotokolle +* Jedes DefectDojo-Objekt verfügt über einen zugehörigen Objektverlauf, der über die Benutzeroberfläche aufgerufen werden kann. Diese Verläufe werden für Assets, Engagements, Tests, Befunde und Endpunkte sowie für Risikoakzeptanzen aufgezeichnet. + +In der klassischen (Open-Source-)Benutzeroberfläche finden Sie Objektprotokolle unter dem ☰-Hamburger-Menü in der Ansicht eines Objekts. + +![Bild](images/auditlogs_ss6.png) diff --git a/docs/content/admin/user_management/OS__audit_logging.es.md b/docs/content/admin/user_management/OS__audit_logging.es.md new file mode 100644 index 00000000000..b2d8fd213f3 --- /dev/null +++ b/docs/content/admin/user_management/OS__audit_logging.es.md @@ -0,0 +1,17 @@ +--- +title: Registros de auditoría +description: Acceda a los registros de auditoría de los objetos de DefectDojo +weight: 1 +audience: opensource +aliases: +- /es/en/customize_dojo/user_management/audit_logging +--- + +Se puede acceder a los registros de auditoría de DefectDojo de varias maneras. + +## Registros de objetos individuales +* Cada objeto de DefectDojo tiene un Historial de objeto asociado, al que se puede acceder a través de la interfaz. Estos historiales se registran para Activos, Compromisos, Tests, Hallazgos y Endpoints, así como para las Aceptaciones de riesgo. + +En la interfaz Clásica (Open-Source), los Registros de objeto se encuentran en el menú ☰ (hamburguesa) dentro de la vista de un objeto. + +![imagen](images/auditlogs_ss6.png) diff --git a/docs/content/admin/user_management/OS__audit_logging.fr.md b/docs/content/admin/user_management/OS__audit_logging.fr.md new file mode 100644 index 00000000000..2220c88e69f --- /dev/null +++ b/docs/content/admin/user_management/OS__audit_logging.fr.md @@ -0,0 +1,17 @@ +--- +title: Journaux d'audit +description: Accéder aux journaux d'audit des objets DefectDojo +weight: 1 +audience: opensource +aliases: +- /fr/en/customize_dojo/user_management/audit_logging +--- + +Les journaux d'audit de DefectDojo sont accessibles de plusieurs façons. + +## Journaux par objet individuel +* Chaque objet DefectDojo possède un historique d'objet (Object History) associé, accessible via l'interface. Ces historiques sont enregistrés pour les Actifs, les Engagements, les Tests, les Constatations et les Points de terminaison, ainsi que pour les Acceptations du risque. + +Dans l'interface Classic (Open-Source), les journaux d'objet se trouvent sous le menu hamburger ☰ dans la vue d'un objet. + +![image](images/auditlogs_ss6.png) diff --git a/docs/content/admin/user_management/OS__audit_logging.ja.md b/docs/content/admin/user_management/OS__audit_logging.ja.md new file mode 100644 index 00000000000..630acca7c8b --- /dev/null +++ b/docs/content/admin/user_management/OS__audit_logging.ja.md @@ -0,0 +1,17 @@ +--- +title: 監査ログ +description: DefectDojoオブジェクトの監査ログへのアクセス方法 +weight: 1 +audience: opensource +aliases: +- /ja/en/customize_dojo/user_management/audit_logging +--- + +DefectDojoの監査ログには、いくつかの方法でアクセスできます。 + +## 個々のオブジェクトのログ +* DefectDojoの各オブジェクトにはオブジェクト履歴が関連付けられており、UIからアクセスできます。この履歴は、アセット、エンゲージメント、テスト、検出事項、エンドポイントに加え、リスク受容についても記録されます。 + +クラシック（オープンソース）UIでは、オブジェクトログはオブジェクトのビュー内にある ☰ ハンバーガーメニューから確認できます。 + +![image](images/auditlogs_ss6.png) diff --git a/docs/content/admin/user_management/OS__authorized_users.de.md b/docs/content/admin/user_management/OS__authorized_users.de.md new file mode 100644 index 00000000000..9d8e2af2238 --- /dev/null +++ b/docs/content/admin/user_management/OS__authorized_users.de.md @@ -0,0 +1,61 @@ +--- +title: Open-Source-Berechtigungen +description: Wie der Zugriff auf Produkte und Produkttypen im Open-Source-DefectDojo + gewährt wird +weight: 1 +audience: opensource +--- + +Open-Source-DefectDojo steuert den Zugriff auf Produkte und Produkttypen über das Modell **Authorized Users**. Jedes Produkt und jeder Produkttyp verfügt über ein Authorized-Users-Panel, das die Personen auflistet, die diesen Datensatz und die darunter verschachtelten Daten sehen können. + +Wenn Sie DefectDojo Pro einsetzen, gilt dieser Artikel nicht für Ihre Installation – Pro verwendet ein umfangreicheres rollenbasiertes System, das in [Berechtigungen in DefectDojo](../about_perms_and_roles/) beschrieben wird. + +## Wie der Zugriff gewährt wird + +Es gibt zwei Listen, und ein Benutzer muss nur auf einer davon stehen, um Zugriff zu erhalten: + +- **Die Authorized-Users-Liste eines Produkts** gewährt Zugriff auf dieses eine Produkt sowie auf alles, was darunter verschachtelt ist (dessen Engagements, Tests, Befunde und Endpunkte). +- **Die Authorized-Users-Liste eines Produkttyps** gewährt Zugriff auf den Produkttyp selbst **und wirkt sich kaskadierend auf jedes darunterliegende Produkt aus**. Ein Benutzer, der für einen Produkttyp autorisiert ist, muss nicht zusätzlich zu jedem untergeordneten Produkt hinzugefügt werden – er ist bereits abgedeckt. + +Es gibt keine Rollen, keine Gruppen und keine globalen Rollen. Ein Benutzer steht entweder auf der Liste (oder ist Superuser/Staff-Mitglied – siehe unten), oder er kann das Produkt nicht sehen. + +## Superuser und Staff umgehen die Listen + +Benutzer, die in DefectDojo als **Superuser** oder **Staff** markiert sind, können unabhängig von den Authorized-Users-Listen jedes Produkt und jeden Produkttyp sehen und bearbeiten. Die Listen dienen dazu, Nicht-Staff-Benutzern Zugriff zu gewähren; sie schränken Staff-Mitglieder oder Superuser nicht ein. + +Das erste Konto, das auf einer neuen DefectDojo-Installation erstellt wird, ist automatisch ein Superuser. + +## Wer die Listen bearbeiten kann + +Nur **Superuser** oder **Staff**-Benutzer sehen die Bedienelemente, um Personen zu einem Authorized-Users-Panel hinzuzufügen oder daraus zu entfernen. Alle anderen, die Zugriff auf ein Produkt oder einen Produkttyp haben, sehen das Panel als schreibgeschützte Übersicht – nützlich, um herauszufinden, wer sonst noch im Team ist, aber nicht, um die Mitgliedschaft zu ändern. + +## Wo sich das Panel befindet + +Das Authorized-Users-Panel erscheint auf zwei Seiten der klassischen Benutzeroberfläche: + +- Die **Produktdetailseite** verfügt über ein Authorized-Users-Panel für dieses Produkt. Sie unterstützt zwei Aktionen für Staff-Benutzer: + - **Einen Benutzer zur Authorized-Users-Liste des Produkts hinzufügen** + - **Einen Benutzer aus der Authorized-Users-Liste des Produkts entfernen** +- Die **Produkttyp-Detailseite** verfügt über ein Authorized-Users-Panel für diesen Produkttyp, mit den entsprechenden zwei Aktionen: + - **Einen Benutzer zur Authorized-Users-Liste des Produkttyps hinzufügen** + - **Einen Benutzer aus der Authorized-Users-Liste des Produkttyps entfernen** + +Wenn Sie einen Benutzer von der Liste eines Produkttyps entfernen, entfällt auch die Kaskade – er verliert den Zugriff auf jedes untergeordnete Produkt, sofern er nicht weiterhin auf der Liste eines bestimmten Produkts steht oder Staff-Mitglied/Superuser ist. + +## Entscheidung zwischen Produkt- und Produkttyp-Zugriff + +Ein paar Faustregeln: + +- Wenn eine Person jedes Produkt unter einer Kategorie sehen soll (zum Beispiel jedes Produkt, das einem bestimmten Team gehört), fügen Sie sie zur Liste des **Produkttyps** hinzu und überlassen Sie den Rest der Kaskade. +- Wenn eine Person nur ein bestimmtes Produkt sehen soll, fügen Sie sie zur Liste dieses **Produkts** hinzu. +- Wenn Sie dieselbe Person zu vielen einzelnen Produkten unter einem Produkttyp hinzufügen, ist das ein Zeichen dafür, dass Sie sie stattdessen zum Produkttyp hinzufügen sollten. + +## Umstieg von einer früheren DefectDojo-Version + +DefectDojo Open Source ist in Version 3.0 zum Authorized-Users-Modell zurückgekehrt. Wenn Sie von einer Version aktualisieren, die das System Members / Groups / Global Roles verwendet hat, wird Ihr bestehender Zugriff durch das Upgrade automatisch in Authorized Users übernommen – eine manuelle Zuordnung ist nicht erforderlich. + +Das Upgrade wird mit einem schreibgeschützten Management-Command, `preview_legacy_authorization_migration`, ausgeliefert, der anhand einer Kopie Ihrer Datenbank zusammenfasst, was ein Upgrade ändern würde. Der empfohlene Ablauf ist, 3.0 in einer Staging-Umgebung mit einem Snapshot der Produktionsumgebung zu installieren, den Befehl auszuführen, die Zusammenfassung zu prüfen und erst dann die Produktionsumgebung zu aktualisieren. + +Wenn Sie sich in die andere Richtung bewegen – von Open Source zu DefectDojo Pro –, liefert Pro einen Befehl `reconcile_authorized_users_to_rbac`, der den Authorized-Users-Zugriff in das RBAC von Pro übernimmt. Er unterstützt `--dry-run` und ist idempotent. + +Weitere Details zu beiden Wegen finden Sie in den [Upgrade-Hinweisen zu 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization). diff --git a/docs/content/admin/user_management/OS__authorized_users.es.md b/docs/content/admin/user_management/OS__authorized_users.es.md new file mode 100644 index 00000000000..76b6d0199f1 --- /dev/null +++ b/docs/content/admin/user_management/OS__authorized_users.es.md @@ -0,0 +1,61 @@ +--- +title: Permisos de código abierto +description: Cómo se otorga el acceso a Productos y Tipos de producto en DefectDojo + de código abierto +weight: 1 +audience: opensource +--- + +DefectDojo de código abierto controla el acceso a Productos y Tipos de producto mediante el modelo de **Usuarios autorizados**. Cada Producto y Tipo de producto tiene un panel de Usuarios autorizados que enumera a las personas que pueden ver ese registro y los datos anidados debajo de él. + +Si utiliza DefectDojo Pro, este artículo no se aplica a su instalación — Pro usa un sistema basado en roles más completo, descrito en [Permisos en DefectDojo](../about_perms_and_roles/). + +## Cómo se otorga el acceso + +Hay dos listas, y un usuario solo necesita aparecer en una de ellas para obtener acceso: + +- **La lista de Usuarios autorizados de un Producto** otorga acceso a ese Producto individual, además de todo lo anidado debajo de él (sus Compromisos, Tests, Hallazgos y Endpoints). +- **La lista de Usuarios autorizados de un Tipo de producto** otorga acceso al Tipo de producto en sí **y se propaga en cascada a todos los Productos que están debajo de él**. Un usuario autorizado en un Tipo de producto no necesita además ser agregado a cada Producto hijo — ya está cubierto. + +No hay roles, ni grupos, ni roles globales. Un usuario está en la lista (o es superusuario/miembro del staff — ver más abajo), o no puede ver el Producto. + +## Los superusuarios y el staff omiten las listas + +Los usuarios marcados como **superusuario** o **staff** en DefectDojo pueden ver y actuar sobre todos los Productos y Tipos de producto, independientemente de las listas de Usuarios autorizados. Las listas existen para otorgar acceso a usuarios que no son del staff; no restringen al staff ni a los superusuarios. + +La primera cuenta creada en una instalación nueva de DefectDojo es automáticamente superusuario. + +## Quién puede editar las listas + +Solo los usuarios **superusuario** o **staff** ven los controles para agregar o quitar personas de un panel de Usuarios autorizados. Todos los demás que tengan acceso a un Producto o Tipo de producto ven el panel como una lista de solo lectura — útil para saber quién más está en el equipo, pero no para cambiar la membresía. + +## Dónde se encuentra el panel + +El panel de Usuarios autorizados aparece en dos páginas de la interfaz clásica: + +- La **página de detalle del Producto** tiene un panel de Usuarios autorizados para ese Producto. Admite dos acciones para los usuarios del staff: + - **Agregar un usuario a la lista de Usuarios autorizados del Producto** + - **Quitar un usuario de la lista de Usuarios autorizados del Producto** +- La **página de detalle del Tipo de producto** tiene un panel de Usuarios autorizados para ese Tipo de producto, con las dos acciones correspondientes: + - **Agregar un usuario a la lista de Usuarios autorizados del Tipo de producto** + - **Quitar un usuario de la lista de Usuarios autorizados del Tipo de producto** + +Cuando quita a un usuario de la lista de un Tipo de producto, la cascada también se elimina — pierde el acceso a todos los Productos hijos, a menos que siga en la lista de un Producto específico, o sea staff/superusuario. + +## Cómo elegir entre acceso a nivel de Producto o de Tipo de producto + +Algunas reglas prácticas: + +- Si una persona debe ver todos los Productos de una categoría (por ejemplo, todos los Productos que pertenecen a un equipo determinado), agréguela a la lista del **Tipo de producto** y deje que la cascada se encargue del resto. +- Si una persona solo debe ver un Producto específico, agréguela a la lista de ese **Producto**. +- Si se encuentra agregando a la misma persona a muchos Productos individuales dentro de un mismo Tipo de producto, es una señal de que debería agregarla al Tipo de producto en su lugar. + +## Si viene de una versión anterior de DefectDojo + +DefectDojo de código abierto volvió al modelo de Usuarios autorizados en la versión 3.0. Si está actualizando desde una versión que tenía el sistema de Miembros / Grupos / Roles globales, la actualización traslada automáticamente su acceso existente a Usuarios autorizados — no se necesita ningún mapeo manual. + +La actualización incluye un comando de administración de solo lectura, `preview_legacy_authorization_migration`, que resume lo que cambiaría una actualización sobre una copia de su base de datos. El flujo de trabajo recomendado es instalar 3.0 en un entorno de staging con una instantánea de producción, ejecutar el comando, revisar el resumen y luego actualizar producción. + +Si se mueve en la dirección contraria — de código abierto a DefectDojo Pro — Pro incluye un comando `reconcile_authorized_users_to_rbac` que traslada el acceso de Usuarios autorizados al RBAC de Pro. Admite `--dry-run` y es idempotente. + +Para más detalle sobre ambos caminos, consulte las [notas de actualización de la 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization). diff --git a/docs/content/admin/user_management/OS__authorized_users.fr.md b/docs/content/admin/user_management/OS__authorized_users.fr.md new file mode 100644 index 00000000000..3d55a7b7536 --- /dev/null +++ b/docs/content/admin/user_management/OS__authorized_users.fr.md @@ -0,0 +1,61 @@ +--- +title: Permissions Open Source +description: Comment l'accès aux Produits et Types de produit est accordé dans DefectDojo + open source +weight: 1 +audience: opensource +--- + +DefectDojo open source contrôle l'accès aux Produits et Types de produit à l'aide du modèle **Authorized Users**. Chaque Produit et Type de produit dispose d'un panneau Authorized Users répertoriant les personnes pouvant voir cet enregistrement et les données qui y sont imbriquées. + +Si vous utilisez DefectDojo Pro, cet article ne s'applique pas à votre installation — Pro utilise un système de rôles plus riche, décrit dans [Autorisations dans DefectDojo](../about_perms_and_roles/). + +## Comment l'accès est accordé + +Il existe deux listes, et un utilisateur n'a besoin de figurer que sur l'une d'elles pour obtenir l'accès : + +- **La liste Authorized Users d'un Produit** accorde l'accès à ce Produit unique, ainsi qu'à tout ce qui est imbriqué en dessous (ses Engagements, Tests, Constatations et Points de terminaison). +- **La liste Authorized Users d'un Type de produit** accorde l'accès au Type de produit lui-même **et se répercute sur chaque Produit qui en dépend**. Un utilisateur autorisé sur un Type de produit n'a pas besoin d'être également ajouté à chaque Produit enfant — il est déjà couvert. + +Il n'y a ni rôles, ni groupes, ni rôles globaux. Un utilisateur est soit sur la liste (ou est superuser/membre du staff — voir ci-dessous), soit il ne peut pas voir le Produit. + +## Les superusers et le staff contournent les listes + +Les utilisateurs marqués comme **superuser** ou **staff** dans DefectDojo peuvent voir et agir sur chaque Produit et Type de produit indépendamment des listes Authorized Users. Ces listes existent pour accorder l'accès aux utilisateurs qui ne sont pas membres du staff ; elles ne restreignent ni le staff ni les superusers. + +Le premier compte créé sur une installation DefectDojo neuve est automatiquement superuser. + +## Qui peut modifier les listes + +Seuls les utilisateurs **superuser** ou **staff** voient les contrôles permettant d'ajouter ou de retirer des personnes d'un panneau Authorized Users. Toute autre personne ayant accès à un Produit ou un Type de produit voit le panneau comme une liste en lecture seule — utile pour savoir qui d'autre fait partie de l'équipe, mais pas pour modifier l'appartenance. + +## Où se trouve le panneau + +Le panneau Authorized Users apparaît sur deux pages de l'interface classique : + +- La **page de détail du Produit** dispose d'un panneau Authorized Users pour ce Produit. Elle prend en charge deux actions pour les utilisateurs staff : + - **Ajouter un utilisateur à la liste Authorized Users du Produit** + - **Retirer un utilisateur de la liste Authorized Users du Produit** +- La **page de détail du Type de produit** dispose d'un panneau Authorized Users pour ce Type de produit, avec les deux actions correspondantes : + - **Ajouter un utilisateur à la liste Authorized Users du Type de produit** + - **Retirer un utilisateur de la liste Authorized Users du Type de produit** + +Lorsque vous retirez un utilisateur de la liste d'un Type de produit, la répercussion est également supprimée — il perd l'accès à chaque Produit enfant, sauf s'il figure encore sur la liste d'un Produit spécifique, ou s'il est staff/superuser. + +## Choisir entre un accès au niveau Produit ou Type de produit + +Quelques règles empiriques : + +- Si une personne doit voir tous les Produits d'une catégorie (par exemple, tous les Produits possédés par une équipe donnée), placez-la sur la liste du **Type de produit** et laissez la répercussion faire le reste. +- Si une personne ne doit voir qu'un seul Produit spécifique, placez-la sur la liste de ce **Produit**. +- Si vous vous retrouvez à ajouter la même personne à de nombreux Produits individuels sous un même Type de produit, c'est le signe que vous devriez plutôt l'ajouter au Type de produit. + +## En provenance d'une version antérieure de DefectDojo + +DefectDojo open source est revenu au modèle Authorized Users dans la version 3.0. Si vous effectuez une mise à niveau depuis une version qui utilisait le système Members / Groups / Global Roles, votre accès existant est automatiquement reporté vers Authorized Users par la mise à niveau — aucune correspondance manuelle n'est nécessaire. + +La mise à niveau est livrée avec une commande de gestion en lecture seule, `preview_legacy_authorization_migration`, qui résume ce que la mise à niveau changerait, à partir d'une copie de votre base de données. Le flux recommandé consiste à installer la 3.0 dans un environnement de staging avec un instantané de la production, à exécuter la commande, à examiner le résumé, puis à mettre à niveau la production. + +Si vous allez dans l'autre sens — d'open source vers DefectDojo Pro — Pro est livré avec une commande `reconcile_authorized_users_to_rbac` qui reporte l'accès Authorized Users vers le RBAC de Pro. Elle prend en charge `--dry-run` et est idempotente. + +Pour plus de détails sur les deux parcours, consultez les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization). diff --git a/docs/content/admin/user_management/OS__authorized_users.ja.md b/docs/content/admin/user_management/OS__authorized_users.ja.md new file mode 100644 index 00000000000..53278ca8fdb --- /dev/null +++ b/docs/content/admin/user_management/OS__authorized_users.ja.md @@ -0,0 +1,60 @@ +--- +title: オープンソース版の権限 +description: オープンソース版DefectDojoにおいて、製品と製品タイプへのアクセスがどのように付与されるか +weight: 1 +audience: opensource +--- + +オープンソース版DefectDojoは、**Authorized Users**（承認済みユーザー）モデルによって製品と製品タイプへのアクセスを制御します。各製品と各製品タイプには、そのレコードおよびその配下にあるデータを閲覧できる人を一覧表示するAuthorized Usersパネルがあります。 + +DefectDojo Proをお使いの場合、この記事はインストール環境には当てはまりません。Proではよりリッチなロールベースのシステムを使用しており、詳細は[DefectDojoにおける権限](../about_perms_and_roles/)で説明しています。 + +## アクセスの付与方法 + +リストは2つあり、ユーザーはそのいずれか一方に含まれているだけでアクセス権を得られます。 + +- **製品のAuthorized Usersリスト** は、その1つの製品と、その配下にあるすべて（エンゲージメント、テスト、検出事項、エンドポイント）へのアクセスを許可します。 +- **製品タイプのAuthorized Usersリスト** は、製品タイプ自体へのアクセスを許可し、**さらにその配下のすべての製品に連鎖します**。製品タイプで承認されたユーザーは、各子製品に個別に追加される必要はなく、すでにアクセス権が及んでいます。 + +ロールもグループもグローバルロールもありません。ユーザーはリストに載っているか（あるいはスーパーユーザーやスタッフメンバーである場合。詳細は下記参照）、そうでなければその製品を閲覧できません。 + +## スーパーユーザーとスタッフはリストをバイパスします + +DefectDojoで **superuser**（スーパーユーザー）または **staff**（スタッフ）とマークされたユーザーは、Authorized Usersリストの内容に関わらず、すべての製品と製品タイプを閲覧・操作できます。これらのリストはスタッフ以外のユーザーにアクセス権を付与するために存在するものであり、スタッフやスーパーユーザーを制限するものではありません。 + +新規にインストールされたDefectDojoで最初に作成されるアカウントは、自動的にスーパーユーザーになります。 + +## リストを編集できるのは誰か + +Authorized Usersパネルで人を追加・削除するコントロールが表示されるのは、**superuser** または **staff** ユーザーのみです。製品や製品タイプへのアクセス権を持つそれ以外の人には、パネルは読み取り専用の名簿として表示されます。チームに他に誰がいるかを知るのには役立ちますが、メンバーシップを変更することはできません。 + +## パネルの場所 + +Authorized Usersパネルは、クラシックUIの2つのページに表示されます。 + +- **製品の詳細ページ** には、その製品のAuthorized Usersパネルがあります。スタッフユーザー向けに2つの操作をサポートしています。 + - **ユーザーを製品のAuthorized Usersリストに追加する** + - **ユーザーを製品のAuthorized Usersリストから削除する** +- **製品タイプの詳細ページ** には、その製品タイプのAuthorized Usersパネルがあり、対応する2つの操作があります。 + - **ユーザーを製品タイプのAuthorized Usersリストに追加する** + - **ユーザーを製品タイプのAuthorized Usersリストから削除する** + +製品タイプのリストからユーザーを削除すると、連鎖的なアクセス権も失われます。特定の製品のリストに個別に載っているか、スタッフ/スーパーユーザーでない限り、そのユーザーはすべての子製品へのアクセス権を失います。 + +## 製品アクセスと製品タイプアクセスのどちらを選ぶか + +いくつかの目安を挙げます。 + +- あるカテゴリー配下のすべての製品（例えば、特定のチームが所有するすべての製品）を閲覧させたい場合は、**製品タイプ** のリストに追加し、あとは連鎖に任せてください。 +- 特定の1つの製品だけを閲覧させたい場合は、その **製品** のリストに追加してください。 +- 同じ人物を、1つの製品タイプ配下の多数の個別製品に何度も追加している場合、それは代わりに製品タイプへ追加すべきだというサインです。 + +## DefectDojoの旧バージョンからの移行 + +オープンソース版DefectDojoは、バージョン3.0でAuthorized Usersモデルに回帰しました。Members / Groups / Global Rolesシステムを使用していたリリースからアップグレードする場合、既存のアクセス権はアップグレードによって自動的にAuthorized Usersへ引き継がれます。手動でのマッピングは不要です。 + +このアップグレードには、読み取り専用の管理コマンド `preview_legacy_authorization_migration` が同梱されており、データベースのコピーに対してアップグレードが何を変更するかの概要を出力します。推奨されるワークフローは、本番環境のスナップショットを使ってステージング環境に3.0をインストールし、このコマンドを実行して概要を確認したうえで、本番環境をアップグレードする、というものです。 + +逆方向——オープンソース版からDefectDojo Proへ——移行する場合は、Proに同梱されている `reconcile_authorized_users_to_rbac` コマンドが、Authorized UsersのアクセスをProのRBACへ引き継ぎます。このコマンドは `--dry-run` に対応しており、冪等です。 + +両方の移行パスについての詳細は、[3.0アップグレードノート](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization)を参照してください。 diff --git a/docs/content/admin/user_management/OS__creating_new_users.de.md b/docs/content/admin/user_management/OS__creating_new_users.de.md new file mode 100644 index 00000000000..c017535d6c9 --- /dev/null +++ b/docs/content/admin/user_management/OS__creating_new_users.de.md @@ -0,0 +1,43 @@ +--- +title: Einen neuen Benutzer erstellen +description: Wie Sie einen neuen Benutzer in Ihrer DefectDojo-Instanz onboarden +audience: opensource +weight: 1 +--- + +Diese Seite beschreibt den empfohlenen Onboarding-Ablauf für das Hinzufügen neuer Benutzer zu einer DefectDojo-Instanz. DefectDojo-Benutzer können sowohl als reguläre, von Menschen bediente Konten als auch als Service-Konten verwendet werden. + +Der Admin, der das Konto erstellt, ist dafür verantwortlich, die anfänglichen Zugangsdaten (Benutzername und Passwort) an den neuen Benutzer zu übermitteln. + +## Empfohlener Ablauf + +1. **Erstellen Sie das Benutzerkonto** in DefectDojo (nur Superuser): + * Navigieren Sie zu **👤 Users → Users**, um die Tabelle „Alle Benutzer“ zu öffnen. + * Klicken Sie auf das 🛠️-Symbol (gekreuzter Schraubenschlüssel und Schraubenzieher). + * Geben Sie den Namen und die E-Mail-Adresse des neuen Benutzers ein. + * Legen Sie ein temporäres Passwort fest. + * Senden Sie das Formular ab. + +2. **Weisen Sie passende Berechtigungen zu** – Produkt-/Produkttyp-Mitgliedschaft, Configuration Permissions, Global Role oder Superuser-Status. Details finden Sie unter [Berechtigungen eines Benutzers festlegen](../set_user_permissions/). Ein neuer Benutzer ohne Zuweisungen kann keine Produkte oder Befunde sehen. + +3. **Senden Sie die Zugangsdaten außerhalb des Systems (out-of-band) an den neuen Benutzer** (per E-Mail, über das Chat-Tool Ihres Teams oder wie Sie sonst Geheimnisse teilen). Fügen Sie Folgendes bei: + * Die URL der DefectDojo-Instanz. + * Den Benutzernamen (in der Regel die E-Mail-Adresse). + * Das gerade festgelegte temporäre Passwort. + * Einen Hinweis, dass der Benutzer beim ersten Login das Passwort ändern und MFA aktivieren sollte (falls Ihre Instanz MFA verwendet). + +4. **Der neue Benutzer meldet sich an und ändert die Zugangsdaten.** Er kann entweder: + * sich mit dem temporären Passwort anmelden und es anschließend über sein Profilmenü ändern, oder + * über den Link **I forgot my password** auf der Login-Seite direkt ein neues Passwort festlegen, ohne das temporäre zu verwenden. Das temporäre Passwort wird weiterhin benötigt, damit der anfängliche Kontodatensatz existiert, aber der Benutzer muss es sich nicht merken, wenn er den Passwort-Reset-Ablauf nutzt. + +5. **Der neue Benutzer richtet MFA ein** über sein Profilmenü. Wir empfehlen dringend, MFA für alle Benutzer auf Instanzen zu verlangen, die nicht hinter SSO liegen. + +## SSO-Benutzer + +Wenn Ihre Instanz mit [SSO](../configure_sso/) konfiguriert ist, sieht der Ablauf anders aus – Benutzer werden in der Regel beim ersten Login über den Identity Provider erstellt, und Sie müssen ihnen anschließend nur noch Gruppenmitgliedschaften oder Rollen zuweisen. + +Wenn Sie zu Open-Source-DefectDojo gewechselt sind (wo SSO nur in Pro verfügbar ist) und sich bestehende SSO-Benutzer nicht mehr anmelden können, lesen Sie [Login für SSO-Benutzer wieder aktivieren](../os__sso_user_local_login_fallback/). + +## Wiederherstellung nach einem verlorenen MFA-Token + +Wenn ein Benutzer den Zugriff auf sein MFA-Gerät verliert, lesen Sie den [Abschnitt zur MFA-Wiederherstellung](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes) im Leitfaden zur Fehlerbehebung bei der Konnektivität. Derzeit gibt es keine Möglichkeit, MFA ohne einen MFA-Code von einem Konto zu entfernen – der Workaround besteht darin, ein neues Konto für den Benutzer zu erstellen und dieselben Berechtigungen erneut zu vergeben. diff --git a/docs/content/admin/user_management/OS__creating_new_users.es.md b/docs/content/admin/user_management/OS__creating_new_users.es.md new file mode 100644 index 00000000000..e77293d202c --- /dev/null +++ b/docs/content/admin/user_management/OS__creating_new_users.es.md @@ -0,0 +1,43 @@ +--- +title: Crear un nuevo usuario +description: Cómo incorporar un nuevo usuario a su instancia de DefectDojo +audience: opensource +weight: 1 +--- + +Esta página describe el flujo de trabajo de incorporación recomendado para agregar nuevos usuarios a una instancia de DefectDojo. Los usuarios de DefectDojo se pueden usar tanto como cuentas estándar operadas por personas como cuentas de servicio. + +El administrador que crea la cuenta es responsable de entregar las credenciales iniciales (nombre de usuario y contraseña) al nuevo usuario. + +## Flujo de trabajo recomendado + +1. **Cree la cuenta de usuario** en DefectDojo (solo superusuario): + * Vaya a **👤 Usuarios → Usuarios** para abrir la tabla de Todos los usuarios. + * Haga clic en el icono 🛠️ (llave y destornillador cruzados). + * Ingrese el nombre y la dirección de correo electrónico del nuevo usuario. + * Establezca una contraseña temporal. + * Envíe el formulario. + +2. **Asigne los permisos** correspondientes — membresía de Producto/Tipo de producto, Permisos de configuración, Rol global o estado de Superusuario. Consulte [Establecer los permisos de un usuario](../set_user_permissions/) para más detalles. Un nuevo usuario sin asignaciones no podrá ver ningún Producto ni Hallazgo. + +3. **Envíe las credenciales al nuevo usuario por un canal externo** (por correo electrónico, la herramienta de chat de su equipo, o como normalmente comparta secretos). Incluya: + * La URL de la instancia de DefectDojo. + * El nombre de usuario (típicamente su dirección de correo electrónico). + * La contraseña temporal que acaba de establecer. + * Una nota indicando que deben cambiar la contraseña y habilitar MFA (si su instancia usa MFA) en el primer inicio de sesión. + +4. **El nuevo usuario inicia sesión y rota la credencial.** Puede hacerlo de dos maneras: + * Iniciar sesión con la contraseña temporal y luego cambiarla desde su menú de perfil, o + * Usar el enlace **I forgot my password** en la página de inicio de sesión para establecer una contraseña directamente sin usar la temporal. La contraseña temporal sigue siendo necesaria para que exista el registro inicial de la cuenta, pero el usuario no necesita recordarla si usa el flujo de restablecimiento de contraseña. + +5. **El nuevo usuario configura MFA** desde su menú de perfil. Recomendamos encarecidamente exigir MFA para todos los usuarios en instancias que no estén detrás de SSO. + +## Usuarios SSO + +Si su instancia está configurada con [SSO](../configure_sso/), el flujo de trabajo es diferente — los usuarios normalmente se crean en el primer inicio de sesión desde el Proveedor de identidad, y usted solo necesita otorgarles membresía de grupo o roles después. + +Si se movió a DefectDojo de código abierto (donde SSO es exclusivo de Pro) y los usuarios SSO existentes ya no pueden iniciar sesión, consulte [Restablecer el inicio de sesión para usuarios SSO](../os__sso_user_local_login_fallback/). + +## Recuperación de un token de MFA perdido + +Si un usuario pierde el acceso a su dispositivo MFA, consulte la [sección de recuperación de MFA](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes) de la guía de resolución de problemas de conectividad. Actualmente no hay forma de quitar MFA de una cuenta sin un código de MFA — la solución alternativa es crear una cuenta nueva para el usuario y volver a otorgar los mismos permisos. diff --git a/docs/content/admin/user_management/OS__creating_new_users.fr.md b/docs/content/admin/user_management/OS__creating_new_users.fr.md new file mode 100644 index 00000000000..44931cb18b6 --- /dev/null +++ b/docs/content/admin/user_management/OS__creating_new_users.fr.md @@ -0,0 +1,43 @@ +--- +title: Créer un nouvel utilisateur +description: Comment intégrer un nouvel utilisateur sur votre instance DefectDojo +audience: opensource +weight: 1 +--- + +Cette page décrit le flux d'intégration recommandé pour ajouter de nouveaux utilisateurs à une instance DefectDojo. Les utilisateurs DefectDojo peuvent être utilisés à la fois comme des comptes standards, exploités par des humains, et comme des comptes de service. + +L'administrateur qui crée le compte est responsable de la transmission des identifiants initiaux (nom d'utilisateur et mot de passe) au nouvel utilisateur. + +## Flux recommandé + +1. **Créez le compte utilisateur** dans DefectDojo (Superuser uniquement) : + * Accédez à **👤 Users → Users** pour ouvrir le tableau All Users. + * Cliquez sur l'icône 🛠️ (clé et tournevis croisés). + * Saisissez le nom et l'adresse e-mail du nouvel utilisateur. + * Définissez un mot de passe temporaire. + * Validez le formulaire. + +2. **Attribuez les permissions** appropriées — appartenance à un Produit/Type de produit, Configuration Permissions, Global Role, ou statut Superuser. Voir [Définir les permissions d'un utilisateur](../set_user_permissions/) pour plus de détails. Un nouvel utilisateur sans aucune attribution ne pourra voir aucun Produit ni aucune Constatation. + +3. **Envoyez les identifiants au nouvel utilisateur par un canal séparé** (e-mail, outil de discussion de votre équipe, ou tout autre moyen que vous utilisez habituellement pour partager des secrets). Incluez : + * L'URL de l'instance DefectDojo. + * Le nom d'utilisateur (généralement son adresse e-mail). + * Le mot de passe temporaire que vous venez de définir. + * Une note indiquant qu'il doit changer le mot de passe et activer la MFA (si votre instance l'utilise) dès la première connexion. + +4. **Le nouvel utilisateur se connecte et change l'identifiant.** Il peut soit : + * Se connecter avec le mot de passe temporaire, puis le changer depuis son menu de profil, soit + * Utiliser le lien **I forgot my password** sur la page de connexion pour définir directement un mot de passe sans utiliser le temporaire. Le mot de passe temporaire reste nécessaire pour que l'enregistrement initial du compte existe, mais l'utilisateur n'a pas besoin de s'en souvenir s'il utilise le flux de réinitialisation du mot de passe. + +5. **Le nouvel utilisateur configure la MFA** depuis son menu de profil. Nous recommandons fortement d'exiger la MFA pour tous les utilisateurs sur les instances qui ne sont pas derrière un SSO. + +## Utilisateurs SSO + +Si votre instance est configurée avec le [SSO](../configure_sso/), le flux est différent — les utilisateurs sont généralement créés lors de leur première connexion depuis le fournisseur d'identité, et vous n'avez plus qu'à leur accorder ensuite une appartenance à un groupe ou des rôles. + +Si vous êtes passé à DefectDojo open source (où le SSO est réservé à Pro) et que les utilisateurs SSO existants ne peuvent plus se connecter, consultez [Réactiver la connexion pour les utilisateurs SSO](../os__sso_user_local_login_fallback/). + +## Récupérer après la perte d'un jeton MFA + +Si un utilisateur perd l'accès à son appareil MFA, consultez la [section de récupération MFA](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes) du guide de dépannage de la connectivité. Il n'existe actuellement aucun moyen de retirer la MFA d'un compte sans code MFA — la solution de contournement consiste à créer un nouveau compte pour l'utilisateur et à lui réattribuer les mêmes permissions. diff --git a/docs/content/admin/user_management/OS__creating_new_users.ja.md b/docs/content/admin/user_management/OS__creating_new_users.ja.md new file mode 100644 index 00000000000..6d88b67bfa7 --- /dev/null +++ b/docs/content/admin/user_management/OS__creating_new_users.ja.md @@ -0,0 +1,43 @@ +--- +title: 新規ユーザーの作成 +description: DefectDojoインスタンスへ新規ユーザーをオンボーディングする方法 +audience: opensource +weight: 1 +--- + +このページでは、DefectDojoインスタンスに新規ユーザーを追加する際に推奨されるオンボーディングの流れを説明します。DefectDojoのユーザーは、人間が操作する標準アカウントとしても、サービスアカウントとしても利用できます。 + +アカウントを作成した管理者は、初期認証情報（ユーザー名とパスワード）を新規ユーザーに届ける責任を負います。 + +## 推奨されるワークフロー + +1. DefectDojoで **ユーザーアカウントを作成する**（スーパーユーザーのみ）: + * **👤 Users → Users** に移動して、All Usersテーブルを開きます。 + * 🛠️（レンチとドライバーが交差したアイコン）をクリックします。 + * 新規ユーザーの名前とメールアドレスを入力します。 + * 仮パスワードを設定します。 + * フォームを送信します。 + +2. 必要に応じて **権限を割り当てます** — 製品/製品タイプのメンバーシップ、Configuration Permissions、Global Role、またはスーパーユーザーのステータスなどです。詳細は[ユーザーの権限を設定する](../set_user_permissions/)を参照してください。何も割り当てられていない新規ユーザーは、いかなる製品や検出事項も閲覧できません。 + +3. **認証情報を新規ユーザーへ帯域外で送付します**（メール、チームのチャットツール、あるいは普段秘密情報を共有している方法など）。含める内容は次のとおりです。 + * DefectDojoインスタンスのURL。 + * ユーザー名（通常はメールアドレス）。 + * 先ほど設定した仮パスワード。 + * 初回ログイン時にパスワードを変更し、（インスタンスがMFAを使用している場合は）MFAを有効化すべき旨の注意書き。 + +4. **新規ユーザーがログインし、認証情報をローテーションします。** 次のいずれかの方法を取れます。 + * 仮パスワードでログインし、プロフィールメニューからパスワードを変更する。 + * ログインページの **I forgot my password**（パスワードを忘れた場合）リンクを使い、仮パスワードを使わずに直接パスワードを設定する。初期アカウントレコードを存在させるために仮パスワードは依然として必要ですが、パスワードリセットの流れを使う場合、ユーザーはそれを覚えておく必要はありません。 + +5. **新規ユーザーがプロフィールメニューからMFAを設定します。** SSOの背後にないインスタンスでは、すべてのユーザーにMFAを必須とすることを強く推奨します。 + +## SSOユーザー + +インスタンスが[SSO](../configure_sso/)で構成されている場合、ワークフローは異なります。ユーザーは通常、IDプロバイダーからの初回ログイン時に作成され、その後はグループメンバーシップやロールを付与するだけで済みます。 + +オープンソース版DefectDojo（SSOはPro限定機能）に移行し、既存のSSOユーザーがログインできなくなった場合は、[SSOユーザーのログインを再有効化する](../os__sso_user_local_login_fallback/)を参照してください。 + +## MFAトークンを紛失した場合の復旧 + +ユーザーがMFAデバイスへのアクセスを失った場合は、接続トラブルシューティングガイドの[MFA復旧セクション](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes)を参照してください。現時点では、MFAコードなしでアカウントからMFAを削除する方法はありません。回避策として、そのユーザー用に新しいアカウントを作成し、同じ権限を再付与してください。 diff --git a/docs/content/admin/user_management/OS__sso_user_local_login_fallback.de.md b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.de.md new file mode 100644 index 00000000000..c936618ada4 --- /dev/null +++ b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.de.md @@ -0,0 +1,58 @@ +--- +title: Login für SSO-Benutzer wieder aktivieren (Open Source) +description: Vergeben Sie über SSO bereitgestellten Benutzern ein lokales Passwort, + nachdem Sie zu Open Source gewechselt sind, wo SSO eine reine Pro-Funktion ist +audience: opensource +weight: 2 +--- + +## Wann das relevant ist + +SSO (SAML, OIDC, OAuth) ist eine Funktion von [DefectDojo Pro](https://defectdojo.com). Wenn Sie auf Open-Source-DefectDojo 3.x aktualisieren (oder anderweitig von Pro wegwechseln), werden die SSO-Login-Optionen entfernt, und Benutzer, die über SSO bereitgestellt wurden, können sich nicht mehr anmelden. Ihre Konten haben nie ein lokales Passwort erhalten, und die Benutzeroberfläche und die API lassen Sie kein Passwort für sie festlegen: DefectDojo erkennt sie als SSO-Konten und blockiert die Änderung. + +Sie müssen diese Benutzer **nicht** löschen und neu anlegen (wodurch deren Verlauf, Berechtigungen und Objekteigentümerschaft verloren gingen). Vergeben Sie stattdessen für jedes Konto im Backend ein lokales Passwort und erzwingen Sie beim nächsten Login einen Passwort-Reset. + +Hintergrundinformationen dazu, dass SSO nur in Pro verfügbar ist, finden Sie im [SSO-Abschnitt](/admin/sso/) und in den [Upgrade-Hinweisen zu 3.0](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only). + +## Warum das passiert + +Open-Source-DefectDojo authentifiziert ausschließlich gegen die lokale Benutzerdatenbank von Django. Ob ein Konto ein „SSO-Benutzer“ ist, wird ausschließlich daran entschieden, ob das Konto ein nutzbares Passwort hat. Über SSO bereitgestellte Konten wurden mit einem *nicht nutzbaren* Passwort erstellt, daher: + +* schlägt der lokale Login fehl (es gibt kein Passwort zum Prüfen), und +* wird das Bedienelement **Force password reset** in der Benutzeroberfläche und der API blockiert, mit einer Meldung, dass der Benutzer über SSO autorisiert ist. + +Das Setzen eines echten Passworts hebt beide Bedingungen gleichzeitig auf: Das Konto kann sich lokal anmelden, und das Flag für den erzwungenen Reset kann gesetzt werden. + +## Der Workaround + +Führen Sie diese Schritte über die Django-Shell im Container `uwsgi` aus: + +```bash +docker compose exec -it uwsgi ./manage.py shell +``` + +### Beispiel für einen einzelnen Benutzer + +```python +from dojo.user.models import Dojo_User, UserContactInfo + +u = Dojo_User.objects.get(username="alice@example.com") +u.set_password("") # makes the account a local login account +u.save() + +uci, _ = UserContactInfo.objects.get_or_create(user=u) +uci.force_password_reset = True # force a change on next login +uci.save() +``` + +## Was der Benutzer als Nächstes tut + +Übermitteln Sie jedem Benutzer das temporäre Passwort außerhalb des Systems (E-Mail, Team-Chat, oder wie Sie sonst Geheimnisse teilen). Beim nächsten Login leitet DefectDojo den Benutzer auf die Seite **Change Password** um und lässt ihn nirgendwo anders hin, bis er sein eigenes Passwort festgelegt hat. Das Flag für den erzwungenen Reset wird danach automatisch zurückgesetzt. + +Wenn auf Ihrer Instanz der Ablauf „I forgot my password“ aktiviert ist (`DD_FORGOT_PASSWORD`, standardmäßig aktiv) und E-Mail konfiguriert ist, können Benutzer stattdessen den Link **I forgot my password** auf der Login-Seite verwenden, sobald ihr Konto ein nutzbares Passwort hat, und ein Passwort festlegen, ohne das temporäre zu benötigen. + +## Hinweise + +* **Kubernetes:** Führen Sie die Shell stattdessen im Django-Pod aus, z. B. `kubectl exec -it deploy/defectdojo-django -c uwsgi -- ./manage.py shell` (passen Sie Deployment- und Containernamen an Ihr Release an). +* Wählen Sie ein starkes Wegwerf-Passwort. Da `force_password_reset = True` gesetzt ist, kann der Benutzer es nicht behalten – es muss also nur einen Login überstehen. +* Behalten Sie mindestens ein funktionierendes lokales Admin-Konto, damit Sie niemals ausgesperrt werden. diff --git a/docs/content/admin/user_management/OS__sso_user_local_login_fallback.es.md b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.es.md new file mode 100644 index 00000000000..a4c1b0c206d --- /dev/null +++ b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.es.md @@ -0,0 +1,58 @@ +--- +title: Restablecer el inicio de sesión para usuarios SSO (código abierto) +description: Otorgar una contraseña local a los usuarios aprovisionados por SSO tras + pasar a código abierto, donde SSO es una función exclusiva de Pro +audience: opensource +weight: 2 +--- + +## Cuándo se aplica esto + +SSO (SAML, OIDC, OAuth) es una función de [DefectDojo Pro](https://defectdojo.com). Si actualiza a DefectDojo de código abierto 3.x (o de otro modo deja de usar Pro), las opciones de inicio de sesión con SSO se eliminan, y los usuarios que fueron aprovisionados mediante SSO ya no pueden iniciar sesión. Sus cuentas nunca recibieron una contraseña local, y la interfaz y la API no le permitirán establecer una para ellos: DefectDojo los detecta como cuentas SSO y bloquea el cambio. + +**No** necesita eliminar y volver a crear estos usuarios (lo cual haría perder su historial, permisos y propiedad de objetos). En su lugar, otorgue a cada cuenta una contraseña local en el backend y fuerce un restablecimiento de contraseña en el siguiente inicio de sesión. + +Consulte la [sección de SSO](/admin/sso/) y las [notas de actualización de la 3.0](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only) para más contexto sobre por qué SSO es exclusivo de Pro. + +## Por qué ocurre + +DefectDojo de código abierto autentica únicamente contra la base de datos de usuarios local de Django. Decide si una cuenta es un "usuario SSO" únicamente en función de si la cuenta tiene una contraseña utilizable. Las cuentas aprovisionadas por SSO se crearon con una contraseña *no utilizable*, por lo que: + +* el inicio de sesión local falla (no hay contraseña que verificar), y +* el control **Force password reset** de la interfaz y la API está bloqueado, con un mensaje de que el usuario está autorizado mediante SSO. + +Establecer una contraseña real resuelve ambas condiciones a la vez: la cuenta puede iniciar sesión localmente, y el indicador de restablecimiento forzado se vuelve configurable. + +## La solución alternativa + +Ejecute estos pasos desde el shell de Django dentro del contenedor `uwsgi`: + +```bash +docker compose exec -it uwsgi ./manage.py shell +``` + +### Ejemplo para un solo usuario + +```python +from dojo.user.models import Dojo_User, UserContactInfo + +u = Dojo_User.objects.get(username="alice@example.com") +u.set_password("") # makes the account a local login account +u.save() + +uci, _ = UserContactInfo.objects.get_or_create(user=u) +uci.force_password_reset = True # force a change on next login +uci.save() +``` + +## Qué hace el usuario a continuación + +Entregue la contraseña temporal a cada usuario por un canal externo (correo electrónico, el chat de su equipo, o como normalmente comparta secretos). En su próximo inicio de sesión, DefectDojo los redirige a la página **Change Password** y no les permitirá ir a ningún otro lado hasta que establezcan su propia contraseña. El indicador de restablecimiento forzado se borra automáticamente una vez que lo hacen. + +Si su instancia tiene habilitado el flujo "I forgot my password" (`DD_FORGOT_PASSWORD`, activado de forma predeterminada) y el correo electrónico configurado, los usuarios pueden en cambio usar el enlace **I forgot my password** en la página de inicio de sesión una vez que su cuenta tenga una contraseña utilizable, y establecer una contraseña sin necesitar la temporal. + +## Notas + +* **Kubernetes:** en su lugar, ejecute el shell en el pod de Django, por ejemplo `kubectl exec -it deploy/defectdojo-django -c uwsgi -- ./manage.py shell` (ajuste los nombres de deployment y contenedor a su versión). +* Elija una contraseña descartable y segura. Con `force_password_reset = True` el usuario no puede conservarla, así que solo necesita durar un inicio de sesión. +* Mantenga al menos una cuenta de administrador local funcional para no quedar nunca bloqueado. diff --git a/docs/content/admin/user_management/OS__sso_user_local_login_fallback.fr.md b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.fr.md new file mode 100644 index 00000000000..fe84b8c9942 --- /dev/null +++ b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.fr.md @@ -0,0 +1,58 @@ +--- +title: Réactiver la connexion pour les utilisateurs SSO (Open Source) +description: Donner un mot de passe local aux utilisateurs provisionnés via SSO après + un passage à Open Source, où le SSO est une fonctionnalité réservée à Pro +audience: opensource +weight: 2 +--- + +## Quand cela s'applique + +SSO (SAML, OIDC, OAuth) est une fonctionnalité de [DefectDojo Pro](https://defectdojo.com). Si vous effectuez une mise à niveau vers DefectDojo open source 3.x (ou si vous quittez Pro d'une autre manière), les options de connexion SSO sont supprimées, et les utilisateurs provisionnés via SSO ne peuvent plus se connecter. Leurs comptes n'ont jamais reçu de mot de passe local, et l'interface comme l'API ne vous permettent pas d'en définir un pour eux : DefectDojo les détecte comme des comptes SSO et bloque le changement. + +Il n'est **pas** nécessaire de supprimer et de recréer ces utilisateurs (ce qui ferait perdre leur historique, leurs permissions et la propriété de leurs objets). À la place, donnez à chaque compte un mot de passe local côté backend et forcez une réinitialisation du mot de passe à la prochaine connexion. + +Consultez la [section SSO](/admin/sso/) et les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only) pour comprendre le contexte du SSO réservé à Pro. + +## Pourquoi cela se produit + +DefectDojo open source s'authentifie uniquement par rapport à la base de données d'utilisateurs locale de Django. Il détermine si un compte est un « utilisateur SSO » uniquement selon que le compte dispose ou non d'un mot de passe utilisable. Les comptes provisionnés via SSO ont été créés avec un mot de passe *inutilisable*, donc : + +* la connexion locale échoue (il n'y a pas de mot de passe à vérifier), et +* le contrôle **Force password reset** dans l'interface et l'API est bloqué, avec un message indiquant que l'utilisateur est autorisé via le SSO. + +Définir un véritable mot de passe lève les deux conditions à la fois : le compte peut se connecter localement, et l'indicateur de réinitialisation forcée devient modifiable. + +## La solution de contournement + +Exécutez ces étapes depuis le shell Django à l'intérieur du conteneur `uwsgi` : + +```bash +docker compose exec -it uwsgi ./manage.py shell +``` + +### Exemple pour un seul utilisateur + +```python +from dojo.user.models import Dojo_User, UserContactInfo + +u = Dojo_User.objects.get(username="alice@example.com") +u.set_password("") # makes the account a local login account +u.save() + +uci, _ = UserContactInfo.objects.get_or_create(user=u) +uci.force_password_reset = True # force a change on next login +uci.save() +``` + +## Ce que fait l'utilisateur ensuite + +Transmettez le mot de passe temporaire à chaque utilisateur par un canal séparé (e-mail, discussion d'équipe, ou tout autre moyen habituel de partage de secrets). À sa prochaine connexion, DefectDojo le redirige vers la page **Change Password** et ne le laisse aller nulle part ailleurs tant qu'il n'a pas défini son propre mot de passe. L'indicateur de réinitialisation forcée se réinitialise automatiquement une fois cela fait. + +Si votre instance a le flux « I forgot my password » activé (`DD_FORGOT_PASSWORD`, activé par défaut) et l'e-mail configuré, les utilisateurs peuvent à la place utiliser le lien **I forgot my password** sur la page de connexion une fois que leur compte dispose d'un mot de passe utilisable, et définir un mot de passe sans avoir besoin du temporaire. + +## Remarques + +* **Kubernetes :** exécutez plutôt le shell dans le pod Django, par exemple `kubectl exec -it deploy/defectdojo-django -c uwsgi -- ./manage.py shell` (ajustez les noms de déploiement et de conteneur à votre version). +* Choisissez un mot de passe jetable robuste. Avec `force_password_reset = True`, l'utilisateur ne peut pas le conserver, il n'a donc besoin de survivre qu'à une seule connexion. +* Conservez au moins un compte administrateur local fonctionnel afin de ne jamais être bloqué. diff --git a/docs/content/admin/user_management/OS__sso_user_local_login_fallback.ja.md b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.ja.md new file mode 100644 index 00000000000..ba771a1456e --- /dev/null +++ b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.ja.md @@ -0,0 +1,57 @@ +--- +title: SSOユーザーのログインを再有効化する（オープンソース版） +description: SSOがPro限定機能であるオープンソース版に移行した後、SSOでプロビジョニングされたユーザーにローカルパスワードを付与する方法 +audience: opensource +weight: 2 +--- + +## この手順が該当するケース + +SSO（SAML、OIDC、OAuth）は[DefectDojo Pro](https://defectdojo.com)の機能です。オープンソース版DefectDojo 3.xにアップグレードする（あるいは何らかの理由でProから離れる）と、SSOのログインオプションは削除され、SSO経由でプロビジョニングされていたユーザーはログインできなくなります。それらのアカウントにはローカルパスワードが一度も設定されていないため、UIやAPIから設定しようとしても、DefectDojoがそれらをSSOアカウントとして検出し、変更をブロックします。 + +これらのユーザーを削除して作り直す必要は**ありません**（それでは履歴、権限、オブジェクトの所有権が失われてしまいます）。代わりに、バックエンドで各アカウントにローカルパスワードを付与し、次回ログイン時にパスワードのリセットを強制してください。 + +SSOがPro限定である背景については、[SSOのセクション](/admin/sso/)と[3.0アップグレードノート](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only)を参照してください。 + +## 発生する理由 + +オープンソース版DefectDojoは、Djangoのローカルユーザーデータベースに対してのみ認証を行います。あるアカウントが「SSOユーザー」かどうかは、そのアカウントが使用可能なパスワードを持っているかどうかだけで判定されます。SSOでプロビジョニングされたアカウントは*使用不可能な*パスワードで作成されているため、次のようになります。 + +* ローカルログインは失敗します（チェックすべきパスワードが存在しないため）。 +* UIおよびAPIの **Force password reset**（パスワードリセットの強制）コントロールはブロックされ、そのユーザーはSSO経由で認証されている旨のメッセージが表示されます。 + +実際のパスワードを設定すると、この両方の条件が同時に解消されます。アカウントはローカルでログインできるようになり、強制リセットフラグも設定できるようになります。 + +## 回避策 + +以下の手順は、`uwsgi` コンテナ内のDjangoシェルから実行します。 + +```bash +docker compose exec -it uwsgi ./manage.py shell +``` + +### 単一ユーザーの例 + +```python +from dojo.user.models import Dojo_User, UserContactInfo + +u = Dojo_User.objects.get(username="alice@example.com") +u.set_password("") # makes the account a local login account +u.save() + +uci, _ = UserContactInfo.objects.get_or_create(user=u) +uci.force_password_reset = True # force a change on next login +uci.save() +``` + +## ユーザーが次に行うこと + +仮パスワードは各ユーザーへ帯域外で届けてください（メール、チームのチャット、あるいは普段秘密情報を共有している方法など）。次回ログイン時、DefectDojoはユーザーを **Change Password**（パスワード変更）ページへリダイレクトし、自分自身のパスワードを設定するまで他のどこにも進めないようにします。設定が完了すると、強制リセットフラグは自動的に解除されます。 + +インスタンスで「I forgot my password」（パスワードを忘れた場合）のフローが有効になっており（`DD_FORGOT_PASSWORD`、デフォルトで有効）、メールが設定されている場合、アカウントが使用可能なパスワードを持つようになった後は、ユーザーはログインページの **I forgot my password** リンクを使い、仮パスワードを使わずにパスワードを設定することもできます。 + +## 補足 + +* **Kubernetes:** 代わりにDjangoのPod内でシェルを実行します。例: `kubectl exec -it deploy/defectdojo-django -c uwsgi -- ./manage.py shell`（デプロイメント名とコンテナ名は環境に合わせて調整してください）。 +* 強力な使い捨てパスワードを選んでください。`force_password_reset = True` によりユーザーはそれを使い続けることができないため、1回のログインに耐えられれば十分です。 +* ロックアウトされないよう、動作するローカル管理者アカウントを少なくとも1つは維持してください。 diff --git a/docs/content/admin/user_management/PRO__audit_log_index.de.md b/docs/content/admin/user_management/PRO__audit_log_index.de.md new file mode 100644 index 00000000000..0d66bd26e09 --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_log_index.de.md @@ -0,0 +1,133 @@ +--- +title: Audit-Protokollierung +description: Jede Erstellungs-, Aktualisierungs- und Löschaktion, die DefectDojo in + seinem Audit-Protokoll erfasst, sowie was aufgezeichnet wird und wie Sie die Aufbewahrung + konfigurieren. +draft: false +weight: 4 +--- + +DefectDojo zeichnet einen Audit-Trail der Änderungen an seinen Daten auf. Jedes verfolgte Objekt zeichnet automatisch Ereignisse für **Erstellen**, **Aktualisieren** und **Löschen** auf, und Beziehungstabellen (many-to-many) zeichnen Ereignisse für **Hinzufügen** und **Entfernen** auf. + +## Funktionsweise + +Die Audit-Verfolgung wird durch Datenbank-Trigger gesteuert, die pro Modell registriert sind. Für jedes +verfolgte Objekt können drei Ereignistypen ausgelöst werden: + +| Ereignistyp | Wann es ausgelöst wird | Aktion | +| ------------- | ----------------------------------------------------------------------------- | ---------- | +| `InsertEvent` | Ein neuer Datensatz wird erstellt | **Erstellen** | +| `UpdateEvent` | Ein Datensatz ändert sich — nur wenn sich ein tatsächlicher Feldwert wirklich ändert | **Aktualisieren** | +| `DeleteEvent` | Ein Datensatz wird gelöscht | **Löschen** | + +Many-to-many-Beziehungstabellen (Tags, Reviewer, Firewall-IP-Bereiche) verfolgen +nur **Hinzufügen** (`InsertEvent`) und **Entfernen** (`DeleteEvent`) — für eine Beziehungszeile gibt es kein +„Update“. + +### Was bei jedem Ereignis erfasst wird + +- **Wer** — der handelnde Benutzer, entnommen aus dem Request-Kontext. +- **Wann** — ein Zeitstempel. +- **Quell-IP** — die Remote-Adresse, unter Berücksichtigung von `X-Forwarded-For`-Proxy-Ketten. +- **Vorher-/Nachher-Snapshot** — die vollständigen Feldwerte des Datensatzes. +- **Context / Label** — gruppiert Ereignisse, die aus derselben Anfrage stammen. Das + Label `initial_backfill` kennzeichnet historische Datensätze, die importiert wurden, als die Verfolgung + erstmals aktiviert wurde. + +Ereignisse, die von Hintergrundjobs erzeugt werden, werden dem Kontext +der ursprünglichen Anfrage wieder zugeordnet, sodass eine asynchron abgeschlossene Aktion weiterhin +dem Benutzer zugeschrieben wird, der sie ausgelöst hat. + +## Core (Open Source) — verfolgte Aktionen + +| Objekt | Erstellen | Aktualisieren | Löschen | Notizen | +| ------------------------------ | :----: | :----: | :----: | ---------------------------------------------- | +| Benutzer | ✅ | ✅ | ✅ | `password` von Snapshots ausgeschlossen | +| Produkttyp | ✅ | ✅ | ✅ | | +| Produkt | ✅ | ✅ | ✅ | | +| Engagement | ✅ | ✅ | ✅ | | +| Test | ✅ | ✅ | ✅ | | +| Befund | ✅ | ✅ | ✅ | | +| Befundgruppe | ✅ | ✅ | ✅ | | +| Befundvorlage | ✅ | ✅ | ✅ | | +| Risikoakzeptanz | ✅ | ✅ | ✅ | | +| Endpunkt | ✅ | ✅ | ✅ | | +| Location | ✅ | ✅ | ✅ | | +| URL | ✅ | ✅ | ✅ | | +| Benachrichtigungs-Webhook | ✅ | ✅ | ✅ | `header_name` / `header_value` ausgeschlossen (Geheimnisse) | + +### Core — Beziehungsereignisse (Add / Remove) + +| Beziehung | Hinzufügen | Entfernen | +| ---------------------------------- | :-: | :----: | +| Befund → Reviewer | ✅ | ✅ | +| Befund → Tags | ✅ | ✅ | +| Befund → Geerbte Tags | ✅ | ✅ | +| Produkt → Tags | ✅ | ✅ | +| Engagement → Tags | ✅ | ✅ | +| Engagement → Geerbte Tags | ✅ | ✅ | +| Test → Tags | ✅ | ✅ | +| Test → Geerbte Tags | ✅ | ✅ | +| Endpunkt → Tags | ✅ | ✅ | +| Endpunkt → Geerbte Tags | ✅ | ✅ | +| Befundvorlage → Tags | ✅ | ✅ | +| App-Analyse (Technologie) → Tags | ✅ | ✅ | +| Objekte/Produkt → Tags | ✅ | ✅ | + +## Pro — verfolgte Aktionen + +| Objekt | Erstellen | Aktualisieren | Löschen | Notizen | +| --------------------------------- | :----: | :----: | :----: | ------------------------------ | +| Erweiterter Befund | ✅ | ✅ | ✅ | Pro-Pendant zum Befund | +| Regel | ✅ | ✅ | ✅ | Regel-Engine | +| Regelaktion | ✅ | ✅ | ✅ | | +| Regelaktionsbedingung | ✅ | ✅ | ✅ | | +| Regelfiltereintrag | ✅ | ✅ | ✅ | | +| Regel-Engine-Vorgang | ✅ | ✅ | ✅ | | +| Regel-Engine-Vorgangsmeldung | ✅ | ✅ | ✅ | | +| Geplanter Task | ✅ | ✅ | ✅ | | +| Lauf eines geplanten Tasks | ✅ | ✅ | ✅ | | +| Mitigationsrichtlinie | ✅ | ✅ | ✅ | | +| Anpassbare Einstellung | ✅ | ✅ | ✅ | Systemkonfigurationsänderungen | +| Feature-Flag-Status | ✅ | ✅ | ✅ | Flag-Umschaltungen + System-Pins | +| Feature-Flag-Definition | ✅ | ✅ | ✅ | Metadaten / Registry-Synchronisierung | +| Cloud-Firewall | ✅ | ✅ | ✅ | Feld `locked` ausgeschlossen | +| Firewall-IP-Maske | ✅ | ✅ | ✅ | | + +### Pro — RBAC / Berechtigungen + +| Objekt | Erstellen | Aktualisieren | Löschen | +| ----------------------------- | :----: | :----: | :----: | +| Gruppe | ✅ | ✅ | ✅ | +| Rolle | ✅ | ✅ | ✅ | +| Gruppenmitgliedschaft | ✅ | ✅ | ✅ | +| Globale Rolle | ✅ | ✅ | ✅ | +| Produkt-Gruppen-Zuweisung | ✅ | ✅ | ✅ | +| Produkttyp-Gruppen-Zuweisung | ✅ | ✅ | ✅ | +| Produktmitglied | ✅ | ✅ | ✅ | +| Produkttyp-Mitglied | ✅ | ✅ | ✅ | + +### Pro — Beziehungsereignisse (Add / Remove) + +| Beziehung | Hinzufügen | Entfernen | +| --------------------------- | :-: | :----: | +| Cloud-Firewall → IP-Bereiche | ✅ | ✅ | + +## Konfiguration und Aufbewahrung (On-Premise Controls) + +| Einstellung | Umgebungsvariable | Standardwert | Auswirkung | +| -------------------- | ------------------------------------- | ------------------ | ------------------------------------------------------------------ | +| Audit-Protokollierung aktivieren | `DD_ENABLE_AUDITLOG` | `True` | Bei `False` werden alle History-Trigger deaktiviert und es werden keine Ereignisse aufgezeichnet | +| Aufbewahrungszeitraum | `DD_AUDITLOG_FLUSH_RETENTION_PERIOD` | `-1` (nie leeren) | Anzahl der Monate an Historie, die aufbewahrt werden; ältere Ereignisse werden vom Flush-Job stapelweise gelöscht | +| Flush-Batchgröße | `DD_AUDITLOG_FLUSH_BATCH_SIZE` | `1000` | Pro Batch gelöschte Zeilen während der Bereinigung | +| Maximale Flush-Batches | `DD_AUDITLOG_FLUSH_MAX_BATCHES` | `100` | Obergrenze für die Anzahl der Batches pro Flush-Lauf | + +## Hinweise und Einschränkungen + +- **Geheimnisse werden niemals erfasst.** Benutzerpasswörter und die Header-Werte von Benachrichtigungs-Webhooks + sind ausdrücklich von Ereignis-Snapshots ausgeschlossen. +- **Updates werden nur bei einer echten Änderung aufgezeichnet.** Ein Speichervorgang, der keinen + Feldwert ändert, erzeugt kein Update-Ereignis; automatisch verwaltete Felder wie + `last_updated` allein lösen keines aus. +- **Authentifizierungsereignisse werden hier nicht erfasst.** Nur + Datenänderungen. Login-, Logout- und fehlgeschlagene Login-Versuche werden separat behandelt und sind nicht Teil dieses Audit-Protokolls. diff --git a/docs/content/admin/user_management/PRO__audit_log_index.es.md b/docs/content/admin/user_management/PRO__audit_log_index.es.md new file mode 100644 index 00000000000..02666375b52 --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_log_index.es.md @@ -0,0 +1,121 @@ +--- +title: Registro de auditoría +description: Cada acción de creación, actualización y eliminación que DefectDojo registra + en su registro de auditoría, además de qué se captura y cómo configurar la retención. +draft: false +weight: 4 +--- + +DefectDojo registra un rastro de auditoría de los cambios en sus datos. Cada objeto rastreado registra automáticamente eventos de **creación**, **actualización** y **eliminación**, y las tablas de relación (muchos a muchos) registran eventos de **agregado** y **eliminación**. + +## Cómo funciona + +El rastreo de auditoría está impulsado por disparadores de base de datos registrados por modelo. Para cada objeto rastreado, pueden dispararse tres tipos de eventos: + +| Tipo de evento | Cuándo se dispara | Acción | +| ------------- | ----------------------------------------------------------------------------- | ---------- | +| `InsertEvent` | Se crea un nuevo registro | **Creación** | +| `UpdateEvent` | Un registro cambia — solo cuando el valor de un campo real realmente cambia | **Actualización** | +| `DeleteEvent` | Se elimina un registro | **Eliminación** | + +Las tablas de relación muchos a muchos (etiquetas, revisores, rangos de IP de firewall) rastrean solo **agregado** (`InsertEvent`) y **eliminación** (`DeleteEvent`) — no existe una "actualización" para una fila de relación. + +### Qué se captura con cada evento + +- **Quién** — el usuario que realiza la acción, tomado del contexto de la solicitud. +- **Cuándo** — una marca de tiempo. +- **IP de origen** — la dirección remota, respetando las cadenas de proxy `X-Forwarded-For`. +- **Instantánea antes/después** — los valores completos de los campos del registro. +- **Contexto / etiqueta** — agrupa los eventos originados en la misma solicitud. La etiqueta `initial_backfill` marca los registros históricos importados cuando se habilitó el rastreo por primera vez. + +Los eventos producidos por trabajos en segundo plano se vuelven a vincular al contexto de la solicitud de origen, de modo que una acción completada de forma asíncrona sigue atribuyéndose al usuario que la originó. + +## Core (Open Source) — acciones rastreadas + +| Objeto | Creación | Actualización | Eliminación | Notas | +| ------------------------------ | :----: | :----: | :----: | ---------------------------------------------- | +| Usuario | ✅ | ✅ | ✅ | `password` excluido de las instantáneas | +| Tipo de producto | ✅ | ✅ | ✅ | | +| Producto | ✅ | ✅ | ✅ | | +| Compromiso | ✅ | ✅ | ✅ | | +| Test | ✅ | ✅ | ✅ | | +| Hallazgo | ✅ | ✅ | ✅ | | +| Grupo de hallazgos | ✅ | ✅ | ✅ | | +| Plantilla de hallazgo | ✅ | ✅ | ✅ | | +| Aceptación de riesgo | ✅ | ✅ | ✅ | | +| Endpoint | ✅ | ✅ | ✅ | | +| Ubicación | ✅ | ✅ | ✅ | | +| URL | ✅ | ✅ | ✅ | | +| Webhook de notificación | ✅ | ✅ | ✅ | `header_name` / `header_value` excluidos (secretos) | + +### Core — eventos de relación (agregado / eliminación) + +| Relación | Agregado | Eliminación | +| ---------------------------------- | :-: | :----: | +| Hallazgo → Revisores | ✅ | ✅ | +| Hallazgo → Etiquetas | ✅ | ✅ | +| Hallazgo → Etiquetas heredadas | ✅ | ✅ | +| Producto → Etiquetas | ✅ | ✅ | +| Compromiso → Etiquetas | ✅ | ✅ | +| Compromiso → Etiquetas heredadas | ✅ | ✅ | +| Test → Etiquetas | ✅ | ✅ | +| Test → Etiquetas heredadas | ✅ | ✅ | +| Endpoint → Etiquetas | ✅ | ✅ | +| Endpoint → Etiquetas heredadas | ✅ | ✅ | +| Plantilla de hallazgo → Etiquetas | ✅ | ✅ | +| Análisis de aplicaciones (Tecnología) → Etiquetas | ✅ | ✅ | +| Objetos/Producto → Etiquetas | ✅ | ✅ | + +## Pro — acciones rastreadas + +| Objeto | Creación | Actualización | Eliminación | Notas | +| --------------------------------- | :----: | :----: | :----: | ------------------------------ | +| Hallazgo mejorado | ✅ | ✅ | ✅ | Complemento Pro de Hallazgo | +| Regla | ✅ | ✅ | ✅ | Motor de reglas | +| Acción de regla | ✅ | ✅ | ✅ | | +| Condición de acción de regla | ✅ | ✅ | ✅ | | +| Entrada de filtro de regla | ✅ | ✅ | ✅ | | +| Operación del motor de reglas | ✅ | ✅ | ✅ | | +| Mensaje de operación del motor de reglas | ✅ | ✅ | ✅ | | +| Tarea programada | ✅ | ✅ | ✅ | | +| Ejecución de tarea programada | ✅ | ✅ | ✅ | | +| Política de mitigación | ✅ | ✅ | ✅ | | +| Ajuste configurable | ✅ | ✅ | ✅ | Cambios de configuración del sistema | +| Estado de indicador de función | ✅ | ✅ | ✅ | Activaciones/desactivaciones + fijaciones del sistema | +| Definición de indicador de función | ✅ | ✅ | ✅ | Metadatos / sincronización de registro | +| Firewall en la nube | ✅ | ✅ | ✅ | Campo `locked` excluido | +| Máscara de IP de firewall | ✅ | ✅ | ✅ | | + +### Pro — RBAC / permisos + +| Objeto | Creación | Actualización | Eliminación | +| ----------------------------- | :----: | :----: | :----: | +| Grupo | ✅ | ✅ | ✅ | +| Rol | ✅ | ✅ | ✅ | +| Membresía de grupo | ✅ | ✅ | ✅ | +| Rol global | ✅ | ✅ | ✅ | +| Asignación de grupo a producto | ✅ | ✅ | ✅ | +| Asignación de grupo a tipo de producto | ✅ | ✅ | ✅ | +| Miembro de producto | ✅ | ✅ | ✅ | +| Miembro de tipo de producto | ✅ | ✅ | ✅ | + +### Pro — eventos de relación (agregado / eliminación) + +| Relación | Agregado | Eliminación | +| --------------------------- | :-: | :----: | +| Firewall en la nube → Rangos de IP | ✅ | ✅ | + +## Configuración y retención (controles on-premise) + +| Ajuste | Variable de entorno | Predeterminado | Efecto | +| -------------------- | ------------------------------------- | ------------------ | ------------------------------------------------------------------ | +| Habilitar el registro de auditoría | `DD_ENABLE_AUDITLOG` | `True` | Cuando es `False`, todos los disparadores de historial se deshabilitan y no se registra ningún evento | +| Período de retención | `DD_AUDITLOG_FLUSH_RETENTION_PERIOD` | `-1` (nunca purgar) | Meses de historial a conservar; los eventos más antiguos se eliminan por lotes mediante el trabajo de purga | +| Tamaño de lote de purga | `DD_AUDITLOG_FLUSH_BATCH_SIZE` | `1000` | Filas eliminadas por lote durante la limpieza | +| Máximo de lotes de purga | `DD_AUDITLOG_FLUSH_MAX_BATCHES` | `100` | Límite en la cantidad de lotes por ejecución de purga | + +## Notas y limitaciones + +- **Los secretos nunca se capturan.** Las contraseñas de usuario y los valores de encabezado de los webhooks de notificación se excluyen explícitamente de las instantáneas de eventos. +- **Las actualizaciones solo se registran ante un cambio real.** Un guardado que no altera ningún valor de campo no genera ningún evento de actualización; los campos autogestionados, como `last_updated` por sí solo, no disparan uno. +- **Los eventos de autenticación no se capturan aquí.** Solo cambios de datos. El inicio de sesión, el cierre de sesión y los intentos fallidos de inicio de sesión se gestionan por separado y no forman parte de este registro de auditoría. diff --git a/docs/content/admin/user_management/PRO__audit_log_index.fr.md b/docs/content/admin/user_management/PRO__audit_log_index.fr.md new file mode 100644 index 00000000000..3e86d049990 --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_log_index.fr.md @@ -0,0 +1,134 @@ +--- +title: Journalisation d'audit +description: Chaque action de création, de mise à jour et de suppression que DefectDojo + enregistre dans son journal d'audit, ainsi que ce qui est capturé et comment configurer + la rétention. +draft: false +weight: 4 +--- + +DefectDojo enregistre une piste d'audit des modifications apportées à ses données. Chaque objet suivi +enregistre automatiquement les événements de **création**, de **mise à jour** et de **suppression**, et les tables de relation +(many-to-many) enregistrent les événements d'**ajout** et de **retrait**. + +## Fonctionnement + +Le suivi d'audit est piloté par des déclencheurs (triggers) de base de données enregistrés par modèle. Pour chaque +objet suivi, trois types d'événements peuvent se déclencher : + +| Type d'événement | Quand il se déclenche | Action | +| ------------- | ----------------------------------------------------------------------------- | ---------- | +| `InsertEvent` | Un nouvel enregistrement est créé | **Création** | +| `UpdateEvent` | Un enregistrement change — uniquement lorsqu'une valeur de champ change réellement | **Mise à jour** | +| `DeleteEvent` | Un enregistrement est supprimé | **Suppression** | + +Les tables de relation many-to-many (étiquettes, réviseurs, plages IP de pare-feu) suivent +uniquement l'**ajout** (`InsertEvent`) et le **retrait** (`DeleteEvent`) — il n'existe pas +de « mise à jour » pour une ligne de relation. + +### Ce qui est capturé à chaque événement + +- **Who** — l'utilisateur à l'origine de l'action, tiré du contexte de la requête. +- **When** — un horodatage. +- **Source IP** — l'adresse distante, en tenant compte des chaînes de proxy `X-Forwarded-For`. +- **Before/after snapshot** — les valeurs complètes des champs de l'enregistrement. +- **Context / label** — regroupe les événements provenant de la même requête. L'étiquette + `initial_backfill` marque les enregistrements historiques importés lors de l'activation initiale du + suivi. + +Les événements produits par des tâches de fond sont rattachés au contexte de la requête +d'origine, de sorte qu'une action effectuée de manière asynchrone est tout de même attribuée à l'utilisateur qui l'a déclenchée. + +## Core (Open Source) — actions suivies + +| Objet | Création | Mise à jour | Suppression | Remarques | +| ------------------------------ | :----: | :----: | :----: | ---------------------------------------------- | +| Utilisateur | ✅ | ✅ | ✅ | `password` exclu des instantanés | +| Type de produit | ✅ | ✅ | ✅ | | +| Produit | ✅ | ✅ | ✅ | | +| Engagement | ✅ | ✅ | ✅ | | +| Test | ✅ | ✅ | ✅ | | +| Constatation | ✅ | ✅ | ✅ | | +| Groupe de constatations | ✅ | ✅ | ✅ | | +| Modèle de constatation | ✅ | ✅ | ✅ | | +| Acceptation du risque | ✅ | ✅ | ✅ | | +| Point de terminaison | ✅ | ✅ | ✅ | | +| Emplacement | ✅ | ✅ | ✅ | | +| URL | ✅ | ✅ | ✅ | | +| Webhook de notification | ✅ | ✅ | ✅ | `header_name` / `header_value` exclus (secrets) | + +### Core — événements de relation (ajout / retrait) + +| Relation | Ajout | Retrait | +| ---------------------------------- | :-: | :----: | +| Constatation → Réviseurs | ✅ | ✅ | +| Constatation → Étiquettes | ✅ | ✅ | +| Constatation → Étiquettes héritées | ✅ | ✅ | +| Produit → Étiquettes | ✅ | ✅ | +| Engagement → Étiquettes | ✅ | ✅ | +| Engagement → Étiquettes héritées | ✅ | ✅ | +| Test → Étiquettes | ✅ | ✅ | +| Test → Étiquettes héritées | ✅ | ✅ | +| Point de terminaison → Étiquettes | ✅ | ✅ | +| Point de terminaison → Étiquettes héritées | ✅ | ✅ | +| Modèle de constatation → Étiquettes | ✅ | ✅ | +| Analyse d'application (Technologie) → Étiquettes | ✅ | ✅ | +| Objets/Produit → Étiquettes | ✅ | ✅ | + +## Pro — actions suivies + +| Objet | Création | Mise à jour | Suppression | Remarques | +| --------------------------------- | :----: | :----: | :----: | ------------------------------ | +| Constatation enrichie | ✅ | ✅ | ✅ | Équivalent Pro de Finding | +| Règle | ✅ | ✅ | ✅ | Moteur de règles | +| Action de règle | ✅ | ✅ | ✅ | | +| Condition d'action de règle | ✅ | ✅ | ✅ | | +| Entrée de filtre de règle | ✅ | ✅ | ✅ | | +| Opération du moteur de règles | ✅ | ✅ | ✅ | | +| Message d'opération du moteur de règles | ✅ | ✅ | ✅ | | +| Tâche planifiée | ✅ | ✅ | ✅ | | +| Exécution de tâche planifiée | ✅ | ✅ | ✅ | | +| Politique d'atténuation | ✅ | ✅ | ✅ | | +| Paramètre ajustable | ✅ | ✅ | ✅ | Modifications de configuration système | +| État du feature flag | ✅ | ✅ | ✅ | Activation/désactivation du flag + épinglages système | +| Définition du feature flag | ✅ | ✅ | ✅ | Métadonnées / synchronisation du registre | +| Pare-feu cloud | ✅ | ✅ | ✅ | champ `locked` exclu | +| Masque IP de pare-feu | ✅ | ✅ | ✅ | | + +### Pro — RBAC / permissions + +| Objet | Création | Mise à jour | Suppression | +| ----------------------------- | :----: | :----: | :----: | +| Groupe | ✅ | ✅ | ✅ | +| Rôle | ✅ | ✅ | ✅ | +| Appartenance au groupe | ✅ | ✅ | ✅ | +| Rôle global | ✅ | ✅ | ✅ | +| Affectation de groupe à un Produit | ✅ | ✅ | ✅ | +| Affectation de groupe à un Type de produit | ✅ | ✅ | ✅ | +| Membre du Produit | ✅ | ✅ | ✅ | +| Membre du Type de produit | ✅ | ✅ | ✅ | + +### Pro — événements de relation (ajout / retrait) + +| Relation | Ajout | Retrait | +| --------------------------- | :-: | :----: | +| Pare-feu cloud → Plages IP | ✅ | ✅ | + +## Configuration et rétention (contrôles on-premise) + +| Paramètre | Variable d'environnement | Valeur par défaut | Effet | +| -------------------- | ------------------------------------- | ------------------ | ------------------------------------------------------------------ | +| Activer la journalisation d'audit | `DD_ENABLE_AUDITLOG` | `True` | Lorsque défini sur `False`, tous les déclencheurs d'historique sont désactivés et aucun événement n'est enregistré | +| Période de rétention | `DD_AUDITLOG_FLUSH_RETENTION_PERIOD` | `-1` (jamais purgé) | Nombre de mois d'historique à conserver ; les événements plus anciens sont supprimés par lots par la tâche de purge | +| Taille des lots de purge | `DD_AUDITLOG_FLUSH_BATCH_SIZE` | `1000` | Lignes supprimées par lot pendant le nettoyage | +| Nombre maximal de lots de purge | `DD_AUDITLOG_FLUSH_MAX_BATCHES` | `100` | Limite du nombre de lots par exécution de purge | + +## Remarques et limites + +- **Les secrets ne sont jamais capturés.** Les mots de passe des utilisateurs et les valeurs d'en-tête des + webhooks de notification sont explicitement exclus des instantanés d'événements. +- **Les mises à jour ne sont enregistrées qu'en cas de changement réel.** Un enregistrement qui ne modifie aucune + valeur de champ ne produit aucun événement de mise à jour ; les champs auto-gérés comme + `last_updated` ne déclenchent pas d'événement à eux seuls. +- **Les événements d'authentification ne sont pas capturés ici.** Seules les + modifications de données le sont. Les connexions, déconnexions et tentatives de connexion échouées sont gérées séparément et ne font pas partie de ce journal d'audit. diff --git a/docs/content/admin/user_management/PRO__audit_log_index.ja.md b/docs/content/admin/user_management/PRO__audit_log_index.ja.md new file mode 100644 index 00000000000..6cda531d208 --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_log_index.ja.md @@ -0,0 +1,120 @@ +--- +title: 監査ログ +description: DefectDojoが監査ログに記録するすべての作成・更新・削除操作、記録される内容、および保持期間の設定方法。 +draft: false +weight: 4 +--- + +DefectDojoはデータへの変更の監査証跡を記録します。追跡対象のオブジェクトはそれぞれ自動的に **create**（作成）、**update**（更新）、**delete**（削除）のイベントを記録し、リレーションシップ（多対多）テーブルは **add**（追加）と **remove**（削除）のイベントを記録します。 + +## 仕組み + +監査トラッキングは、モデルごとに登録されたデータベーストリガーによって駆動されます。追跡対象の各オブジェクトについて、次の3種類のイベントが発生し得ます。 + +| イベント種別 | 発生タイミング | アクション | +| ------------- | ----------------------------------------------------------------------------- | ---------- | +| `InsertEvent` | 新しいレコードが作成されたとき | **Create**（作成） | +| `UpdateEvent` | レコードが変更されたとき——実際にフィールドの値が変わった場合のみ | **Update**（更新） | +| `DeleteEvent` | レコードが削除されたとき | **Delete**（削除） | + +多対多のリレーションシップテーブル（タグ、レビュアー、ファイアウォールIP範囲）は、**add**（`InsertEvent`）と **remove**（`DeleteEvent`）のみを追跡します。リレーションシップの行に「update」は存在しません。 + +### すべてのイベントで記録される内容 + +- **Who**（実行者） — リクエストコンテキストから取得した操作ユーザー。 +- **When**（日時） — タイムスタンプ。 +- **Source IP**（送信元IP） — `X-Forwarded-For` プロキシチェーンを考慮したリモートアドレス。 +- **Before/after snapshot**（変更前後のスナップショット） — レコードの全フィールド値。 +- **Context / label**（コンテキスト / ラベル） — 同一リクエストに由来するイベントをグループ化します。ラベル `initial_backfill` は、トラッキングが最初に有効化されたときにインポートされた過去のレコードを示します。 + +バックグラウンドジョブによって生成されたイベントは、発生元のリクエストのコンテキストへ結び付けられるため、非同期に完了した操作であっても、それを引き起こしたユーザーに正しく帰属します。 + +## コア（オープンソース）— 追跡対象のアクション + +| オブジェクト | 作成 | 更新 | 削除 | 備考 | +| ------------------------------ | :----: | :----: | :----: | ---------------------------------------------- | +| ユーザー | ✅ | ✅ | ✅ | `password` はスナップショットから除外されます | +| 製品タイプ | ✅ | ✅ | ✅ | | +| 製品 | ✅ | ✅ | ✅ | | +| エンゲージメント | ✅ | ✅ | ✅ | | +| テスト | ✅ | ✅ | ✅ | | +| 検出事項 | ✅ | ✅ | ✅ | | +| 検出事項グループ | ✅ | ✅ | ✅ | | +| 検出事項テンプレート | ✅ | ✅ | ✅ | | +| リスク受容 | ✅ | ✅ | ✅ | | +| エンドポイント | ✅ | ✅ | ✅ | | +| ロケーション | ✅ | ✅ | ✅ | | +| URL | ✅ | ✅ | ✅ | | +| 通知Webhook | ✅ | ✅ | ✅ | `header_name` / `header_value` は除外されます（機密情報のため） | + +### コア — リレーションシップ（追加 / 削除）イベント + +| リレーションシップ | 追加 | 削除 | +| ---------------------------------- | :-: | :----: | +| 検出事項 → レビュアー | ✅ | ✅ | +| 検出事項 → タグ | ✅ | ✅ | +| 検出事項 → 継承タグ | ✅ | ✅ | +| 製品 → タグ | ✅ | ✅ | +| エンゲージメント → タグ | ✅ | ✅ | +| エンゲージメント → 継承タグ | ✅ | ✅ | +| テスト → タグ | ✅ | ✅ | +| テスト → 継承タグ | ✅ | ✅ | +| エンドポイント → タグ | ✅ | ✅ | +| エンドポイント → 継承タグ | ✅ | ✅ | +| 検出事項テンプレート → タグ | ✅ | ✅ | +| アプリ分析（Technology） → タグ | ✅ | ✅ | +| Objects/Product → タグ | ✅ | ✅ | + +## Pro — 追跡対象のアクション + +| オブジェクト | 作成 | 更新 | 削除 | 備考 | +| --------------------------------- | :----: | :----: | :----: | ------------------------------ | +| 拡張検出事項 | ✅ | ✅ | ✅ | 検出事項に対応するPro版 | +| ルール | ✅ | ✅ | ✅ | ルールエンジン | +| ルールアクション | ✅ | ✅ | ✅ | | +| ルールアクション条件 | ✅ | ✅ | ✅ | | +| ルールフィルターエントリ | ✅ | ✅ | ✅ | | +| ルールエンジン操作 | ✅ | ✅ | ✅ | | +| ルールエンジン操作メッセージ | ✅ | ✅ | ✅ | | +| スケジュールタスク | ✅ | ✅ | ✅ | | +| スケジュールタスク実行 | ✅ | ✅ | ✅ | | +| 緩和ポリシー | ✅ | ✅ | ✅ | | +| 調整可能な設定 | ✅ | ✅ | ✅ | システム設定の変更 | +| フィーチャーフラグの状態 | ✅ | ✅ | ✅ | フラグの切り替え + システムピン留め | +| フィーチャーフラグ定義 | ✅ | ✅ | ✅ | メタデータ / レジストリ同期 | +| クラウドファイアウォール | ✅ | ✅ | ✅ | `locked` フィールドは除外されます | +| ファイアウォールIPマスク | ✅ | ✅ | ✅ | | + +### Pro — RBAC / 権限 + +| オブジェクト | 作成 | 更新 | 削除 | +| ----------------------------- | :----: | :----: | :----: | +| グループ | ✅ | ✅ | ✅ | +| ロール | ✅ | ✅ | ✅ | +| グループメンバーシップ | ✅ | ✅ | ✅ | +| グローバルロール | ✅ | ✅ | ✅ | +| 製品グループ割り当て | ✅ | ✅ | ✅ | +| 製品タイプグループ割り当て | ✅ | ✅ | ✅ | +| 製品メンバー | ✅ | ✅ | ✅ | +| 製品タイプメンバー | ✅ | ✅ | ✅ | + +### Pro — リレーションシップ（追加 / 削除）イベント + +| リレーションシップ | 追加 | 削除 | +| --------------------------- | :-: | :----: | +| クラウドファイアウォール → IP範囲 | ✅ | ✅ | + +## 設定と保持期間（オンプレミス制御） + +| 設定 | 環境変数 | デフォルト | 効果 | +| -------------------- | ------------------------------------- | ------------------ | ------------------------------------------------------------------ | +| 監査ログを有効化 | `DD_ENABLE_AUDITLOG` | `True` | `False` の場合、すべての履歴トリガーが無効化され、イベントは記録されません | +| 保持期間 | `DD_AUDITLOG_FLUSH_RETENTION_PERIOD` | `-1`（フラッシュしない） | 保持する履歴の月数。それより古いイベントはフラッシュジョブによってバッチ単位で削除されます | +| フラッシュのバッチサイズ | `DD_AUDITLOG_FLUSH_BATCH_SIZE` | `1000` | クリーンアップ時にバッチごとに削除される行数 | +| フラッシュの最大バッチ数 | `DD_AUDITLOG_FLUSH_MAX_BATCHES` | `100` | 1回のフラッシュ実行あたりのバッチ数の上限 | + +## 補足と制限事項 + +- **機密情報は決して記録されません。** ユーザーのパスワードと通知Webhookのヘッダー値は、イベントのスナップショットから明示的に除外されます。 +- **更新は実際に変更があった場合のみ記録されます。** フィールドの値を変更しない保存では更新イベントは発生しません。`last_updated` のような自動管理フィールドのみの変化ではイベントは発生しません。 +- **認証イベントはここには記録されません。** 対象はデータの変更のみです。ログイン、ログアウト、ログイン失敗の活動は別途扱われ、この監査ログには含まれません。 diff --git a/docs/content/admin/user_management/PRO__audit_logging.de.md b/docs/content/admin/user_management/PRO__audit_logging.de.md new file mode 100644 index 00000000000..7342b615608 --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_logging.de.md @@ -0,0 +1,110 @@ +--- +title: Audit-Logs +description: Zugriff auf Audit-Logs für DefectDojo-Objekte +weight: 1 +audience: pro +--- + +**Audit-Logs** bieten eine chronologische Aufzeichnung von Aktionen, die innerhalb von DefectDojo durchgeführt wurden. Sie gewährleisten Verantwortlichkeit und Compliance, indem sie festhalten, welcher Benutzer welche Aktion wann durchgeführt hat. + +Audit-Logs sind wertvoll für: +- **Sicherheitsuntersuchungen**: Ermitteln, wer sensible Aktionen durchgeführt hat. +- **Compliance**: Nachweis einer prüfbaren Historie für Standards wie SOC 2, ISO 27001 oder interne Governance-Anforderungen. +- **Fehlerbehebung**: Feststellen, wann sich eine Konfiguration oder ein Objekt geändert hat. +- **Verantwortlichkeit**: Verfolgen administrativer und benutzerbezogener Aktivitäten über die gesamte Plattform hinweg. + +Kurz gesagt, bieten Audit-Logs eine zentrale Aufzeichnung wichtiger Ereignisse, die Administratoren hilft, die Aktivitätshistorie ihrer Instanz über die Historie einzelner Objekte hinaus zu verstehen. + +### Zugriff auf Audit-Logs + +Audit-Logs sind über die Seitenleiste im Untermenü Configurations zugänglich. + +![image](images/auditlogs_ss2.png) + +### Berechtigungen + +Der Zugriff auf Audit-Logs wird durch die globale Rolle eines Benutzers bestimmt. + +Die globalen Rollen API Importer, Reader und Writer erlauben keinen Zugriff auf Audit-Logs, während die Rollen Maintainer und Owner dies tun. Superuser haben unabhängig von ihrer globalen Rolle ebenfalls Zugriff auf Audit-Logs. + +Weitere Informationen zu Berechtigungen und globalen Rollen finden Sie [hier](/admin/user_management/pro_permissions_overhaul/). + +## Inhalte der Audit-Logs + +Audit-Logs erfassen eine Vielzahl von Aktionen, unter anderem: +- Interaktionen mit Objekten (z. B. das Erstellen, Aktualisieren oder Löschen von Objekten). +- Aktualisierungen der Priorität und des Risiko-Scores eines Befunds. +- Erstellung und Bearbeitung von Benutzerprofilen. +- Aktualisierungen des EPSS-Perzentils. + +Die vollständige Liste der Änderungen und Aktionen, die in Audit-Logs erfasst werden, finden Sie [hier](../pro__audit_log_index/). + +## Audit-Logs-Tabelle + +Audit-Logs enthalten mehrere Spalten mit verschiedenen Daten zur Verbesserung der Nachvollziehbarkeit, darunter: +- **Timestamp**: Der Zeitpunkt, zu dem die Änderung stattfand. +- **User**: Der Benutzer, der die Aktion durchgeführt hat. +- **Action**: Welche Aktion durchgeführt wurde (z. B. create, update, delete). +- **Model**: Welcher Aspekt geändert wurde (z. B. Asset, User, Finding, Location, Firewall, URL usw.). +- **Object ID**: Die eindeutige ID von DefectDojo für das geänderte Objekt. +- **Object Name**: Der Name des betroffenen Objekts. +- **Changes**: Die von der Aktion geänderten Felder, einschließlich ihrer vorherigen und aktualisierten Werte. +- **Data**: Ein exakter Schnappschuss des Datensatzes zum Zeitpunkt der Aktion, einschließlich aller Felder, nicht nur der geänderten. +- **Context**: Umgebende Details dazu, wie die Änderung erfolgte, wer sie vorgenommen hat, aus welchem Bereich der App sie stammt, und eine Kennzeichnung, welcher Job die Änderung durchgeführt hat (falls es sich um einen automatisierten Job handelte). +- **URL**: Die URL, die zur Ausführung des jeweiligen Vorgangs verwendet wurde. Diese Pfade können sich auf die Vue-Benutzeroberfläche von DefectDojo oder auf die REST-API beziehen. Das URL-Feld wird bei Backend-Prozessen nicht ausgefüllt. +- **IP Address**: Die Netzwerkadresse des Geräts, von dem die Änderung vorgenommen wurde. Dies wird bei Backend-Prozessen nicht ausgefüllt. + +### Audit-Logs-Zeitleiste + +Standardmäßig zeigen Audit-Logs Einträge der letzten 31 Tage an. Ältere Einträge bleiben verfügbar und können durch Anpassen des Timestamp-Filters angezeigt werden. + +![image](images/auditlogs_ss3.gif) + +### Filtern von Audit-Logs + +Die Audit-Logs-Tabelle enthält Filter, mit denen Sie die angezeigten Ergebnisse eingrenzen können. Wenn Sie beispielsweise nur Aktionen sehen möchten, die Assets betreffen, können Sie innerhalb der Tabelle nach Assets filtern. + +![image](images/auditlogs_ss1.png) + +Die Spalten innerhalb von Audit-Logs können außerdem alphabetisch, auf- oder absteigend oder chronologisch angeordnet werden, je nach Inhalt der jeweiligen Spalte. Spalten können zudem je nach gewünschter Anordnung nach links oder rechts gezogen werden. + +![image](images/auditlogs_ss4.gif) + +## Objektverlauf + +**Objektverlauf** bietet eine chronologische Aufzeichnung der Änderungen an einem einzelnen DefectDojo-Objekt (z. B. Organisation, Asset, Engagement, Test, Befunde, Endpunkte und Risikoakzeptanzen). Jeder Eintrag enthält Details wie Zeitstempel, Benutzer, durchgeführte Aktion und die zugehörigen Änderungen. + +Im Gegensatz zu Audit-Logs, die Ereignisse für eine gesamte Instanz erfassen, bezieht sich der Objektverlauf ausschließlich auf die Aktivität eines einzelnen Objekts, wodurch es einfacher wird, die Historie eines Objekts zu verstehen, ohne durch unzusammenhängende Systemereignisse filtern zu müssen. + +Der Objektverlauf ist nützlich für: +- Die Überprüfung der Entwicklung eines Objekts im Zeitverlauf. +- Die Feststellung, wann eine Änderung vorgenommen wurde. +- Die Ermittlung, welcher Benutzer eine Änderung vorgenommen hat. +- Die Fehlerbehebung bei unerwarteten Änderungen. + +### Zugriff auf den Objektverlauf + +Der Objektverlauf ist über das Zahnradmenü oben rechts in der Ansicht eines Objekts zugänglich. Nur Benutzer mit Zugriff auf das betreffende Objekt können dessen Objektverlauf einsehen. + +### Audit-Logs und Objektverlauf + +Obwohl sich die Funktion von Audit-Logs und Objektverlauf überschneidet, arbeiten sie in unterschiedlichen Geltungsbereichen. Der Objektverlauf konzentriert sich auf Änderungen an einzelnen Objekten, während Audit-Logs eine instanzweite Aufzeichnung wichtiger Ereignisse in Ihrer gesamten DefectDojo-Instanz bieten und damit einen umfassenderen Überblick über die Aktivität geben. + +## Endpunkte + +### Objektverlauf-Endpunkt (nur Pro) + +DefectDojo Pro-Benutzer haben Zugriff auf einen `/history`-API-Pfad für diese Objekte, um ähnliche Daten einzusehen. Beispiel: `/api/v2/findings/{id}/history/`. + +### Audit-Log-Endpunkt (nur Pro) + +DefectDojo Pro-Benutzer haben außerdem Zugriff auf einen dedizierten `/audit_log`-Endpunkt für ihre gesamte Instanz. Dieses Protokoll kann nur von Benutzern oder API-Tokens mit Superuser-Berechtigungen abgerufen werden. + +Diese API liefert 31 Tage an Audit-Logs zurück. + +* Das Senden von Standard- oder leeren Parametern liefert die letzten 31 Tage an Audit-Logs zurück. + +* Der Parameter `window_month` nimmt einen Monat und ein Jahr im Format MM-YYYY entgegen und liefert die Audit-Logs für diesen Monat. +* Sie können den Parameter `window_start` setzen, um diese Logs auf ein kürzeres Zeitfenster zu beschränken, anstatt den gesamten Monat zurückzugeben. + +Weitere Informationen finden Sie in der API-Dokumentation, die sich in Ihrer Instanz befindet: `your-instance.cloud.defectdojo.com/api/v2/oa3/swagger-ui/` diff --git a/docs/content/admin/user_management/PRO__audit_logging.es.md b/docs/content/admin/user_management/PRO__audit_logging.es.md new file mode 100644 index 00000000000..b25ed12266f --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_logging.es.md @@ -0,0 +1,110 @@ +--- +title: Registros de auditoría +description: Acceda a los registros de auditoría de los objetos de DefectDojo +weight: 1 +audience: pro +--- + +Los **Registros de auditoría** proporcionan un registro cronológico de las acciones realizadas dentro de DefectDojo. Garantizan la responsabilidad y el cumplimiento normativo al registrar qué usuario realizó qué acción y cuándo. + +Los registros de auditoría son valiosos para: +- **Investigaciones de seguridad**: determinar quién realizó acciones sensibles. +- **Cumplimiento normativo**: demostrar un historial auditable para estándares como SOC 2, ISO 27001 u otros requisitos de gobernanza interna. +- **Resolución de problemas**: identificar cuándo cambió una configuración u objeto. +- **Responsabilidad**: hacer seguimiento de la actividad administrativa y de los usuarios en toda la plataforma. + +En resumen, los Registros de auditoría proporcionan un registro centralizado de eventos importantes que ayuda a los administradores a comprender el historial de actividad de su instancia más allá del historial de cualquier objeto individual. + +### Acceso a los Registros de auditoría + +Se puede acceder a los Registros de auditoría desde la barra lateral, dentro del submenú de Configuraciones. + +![image](images/auditlogs_ss2.png) + +### Permisos + +El acceso a los Registros de auditoría se determina según el rol global del Usuario. + +Los roles globales de API Importer, Reader y Writer no permiten el acceso a los Registros de auditoría, mientras que los roles Maintainer y Owner sí lo hacen. Los superusuarios también tienen acceso a los Registros de auditoría independientemente de su rol global. + +Puede encontrar más información sobre permisos y roles globales [aquí](/admin/user_management/pro_permissions_overhaul/). + +## Contenido de los Registros de auditoría + +Los Registros de auditoría hacen seguimiento de una variedad de acciones, incluyendo, entre otras: +- Interacciones con objetos (por ejemplo, crear, actualizar o eliminar objetos). +- Actualizaciones de la prioridad y la puntuación de riesgo de un Hallazgo. +- Creación y edición de perfiles de Usuario. +- Actualizaciones del percentil EPSS. + +La lista completa de cambios y acciones registrados en los Registros de auditoría se puede encontrar [aquí](../pro__audit_log_index/). + +## Tabla de Registros de auditoría + +Los Registros de auditoría incluyen varias columnas con distintos datos para mejorar la trazabilidad, entre ellas: +- **Timestamp**: la hora en la que ocurrió el cambio. +- **Usuario**: el usuario que realizó la acción. +- **Action**: qué acción se realizó (por ejemplo, crear, actualizar, eliminar). +- **Model**: qué aspecto se modificó (por ejemplo, Asset, User, Finding, Location, Firewall, URL, etc.). +- **Object ID**: el ID único de DefectDojo para el objeto que se modificó. +- **Object Name**: el nombre del objeto afectado. +- **Changes**: campos específicos modificados por la acción, incluyendo sus valores anteriores y actualizados. +- **Data**: una instantánea exacta del registro en el momento en que se realizó la acción, incluyendo todos los campos, no solo los que cambiaron. +- **Context**: detalles del contexto de cómo ocurrió el cambio, quién lo hizo, desde dónde en la aplicación se originó, y una etiqueta que indica qué job realizó el cambio (si se trató de un job automatizado). +- **URL**: la URL utilizada para ejecutar la operación en cuestión. Estas rutas pueden referirse a la interfaz Vue de DefectDojo o a la API REST. El campo URL no se completará para los procesos de back-end. +- **IP Address**: la dirección de red del dispositivo que realizó el cambio. Este campo no se completará para los procesos de back-end. + +### Cronología de los Registros de auditoría + +De forma predeterminada, los Registros de auditoría muestran las entradas de los últimos 31 días. Las entradas más antiguas siguen estando disponibles y se pueden consultar ajustando el filtro Timestamp. + +![image](images/auditlogs_ss3.gif) + +### Filtrado de los Registros de auditoría + +La tabla de Registros de auditoría incluye filtros que ayudan a acotar los resultados mostrados. Por ejemplo, si desea ver únicamente las acciones relacionadas con Assets, puede filtrar por Assets dentro de la tabla. + +![image](images/auditlogs_ss1.png) + +Las columnas de los Registros de auditoría también se pueden ordenar alfabéticamente, en orden ascendente/descendente o cronológico, según el contenido de la columna en cuestión. Las columnas también se pueden arrastrar hacia la izquierda o la derecha según el orden preferido. + +![image](images/auditlogs_ss4.gif) + +## Historial del objeto + +El **Historial del objeto** proporciona un registro cronológico de los cambios realizados en un objeto individual de DefectDojo (por ejemplo, Organization, Asset, Compromiso, Test, Hallazgos, Endpoints y Aceptaciones de riesgo). Cada entrada incluye detalles como la marca de tiempo, el usuario, la acción realizada y los cambios asociados. + +A diferencia de los Registros de auditoría, que registran eventos en toda la instancia, el Historial del objeto se limita estrictamente a la actividad de un solo objeto, lo que facilita comprender el historial de un objeto sin tener que filtrar eventos del sistema no relacionados. + +El Historial del objeto es útil para: +- Revisar la evolución de un objeto a lo largo del tiempo. +- Determinar cuándo se realizó un cambio. +- Identificar qué usuario hizo una modificación. +- Resolver cambios inesperados. + +### Acceso al Historial del objeto + +Se puede acceder al Historial del objeto a través del menú de engranaje en la esquina superior derecha de la vista de cualquier objeto. Solo los Usuarios con acceso al objeto en cuestión pueden ver su Historial del objeto. + +### Registros de auditoría e Historial del objeto + +Aunque la función de los Registros de auditoría y el Historial del objeto se superpone, operan en ámbitos diferentes. El Historial del objeto se centra en los cambios realizados en objetos individuales, mientras que los Registros de auditoría ofrecen un registro de eventos significativos en toda su instancia de DefectDojo, brindando una vista panorámica más amplia de la actividad. + +## Endpoints + +### Endpoint de historial del objeto (solo Pro) + +Los usuarios de DefectDojo Pro tienen acceso a una ruta de API `/history` para estos objetos, con la que pueden consultar datos similares. Por ejemplo: `/api/v2/findings/{id}/history/`. + +### Endpoint de registro de auditoría (solo Pro) + +Los usuarios de DefectDojo Pro también tienen acceso a un endpoint dedicado `/audit_log` para toda su instancia. Solo pueden acceder a este registro los usuarios o tokens de API con permisos de superusuario. + +Esta API devuelve 31 días de registros de auditoría. + +* Enviar parámetros predeterminados o vacíos devolverá los registros de auditoría de los últimos 31 días. + +* El parámetro `window_month` toma un mes y un año en formato MM-YYYY y proporciona los registros de auditoría de ese mes. +* Puede configurar el parámetro `window_start` para limitar estos registros a una ventana más corta, en lugar de devolver el mes completo. + +Para obtener más información, consulte la documentación de la API, ubicada en su instancia: `your-instance.cloud.defectdojo.com/api/v2/oa3/swagger-ui/` diff --git a/docs/content/admin/user_management/PRO__audit_logging.fr.md b/docs/content/admin/user_management/PRO__audit_logging.fr.md new file mode 100644 index 00000000000..b0dc5a29f5f --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_logging.fr.md @@ -0,0 +1,110 @@ +--- +title: Journaux d'audit +description: Accéder aux journaux d'audit des objets DefectDojo +weight: 1 +audience: pro +--- + +Les **journaux d'audit** fournissent un enregistrement chronologique des actions effectuées au sein de DefectDojo. Ils garantissent la responsabilisation et la conformité en enregistrant quel utilisateur a effectué quelle action et à quel moment. + +Les journaux d'audit sont utiles pour : +- **Enquêtes de sécurité** : déterminer qui a effectué des actions sensibles. +- **Conformité** : démontrer un historique auditable pour des normes telles que SOC 2, ISO 27001, ou des exigences de gouvernance interne. +- **Dépannage** : identifier le moment où une configuration ou un objet a changé. +- **Responsabilisation** : suivre l'activité administrative et utilisateur sur l'ensemble de la plateforme. + +En résumé, les journaux d'audit fournissent un enregistrement centralisé des événements importants qui aide les administrateurs à comprendre l'historique d'activité de leur instance, au-delà de l'historique d'un seul objet. + +### Accéder aux journaux d'audit + +Les journaux d'audit sont accessibles via la barre latérale, dans le sous-menu Configurations. + +![image](images/auditlogs_ss2.png) + +### Autorisations + +L'accès aux journaux d'audit est déterminé par le rôle global de l'utilisateur. + +Les rôles globaux API Importer, Reader et Writer ne permettent pas d'accéder aux journaux d'audit, contrairement aux rôles Maintainer et Owner. Les superutilisateurs ont également accès aux journaux d'audit, quel que soit leur rôle global. + +Vous trouverez plus d'informations sur les autorisations et les rôles globaux [ici](/admin/user_management/pro_permissions_overhaul/). + +## Contenu des journaux d'audit + +Les journaux d'audit suivent une variété d'actions, y compris, sans s'y limiter : +- Les interactions avec les objets (par exemple, la création, la mise à jour ou la suppression d'objets). +- Les mises à jour de la priorité et du score de risque d'une Constatation. +- La création et la modification des profils Utilisateur. +- Les mises à jour du percentile EPSS. + +La liste complète des modifications et actions capturées dans les journaux d'audit se trouve [ici](../pro__audit_log_index/). + +## Tableau des journaux d'audit + +Les journaux d'audit comprennent plusieurs colonnes contenant diverses données pour améliorer la traçabilité, notamment : +- **Horodatage** : l'heure à laquelle la modification a eu lieu. +- **Utilisateur** : l'utilisateur qui a effectué l'action. +- **Action** : l'action effectuée (par exemple, création, mise à jour, suppression). +- **Modèle** : l'aspect modifié (par exemple, Actif, Utilisateur, Constatation, Emplacement, Pare-feu, URL, etc.). +- **ID de l'objet** : l'identifiant unique de DefectDojo pour l'objet qui a été modifié. +- **Nom de l'objet** : le nom de l'objet concerné. +- **Modifications** : les champs spécifiques modifiés par l'action, y compris leurs valeurs précédentes et mises à jour. +- **Données** : un instantané exact de l'enregistrement au moment où l'action a été effectuée, incluant chaque champ, et pas seulement ceux qui ont été modifiés. +- **Contexte** : les détails environnants de la façon dont la modification s'est produite, qui l'a effectuée, d'où dans l'application elle provient, et une étiquette indiquant quelle tâche a effectué la modification (s'il s'agissait d'une tâche automatisée). +- **URL** : l'URL utilisée pour exécuter l'opération en question. Ces chemins peuvent faire référence à l'interface Vue de DefectDojo, ou à l'API REST. Le champ URL ne sera pas renseigné pour les processus back-end. +- **Adresse IP** : l'adresse réseau de l'appareil ayant effectué la modification. Ce champ ne sera pas renseigné pour les processus back-end. + +### Chronologie des journaux d'audit + +Par défaut, les journaux d'audit affichent les entrées des 31 derniers jours. Les entrées plus anciennes restent disponibles et peuvent être consultées en ajustant le filtre Horodatage. + +![image](images/auditlogs_ss3.gif) + +### Filtrer les journaux d'audit + +Le tableau des journaux d'audit comprend des filtres permettant d'affiner les résultats affichés. Par exemple, si vous souhaitiez voir uniquement les actions relatives aux Actifs, vous pourriez filtrer sur les Actifs dans le tableau. + +![image](images/auditlogs_ss1.png) + +Les colonnes des journaux d'audit peuvent également être classées par ordre alphabétique, croissant/décroissant, ou chronologique, selon le contenu de la colonne en question. Les colonnes peuvent aussi être déplacées vers la gauche ou la droite selon l'agencement souhaité. + +![image](images/auditlogs_ss4.gif) + +## Historique de l'objet + +L'**historique de l'objet** fournit un enregistrement chronologique des modifications apportées à un objet DefectDojo individuel (par exemple, Organisation, Actif, Engagement, Test, Constatations, Points de terminaison et Acceptations du risque). Chaque entrée inclut des détails tels que l'horodatage, l'utilisateur, l'action effectuée et les modifications associées. + +Contrairement aux journaux d'audit, qui enregistrent les événements de l'ensemble d'une instance, l'historique de l'objet se rapporte strictement à l'activité d'un seul objet, ce qui facilite la compréhension de l'historique d'un objet sans avoir à filtrer des événements système non liés. + +L'historique de l'objet est utile pour : +- Examiner l'évolution d'un objet au fil du temps. +- Déterminer à quel moment une modification a été effectuée. +- Identifier quel utilisateur a effectué une modification. +- Dépanner des modifications inattendues. + +### Accéder à l'historique de l'objet + +L'historique de l'objet est accessible via le menu en forme d'engrenage situé en haut à droite de la vue de n'importe quel objet. Seuls les utilisateurs ayant accès à l'objet en question peuvent consulter son historique. + +### Journaux d'audit et historique de l'objet + +Bien que les fonctions des journaux d'audit et de l'historique de l'objet se recoupent, elles opèrent à des échelles différentes. L'historique de l'objet se concentre sur les modifications apportées à des objets individuels, tandis que les journaux d'audit fournissent un enregistrement à l'échelle du système des événements significatifs survenus dans votre instance DefectDojo, offrant une vue d'ensemble plus large de l'activité. + +## Points de terminaison + +### Point de terminaison de l'historique de l'objet (Pro uniquement) + +DefectDojo Pro les utilisateurs ont accès à un chemin d'API `/history` pour ces objets afin de consulter des données similaires. Par exemple : `/api/v2/findings/{id}/history/`. + +### Point de terminaison des journaux d'audit (Pro uniquement) + +DefectDojo Pro les utilisateurs ont également accès à un point de terminaison `/audit_log` dédié pour l'ensemble de leur instance. Ce journal ne peut être consulté que par des utilisateurs ou des jetons API disposant des autorisations de superutilisateur. + +Cette API renvoie 31 jours de journaux d'audit. + +* L'envoi de paramètres par défaut ou vides renverra les 31 derniers jours de journaux d'audit. + +* Le paramètre `window_month`, qui prend un mois et une année au format MM-YYYY, fournit les journaux d'audit pour ce mois. +* Vous pouvez définir le paramètre `window_start` pour limiter ces journaux à une fenêtre plus courte, plutôt que de renvoyer le mois entier. + +Pour plus d'informations, consultez la documentation de l'API, disponible sur votre instance : `your-instance.cloud.defectdojo.com/api/v2/oa3/swagger-ui/` diff --git a/docs/content/admin/user_management/PRO__audit_logging.ja.md b/docs/content/admin/user_management/PRO__audit_logging.ja.md new file mode 100644 index 00000000000..489065e3269 --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_logging.ja.md @@ -0,0 +1,110 @@ +--- +title: 監査ログ +description: DefectDojoオブジェクトの監査ログにアクセスする +weight: 1 +audience: pro +--- + +**監査ログ**は、DefectDojo内で実行されたアクションの時系列記録を提供します。どのユーザーがいつどのアクションを実行したかを記録することで、説明責任とコンプライアンスを確保します。 + +監査ログは以下の場面で役立ちます。 +- **セキュリティ調査**: 誰が機密性の高い操作を実行したかを特定します。 +- **コンプライアンス**: SOC 2、ISO 27001、または社内ガバナンス要件などの標準に対応する監査可能な履歴を提示します。 +- **トラブルシューティング**: 設定やオブジェクトが変更された時期を特定します。 +- **説明責任**: プラットフォーム全体における管理者およびユーザーの活動を追跡します。 + +つまり、監査ログは重要なイベントを一元的に記録することで、管理者が個々のオブジェクトの履歴を超えてインスタンスの活動履歴を把握できるようにします。 + +### Accessing Audit Logs + +監査ログには、サイドバーの「Configurations」サブメニューからアクセスできます。 + +![image](images/auditlogs_ss2.png) + +### Permissions + +監査ログへのアクセスは、ユーザーのグローバルロールによって決まります。 + +API Importer、Reader、Writerのグローバルロールは監査ログへのアクセスを許可されませんが、MaintainerとOwnerのロールは許可されます。スーパーユーザーは、グローバルロールに関係なく監査ログにアクセスできます。 + +権限とグローバルロールの詳細については、[こちら](/admin/user_management/pro_permissions_overhaul/)を参照してください。 + +## Audit Logs Contents + +監査ログは、以下を含む(ただしこれらに限定されない)さまざまなアクションを追跡します。 +- オブジェクトとのやり取り(オブジェクトの作成、更新、削除など)。 +- 検出事項の優先度およびリスクスコアの更新。 +- ユーザープロフィールの作成および編集。 +- EPSSパーセンタイルの更新。 + +監査ログに記録される変更およびアクションの全リストは、[こちら](../pro__audit_log_index/)で確認できます。 + +## Audit Logs Table + +監査ログには、トレーサビリティを向上させるためのさまざまなデータを含む複数の列があります。 +- **Timestamp**: 変更が発生した時刻。 +- **User**: アクションを実行したユーザー。 +- **Action**: 実行されたアクション(作成、更新、削除など)。 +- **Model**: 変更された対象(Asset、User、Finding、Location、Firewall、URLなど)。 +- **Object ID**: 変更されたオブジェクトのDefectDojo固有のID。 +- **Object Name**: 影響を受けたオブジェクトの名前。 +- **Changes**: そのアクションによって変更された特定のフィールド。変更前と変更後の値を含みます。 +- **Data**: アクションが実行された時点でのレコードの正確なスナップショット。変更されたフィールドだけでなく、すべてのフィールドを含みます。 +- **Context**: 変更がどのように発生したか、誰が行ったか、アプリのどこから発生したか、および(自動化されたジョブの場合)どのジョブが変更を実行したかを示すラベルなど、変更に関する周辺情報。 +- **URL**: 特定の操作を実行するために使用されたURL。これらのパスは、DefectDojoのVue UIまたはREST APIを参照する場合があります。バックエンド処理の場合、URLフィールドは入力されません。 +- **IP Address**: 変更を行ったデバイスのネットワークアドレス。バックエンド処理の場合は入力されません。 + +### Audit Logs Timeline + +デフォルトでは、監査ログには過去31日間のエントリが表示されます。それより古いエントリも引き続き利用可能で、Timestampフィルターを調整することで表示できます。 + +![image](images/auditlogs_ss3.gif) + +### Filtering Audit Logs + +監査ログテーブルには、表示される結果を絞り込むためのフィルターが用意されています。たとえば、Assetsに関連するアクションのみを表示したい場合は、テーブル内でAssetsをフィルタリングできます。 + +![image](images/auditlogs_ss1.png) + +監査ログ内の列は、列の内容に応じて、アルファベット順、昇順/降順、または時系列順に並べ替えることもできます。列は、任意の並び順にするために左右にドラッグすることもできます。 + +![image](images/auditlogs_ss4.gif) + +## Object History + +**オブジェクト履歴**は、個々のDefectDojoオブジェクト(Organization、Asset、Engagement、Test、Findings、Endpoints、Risk Acceptancesなど)に加えられた変更の時系列記録を提供します。各エントリには、タイムスタンプ、ユーザー、実行されたアクション、および関連する変更などの詳細が含まれます。 + +インスタンス全体のイベントを記録する監査ログとは異なり、オブジェクト履歴は単一のオブジェクトの活動のみに限定されるため、無関係なシステムイベントをフィルタリングすることなく、オブジェクトの履歴を把握しやすくなります。 + +オブジェクト履歴は以下の場合に役立ちます。 +- オブジェクトの経時的な変化を確認する。 +- 変更がいつ行われたかを特定する。 +- どのユーザーが変更を行ったかを特定する。 +- 予期しない変更のトラブルシューティングを行う。 + +### Accessing Object History + +オブジェクト履歴には、各オブジェクトのビューの右上にある歯車メニューからアクセスできます。当該オブジェクトへのアクセス権を持つユーザーのみが、そのオブジェクトのオブジェクト履歴を表示できます。 + +### Audit Logs and Object History + +監査ログとオブジェクト履歴の機能は重複していますが、それぞれ異なる範囲で動作します。オブジェクト履歴は個々のオブジェクトに加えられた変更に焦点を当てるのに対し、監査ログはDefectDojoインスタンス全体にわたる重要なイベントをシステム全体で記録し、活動をより広い視点から俯瞰できるようにします。 + +## Endpoints + +### Object History Endpoint (Pro Only) + +DefectDojo Proのユーザーは、これらのオブジェクトについて同様のデータを表示するための`/history` APIパスにアクセスできます。例: `/api/v2/findings/{id}/history/`。 + +### Audit Log Endpoint (Pro Only) + +DefectDojo Proのユーザーは、インスタンス全体に対して専用の`/audit_log`エンドポイントにもアクセスできます。このログには、スーパーユーザー権限を持つユーザーまたはAPIトークンのみがアクセスできます。 + +このAPIは31日分の監査ログを返します。 + +* デフォルトまたは空のパラメータを送信すると、直近31日分の監査ログが返されます。 + +* パラメータ`window_month`は、MM-YYYY形式で月と年を指定し、その月の監査ログを提供します。 +* `window_start`パラメータを設定すると、月全体を返す代わりに、これらのログをより短い期間に限定できます。 + +詳細については、インスタンス内にあるAPIドキュメントを参照してください: `your-instance.cloud.defectdojo.com/api/v2/oa3/swagger-ui/` diff --git a/docs/content/admin/user_management/PRO__creating_new_users.de.md b/docs/content/admin/user_management/PRO__creating_new_users.de.md new file mode 100644 index 00000000000..da1dfcfd445 --- /dev/null +++ b/docs/content/admin/user_management/PRO__creating_new_users.de.md @@ -0,0 +1,42 @@ +--- +title: Einen neuen Benutzer erstellen +description: So binden Sie einen neuen Benutzer in Ihre DefectDojo-Instanz ein +audience: pro +weight: 1 +--- + +Diese Seite beschreibt den empfohlenen Onboarding-Workflow zum Hinzufügen neuer Benutzer zu einer DefectDojo-Instanz. DefectDojo-Benutzer können sowohl als reguläre, von Menschen bediente Konten als auch als Servicekonten verwendet werden. + +Der Administrator, der das Konto erstellt, ist dafür verantwortlich, dem neuen Benutzer die anfänglichen Zugangsdaten (Benutzername und Passwort) zu übermitteln. + +## Empfohlener Workflow + +1. **Erstellen Sie das Benutzerkonto** in DefectDojo (nur Superuser): + * Navigieren Sie zu **👤 Benutzer → ➕ Neuer Benutzer**. + * Geben Sie den Namen und die E-Mail-Adresse des neuen Benutzers ein. + * Legen Sie ein temporäres Passwort fest. + * Senden Sie das Formular ab. + +2. **Weisen Sie passende Berechtigungen zu** — Produkt-/Produkttyp-Mitgliedschaft, Konfigurationsberechtigungen, globale Rolle oder Superuser-Status. Details finden Sie unter [Berechtigungen eines Benutzers festlegen](../set_user_permissions/). Ein neuer Benutzer ohne Zuweisungen kann keine Produkte oder Befunde sehen. + +3. **Senden Sie die Zugangsdaten out-of-band an den neuen Benutzer** (per E-Mail, über das Chat-Tool Ihres Teams oder auf die Art, wie Sie normalerweise Geheimnisse teilen). Fügen Sie hinzu: + * Die URL der DefectDojo-Instanz. + * Den Benutzernamen (in der Regel die E-Mail-Adresse). + * Das soeben festgelegte temporäre Passwort. + * Einen Hinweis, dass sie beim ersten Login das Passwort ändern und MFA aktivieren sollten (falls Ihre Instanz MFA verwendet). + +4. **Der neue Benutzer meldet sich an und wechselt die Zugangsdaten.** Dabei kann er entweder: + * sich mit dem temporären Passwort anmelden und es anschließend über das Profilmenü ändern, oder + * den Link **I forgot my password** auf der Login-Seite verwenden, um direkt ein Passwort festzulegen, ohne das temporäre zu verwenden. Das temporäre Passwort ist weiterhin erforderlich, damit der anfängliche Kontodatensatz existiert, aber der Benutzer muss es sich nicht merken, wenn er den Passwort-Zurücksetzen-Ablauf nutzt. + +5. **Der neue Benutzer konfiguriert MFA** über sein Profilmenü. Wir empfehlen dringend, MFA für alle Benutzer auf Instanzen zu verlangen, die nicht hinter SSO liegen. + +## SSO-Benutzer + +Wenn Ihre Instanz mit [SSO](../configure_sso/) konfiguriert ist, unterscheidet sich der Workflow — Benutzer werden in der Regel beim ersten Login durch den Identity Provider erstellt, und Sie müssen ihnen anschließend nur noch Gruppenmitgliedschaften oder Rollen zuweisen. + +## Wiederherstellung nach einem verlorenen MFA-Token + +Wenn ein Benutzer den Zugriff auf sein MFA-Gerät verliert, kann er sich mit einem der bei der Registrierung ausgestellten Wiederherstellungscodes anmelden. Sind auch diese nicht mehr verfügbar, kann ein Administrator mit Serverzugriff MFA für das Konto mit `python manage.py remove_mfa --username ` zurücksetzen, woraufhin sich der Benutzer mit seinem Passwort anmeldet und sich erneut registriert — seine Berechtigungen und seine Historie bleiben erhalten, sodass kein Ersatzkonto erstellt werden muss. + +Die vollständigen Wiederherstellungsoptionen finden Sie unter [Multi-Faktor-Authentifizierung](../pro__mfa/#recovering-a-user-who-has-lost-their-mfa-device); beachten Sie außerdem, dass der Zugriff auf den **Cloud Manager** selbst eine separate Angelegenheit ist — siehe den [Leitfaden zur Fehlerbehebung bei der Konnektivität](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes). diff --git a/docs/content/admin/user_management/PRO__creating_new_users.es.md b/docs/content/admin/user_management/PRO__creating_new_users.es.md new file mode 100644 index 00000000000..e08abe0a00a --- /dev/null +++ b/docs/content/admin/user_management/PRO__creating_new_users.es.md @@ -0,0 +1,42 @@ +--- +title: Creación de un nuevo usuario +description: Cómo incorporar un nuevo usuario a su instancia de DefectDojo +audience: pro +weight: 1 +--- + +Esta página describe el flujo de trabajo de incorporación recomendado para agregar nuevos usuarios a una instancia de DefectDojo. Los usuarios de DefectDojo se pueden utilizar tanto como cuentas estándar operadas por personas como cuentas de servicio. + +El administrador que crea la cuenta es responsable de entregar las credenciales iniciales (nombre de usuario y contraseña) al nuevo usuario. + +## Flujo de trabajo recomendado + +1. **Cree la cuenta de usuario** en DefectDojo (solo Superuser): + * Vaya a **👤 Users → ➕ New User**. + * Ingrese el nombre y la dirección de correo electrónico del nuevo usuario. + * Establezca una contraseña temporal. + * Envíe el formulario. + +2. **Asigne los permisos** correspondientes: membresía de Producto/Tipo de producto, Permisos de configuración, Rol global o estado de Superuser. Consulte [Establecer los permisos de un Usuario](../set_user_permissions/) para obtener más información. Un nuevo usuario sin asignaciones no podrá ver ningún Producto ni Hallazgo. + +3. **Envíe las credenciales al nuevo usuario por un canal externo** (por correo electrónico, la herramienta de chat de su equipo, o la forma en que normalmente comparte información confidencial). Incluya: + * La URL de la instancia de DefectDojo. + * El nombre de usuario (normalmente su dirección de correo electrónico). + * La contraseña temporal que acaba de establecer. + * Una nota indicando que debe cambiar la contraseña y habilitar la MFA (si su instancia utiliza MFA) en el primer inicio de sesión. + +4. **El nuevo usuario inicia sesión y renueva la credencial.** Puede hacerlo de dos maneras: + * Iniciar sesión con la contraseña temporal y luego cambiarla desde su menú de perfil, o + * Usar el enlace **I forgot my password** en la página de inicio de sesión para establecer una contraseña directamente, sin usar la temporal. La contraseña temporal sigue siendo necesaria para que exista el registro inicial de la cuenta, pero el usuario no necesita recordarla si utiliza el flujo de restablecimiento de contraseña. + +5. **El nuevo usuario configura la MFA** desde su menú de perfil. Recomendamos encarecidamente exigir la MFA a todos los usuarios en las instancias que no están detrás de un SSO. + +## Usuarios SSO + +Si su instancia está configurada con [SSO](../configure_sso/), el flujo de trabajo es diferente: los usuarios normalmente se crean en el primer inicio de sesión desde el Identity Provider, y usted solo necesita otorgarles membresía de grupo o roles después. + +## Recuperación de un token de MFA perdido + +Si un usuario pierde el acceso a su dispositivo de MFA, puede iniciar sesión con uno de los códigos de recuperación emitidos al momento de la inscripción. Si esos códigos también se han perdido, un administrador con acceso al servidor puede eliminar la MFA de la cuenta con `python manage.py remove_mfa --username `, tras lo cual el usuario inicia sesión con su contraseña y se inscribe nuevamente; sus permisos e historial se conservan, por lo que no es necesario crear una cuenta de reemplazo. + +Consulte [Autenticación multifactor](../pro__mfa/#recovering-a-user-who-has-lost-their-mfa-device) para conocer todas las opciones de recuperación, y tenga en cuenta que el acceso al propio **Cloud Manager** es un asunto aparte; consulte la [guía de resolución de problemas de conectividad](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes). diff --git a/docs/content/admin/user_management/PRO__creating_new_users.fr.md b/docs/content/admin/user_management/PRO__creating_new_users.fr.md new file mode 100644 index 00000000000..788b660ebb4 --- /dev/null +++ b/docs/content/admin/user_management/PRO__creating_new_users.fr.md @@ -0,0 +1,42 @@ +--- +title: Créer un nouvel utilisateur +description: Comment intégrer un nouvel utilisateur sur votre instance DefectDojo +audience: pro +weight: 1 +--- + +Cette page décrit le flux de travail d'intégration recommandé pour ajouter de nouveaux utilisateurs à une instance DefectDojo. Les utilisateurs DefectDojo peuvent être utilisés à la fois comme des comptes standard, opérés par des humains, et comme des comptes de service. + +L'administrateur qui crée le compte est responsable de la transmission des identifiants initiaux (nom d'utilisateur et mot de passe) au nouvel utilisateur. + +## Flux de travail recommandé + +1. **Créez le compte utilisateur** dans DefectDojo (superutilisateur uniquement) : + * Accédez à **👤 Utilisateurs → ➕ Nouvel utilisateur**. + * Saisissez le nom et l'adresse e-mail du nouvel utilisateur. + * Définissez un mot de passe temporaire. + * Envoyez le formulaire. + +2. **Attribuez les autorisations** appropriées — appartenance à un Produit/Type de produit, Autorisations de configuration, Rôle global, ou statut de superutilisateur. Consultez [Définir les autorisations d'un utilisateur](../set_user_permissions/) pour plus de détails. Un nouvel utilisateur sans aucune attribution ne pourra voir aucun Produit ni aucune Constatation. + +3. **Envoyez les identifiants au nouvel utilisateur par un canal séparé** (par e-mail, via l'outil de discussion de votre équipe, ou toute autre méthode que vous utilisez habituellement pour partager des secrets). Incluez : + * L'URL de l'instance DefectDojo. + * Le nom d'utilisateur (généralement son adresse e-mail). + * Le mot de passe temporaire que vous venez de définir. + * Une note indiquant qu'il doit changer le mot de passe et activer la MFA (si votre instance utilise la MFA) lors de la première connexion. + +4. **Le nouvel utilisateur se connecte et renouvelle ses identifiants.** Il peut soit : + * Se connecter avec le mot de passe temporaire, puis le modifier depuis son menu de profil, soit + * Utiliser le lien **J'ai oublié mon mot de passe** sur la page de connexion pour définir directement un mot de passe sans utiliser le mot de passe temporaire. Le mot de passe temporaire reste nécessaire pour que l'enregistrement initial du compte existe, mais l'utilisateur n'a pas besoin de s'en souvenir s'il utilise le flux de réinitialisation du mot de passe. + +5. **Le nouvel utilisateur configure la MFA** depuis son menu de profil. Nous recommandons fortement d'exiger la MFA pour tous les utilisateurs sur les instances qui ne sont pas protégées par le SSO. + +## Utilisateurs SSO + +Si votre instance est configurée avec le [SSO](../configure_sso/), le flux de travail est différent — les utilisateurs sont généralement créés lors de leur première connexion depuis le fournisseur d'identité, et il vous suffit ensuite de leur accorder une appartenance à un groupe ou des rôles. + +## Récupération après la perte d'un jeton MFA + +Si un utilisateur perd l'accès à son appareil MFA, il peut se connecter à l'aide de l'un des codes de récupération émis lors de son inscription. Si ceux-ci ont également été perdus, un administrateur disposant d'un accès serveur peut retirer la MFA du compte avec `python manage.py remove_mfa --username `, après quoi l'utilisateur se connecte avec son mot de passe et s'inscrit à nouveau — ses autorisations et son historique sont conservés, il n'est donc pas nécessaire de créer un compte de remplacement. + +Consultez [Authentification multifacteur](../pro__mfa/#recovering-a-user-who-has-lost-their-mfa-device) pour connaître toutes les options de récupération, et notez que l'accès au **Cloud Manager** lui-même est une question distincte — consultez le [guide de dépannage de la connectivité](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes). diff --git a/docs/content/admin/user_management/PRO__creating_new_users.ja.md b/docs/content/admin/user_management/PRO__creating_new_users.ja.md new file mode 100644 index 00000000000..58d2d9fa034 --- /dev/null +++ b/docs/content/admin/user_management/PRO__creating_new_users.ja.md @@ -0,0 +1,42 @@ +--- +title: 新しいユーザーの作成 +description: DefectDojoインスタンスに新しいユーザーをオンボーディングする方法 +audience: pro +weight: 1 +--- + +このページでは、DefectDojoインスタンスに新しいユーザーを追加するための推奨オンボーディングワークフローについて説明します。DefectDojoのユーザーは、人間が操作する標準アカウントとしても、サービスアカウントとしても使用できます。 + +アカウントを作成した管理者は、初期認証情報(ユーザー名とパスワード)を新しいユーザーに届ける責任を負います。 + +## Recommended workflow + +1. **Create the user account** in DefectDojo (Superuser only): + * **👤 Users → ➕ New User**に移動します。 + * 新しいユーザーの名前とメールアドレスを入力します。 + * 一時パスワードを設定します。 + * フォームを送信します。 + +2. 必要に応じて**権限を割り当てます** — 製品/製品タイプのメンバーシップ、設定権限、グローバルロール、またはスーパーユーザーステータスなどです。詳細は[ユーザーの権限を設定する](../set_user_permissions/)を参照してください。割り当てのない新しいユーザーは、いかなる製品や検出事項も閲覧できません。 + +3. **帯域外の手段で認証情報を新しいユーザーに送信します**(メール、チームのチャットツール、または通常シークレットを共有する方法など)。以下を含めてください。 + * DefectDojoインスタンスのURL。 + * ユーザー名(通常はメールアドレス)。 + * 先ほど設定した一時パスワード。 + * 初回ログイン時にパスワードを変更し、(インスタンスがMFAを使用している場合は)MFAを有効にする必要がある旨の注意事項。 + +4. **新しいユーザーはログインし、認証情報を更新します。** 次のいずれかの方法を選択できます。 + * 一時パスワードでログインし、プロフィールメニューから変更する。 + * ログインページの**I forgot my password**リンクを使用して、一時パスワードを使わずに直接パスワードを設定する。一時パスワードは初期アカウントレコードを作成するために必要ですが、パスワードリセットフローを使用する場合、ユーザーはそれを記憶しておく必要はありません。 + +5. **新しいユーザーは**プロフィールメニューから**MFAを設定します**。SSOを利用していないインスタンスでは、すべてのユーザーにMFAを要求することを強くお勧めします。 + +## SSO Users + +インスタンスが[SSO](../configure_sso/)で設定されている場合、ワークフローは異なります。通常、ユーザーはIDプロバイダーからの初回ログイン時に作成され、その後グループメンバーシップやロールを付与するだけで済みます。 + +## Recovering from a lost MFA token + +ユーザーがMFAデバイスにアクセスできなくなった場合、登録時に発行されたリカバリーコードのいずれかを使用してログインできます。それらも失われている場合、サーバーアクセス権を持つ管理者は`python manage.py remove_mfa --username `を使用してアカウントからMFAをクリアできます。その後、ユーザーはパスワードでログインし、再度登録します — 権限と履歴は保持されるため、代替アカウントを作成する必要はありません。 + +完全な復旧オプションについては[多要素認証](../pro__mfa/#recovering-a-user-who-has-lost-their-mfa-device)を参照してください。なお、**Cloud Manager**自体へのアクセスは別の問題であることに注意してください — 詳細は[接続トラブルシューティングガイド](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes)を参照してください。 diff --git a/docs/content/admin/user_management/PRO__custom_rbac_roles.de.md b/docs/content/admin/user_management/PRO__custom_rbac_roles.de.md new file mode 100644 index 00000000000..260d1fecc10 --- /dev/null +++ b/docs/content/admin/user_management/PRO__custom_rbac_roles.de.md @@ -0,0 +1,212 @@ +--- +title: Benutzerdefinierte RBAC-Rollen +description: Erstellen Sie eigene Rollen, indem Sie einzelne Berechtigungen auswählen, + und nutzen Sie die fünf integrierten Rollen als klonbare Ausgangspunkte +weight: 5 +audience: pro +--- + +> **DefectDojo Pro-Funktion.** Das auf dieser Seite beschriebene RBAC-System für Mitglieder/Gruppen/globale Rollen ist Teil von DefectDojo Pro. Open-Source-DefectDojo verwendet das Modell [Authorized Users](../os__authorized_users/). Weitere Informationen zur Zugriffskontrolle in der Open-Source-Version finden Sie auf dieser Seite sowie in den [3.0-Upgrade-Hinweisen](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization), wenn Sie zwischen den Editionen wechseln. + +DefectDojo Pro wird mit fünf Rollen ausgeliefert: **Reader**, **Writer**, **Maintainer**, **Owner** und **API Importer**. Falls keine davon passt, können Sie jetzt Ihre eigene Rolle erstellen, indem Sie genau festlegen, welche Berechtigungen sie gewährt. + +Eine benutzerdefinierte Rolle funktioniert überall dort, wo auch eine integrierte Rolle funktioniert: als globale Rolle, als Rolle einer Gruppe, als Standard-Gruppenrolle und als Mitgliedsrolle für eine einzelne Organisation oder ein einzelnes Asset. + +Die fünf integrierten Rollen werden zu **gesperrten, klonbaren Vorlagen**. Ihre Berechtigungen bleiben unverändert (siehe die [Tabellen der Aktionsberechtigungen](../user_permission_chart/) für die jeweils gewährten Rechte), sie können weder bearbeitet noch gelöscht werden, und das Klonen einer solchen Rolle ist der empfohlene Weg, um eine neue Rolle zu erstellen. + +## Bevor Sie beginnen + +Die Verwaltung benutzerdefinierter Rollen ist standardmäßig deaktiviert. Ein **Superuser** aktiviert sie unter **Settings > Feature Flags**, indem er **Custom Roles** einschaltet. Wie diese Seite funktioniert, erfahren Sie unter [Feature Flags](/admin/feature_flags/pro__feature_flags/). + +Solange die Funktion deaktiviert ist, bleibt die Seite „Rollen" weiterhin lesbar: Sie können die integrierten Rollen und ihre Berechtigungen einsehen, aber nichts erstellen, bearbeiten, klonen oder löschen. + +Die Verwaltung von Rollen erfordert den **Superuser**-Status oder die integrierte globale Rolle **Owner**. Dies ist beabsichtigt und kann nicht an eine benutzerdefinierte Rolle delegiert werden: siehe [Was eine benutzerdefinierte globale Rolle freischaltet](#what-a-custom-global-role-unlocks). + +## Öffnen der Seite „Rollen" + +Gehen Sie in der linken Seitenleiste zu **👤 Users > Roles**. Der Menüeintrag ist für Superuser und Inhaber der integrierten globalen Rolle Owner sichtbar. + +![Die Seite „Rollen" mit integrierten und benutzerdefinierten Rollen](images/pro_roles_list.png) + +Die Tabelle listet alle Rollen Ihrer Instanz auf: + +| Column | What it shows | +| --- | --- | +| **ID** | Die numerische ID der Rolle. Nützlich beim Filtern der Benutzertabelle oder beim Aufruf der API. | +| **Name** | Der Name der Rolle. | +| **Description** | Ihre eigene Notiz dazu, wofür die Rolle gedacht ist. Optional und leer, sofern sie niemand ausfüllt. Die integrierten Rollen werden ohne Beschreibung ausgeliefert. | +| **Permissions** | Eine Anzahl der gewährten Berechtigungen. Klicken Sie darauf, um eine schreibgeschützte Ansicht des gesamten Rasters zu öffnen. | +| **Users** | Wie viele Benutzer diese Rolle als globale Rolle innehaben. Klicken Sie durch, um sie in der Benutzertabelle zu sehen. | +| **Type** | **Built-in** für die fünf Vorlagen, **Custom** für selbst erstellte Rollen. | + +Jede Spalte ist sortier- und filterbar, und die Stichwortsuche durchsucht Name und Beschreibung. + +## Erstellen einer Rolle + +### Eine integrierte Rolle klonen (empfohlen) + +Das Klonen startet mit einem bewährten Berechtigungssatz anstelle eines leeren Rasters, wodurch es viel schwerer wird, versehentlich eine Berechtigung zu vergessen, die eine Rolle benötigt. + +1. Suchen Sie die Rolle, die Ihrem Bedarf am nächsten kommt. +2. Öffnen Sie deren **⋮**-Menü und wählen Sie **Clone Role**. +3. Eine Kopie wird sofort erstellt, benannt ` (copy)`, mit denselben Berechtigungen und derselben Beschreibung wie die Rolle, von der sie stammt. +4. Öffnen Sie das **⋮**-Menü der Kopie, wählen Sie **Edit Role**, benennen Sie sie dann um und passen Sie ihre Berechtigungen an. + +Integrierte Rollen können geklont werden, obwohl sie nicht bearbeitet werden können. Der Klon speichert, von welcher Rolle er stammt. + +### Von Grund auf neu erstellen + +1. Klicken Sie auf **New Role**. +2. Geben Sie ihr einen **Name** (erforderlich) und optional eine **Description**. +3. Wählen Sie ihre Berechtigungen im Raster unten aus (siehe nächster Abschnitt). +4. Klicken Sie auf **Save Role**. + +Rollennamen müssen eindeutig sein, wobei die Prüfung Groß-/Kleinschreibung ignoriert: Existiert bereits `Triage Lead`, wird `triage lead` abgelehnt. + +## Berechtigungen auswählen + +![Das Berechtigungsraster im Rollenformular](images/pro_role_permission_grid.png) + +Die Berechtigungen sind in drei Tabellen plus eine Checkliste gruppiert. + +**Object Permissions** gelten für die Organisationen und Assets, denen die Rolle zugewiesen ist, sowie für alles, was darunter verschachtelt ist. + +| Row | View | Add | Edit | Delete | +| --- | --- | --- | --- | --- | +| Organization | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset | ☑️ | ☑️ ¹ | ☑️ | ☑️ | +| Engagement | ☑️ | ☑️ | ☑️ | ☑️ | +| Test | ☑️ | ☑️ | ☑️ | ☑️ | +| Finding | ☑️ | ☑️ | ☑️ | ☑️ | +| Finding Group | ☑️ | ☑️ | ☑️ | ☑️ | +| Risk Acceptance | ☑️ | ☑️ | ☑️ | ☑️ | +| Location | ☑️ | ☑️ | ☑️ | ☑️ | +| Component | ☑️ | | | | +| Note | ² | ☑️ | ☑️ | ☑️ | +| Benchmark | ² | | ☑️ | ☑️ | +| Language | ☑️ | ☑️ | ☑️ | ☑️ | +| Technology | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset API Scan Configuration | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset Tracking Files | ☑️ | ☑️ | ☑️ | ☑️ | +| Group | ☑️ | | ☑️ | ☑️ | + +1. **Asset > Add** bedeutet das Erstellen eines neuen Assets innerhalb einer Organisation, der die Rolle zugewiesen ist. +2. Die Ansicht für Notes und Benchmarks wird vererbt: Eine Rolle, die das übergeordnete Engagement, den Test, den Finding oder das Asset anzeigen kann, kann auch dessen Notes und Benchmarks anzeigen. Diese Zellen zeigen ein **?**-Symbol anstelle eines Kontrollkästchens. + +**Group & Member Permissions** steuern, wer die Mitgliedschaft verwalten kann. Die Spalten hier sind View, Manage, Add, Add Owner, Edit und Delete. + +| Row | Available actions | +| --- | --- | +| Organization Group, Asset Group | View, Add, Add Owner, Edit, Delete | +| Organization Member, Asset Member, Group Member | Manage, Add Owner, Delete | + +**Global Feature Permissions** steuern instanzweite Pro-Funktionen und nicht einzelne Organisationen oder Assets, daher **wirken sie nur, wenn die Rolle als globale Rolle vergeben ist**. Werden sie einer Rolle gewährt, die nur als Asset-Mitgliedschaft verwendet wird, hat das keine Wirkung. + +| Row | Available actions | +| --- | --- | +| Report Template | View, Add, Edit, Delete | +| Generated Report | View, Add, Delete | +| Connector, Sensei, Asset Hierarchy, Version Manager, Tuner, Universal Parser, Rule, Integration | View, Edit | +| Mitigation Policy | Edit | +| Audit Log, Metering | View | + +**Additional Permissions** ist eine Checkliste von Fähigkeiten, die nicht in das Schema View/Add/Edit/Delete passen: + +* **Configure Asset Notifications**: festlegen, welche Benachrichtigungen ein einzelnes Asset sendet und wohin. +* **Import Scan Result**: Scan-Ergebnisse importieren und erneut importieren, wodurch Findings erstellt und aktualisiert werden. +* **Share Dashboard Layout**: ein Dashboard-Layout für andere Benutzer veröffentlichen. Nur als globale Rolle. +* **Share Table Preference**: eine gespeicherte Tabellenansicht (Spalten, Filter, Sortierreihenfolge) veröffentlichen. Nur als globale Rolle. +* **View Note History**: sehen, wer eine Note wann geändert hat. + +### So lesen Sie das Raster + +![Die schreibgeschützte Ansicht der Berechtigungen einer Rolle](images/pro_role_permissions_modal.png) + +| What you see | What it means | +| --- | --- | +| Ein leeres Kontrollkästchen | Die Berechtigung existiert und ist nicht gewährt. Klicken Sie, um sie zu gewähren. | +| Ein aktiviertes Kontrollkästchen | Gewährt. | +| Eine schattierte, leere Zelle | Die Berechtigung existiert für diese Zeile und Aktion nicht. Nicht auswählbar. | +| Ein **?**-Symbol | Die Ansicht wird von einem übergeordneten Objekt vererbt, hier gibt es also nichts zu gewähren. | +| Ein grünes ✔ (schreibgeschützte Ansicht) | Gewährt. | +| Ein rotes ✘ (schreibgeschützte Ansicht) | Nicht gewährt. | + +In jeder Zeile steuert die am weitesten links stehende Berechtigung (**View**, bei Mitgliederzeilen **Manage**) den Rest der Zeile. Sie müssen sie gewähren, bevor die übrigen Zellen dieser Zeile verfügbar werden, denn eine Rolle kann nicht sinnvoll bearbeiten oder löschen, was sie nicht sehen kann. Wird die steuernde Berechtigung entfernt, werden auch die übrigen Berechtigungen der Zeile entfernt. + +## Bearbeiten, Klonen und Löschen + +Das **⋮**-Menü jeder Zeile bietet **Edit Role**, **Clone Role**, **Delete Role** und **Role History**. + +Integrierte Rollen bieten nur **Clone Role**. Sie können von niemandem bearbeitet oder gelöscht werden, auch nicht von Superusern. Dadurch bleibt eine bekannte Ausgangsbasis erhalten und Upgrades bleiben vorhersehbar. + +Das Löschen einer Rolle, die noch jemandem zugewiesen ist, schlägt fehl. Weisen Sie diese Zuweisungen zunächst um oder entfernen Sie sie, und löschen Sie die Rolle erst danach. Als Zuweisungen zählen dabei Organisations- und Asset-Mitgliedschaften (sowohl für Benutzer als auch für Gruppen), globale Rollen, Gruppenmitgliedschaften sowie die Standard-Gruppenrolle in den Systemeinstellungen. + +Die API kann die Neuzuweisung für Sie in einem einzigen Aufruf durchführen. Siehe [Verwalten von Rollen über die API](#managing-roles-through-the-api). + +## Zuweisen einer benutzerdefinierten Rolle + +Benutzerdefinierte Rollen erscheinen in jedem Rollen-Dropdown, neben den integrierten Rollen: + +| Where | How | +| --- | --- | +| **Global Role on a user** | Das Feld **Global Role** im Formular des Benutzers. Nur für Superuser. Siehe [Berechtigungen eines Benutzers festlegen](../set_user_permissions/). | +| **Global Role on a group** | Das Feld **Global Role** im Formular der Gruppe. Siehe [Berechtigungen teilen: Benutzergruppen](../create_user_group/). | +| **Organization or Asset membership** | Der Berechtigungsdialog der Organisation oder des Assets, sowohl für Benutzer als auch für Gruppen. Siehe [Berechtigungen in Pro festlegen](../pro_permissions_overhaul/). | +| **Default group role** | **Default group role** in den Systemeinstellungen, angewendet auf neu erstellte Benutzer. Siehe [Standardberechtigungen verwalten](../about_perms_and_roles/#manage-default-permissions). | +| **Role within a group** | Das Rollen-Dropdown in der Mitgliederliste einer Gruppe. Dieses Dropdown bietet nur Rollen an, die mindestens eine Group-Berechtigung gewähren; eine Rolle ohne Group-Berechtigungen erscheint dort also nicht. | + +Zwei Einschränkungen sind wichtig zu wissen: + +* **Die Owner-Stufe ist reserviert.** Eine benutzerdefinierte Rolle kann niemals eine Rolle der Owner-Stufe sein. Nur die integrierte Owner-Rolle ist das, weshalb nur sie die implizite Macht besitzt, andere Owner zu verwalten. +* **Um jemand anderem die Owner-Rolle zu gewähren, ist weiterhin die passende Add-Owner-Berechtigung erforderlich**, unabhängig davon, ob Sie dies bei einer Organisation, einem Asset oder einer Gruppe tun. + +## Was eine benutzerdefinierte globale Rolle freischaltet + +Teile der Benutzeroberfläche sind an eine Mindest-Globalrolle gebunden statt an eine einzelne Berechtigung. Damit benutzerdefinierte Rollen mit diesen Schranken funktionieren, ordnet DefectDojo eine benutzerdefinierte globale Rolle den integrierten Stufen zu: Eine benutzerdefinierte Rolle erreicht die höchste Stufe, deren Berechtigungen sie **vollständig** abdeckt. + +* Eine benutzerdefinierte Rolle, die alles abdeckt, was Maintainer gewährt, wird für diese Schranken wie Maintainer behandelt. +* Deckt sie alles ab, was Writer gewährt, wird sie wie Writer behandelt. Ebenso für Reader. +* Deckt sie keine davon vollständig ab, erreicht sie keine Stufe. Ihre einzelnen Berechtigungen funktionieren weiterhin genau wie gewährt; nur die stufenbasierten UI-Schranken bleiben verschlossen. +* **Owner kann auf diesem Weg nie erreicht werden.** Die Rollenverwaltung und alles andere, was an die globale Owner-Rolle gebunden ist, bleibt Superusern und der integrierten Owner-Rolle vorbehalten. + +Die Abdeckung muss vollständig sein, was gelegentlich überrascht. Eine von Maintainer geklonte Rolle erreicht die Maintainer-Stufe. Bauen Sie die Berechtigungen von Maintainer von Hand nach und übersehen dabei eine, landet die Rolle stattdessen auf der Writer-Stufe. Fehlt bei einer benutzerdefinierten globalen Rolle eine erwartete UI-Funktion, vergleichen Sie sie mit der integrierten Stufe in den [Tabellen der Aktionsberechtigungen](../user_permission_chart/). + +## Rollenverlauf + +Benutzerdefinierte Rollen führen ein Prüfprotokoll. Öffnen Sie **Role History** über das **⋮**-Menü einer Rolle, um zu sehen, welche Berechtigungen von wem und wann gewährt oder entzogen wurden, zusammen mit Änderungen daran, wer die Rolle innehat. + +Zwei Dinge zeigt dieser Verlauf nicht: Änderungen am Namen und an der Beschreibung einer Rolle selbst sowie die Berechtigungen integrierter Rollen (diese werden vorab angelegt, nie bearbeitet und erzeugen daher nie einen Verlauf). + +Der Rollenverlauf ist ein Lesevorgang und daher unabhängig davon verfügbar, ob die Custom-Roles-Funktion aktiviert ist. + +## Verwalten von Rollen über die API + +Rollen sind unter `/api/v2/roles/` verfügbar. Lesezugriffe stehen jedem authentifizierten Benutzer offen, da Clients die Rollenliste benötigen, um Dropdowns zu befüllen. Schreibzugriffe erfordern den Superuser-Status oder die integrierte globale Owner-Rolle sowie das Custom-Roles-Feature-Flag. + +| Operation | Request | +| --- | --- | +| List roles | `GET /api/v2/roles/` | +| Retrieve one role | `GET /api/v2/roles/{id}/` | +| List every grantable permission | `GET /api/v2/roles/permissions_catalog/` | +| Create a role | `POST /api/v2/roles/` mit `name`, optional `description` und einer `permissions`-Liste | +| Replace a role's permissions | `PATCH /api/v2/roles/{id}/` mit einer `permissions`-Liste | +| Clone a role | `POST /api/v2/roles/{id}/clone/` mit optionalem `name` und `description` | +| Delete a role | `DELETE /api/v2/roles/{id}/` | +| Delete a role and move its assignments | `DELETE /api/v2/roles/{id}/?reassign_to={other_role_id}` | +| Read a role's history | `GET /api/v2/roles/{id}/history/` | + +Hinweise: + +* `permissions` **ersetzt** die Berechtigungsliste der Rolle, statt sie zu ergänzen. Senden Sie die vollständige Menge, die die Rolle am Ende haben soll. +* `?reassign_to=` verschiebt alle Zuweisungen der gelöschten Rolle in einer einzigen Transaktion auf die von Ihnen genannte Rolle. Dies ist der einzige Weg für eine Massen-Neuzuweisung: Die Benutzeroberfläche bietet dies nicht an. +* Der Versuch, eine integrierte Rolle zu bearbeiten oder zu löschen, liefert `403`. Das Bearbeiten eines unbekannten Berechtigungswerts, die Wiederverwendung eines bestehenden Rollennamens oder das Löschen einer verwendeten Rolle ohne `reassign_to` liefert `400` mit einer Erklärung. +* `is_owner` kann nicht über die API gesetzt werden. Wird es dennoch gesendet, wird es akzeptiert und ignoriert. + +## Wissenswertes + +* **Mehrere Rollen am selben Objekt gewähren die Vereinigung ihrer Berechtigungen.** Hält ein Benutzer direkt eine Rolle an einem Asset und erbt über eine Gruppe eine weitere, erhält er alles, was beide Rollen gewähren. Rollen fügen Berechtigungen immer nur hinzu, nie entziehen sie welche. +* **Berechtigungsänderungen werden beim nächsten Laden der Seite übernommen**, nicht sofort in der aktuellen Ansicht. Hintergrundjobs können bis zu 30 Sekunden brauchen, zwischengespeicherte Berechtigungsdaten bis zu 5 Minuten, bis eine Änderung sichtbar wird. +* **Rollen-Dropdowns listen bis zu 250 Rollen auf.** Darüber hinaus erscheinen manche Rollen nicht mehr in Dropdowns, funktionieren aber weiterhin. +* **Maintainer und Owner können Organizations hinzufügen, das Raster zeigt dies jedoch nicht.** Bei diesen beiden Rollen ist diese Gewährung als globale Gewährung gespeichert, und das Raster liest nur objektbezogene Gewährungen, weshalb ihre Zelle **Organization > Add** als nicht gewährt angezeigt wird. Das Klonen einer der beiden Rollen übernimmt die Gewährung. +* **Die Terminologie folgt Ihrer Instanz.** Diese Dokumentation verwendet Organization und Asset, die Standardbezeichnungen. Wurde die Umbenennung Organization/Asset in Ihrer Instanz deaktiviert, lauten dieselben Zeilen stattdessen Product Type und Product. +* **Die Seite „Rollen" ist für alle anderen schreibgeschützt.** Ein Benutzer, der direkt `/settings/roles` aufruft, kann die Rollen und ihre Berechtigungen sehen, aber nichts ändern. Berechtigungsdaten sind nicht sensibel, und der Server setzt die eigentliche Grenze bei jedem Schreibvorgang durch. diff --git a/docs/content/admin/user_management/PRO__custom_rbac_roles.es.md b/docs/content/admin/user_management/PRO__custom_rbac_roles.es.md new file mode 100644 index 00000000000..c3f0ba3789b --- /dev/null +++ b/docs/content/admin/user_management/PRO__custom_rbac_roles.es.md @@ -0,0 +1,212 @@ +--- +title: Roles RBAC personalizados +description: Cree sus propios roles eligiendo permisos individuales, utilizando los + cinco roles integrados como puntos de partida clonables +weight: 5 +audience: pro +--- + +> **Función de DefectDojo Pro.** El sistema RBAC de Members / Groups / Global Roles descrito en esta página forma parte de DefectDojo Pro. La versión de código abierto de DefectDojo utiliza el modelo de [Usuarios autorizados](../os__authorized_users/). Consulte esa página para conocer el control de acceso en la versión de código abierto, y las [notas de actualización a 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si está migrando entre ediciones. + +DefectDojo Pro incluye cinco roles: **Reader**, **Writer**, **Maintainer**, **Owner** y **API Importer**. Si ninguno de ellos se ajusta a sus necesidades, ahora puede crear su propio rol eligiendo exactamente qué permisos otorga. + +Un rol personalizado funciona en cualquier lugar donde funcione un rol integrado: como Rol global, como rol de un Grupo, como rol de grupo predeterminado, y como rol de miembro en una Organization o Asset individual. + +Los cinco roles integrados se convierten en **ajustes preestablecidos bloqueados y clonables**. Sus permisos no cambian (consulte las [tablas de permisos de acciones](../user_permission_chart/) para ver qué otorga cada uno), no se pueden editar ni eliminar, y clonar uno de ellos es la forma recomendada de crear un nuevo rol. + +## Antes de empezar + +La gestión de roles personalizados está desactivada de forma predeterminada. Un **superuser** la activa desde **Settings > Feature Flags**, habilitando **Custom Roles**. Consulte [Feature Flags](/admin/feature_flags/pro__feature_flags/) para saber cómo funciona esa página. + +Mientras la función esté desactivada, la página Roles se puede seguir consultando: puede ver los roles integrados y sus permisos, pero no puede crear, editar, clonar ni eliminar nada. + +Gestionar roles requiere el estado de **superuser** o el Rol global integrado **Owner**. Esto es intencional y no se puede delegar a un rol personalizado: consulte [Qué desbloquea un Rol global personalizado](#what-a-custom-global-role-unlocks). + +## Apertura de la página Roles + +Vaya a **👤 Users > Roles** en la barra lateral izquierda. Esta entrada de menú es visible para los superusuarios y para quienes tienen el Rol global integrado Owner. + +![La página Roles con la lista de roles integrados y personalizados](images/pro_roles_list.png) + +La tabla enumera todos los roles de su instancia: + +| Column | What it shows | +| --- | --- | +| **ID** | El id numérico del rol. Útil al filtrar la tabla Users o al llamar a la API. | +| **Name** | El nombre del rol. | +| **Description** | Su propia nota sobre para qué sirve el rol. Es opcional, y queda vacía a menos que alguien la complete. Los roles integrados no incluyen ninguna. | +| **Permissions** | Un conteo de los permisos otorgados. Haga clic para abrir una vista de solo lectura de la cuadrícula completa. | +| **Users** | Cuántos usuarios tienen este rol como su Rol global. Haga clic para verlos en la tabla Users. | +| **Type** | **Built-in** para los cinco ajustes preestablecidos, **Custom** para los roles que usted creó. | + +Todas las columnas se pueden ordenar y filtrar, y la búsqueda por palabra clave coincide con el nombre y la descripción. + +## Creación de un rol + +### Clonar un rol integrado (recomendado) + +Clonar le permite partir de un conjunto de permisos ya probado en lugar de una cuadrícula vacía, lo que hace mucho más difícil olvidar por accidente un permiso que el rol necesita. + +1. Busque el rol más cercano a lo que necesita. +2. Abra su menú **⋮** y seleccione **Clone Role**. +3. Se crea una copia de inmediato, llamada ` (copy)`, con los mismos permisos y la misma descripción que el rol del que proviene. +4. Abra el menú **⋮** de la copia, seleccione **Edit Role**, luego cambie su nombre y ajuste sus permisos. + +Los roles integrados se pueden clonar aunque no se puedan editar. El clon registra de qué rol proviene. + +### Empezar desde cero + +1. Haga clic en **New Role**. +2. Asígnele un **Name** (obligatorio) y, opcionalmente, una **Description**. +3. Elija sus permisos en la cuadrícula a continuación (consulte la siguiente sección). +4. Haga clic en **Save Role**. + +Los nombres de los roles deben ser únicos, y la verificación no distingue mayúsculas de minúsculas: si `Triage Lead` ya existe, `triage lead` será rechazado. + +## Elección de permisos + +![La cuadrícula de permisos en el formulario de rol](images/pro_role_permission_grid.png) + +Los permisos se agrupan en tres tablas más una lista de verificación. + +**Object Permissions** se aplican a las Organizations y Assets a las que se asigna el rol, y a todo lo anidado dentro de ellas. + +| Row | View | Add | Edit | Delete | +| --- | --- | --- | --- | --- | +| Organization | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset | ☑️ | ☑️ ¹ | ☑️ | ☑️ | +| Compromiso | ☑️ | ☑️ | ☑️ | ☑️ | +| Test | ☑️ | ☑️ | ☑️ | ☑️ | +| Hallazgo | ☑️ | ☑️ | ☑️ | ☑️ | +| Grupo de hallazgos | ☑️ | ☑️ | ☑️ | ☑️ | +| Aceptación de riesgo | ☑️ | ☑️ | ☑️ | ☑️ | +| Location | ☑️ | ☑️ | ☑️ | ☑️ | +| Component | ☑️ | | | | +| Nota | ² | ☑️ | ☑️ | ☑️ | +| Benchmark | ² | | ☑️ | ☑️ | +| Language | ☑️ | ☑️ | ☑️ | ☑️ | +| Technology | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset API Scan Configuration | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset Tracking Files | ☑️ | ☑️ | ☑️ | ☑️ | +| Grupo | ☑️ | | ☑️ | ☑️ | + +1. **Asset > Añadir** significa crear un nuevo Asset dentro de una Organization a la que está asignado el rol. +2. El permiso Ver para Notas y Benchmarks se hereda: un rol que puede ver el Compromiso, Test, Hallazgo o Asset superior puede ver sus Notas y Benchmarks. Estas celdas muestran un ícono **?** en lugar de una casilla de verificación. + +**Group & Member Permissions** controlan quién puede gestionar la membresía. Las columnas aquí son Ver, Gestionar, Añadir, Añadir propietario, Editar y Eliminar. + +| Row | Available actions | +| --- | --- | +| Organization Group, Asset Group | Ver, Añadir, Añadir propietario, Editar, Eliminar | +| Organization Member, Asset Member, Group Member | Gestionar, Añadir propietario, Eliminar | + +**Global Feature Permissions** controlan el acceso a funciones de Pro a nivel de instancia, en lugar de Organizations o Assets individuales, por lo que **solo tienen efecto cuando el rol se tiene como Rol global**. Otorgarlos a un rol que solo se usa como membresía de Asset no tiene ningún efecto. + +| Row | Available actions | +| --- | --- | +| Report Template | Ver, Añadir, Editar, Eliminar | +| Generated Report | Ver, Añadir, Eliminar | +| Connector, Sensei, Asset Hierarchy, Version Manager, Tuner, Universal Parser, Rule, Integration | Ver, Editar | +| Mitigation Policy | Editar | +| Audit Log, Metering | Ver | + +**Additional Permissions** es una lista de verificación de capacidades que no encajan en el esquema Ver/Añadir/Editar/Eliminar: + +* **Configure Asset Notifications**: elegir qué notificaciones envía un Asset individual, y a dónde. +* **Import Scan Result**: importar y reimportar resultados de escaneo, creando y actualizando hallazgos. +* **Share Dashboard Layout**: publicar un diseño de panel para otros usuarios. Solo Rol global. +* **Share Table Preference**: publicar una vista de tabla guardada (columnas, filtros, orden). Solo Rol global. +* **View Note History**: ver quién cambió una nota y cuándo. + +### Cómo interpretar la cuadrícula + +![La vista de solo lectura de los permisos de un rol](images/pro_role_permissions_modal.png) + +| What you see | What it means | +| --- | --- | +| Una casilla de verificación vacía | El permiso existe y no está otorgado. Haga clic para otorgarlo. | +| Una casilla de verificación marcada | Otorgado. | +| Una celda vacía y sombreada | El permiso no existe para esa fila y acción. No se puede seleccionar. | +| Un ícono **?** | El permiso Ver se hereda de un objeto superior, por lo que no hay nada que otorgar aquí. | +| Un ✔ verde (vista de solo lectura) | Otorgado. | +| Una ✘ roja (vista de solo lectura) | No otorgado. | + +En cada fila, el permiso situado más a la izquierda (**Ver**, o **Gestionar** en las filas de miembros) condiciona el resto de la fila. Debe otorgarlo antes de que las demás celdas de esa fila estén disponibles, porque un rol no puede editar ni eliminar de forma significativa lo que no puede ver. Al revocar ese permiso se revoca también el resto de la fila. + +## Edición, clonación y eliminación + +El menú **⋮** de cada fila ofrece **Edit Role**, **Clone Role**, **Delete Role** y **Role History**. + +Los roles integrados solo ofrecen **Clone Role**. Nadie puede editarlos ni eliminarlos, ni siquiera los superusuarios. Esto mantiene una base de referencia conocida y hace que las actualizaciones sean predecibles. + +Eliminar un rol que todavía esté asignado a alguien fallará. Primero reasigne o elimine esas asignaciones, y luego elimine el rol. Las asignaciones que cuentan para este propósito son las membresías de Organization y Asset (tanto de usuario como de grupo), los Roles globales, las membresías de Grupo y el rol de grupo predeterminado en System Settings. + +La API puede hacer la reasignación por usted en una sola llamada. Consulte [Gestión de roles a través de la API](#managing-roles-through-the-api). + +## Asignación de un rol personalizado + +Los roles personalizados aparecen en todos los menús desplegables de roles, junto con los integrados: + +| Where | How | +| --- | --- | +| **Rol global en un usuario** | El campo **Global Role** en el formulario del usuario. Solo superusuarios. Consulte [Establecer los permisos de un Usuario](../set_user_permissions/). | +| **Rol global en un grupo** | El campo **Global Role** en el formulario del grupo. Consulte [Compartir permisos: grupos de usuarios](../create_user_group/). | +| **Membresía de Organization o Asset** | El diálogo Permissions en la Organization o el Asset, tanto para usuarios como para grupos. Consulte [Establecer permisos en Pro](../pro_permissions_overhaul/). | +| **Rol de grupo predeterminado** | **Default group role** en System Settings, aplicado a los usuarios recién creados. Consulte [Gestionar los permisos predeterminados](../about_perms_and_roles/#manage-default-permissions). | +| **Rol dentro de un grupo** | El menú desplegable de roles en la lista de miembros de un grupo. Este menú solo ofrece roles que otorgan al menos un permiso de Group, por lo que un rol sin permisos de Group no aparecerá allí. | + +Vale la pena conocer dos restricciones: + +* **El nivel Owner está reservado.** Un rol personalizado nunca puede ser un rol de nivel Owner. Solo el Owner integrado lo es, por lo que solo él conlleva el poder implícito de gestionar a otros Owners. +* **Otorgar el rol Owner a otra persona sigue requiriendo el permiso Add Owner correspondiente**, ya sea que lo haga en una Organization, un Asset o un Group. + +## Qué desbloquea un Rol global personalizado + +Algunas partes de la interfaz dependen de un Rol global mínimo en lugar de un permiso individual. Para que los roles personalizados funcionen con esas restricciones, DefectDojo clasifica un Rol global personalizado frente a los niveles integrados: un rol personalizado obtiene el nivel más alto cuyos permisos cubre **por completo**. + +* Un rol personalizado que cubre todo lo que otorga Maintainer se trata como Maintainer para esas restricciones. +* Cubra todo lo que otorga Writer, y se tratará como Writer. Lo mismo para Reader. +* Si no cubre ninguno de ellos por completo, no obtiene ningún nivel. Sus permisos individuales siguen funcionando exactamente como se otorgaron; solo permanecen cerradas las restricciones de interfaz basadas en niveles. +* **El nivel Owner nunca se puede obtener de esta manera.** La gestión de roles, y todo lo demás que depende del Rol global Owner, permanece reservada a los superusuarios y al Owner integrado. + +La cobertura debe ser completa, algo que a veces sorprende. Un rol clonado de Maintainer obtiene el nivel Maintainer. Si reconstruye los permisos de Maintainer a mano y omite uno, el rol termina en el nivel Writer. Si a un Rol global personalizado le falta interfaz que usted esperaba ver, compárelo con el nivel integrado en las [tablas de permisos de acciones](../user_permission_chart/). + +## Historial de roles + +Los roles personalizados mantienen un registro de auditoría. Abra **Role History** desde el menú **⋮** de un rol para ver qué permisos se otorgaron o revocaron, por quién y cuándo, junto con los cambios en quién tiene el rol. + +Hay dos cosas que este historial no muestra: los cambios en el propio nombre y descripción de un rol, y los permisos de los roles integrados (esos se generan de forma predeterminada, nunca se editan, por lo que nunca generan historial). + +El historial de roles es una operación de lectura, por lo que está disponible independientemente de que la función Custom Roles esté activada o no. + +## Gestión de roles a través de la API + +Los roles están disponibles en `/api/v2/roles/`. Las lecturas están abiertas a cualquier usuario autenticado, porque los clientes necesitan la lista de roles para completar los menús desplegables. Las escrituras requieren el estado de superuser o el Rol global integrado Owner, además del feature flag Custom Roles. + +| Operation | Request | +| --- | --- | +| List roles | `GET /api/v2/roles/` | +| Retrieve one role | `GET /api/v2/roles/{id}/` | +| List every grantable permission | `GET /api/v2/roles/permissions_catalog/` | +| Create a role | `POST /api/v2/roles/` with `name`, optional `description`, and a `permissions` list | +| Replace a role's permissions | `PATCH /api/v2/roles/{id}/` with a `permissions` list | +| Clone a role | `POST /api/v2/roles/{id}/clone/` with an optional `name` and `description` | +| Delete a role | `DELETE /api/v2/roles/{id}/` | +| Delete a role and move its assignments | `DELETE /api/v2/roles/{id}/?reassign_to={other_role_id}` | +| Read a role's history | `GET /api/v2/roles/{id}/history/` | + +Notas: + +* `permissions` **reemplaza** la lista de permisos otorgados del rol en lugar de añadirse a ella. Envíe el conjunto completo con el que desea que el rol termine. +* `?reassign_to=` mueve todas las asignaciones del rol eliminado al rol que indique, en una sola transacción. Esta es la única forma de reasignar en bloque: la interfaz no lo ofrece. +* Intentar editar o eliminar un rol integrado devuelve `403`. Editar un valor de permiso desconocido, reutilizar el nombre de un rol existente, o eliminar un rol en uso sin `reassign_to`, devuelve `400` con una explicación. +* `is_owner` no se puede establecer a través de la API. Enviarlo en la solicitud se acepta pero se ignora. + +## Aspectos a tener en cuenta + +* **Varios roles sobre el mismo objeto otorgan la unión de sus permisos.** Si un usuario tiene un rol directamente en un Asset y hereda otro a través de un grupo, obtiene todo lo que otorga cualquiera de los dos roles. Los roles solo añaden permisos, nunca los quitan. +* **Los cambios de permisos se aplican en la siguiente carga de página**, no de forma instantánea en la vista actual. Los jobs en segundo plano pueden tardar hasta 30 segundos, y los datos de permisos en caché hasta 5 minutos, en reflejar una edición. +* **Los menús desplegables de roles muestran hasta 250 roles.** Más allá de eso, algunos roles no aparecerán en los menús desplegables, aunque seguirán funcionando. +* **Maintainer y Owner pueden añadir Organizations, pero la cuadrícula no lo muestra.** Para esos dos roles, ese permiso se almacena como una concesión de alcance global, y la cuadrícula solo muestra las concesiones de alcance de objeto, por lo que su celda **Organization > Añadir** aparece como no otorgada. Clonar cualquiera de los dos roles conserva ese permiso. +* **La terminología sigue la de su instancia.** Esta documentación usa Organization y Asset, las etiquetas predeterminadas. Si en su instancia se ha desactivado el cambio de nombre de Organization / Asset, las mismas filas se leen como Product Type y Product. +* **La página Roles es de solo lectura para todos los demás.** Un usuario que acceda directamente a `/settings/roles` puede ver los roles y sus permisos, pero no puede cambiar nada. Los datos de permisos no son sensibles, y el servidor aplica el límite real en cada escritura. diff --git a/docs/content/admin/user_management/PRO__custom_rbac_roles.fr.md b/docs/content/admin/user_management/PRO__custom_rbac_roles.fr.md new file mode 100644 index 00000000000..aea43c5480a --- /dev/null +++ b/docs/content/admin/user_management/PRO__custom_rbac_roles.fr.md @@ -0,0 +1,212 @@ +--- +title: Rôles RBAC personnalisés +description: Créez vos propres rôles en choisissant des autorisations individuelles, + en utilisant les cinq rôles intégrés comme points de départ clonables +weight: 5 +audience: pro +--- + +> **Fonctionnalité DefectDojo Pro.** Le système RBAC Membres / Groupes / Rôles globaux décrit sur cette page fait partie de DefectDojo Pro. La version open source de DefectDojo utilise le modèle [Utilisateurs autorisés](../os__authorized_users/). Consultez cette page pour le contrôle d'accès en open source, ainsi que les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si vous passez d'une édition à l'autre. + +DefectDojo Pro est livré avec cinq rôles : **Reader**, **Writer**, **Maintainer**, **Owner**, et **API Importer**. Si aucun d'entre eux ne convient, vous pouvez désormais créer votre propre rôle en choisissant exactement les autorisations qu'il accorde. + +Un rôle personnalisé fonctionne partout où un rôle intégré fonctionne : en tant que Rôle global, en tant que rôle d'un Groupe, en tant que rôle de groupe par défaut, et en tant que rôle de membre sur une Organisation ou un Actif individuel. + +Les cinq rôles intégrés deviennent des **préréglages verrouillés et clonables**. Leurs autorisations restent inchangées (consultez les [tableaux des autorisations par action](../user_permission_chart/) pour savoir ce que chacun accorde), ils ne peuvent être ni modifiés ni supprimés, et les cloner est la méthode recommandée pour créer un nouveau rôle. + +## Avant de commencer + +La gestion des rôles personnalisés est désactivée par défaut. Un **superutilisateur** l'active depuis **Settings > Feature Flags**, en activant **Custom Roles**. Consultez [Indicateurs de fonctionnalités](/admin/feature_flags/pro__feature_flags/) pour savoir comment fonctionne cette page. + +Tant que la fonctionnalité est désactivée, la page Rôles reste consultable : vous pouvez voir les rôles intégrés et leurs autorisations, mais vous ne pouvez rien créer, modifier, cloner ou supprimer. + +La gestion des rôles nécessite le statut de **superutilisateur** ou le Rôle global **Owner** intégré. Ceci est volontaire et ne peut être délégué à un rôle personnalisé : consultez [Ce que débloque un Rôle global personnalisé](#what-a-custom-global-role-unlocks). + +## Ouvrir la page Rôles + +Accédez à **👤 Users > Roles** dans la barre latérale gauche. Cette entrée de menu est visible par les superutilisateurs et les détenteurs du Rôle global Owner intégré. + +![La page Rôles listant les rôles intégrés et personnalisés](images/pro_roles_list.png) + +Le tableau répertorie tous les rôles de votre instance : + +| Colonne | Ce qu'elle affiche | +| --- | --- | +| **ID** | L'identifiant numérique du rôle. Utile pour filtrer le tableau des Utilisateurs ou pour les appels à l'API. | +| **Nom** | Le nom du rôle. | +| **Description** | Votre propre note décrivant l'objet du rôle. Facultatif, et vide à moins que quelqu'un ne le renseigne. Les rôles intégrés n'en ont pas par défaut. | +| **Autorisations** | Un décompte des autorisations accordées. Cliquez dessus pour ouvrir une vue en lecture seule de la grille complète. | +| **Utilisateurs** | Le nombre d'utilisateurs détenant ce rôle en tant que Rôle global. Cliquez pour les voir dans le tableau des Utilisateurs. | +| **Type** | **Built-in** pour les cinq préréglages, **Custom** pour les rôles que vous avez créés. | + +Chaque colonne est triable et filtrable, et la recherche par mot-clé porte sur le nom et la description. + +## Créer un rôle + +### Cloner un rôle intégré (recommandé) + +Le clonage vous permet de partir d'un ensemble d'autorisations déjà éprouvé plutôt que d'une grille vide, ce qui réduit considérablement le risque d'oublier accidentellement une autorisation dont un rôle a besoin. + +1. Recherchez le rôle le plus proche de ce que vous souhaitez. +2. Ouvrez son menu **⋮** et choisissez **Clone Role**. +3. Une copie est créée immédiatement, nommée ` (copy)`, avec les mêmes autorisations et la même description que le rôle d'origine. +4. Ouvrez le menu **⋮** de la copie, choisissez **Edit Role**, puis renommez-la et ajustez ses autorisations. + +Les rôles intégrés peuvent être clonés même s'ils ne peuvent pas être modifiés. Le clone conserve la trace du rôle dont il provient. + +### Partir de zéro + +1. Cliquez sur **New Role**. +2. Donnez-lui un **Name** (obligatoire) et, éventuellement, une **Description**. +3. Choisissez ses autorisations dans la grille ci-dessous (voir la section suivante). +4. Cliquez sur **Save Role**. + +Les noms de rôle doivent être uniques, et la vérification ignore la casse : si `Triage Lead` existe, `triage lead` est rejeté. + +## Choisir les autorisations + +![La grille des autorisations dans le formulaire de rôle](images/pro_role_permission_grid.png) + +Les autorisations sont regroupées en trois tableaux, plus une liste de contrôle. + +**Les autorisations sur les objets** s'appliquent aux Organisations et aux Actifs auxquels le rôle est attribué, ainsi qu'à tout ce qui leur est imbriqué. + +| Ligne | Voir | Ajouter | Modifier | Supprimer | +| --- | --- | --- | --- | --- | +| Organisation | ☑️ | ☑️ | ☑️ | ☑️ | +| Actif | ☑️ | ☑️ ¹ | ☑️ | ☑️ | +| Engagement | ☑️ | ☑️ | ☑️ | ☑️ | +| Test | ☑️ | ☑️ | ☑️ | ☑️ | +| Constatation | ☑️ | ☑️ | ☑️ | ☑️ | +| Groupe de constatations | ☑️ | ☑️ | ☑️ | ☑️ | +| Acceptation du risque | ☑️ | ☑️ | ☑️ | ☑️ | +| Emplacement | ☑️ | ☑️ | ☑️ | ☑️ | +| Composant | ☑️ | | | | +| Note | ² | ☑️ | ☑️ | ☑️ | +| Benchmark | ² | | ☑️ | ☑️ | +| Langue | ☑️ | ☑️ | ☑️ | ☑️ | +| Technologie | ☑️ | ☑️ | ☑️ | ☑️ | +| Configuration de l'analyse API de l'Actif | ☑️ | ☑️ | ☑️ | ☑️ | +| Fichiers de suivi de l'Actif | ☑️ | ☑️ | ☑️ | ☑️ | +| Groupe | ☑️ | | ☑️ | ☑️ | + +1. **Actif > Ajouter** signifie créer un nouvel Actif au sein d'une Organisation à laquelle le rôle est attribué. +2. La visualisation des Notes et des Benchmarks est héritée : un rôle pouvant consulter l'Engagement, le Test, la Constatation ou l'Actif parent peut consulter ses Notes et ses Benchmarks. Ces cellules affichent une icône **?** au lieu d'une case à cocher. + +**Les autorisations de Groupe et de Membre** contrôlent qui peut gérer l'appartenance. Les colonnes ici sont Voir, Gérer, Ajouter, Ajouter un Owner, Modifier et Supprimer. + +| Ligne | Actions disponibles | +| --- | --- | +| Groupe d'Organisation, Groupe d'Actif | Voir, Ajouter, Ajouter un Owner, Modifier, Supprimer | +| Membre d'Organisation, Membre d'Actif, Membre de Groupe | Gérer, Ajouter un Owner, Supprimer | + +**Les autorisations de fonctionnalités globales** conditionnent l'accès à des fonctionnalités Pro à l'échelle de l'instance plutôt qu'à des Organisations ou des Actifs individuels, **elles ne prennent donc effet que lorsque le rôle est détenu en tant que Rôle global**. Les accorder sur un rôle utilisé uniquement comme appartenance à un Actif n'a aucun effet. + +| Ligne | Actions disponibles | +| --- | --- | +| Modèle de rapport | Voir, Ajouter, Modifier, Supprimer | +| Rapport généré | Voir, Ajouter, Supprimer | +| Connector, Sensei, Hiérarchie des Actifs, Version Manager, Tuner, Universal Parser, Règle, Intégration | Voir, Modifier | +| Politique de mitigation | Modifier | +| Journal d'audit, Metering | Voir | + +**Les autorisations supplémentaires** forment une liste de contrôle de capacités qui ne correspondent pas au schéma Voir/Ajouter/Modifier/Supprimer : + +* **Configurer les notifications de l'Actif** : choisir quelles notifications un Actif envoie, et où. +* **Importer un résultat d'analyse** : importer et réimporter des résultats d'analyse, en créant et en mettant à jour des Constatations. +* **Partager la disposition du tableau de bord** : publier une disposition de Tableau de bord pour d'autres utilisateurs. Rôle global uniquement. +* **Partager les préférences de tableau** : publier une vue de tableau enregistrée (colonnes, filtres, ordre de tri). Rôle global uniquement. +* **Voir l'historique des notes** : voir qui a modifié une note et quand. + +### Comment lire la grille + +![La vue en lecture seule des autorisations d'un rôle](images/pro_role_permissions_modal.png) + +| Ce que vous voyez | Ce que cela signifie | +| --- | --- | +| Une case à cocher vide | L'autorisation existe et n'est pas accordée. Cliquez pour l'accorder. | +| Une case à cocher cochée | Accordée. | +| Une cellule vide et grisée | L'autorisation n'existe pas pour cette ligne et cette action. Non sélectionnable. | +| Une icône **?** | La visualisation est héritée d'un objet parent, il n'y a donc rien à accorder ici. | +| Une coche verte ✔ (vue en lecture seule) | Accordée. | +| Une croix rouge ✘ (vue en lecture seule) | Non accordée. | + +Dans chaque ligne, l'autorisation la plus à gauche (**Voir**, ou **Gérer** sur les lignes de membres) conditionne le reste de la ligne. Vous devez l'accorder avant que les autres cellules de cette ligne ne deviennent disponibles, car un rôle ne peut pas réellement modifier ou supprimer ce qu'il ne peut pas voir. Décocher cette condition efface également le reste de la ligne. + +## Modifier, cloner et supprimer + +Le menu **⋮** de chaque ligne propose **Edit Role**, **Clone Role**, **Delete Role**, et **Role History**. + +Les rôles intégrés ne proposent que **Clone Role**. Ils ne peuvent être ni modifiés ni supprimés, par personne, y compris les superutilisateurs. Cela permet de conserver une base de référence connue et de garder les mises à niveau prévisibles. + +La suppression d'un rôle encore attribué à quelqu'un échouera. Réattribuez ou supprimez d'abord ces attributions, puis supprimez le rôle. Les attributions prises en compte à cet effet sont les appartenances à une Organisation et à un Actif (utilisateur comme groupe), les Rôles globaux, les appartenances à un Groupe, et le rôle de groupe par défaut dans les Paramètres système. + +L'API peut effectuer cette réattribution pour vous en un seul appel. Consultez [Gérer les rôles via l'API](#managing-roles-through-the-api). + +## Attribuer un rôle personnalisé + +Les rôles personnalisés apparaissent dans chaque liste déroulante de rôles, aux côtés des rôles intégrés : + +| Où | Comment | +| --- | --- | +| **Rôle global sur un utilisateur** | Le champ **Global Role** du formulaire de l'utilisateur. Superutilisateurs uniquement. Consultez [Définir les autorisations d'un utilisateur](../set_user_permissions/). | +| **Rôle global sur un groupe** | Le champ **Global Role** du formulaire du groupe. Consultez [Partager les autorisations : Groupes d'utilisateurs](../create_user_group/). | +| **Appartenance à une Organisation ou à un Actif** | La boîte de dialogue Autorisations sur l'Organisation ou l'Actif, pour les utilisateurs comme pour les groupes. Consultez [Définir les autorisations dans Pro](../pro_permissions_overhaul/). | +| **Rôle de groupe par défaut** | **Default group role** dans les Paramètres système, appliqué aux utilisateurs nouvellement créés. Consultez [Gérer les autorisations par défaut](../about_perms_and_roles/#manage-default-permissions). | +| **Rôle au sein d'un groupe** | La liste déroulante de rôles dans la liste des membres d'un groupe. Cette liste ne propose que les rôles accordant au moins une autorisation de Groupe ; un rôle sans autorisation de Groupe n'y apparaîtra donc pas. | + +Deux contraintes sont à connaître : + +* **Le niveau Owner est réservé.** Un rôle personnalisé ne peut jamais être un rôle de niveau Owner. Seul le rôle intégré Owner l'est, et lui seul détient donc le pouvoir implicite de gérer d'autres Owners. +* **Accorder le rôle Owner à quelqu'un d'autre nécessite toujours l'autorisation Add Owner correspondante**, que vous le fassiez sur une Organisation, un Actif ou un Groupe. + +## Ce que débloque un Rôle global personnalisé + +Certaines parties de l'interface sont conditionnées à un Rôle global minimum plutôt qu'à une autorisation individuelle. Pour que les rôles personnalisés fonctionnent avec ces conditions, DefectDojo classe un Rôle global personnalisé par rapport aux niveaux intégrés : un rôle personnalisé obtient le niveau le plus élevé dont il couvre **complètement** les autorisations. + +* Un rôle personnalisé qui couvre tout ce qu'accorde Maintainer est traité comme Maintainer pour ces conditions. +* Couvrez tout ce qu'accorde Writer, et il est traité comme Writer. Idem pour Reader. +* Ne couvrez complètement aucun d'entre eux, et il n'obtient aucun niveau. Ses autorisations individuelles fonctionnent malgré tout exactement comme accordées ; seules les conditions d'interface basées sur le niveau restent fermées. +* **Le niveau Owner ne peut jamais être obtenu de cette façon.** La gestion des rôles, et tout ce qui est conditionné au Rôle global Owner, reste réservée aux superutilisateurs et au rôle intégré Owner. + +La couverture doit être complète, ce qui surprend parfois. Un rôle cloné à partir de Maintainer obtient le niveau Maintainer. Reconstruisez les autorisations de Maintainer à la main, oubliez-en une, et le rôle se retrouve au niveau Writer à la place. Si un Rôle global personnalisé n'affiche pas l'interface que vous attendiez, comparez-le au niveau intégré correspondant dans les [tableaux des autorisations par action](../user_permission_chart/). + +## Historique des rôles + +Les rôles personnalisés conservent une piste d'audit. Ouvrez **Role History** depuis le menu **⋮** d'un rôle pour voir quelles autorisations ont été accordées ou révoquées, par qui, et quand, ainsi que les changements concernant qui détient le rôle. + +Deux choses que cet historique ne montre pas : les modifications du nom et de la description du rôle lui-même, et les autorisations des rôles intégrés (celles-ci sont préconfigurées, jamais modifiées, et ne génèrent donc jamais d'historique). + +L'historique des rôles est une simple lecture, il est donc disponible que la fonctionnalité Custom Roles soit activée ou non. + +## Gérer les rôles via l'API + +Les rôles sont disponibles à l'adresse `/api/v2/roles/`. Les lectures sont ouvertes à tout utilisateur authentifié, car les clients ont besoin de la liste des rôles pour peupler les listes déroulantes. Les écritures nécessitent le statut de superutilisateur ou le Rôle global Owner intégré, ainsi que l'indicateur de fonctionnalité Custom Roles. + +| Opération | Requête | +| --- | --- | +| Lister les rôles | `GET /api/v2/roles/` | +| Récupérer un rôle | `GET /api/v2/roles/{id}/` | +| Lister toutes les autorisations attribuables | `GET /api/v2/roles/permissions_catalog/` | +| Créer un rôle | `POST /api/v2/roles/` avec `name`, `description` en option, et une liste `permissions` | +| Remplacer les autorisations d'un rôle | `PATCH /api/v2/roles/{id}/` avec une liste `permissions` | +| Cloner un rôle | `POST /api/v2/roles/{id}/clone/` avec un `name` et une `description` en option | +| Supprimer un rôle | `DELETE /api/v2/roles/{id}/` | +| Supprimer un rôle et déplacer ses attributions | `DELETE /api/v2/roles/{id}/?reassign_to={other_role_id}` | +| Lire l'historique d'un rôle | `GET /api/v2/roles/{id}/history/` | + +Remarques : + +* `permissions` **remplace** la liste des autorisations accordées au rôle plutôt que de s'y ajouter. Envoyez l'ensemble complet que vous souhaitez voir le rôle obtenir au final. +* `?reassign_to=` déplace toutes les attributions du rôle supprimé vers le rôle que vous indiquez, en une seule transaction. C'est le seul moyen de réattribuer en masse : l'interface ne le propose pas. +* Toute tentative de modification ou de suppression d'un rôle intégré renvoie `403`. Modifier une valeur d'autorisation inconnue, réutiliser un nom de rôle existant, ou supprimer un rôle en cours d'utilisation sans `reassign_to` renvoie `400` accompagné d'une explication. +* `is_owner` ne peut pas être défini via l'API. L'envoyer est accepté mais ignoré. + +## À savoir + +* **Plusieurs rôles sur le même objet accordent l'union de leurs autorisations.** Si un utilisateur détient un rôle directement sur un Actif et en hérite un autre via un groupe, il obtient tout ce que l'un ou l'autre rôle accorde. Les rôles ne font qu'ajouter des autorisations, jamais en retirer. +* **Les modifications d'autorisations sont prises en compte au prochain chargement de page**, pas instantanément dans la vue actuelle. Les tâches en arrière-plan peuvent prendre jusqu'à 30 secondes, et les données d'autorisation mises en cache jusqu'à 5 minutes, avant de refléter une modification. +* **Les listes déroulantes de rôles affichent jusqu'à 250 rôles.** Au-delà, certains rôles n'apparaîtront plus dans les listes déroulantes, bien qu'ils continuent de fonctionner. +* **Maintainer et Owner peuvent ajouter des Organisations, mais la grille ne l'indique pas.** Pour ces deux rôles, cette autorisation est stockée comme une autorisation de portée globale, et la grille ne lit que les autorisations de portée objet ; leur cellule **Organisation > Ajouter** apparaît donc comme non accordée. Cloner l'un ou l'autre rôle préserve cette autorisation. +* **La terminologie suit votre instance.** Cette documentation utilise Organisation et Actif, les libellés par défaut. Si votre instance a désactivé le renommage Organisation / Actif, les mêmes lignes affichent Type de produit et Produit à la place. +* **La page Rôles est en lecture seule pour tous les autres.** Un utilisateur qui accède directement à `/settings/roles` peut voir les rôles et leurs autorisations mais ne peut rien modifier. Les données d'autorisation ne sont pas sensibles, et le serveur applique la véritable limite à chaque écriture. diff --git a/docs/content/admin/user_management/PRO__custom_rbac_roles.ja.md b/docs/content/admin/user_management/PRO__custom_rbac_roles.ja.md new file mode 100644 index 00000000000..8851c3fc475 --- /dev/null +++ b/docs/content/admin/user_management/PRO__custom_rbac_roles.ja.md @@ -0,0 +1,211 @@ +--- +title: カスタムRBACロール +description: 5つの組み込みロールを複製可能な出発点として使用し、個々の権限を選択して独自のロールを構築する +weight: 5 +audience: pro +--- + +> **DefectDojo Pro feature.** このページで説明されているMembers / Groups / Global RolesのRBACシステムは、DefectDojo Proの一部です。オープンソース版のDefectDojoは[Authorized Users](../os__authorized_users/)モデルを使用します。オープンソース版のアクセス制御についてはそのページを参照し、エディション間を移行する場合は[3.0アップグレードノート](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization)を参照してください。 + +DefectDojo Proには、**Reader**、**Writer**、**Maintainer**、**Owner**、**API Importer**の5つのロールが用意されています。これらのいずれも適合しない場合は、付与する権限を正確に選択して独自のロールを構築できます。 + +カスタムロールは、組み込みロールが機能するあらゆる場所で機能します。グローバルロールとして、グループのロールとして、デフォルトのグループロールとして、また個々のOrganizationやAssetのメンバーロールとしてです。 + +5つの組み込みロールは、**ロックされた複製可能なプリセット**になります。それぞれの権限は変更されておらず(各ロールが付与する権限については[操作権限チャート](../user_permission_chart/)を参照)、編集や削除はできません。新しいロールを作成する際は、いずれかを複製することが推奨される方法です。 + +## Before you start + +カスタムロール管理はデフォルトでオフになっています。**スーパーユーザー**は、**Settings > Feature Flags**から**Custom Roles**を有効にすることでオンにできます。そのページの動作については[Feature Flags](/admin/feature_flags/pro__feature_flags/)を参照してください。 + +この機能がオフの間も、Rolesページは引き続き閲覧可能です。組み込みロールとその権限を表示できますが、作成、編集、複製、削除は一切できません。 + +ロールの管理には、**スーパーユーザー**ステータスまたは組み込みの**Owner**グローバルロールが必要です。これは意図的な設計であり、カスタムロールに委譲することはできません — [カスタムグローバルロールが解放するもの](#what-a-custom-global-role-unlocks)を参照してください。 + +## Opening the Roles page + +左サイドバーの**👤 Users > Roles**に移動します。このメニュー項目は、スーパーユーザーおよび組み込みのOwnerグローバルロールを保有するユーザーに表示されます。 + +![The Roles page listing built-in and custom roles](images/pro_roles_list.png) + +このテーブルには、インスタンス内のすべてのロールが一覧表示されます。 + +| Column | What it shows | +| --- | --- | +| **ID** | ロールの数値ID。Usersテーブルをフィルタリングしたり、APIを呼び出したりする際に便利です。 | +| **Name** | ロール名。 | +| **Description** | ロールの目的に関する独自のメモ。任意項目で、誰かが入力しない限り空欄です。組み込みロールにはこの項目はありません。 | +| **Permissions** | 付与された権限の数。クリックすると、グリッド全体の読み取り専用ビューが開きます。 | +| **Users** | このロールをグローバルロールとして保有するユーザー数。クリックするとUsersテーブルでそれらのユーザーを確認できます。 | +| **Type** | 5つのプリセットは**Built-in**、作成したロールは**Custom**です。 | + +すべての列は並べ替えおよびフィルタリングが可能で、キーワード検索は名前と説明の両方に一致します。 + +## Creating a role + +### Clone a built-in role (recommended) + +複製から始めると、空のグリッドではなく既知の正しい権限セットから開始できるため、ロールに必要な権限を誤って除外してしまう可能性が大幅に低くなります。 + +1. 目的に最も近いロールを見つけます。 +2. その**⋮**メニューを開き、**Clone Role**を選択します。 +3. ` (copy)`という名前で、複製元と同じ権限と説明を持つコピーが即座に作成されます。 +4. コピーの**⋮**メニューを開き、**Edit Role**を選択して、名前を変更し権限を調整します。 + +組み込みロールは編集できませんが、複製することはできます。複製されたロールには、複製元のロールが記録されます。 + +### Start from scratch + +1. **New Role**をクリックします。 +2. **Name**(必須)を入力し、任意で**Description**を入力します。 +3. 下のグリッドで権限を選択します(次のセクションを参照)。 +4. **Save Role**をクリックします。 + +ロール名は一意である必要があり、この確認では大文字と小文字は区別されません。`Triage Lead`が存在する場合、`triage lead`は拒否されます。 + +## Choosing permissions + +![The permission grid in the role form](images/pro_role_permission_grid.png) + +権限は、3つのテーブルと1つのチェックリストにグループ化されています。 + +**Object Permissions**は、ロールが割り当てられているOrganizationおよびAsset、およびそれらの配下にあるすべての項目に適用されます。 + +| Row | View | Add | Edit | Delete | +| --- | --- | --- | --- | --- | +| Organization | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset | ☑️ | ☑️ ¹ | ☑️ | ☑️ | +| Engagement | ☑️ | ☑️ | ☑️ | ☑️ | +| Test | ☑️ | ☑️ | ☑️ | ☑️ | +| Finding | ☑️ | ☑️ | ☑️ | ☑️ | +| Finding Group | ☑️ | ☑️ | ☑️ | ☑️ | +| Risk Acceptance | ☑️ | ☑️ | ☑️ | ☑️ | +| Location | ☑️ | ☑️ | ☑️ | ☑️ | +| Component | ☑️ | | | | +| Note | ² | ☑️ | ☑️ | ☑️ | +| Benchmark | ² | | ☑️ | ☑️ | +| Language | ☑️ | ☑️ | ☑️ | ☑️ | +| Technology | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset API Scan Configuration | ☑️ | ☑️ | ☑️ | ☑️ | +| Asset Tracking Files | ☑️ | ☑️ | ☑️ | ☑️ | +| Group | ☑️ | | ☑️ | ☑️ | + +1. **Asset > Add**は、ロールが割り当てられているOrganization内に新しいAssetを作成することを意味します。 +2. NotesおよびBenchmarksのViewは継承されます。親のEngagement、Test、Finding、またはAssetを表示できるロールは、そのNotesおよびBenchmarksも表示できます。これらのセルには、チェックボックスの代わりに**?**アイコンが表示されます。 + +**Group & Member Permissions**は、メンバーシップを管理できるユーザーを制御します。ここでの列は、View、Manage、Add、Add Owner、Edit、Deleteです。 + +| Row | Available actions | +| --- | --- | +| Organization Group, Asset Group | View, Add, Add Owner, Edit, Delete | +| Organization Member, Asset Member, Group Member | Manage, Add Owner, Delete | + +**Global Feature Permissions**は、個々のOrganizationやAssetではなく、インスタンス全体のPro機能をゲートするものであるため、**ロールがグローバルロールとして保持されている場合にのみ有効になります**。Assetのメンバーシップとしてのみ使用されるロールにこれらを付与しても効果はありません。 + +| Row | Available actions | +| --- | --- | +| Report Template | View, Add, Edit, Delete | +| Generated Report | View, Add, Delete | +| Connector, Sensei, Asset Hierarchy, Version Manager, Tuner, Universal Parser, Rule, Integration | View, Edit | +| Mitigation Policy | Edit | +| Audit Log, Metering | View | + +**Additional Permissions**は、View/Add/Edit/Deleteの形に当てはまらない機能のチェックリストです。 + +* **Configure Asset Notifications**: 単一のAssetがどの通知をどこに送信するかを選択します。 +* **Import Scan Result**: スキャン結果をインポートおよび再インポートし、検出事項を作成・更新します。 +* **Share Dashboard Layout**: ダッシュボードレイアウトを他のユーザーに公開します。Global Roleのみ。 +* **Share Table Preference**: 保存されたテーブルビュー(列、フィルター、並べ替え順)を公開します。Global Roleのみ。 +* **View Note History**: メモをいつ誰が変更したかを確認します。 + +### How to read the grid + +![The read-only view of a role's permissions](images/pro_role_permissions_modal.png) + +| What you see | What it means | +| --- | --- | +| An empty checkbox | 権限は存在するが付与されていない。クリックすると付与される。 | +| A checked checkbox | 付与済み。 | +| A shaded, empty cell | その行とアクションに対する権限が存在しない。選択不可。 | +| A **?** icon | Viewが親オブジェクトから継承されているため、ここで付与するものはない。 | +| A green ✔ (read-only view) | 付与済み。 | +| A red ✘ (read-only view) | 付与されていない。 | + +各行において、最も左の権限(**View**、メンバー行の場合は**Manage**)が、その行の残りをゲートします。表示できないものを意味のある形で編集・削除することはできないため、その行の他のセルを利用可能にするには、まずこの権限を付与する必要があります。このゲートを解除すると、行の残りの部分も一緒に解除されます。 + +## Editing, cloning, and deleting + +各行の**⋮**メニューには、**Edit Role**、**Clone Role**、**Delete Role**、**Role History**があります。 + +組み込みロールでは**Clone Role**のみが提供されます。スーパーユーザーを含め、誰もこれらを編集または削除することはできません。これにより、既知のベースラインが維持され、アップグレードの予測可能性が保たれます。 + +誰かに割り当てられたままのロールを削除しようとすると失敗します。まずそれらの割り当てを再割り当てまたは削除してから、ロールを削除してください。ここでの割り当てには、Organizationおよびassetのメンバーシップ(ユーザーとグループの両方)、Global Role、グループメンバーシップ、System Settingsのデフォルトグループロールが含まれます。 + +APIを使用すると、この再割り当てを1回の呼び出しで行うことができます。[APIを通じたロールの管理](#managing-roles-through-the-api)を参照してください。 + +## Assigning a custom role + +カスタムロールは、組み込みロールと並んで、すべてのロールドロップダウンに表示されます。 + +| Where | How | +| --- | --- | +| **Global Role on a user** | ユーザーのフォームにある**Global Role**フィールド。スーパーユーザーのみ。[ユーザーの権限を設定する](../set_user_permissions/)を参照。 | +| **Global Role on a group** | グループのフォームにある**Global Role**フィールド。[権限の共有: ユーザーグループ](../create_user_group/)を参照。 | +| **Organization or Asset membership** | OrganizationまたはAssetのPermissionsダイアログ(ユーザーとグループの両方)。[Proでの権限設定](../pro_permissions_overhaul/)を参照。 | +| **Default group role** | System Settingsの**Default group role**。新規作成されたユーザーに適用されます。[デフォルト権限の管理](../about_perms_and_roles/#manage-default-permissions)を参照。 | +| **Role within a group** | グループのメンバーリストにあるロールドロップダウン。このドロップダウンには、少なくとも1つのGroup権限を付与するロールのみが表示されるため、Group権限を持たないロールはここに表示されません。 | + +知っておくべき2つの制約があります。 + +* **Owner-tierは予約されています。** カスタムロールがOwner-tierのロールになることは決してありません。組み込みのOwnerのみがOwner-tierであり、そのため他のOwnerを管理する暗黙の権限を持つのもOwnerのみです。 +* **他のユーザーにOwnerロールを付与するには、対応するAdd Owner権限が必要です**。これは、Organization、Asset、Groupのいずれで行う場合も同様です。 + +## What a custom Global Role unlocks + +UIの一部は、個々の権限ではなく、最低限必要なGlobal Roleによってゲートされています。カスタムロールをこれらのゲートに対応させるため、DefectDojoはカスタムGlobal Roleを組み込みのティアと比較してランク付けします。カスタムロールは、その権限が**完全に**カバーする最高位のティアを獲得します。 + +* Maintainerが付与するすべてをカバーするカスタムロールは、それらのゲートに対してMaintainerとして扱われます。 +* Writerが付与するすべてをカバーする場合は、Writerとして扱われます。Readerも同様です。 +* いずれも完全にカバーしない場合、ティアは獲得されません。個々の権限は付与されたとおりに機能しますが、ティアベースのUIゲートは閉じたままになります。 +* **Ownerはこの方法では決して獲得できません。** ロール管理、およびOwner Global Roleによってゲートされているその他すべては、スーパーユーザーと組み込みのOwnerに留まります。 + +カバレッジは完全である必要があり、これは時に人を驚かせます。Maintainerから複製されたロールはMaintainerティアを獲得します。しかし、Maintainerの権限を手作業で再現する際に1つでも見落とすと、そのロールはWriterティアになってしまいます。カスタムGlobal Roleに期待したUIが表示されない場合は、[操作権限チャート](../user_permission_chart/)の組み込みティアと比較してください。 + +## Role history + +カスタムロールは監査証跡を保持します。ロールの**⋮**メニューから**Role History**を開くと、どの権限が誰によっていつ付与または取り消されたか、およびロールの保有者の変更を確認できます。 + +この履歴に表示されない2つのことがあります。ロール自体の名前や説明の変更、および組み込みロールの権限(これらはシード投入されたもので編集されることがないため、履歴は生成されません)です。 + +ロール履歴は読み取り専用であるため、Custom Roles機能のオン/オフに関わらず利用できます。 + +## Managing roles through the API + +ロールは`/api/v2/roles/`で利用できます。クライアントはドロップダウンにロール一覧を表示する必要があるため、読み取りはすべての認証済みユーザーに開放されています。書き込みには、スーパーユーザーステータスまたは組み込みのOwner Global Roleに加え、Custom Roles機能フラグが必要です。 + +| Operation | Request | +| --- | --- | +| List roles | `GET /api/v2/roles/` | +| Retrieve one role | `GET /api/v2/roles/{id}/` | +| List every grantable permission | `GET /api/v2/roles/permissions_catalog/` | +| Create a role | `name`、任意の`description`、`permissions`リストを指定して`POST /api/v2/roles/` | +| Replace a role's permissions | `permissions`リストを指定して`PATCH /api/v2/roles/{id}/` | +| Clone a role | 任意の`name`と`description`を指定して`POST /api/v2/roles/{id}/clone/` | +| Delete a role | `DELETE /api/v2/roles/{id}/` | +| Delete a role and move its assignments | `DELETE /api/v2/roles/{id}/?reassign_to={other_role_id}` | +| Read a role's history | `GET /api/v2/roles/{id}/history/` | + +Notes: + +* `permissions`は、ロールの権限リストに追加するのではなく、**置き換えます**。ロールに最終的に持たせたい完全なセットを送信してください。 +* `?reassign_to=`は、削除されるロールのすべての割り当てを、指定したロールへ1つのトランザクションで移動します。これは一括で再割り当てを行う唯一の方法であり、UIにはこの機能はありません。 +* 組み込みロールの編集または削除を試みると`403`が返されます。不明な権限値の編集、既存のロール名の再利用、`reassign_to`を指定せずに使用中のロールを削除しようとすると、説明付きの`400`が返されます。 +* `is_owner`はAPIから設定できません。送信しても受理されますが無視されます。 + +## Things to know + +* **同一オブジェクトに複数のロールがある場合、それらの権限の和集合が付与されます。** ユーザーがAssetに直接ロールを保有し、グループを通じて別のロールを継承している場合、いずれかのロールが付与するすべての権限を得られます。ロールは権限を追加するだけで、決して削除しません。 +* **権限の変更は、現在の画面には即座に反映されず、次回のページ読み込み時に反映されます。** バックグラウンドジョブは最大30秒、キャッシュされた権限データは最大5分かかって編集内容を反映します。 +* **ロールドロップダウンには最大250件のロールが表示されます。** それを超えると、一部のロールはドロップダウンに表示されなくなりますが、引き続き機能します。 +* **MaintainerとOwnerはOrganizationを追加できますが、グリッドにはそれが表示されません。** これら2つのロールでは、その権限はグローバルスコープの付与として保存されており、グリッドはオブジェクトスコープの付与のみを読み取るため、**Organization > Add**セルは付与されていないと表示されます。いずれかのロールを複製すると、この権限は保持されます。 +* **用語はインスタンスの設定に従います。** 本ドキュメントではデフォルトのラベルであるOrganizationとAssetを使用しています。インスタンスでOrganization / Assetのリラベリングがオフになっている場合、同じ行はProduct TypeとProductと表示されます。 +* **Rolesページは、それ以外のユーザーにとっては読み取り専用です。** `/settings/roles`に直接アクセスしたユーザーはロールとその権限を見ることができますが、何も変更できません。権限データは機密性が高いものではなく、実際の境界はすべての書き込み時にサーバー側で強制されます。 diff --git a/docs/content/admin/user_management/PRO__mfa.de.md b/docs/content/admin/user_management/PRO__mfa.de.md new file mode 100644 index 00000000000..e3f5f361ca6 --- /dev/null +++ b/docs/content/admin/user_management/PRO__mfa.de.md @@ -0,0 +1,86 @@ +--- +title: Multi-Faktor-Authentifizierung (MFA) +description: Richten Sie MFA für Ihr eigenes Konto ein, machen Sie es für Ihre gesamte + Instanz verpflichtend und stellen Sie den Zugriff für einen Benutzer wieder her, + der sein Gerät verloren hat +audience: pro +weight: 3 +--- + +Die Multi-Faktor-Authentifizierung fügt der Anmeldung einen zweiten Schritt hinzu: Nach Ihrem Passwort fragt DefectDojo nach einem sechsstelligen Code aus einer Authenticator-App. Wir empfehlen dringend, sie für jeden Benutzer verpflichtend zu machen, auf Instanzen, die nicht hinter SSO liegen. + +Die MFA von DefectDojo Pro verwendet eine **TOTP-Authenticator-App** — Google Authenticator, 1Password, Authy oder jede andere App, die einen Standard-QR-Code scannen kann. Es gibt keine E-Mail- oder SMS-Option. + +## MFA für Ihr Konto einrichten + +1. Gehen Sie zu **Connect \> Authorization \> MFA Settings**. +2. Klicken Sie unter **Personal Multi-Factor Authentication Settings** auf **Set Up MFA**. +3. Scannen Sie den QR-Code mit Ihrer Authenticator-App. Falls Sie ihn nicht scannen können, zeigt der Einrichtungsbildschirm den Schlüssel auch als Text an, den Sie von Hand in Ihre App eingeben können. +4. Geben Sie den sechsstelligen Code ein, den Ihre App anzeigt, und klicken Sie auf **Verify & enable**. +5. DefectDojo zeigt Ihre **Recovery-Codes** an. Speichern Sie sie an einem sicheren Ort, bevor Sie fortfahren — siehe unten. Klicken Sie auf **Copy codes**, bewahren Sie sie auf und klicken Sie dann auf **I've saved them. Continue**. + +MFA ist ab diesem Zeitpunkt aktiv. Bei Ihrer nächsten Anmeldung fragt DefectDojo nach Ihrem Passwort zusätzlich nach einem Code. + +### Recovery-Codes + +Beim Aktivieren von MFA erhalten Sie **zehn Einweg-Recovery-Codes**. Jeder kann einmal anstelle eines Codes aus Ihrer Authenticator-App verwendet werden und wird bei Gebrauch verbraucht. + +Sie werden **einmalig** auf dem abschließenden Einrichtungsbildschirm angezeigt. Die Seite „MFA Settings" zeigt danach nur noch an, wie viele Ihnen noch verbleiben, nicht die Codes selbst. + +Falls Sie Ihre Recovery-Codes verlieren — oder nach der Verwendung mehrerer einen neuen Satz möchten — klicken Sie auf der Seite „MFA Settings" auf **Regenerate Recovery Codes**. Dies **ersetzt alle Ihre bestehenden Codes**: Zuvor gespeicherte Codes funktionieren danach sofort nicht mehr, speichern Sie den neuen Satz also umgehend. + +Recovery-Codes sind es, die Ihnen den Zugang ermöglichen, wenn Sie Ihr Telefon verlieren; bewahren Sie sie daher getrennt von dem Gerät auf, auf dem Ihre Authenticator-App läuft. + +### MFA deaktivieren + +**Disable MFA** auf der Seite „MFA Settings" deaktiviert MFA für Ihr eigenes Konto. Sie müssen dafür nur angemeldet sein — ein Code zur Bestätigung wird nicht verlangt. + +Hat Ihr Administrator MFA verpflichtend gemacht, werden Sie bei Ihrer nächsten Anmeldung erneut zur Einrichtung aufgefordert. + +## Anmelden mit MFA + +Nach der Eingabe von Benutzername und Passwort fragt DefectDojo nach Ihrem sechsstelligen Code. Falls Sie Ihre Authenticator-App nicht zur Hand haben, geben Sie stattdessen einen Ihrer **Recovery-Codes** in dasselbe Feld ein — dieser Code wird dann verbraucht. + +## MFA für alle verpflichtend machen + +Superuser können MFA instanzweit verpflichtend machen: + +1. Gehen Sie zu **Connect \> Authorization \> MFA Settings**. +2. Aktivieren Sie in der Karte **MFA Settings** — nur für Superuser sichtbar — das Kontrollkästchen **Require Multi-Factor Authentication Globally**. +3. Absenden. + +Dies ist **standardmäßig deaktiviert**. + +Sobald es aktiviert ist, wird jeder Benutzer, der sich noch nicht registriert hat, bei der nächsten Anmeldung zum MFA-Einrichtungsbildschirm geleitet und **kann diesen nicht überspringen**. Er schließt die Registrierung ab, speichert seine Recovery-Codes und gelangt dann dorthin, wohin er ursprünglich wollte. + +### SSO-Benutzer + +MFA wird von DefectDojo durchgesetzt und nicht an Ihren Identitätsanbieter delegiert. Ist globales MFA verpflichtend, werden auch Benutzer, die sich über SSO anmelden, zur MFA-Einrichtung geleitet, nachdem ihr Anbieter sie zu DefectDojo zurückgeführt hat, und bei nachfolgenden Anmeldungen nach einem Code gefragt. + +Es gibt keine Einstellung, um SSO-Benutzer davon auszunehmen. Erzwingt Ihr Identitätsanbieter bereits eine eigene MFA, entscheiden Sie bewusst, ob Sie beides möchten — das Aktivieren von globalem MFA bedeutet für SSO-Benutzer zwei Abfragen. + +## Wiederherstellen eines Benutzers, der sein MFA-Gerät verloren hat + +Gehen Sie diese Schritte der Reihe nach durch: + +1. **Einen Recovery-Code verwenden.** Hat der Benutzer noch seine Recovery-Codes, gibt er bei der Anmeldung einen davon anstelle eines App-Codes ein und richtet MFA anschließend von Grund auf neu ein. +2. **Ist er noch irgendwo angemeldet,** kann er zu **MFA Settings** gehen und auf **Disable MFA** klicken, ohne dass ein Code nötig ist, und sich danach erneut registrieren. +3. **Einen Administrator bitten, seine MFA zurückzusetzen.** Mit Serverzugriff kann ein Administrator MFA von einem Konto entfernen: + + ``` + python manage.py remove_mfa --username + ``` + + Der Befehl akzeptiert anstelle von `--username` auch `--user-id` oder `--email` (genau eines ist erforderlich; bei `--email` wird Groß-/Kleinschreibung ignoriert). Vor der Änderung wird eine Bestätigung verlangt. Der Benutzer kann sich danach mit nur seinem Passwort anmelden und sich erneut registrieren. + + Dies ist ein Shell-Befehl und benötigt daher Zugriff auf den DefectDojo-Container oder -Host. Es gibt keine entsprechende Schaltfläche in der Benutzeroberfläche oder einen Endpunkt in der API. Wenden Sie sich bei **DefectDojo Cloud** an den [DefectDojo Support](mailto:support@defectdojo.com), um dies ausführen zu lassen. + +Das Anlegen eines Ersatzkontos ist **nicht** notwendig — das Zurücksetzen der MFA erhält die bestehenden Berechtigungen, den Verlauf und die Zuweisungen des Benutzers. + +## MFA und die API + +Ist bei einem Benutzer MFA aktiviert, müssen Anfragen an `/api/v2/api-token-auth/` — den Endpunkt, der Benutzername und Passwort gegen ein API-Token tauscht — zusätzlich zu den Zugangsdaten einen MFA-Code im Feld `mfa_code` enthalten. Akzeptiert wird entweder ein aktueller TOTP-Code oder ein unbenutzter Recovery-Code; die Übergabe eines Recovery-Codes hier **verbraucht** ihn. + +Ein fehlender oder falscher Code liefert denselben allgemeinen Fehler *„Unable to log in with provided credentials"* wie ein falsches Passwort. Wenn Token-Anfragen also fehlschlagen, nachdem ein Benutzer MFA aktiviert hat, ist dies als Erstes zu prüfen. + +**Bestehende API-Token funktionieren weiterhin.** Das Aktivieren oder Deaktivieren von MFA widerruft oder erneuert bereits ausgestellte Token nicht — die MFA-Prüfung erfolgt bei der Ausstellung eines Tokens, nicht bei jeder damit gestellten Anfrage. Langlebige Automatisierungen, die bereits ein Token besitzen, sind von der MFA-Registrierung eines Benutzers nicht betroffen. diff --git a/docs/content/admin/user_management/PRO__mfa.es.md b/docs/content/admin/user_management/PRO__mfa.es.md new file mode 100644 index 00000000000..962f8dcf72b --- /dev/null +++ b/docs/content/admin/user_management/PRO__mfa.es.md @@ -0,0 +1,85 @@ +--- +title: Autenticación multifactor (MFA) +description: Configure la MFA en su propia cuenta, exíjala en toda su instancia, y + recupere a un usuario que haya perdido su dispositivo +audience: pro +weight: 3 +--- + +La autenticación multifactor añade un segundo paso al inicio de sesión: después de su contraseña, DefectDojo solicita un código de seis dígitos de una aplicación de autenticación. Recomendamos encarecidamente exigirla para todos los usuarios en las instancias que no están detrás de un SSO. + +La MFA de DefectDojo Pro utiliza una **aplicación de autenticación TOTP** — Google Authenticator, 1Password, Authy, o cualquier otra aplicación que escanee un código QR estándar. No existe una opción por correo electrónico o SMS. + +## Configuración de la MFA en su cuenta + +1. Vaya a **Connect \> Authorization \> MFA Settings**. +2. En **Personal Multi-Factor Authentication Settings**, haga clic en **Set Up MFA**. +3. Escanee el código QR con su aplicación de autenticación. Si no puede escanearlo, la pantalla de configuración también muestra la clave como texto, que puede escribir en su aplicación manualmente. +4. Ingrese el código de seis dígitos que muestra su aplicación, y haga clic en **Verify & enable**. +5. DefectDojo muestra sus **códigos de recuperación**. Guárdelos en un lugar seguro antes de continuar — vea más abajo. Haga clic en **Copy codes**, guárdelos, y luego haga clic en **I've saved them. Continue**. + +La MFA queda activa a partir de ese momento. La próxima vez que inicie sesión, DefectDojo le pedirá un código después de su contraseña. + +### Códigos de recuperación + +Se le entregan **diez códigos de recuperación de un solo uso** al habilitar la MFA. Cada uno se puede usar una vez, en lugar de un código de su aplicación de autenticación, y se consume al utilizarlo. + +Se muestran **una sola vez**, en la pantalla final de configuración. Después, la página MFA Settings solo muestra cuántos le quedan, no los códigos en sí. + +Si pierde sus códigos de recuperación — o desea un nuevo conjunto después de haber usado varios — haga clic en **Regenerate Recovery Codes** en la página MFA Settings. Esto **reemplaza todos sus códigos existentes**: los que haya guardado anteriormente dejan de funcionar de inmediato, así que guarde el nuevo conjunto enseguida. + +Los códigos de recuperación son lo que le permite volver a entrar cuando pierde su teléfono, así que guárdelos en un lugar distinto del dispositivo donde ejecuta su aplicación de autenticación. + +### Desactivación de la MFA + +**Disable MFA** en la página MFA Settings la desactiva para su propia cuenta. Solo necesita haber iniciado sesión — no se le pedirá un código de confirmación. + +Si su administrador ha hecho obligatoria la MFA, se le pedirá que la configure de nuevo en su próximo inicio de sesión. + +## Inicio de sesión con MFA + +Después de ingresar su nombre de usuario y contraseña, DefectDojo le solicita su código de seis dígitos. Si no tiene su aplicación de autenticación, ingrese en su lugar uno de sus **códigos de recuperación** en el mismo campo — ese código quedará entonces consumido. + +## Exigir la MFA para todos + +Los superusuarios pueden hacer obligatoria la MFA en toda la instancia: + +1. Vaya a **Connect \> Authorization \> MFA Settings**. +2. En la tarjeta **MFA Settings** — visible solo para los Superusers — marque **Require Multi-Factor Authentication Globally**. +3. Envíe el formulario. + +Esto está **desactivado de forma predeterminada**. + +Una vez activado, cualquier usuario que aún no se haya inscrito es enviado a la pantalla de configuración de MFA en su próximo inicio de sesión, y **no puede omitirla**. Completa la inscripción, guarda sus códigos de recuperación, y llega al lugar al que se dirigía originalmente. + +### Usuarios SSO + +La MFA es aplicada por DefectDojo, no delegada a su proveedor de identidad. Con la MFA global obligatoria, los usuarios que inician sesión mediante SSO también son enviados a configurar la MFA después de que su proveedor los devuelve a DefectDojo, y se les solicita un código en los inicios de sesión posteriores. + +No existe una configuración para eximir a los usuarios SSO. Si su proveedor de identidad ya aplica su propia MFA, decida deliberadamente si desea ambas — activar la MFA global implicará dos solicitudes para los usuarios SSO. + +## Recuperación de un usuario que ha perdido su dispositivo de MFA + +Siga estos pasos en orden: + +1. **Use un código de recuperación.** Si el usuario aún conserva sus códigos de recuperación, ingresa uno en lugar del código de la aplicación al iniciar sesión, y luego configura la MFA de nuevo desde cero. +2. **Si todavía tiene una sesión iniciada en algún lugar,** puede ir a **MFA Settings** y hacer clic en **Disable MFA** sin necesitar un código, y luego volver a inscribirse. +3. **Pida a un administrador que elimine su MFA.** Con acceso al servidor, un administrador puede eliminar la MFA de una cuenta: + + ``` + python manage.py remove_mfa --username + ``` + + El comando también acepta `--user-id` o `--email` en lugar de `--username` (se requiere exactamente uno; `--email` no distingue mayúsculas de minúsculas). Solicita confirmación antes de realizar el cambio. El usuario puede entonces iniciar sesión solo con su contraseña e inscribirse de nuevo. + + Este es un comando de shell, por lo que requiere acceso al contenedor o host de DefectDojo. No existe un botón equivalente en la interfaz ni un endpoint en la API. En **DefectDojo Cloud**, comuníquese con [Soporte de DefectDojo](mailto:support@defectdojo.com) para que lo ejecuten. + +Crear una cuenta de reemplazo **no** es necesario — eliminar la MFA conserva los permisos, el historial y las asignaciones existentes del usuario. + +## MFA y la API + +Cuando un usuario tiene la MFA habilitada, las solicitudes a `/api/v2/api-token-auth/` — el endpoint que intercambia un nombre de usuario y contraseña por un token de API — también deben incluir un código de MFA, en un campo `mfa_code` junto con las credenciales. Se acepta tanto un código TOTP vigente como un código de recuperación sin usar; pasar un código de recuperación aquí lo **consume**. + +Un código faltante o incorrecto devuelve el mismo error genérico *"Unable to log in with provided credentials"* que una contraseña incorrecta, por lo que, si las solicitudes de token empiezan a fallar después de que un usuario habilita la MFA, esto es lo primero que hay que verificar. + +**Los tokens de API existentes siguen funcionando.** Habilitar o deshabilitar la MFA no revoca ni rota los tokens ya emitidos — la verificación de MFA se aplica cuando se emite un token, no en cada solicitud realizada con él. La automatización de larga duración que ya posee un token no se ve afectada porque un usuario se inscriba en la MFA. diff --git a/docs/content/admin/user_management/PRO__mfa.fr.md b/docs/content/admin/user_management/PRO__mfa.fr.md new file mode 100644 index 00000000000..25c57f618da --- /dev/null +++ b/docs/content/admin/user_management/PRO__mfa.fr.md @@ -0,0 +1,85 @@ +--- +title: Authentification multifacteur (MFA) +description: Configurez la MFA sur votre propre compte, rendez-la obligatoire sur + l'ensemble de votre instance, et récupérez un utilisateur ayant perdu son appareil +audience: pro +weight: 3 +--- + +L'authentification multifacteur ajoute une seconde étape à la connexion : après votre mot de passe, DefectDojo demande un code à six chiffres provenant d'une application d'authentification. Nous recommandons fortement de l'exiger pour tous les utilisateurs sur les instances qui ne sont pas protégées par le SSO. + +La MFA de DefectDojo Pro utilise une **application d'authentification TOTP** — Google Authenticator, 1Password, Authy, ou toute autre application capable de scanner un code QR standard. Il n'existe pas d'option par e-mail ou par SMS. + +## Configurer la MFA sur votre compte + +1. Accédez à **Connect \> Authorization \> MFA Settings**. +2. Sous **Personal Multi-Factor Authentication Settings**, cliquez sur **Set Up MFA**. +3. Scannez le code QR avec votre application d'authentification. Si vous ne pouvez pas le scanner, l'écran de configuration affiche également la clé sous forme de texte, que vous pouvez saisir manuellement dans votre application. +4. Saisissez le code à six chiffres affiché par votre application, puis cliquez sur **Verify & enable**. +5. DefectDojo affiche vos **codes de récupération**. Enregistrez-les en lieu sûr avant de continuer — voir ci-dessous. Cliquez sur **Copy codes**, conservez-les, puis cliquez sur **I've saved them. Continue**. + +La MFA est active à partir de ce moment. Lors de votre prochaine connexion, DefectDojo vous demandera un code après votre mot de passe. + +### Codes de récupération + +Vous recevez **dix codes de récupération à usage unique** lorsque vous activez la MFA. Chacun peut être utilisé une seule fois, à la place d'un code de votre application d'authentification, et est consommé après utilisation. + +Ils ne sont affichés **qu'une seule fois**, sur l'écran final de configuration. La page des paramètres MFA n'indique ensuite que le nombre de codes restants, pas les codes eux-mêmes. + +Si vous perdez vos codes de récupération — ou souhaitez un nouveau jeu après en avoir utilisé plusieurs — cliquez sur **Regenerate Recovery Codes** sur la page des paramètres MFA. Cette action **remplace tous vos codes existants** : tous ceux que vous aviez enregistrés précédemment cessent de fonctionner immédiatement, alors enregistrez le nouveau jeu sans attendre. + +Les codes de récupération sont ce qui vous permet de retrouver l'accès lorsque vous perdez votre téléphone ; conservez-les donc dans un endroit distinct de l'appareil exécutant votre application d'authentification. + +### Désactiver la MFA + +**Disable MFA** sur la page des paramètres MFA la désactive pour votre propre compte. Il vous suffit d'être connecté — aucun code ne vous est demandé pour confirmer. + +Si votre administrateur a rendu la MFA obligatoire, vous serez invité à la reconfigurer lors de votre prochaine connexion. + +## Se connecter avec la MFA + +Après avoir saisi votre nom d'utilisateur et votre mot de passe, DefectDojo vous demande votre code à six chiffres. Si vous n'avez pas votre application d'authentification, saisissez à la place l'un de vos **codes de récupération** dans le même champ — ce code est alors consommé. + +## Exiger la MFA pour tout le monde + +Les superutilisateurs peuvent rendre la MFA obligatoire sur l'ensemble de l'instance : + +1. Accédez à **Connect \> Authorization \> MFA Settings**. +2. Dans le bloc **MFA Settings** — visible uniquement par les superutilisateurs — cochez **Require Multi-Factor Authentication Globally**. +3. Envoyez. + +Cette option est **désactivée par défaut**. + +Une fois activée, tout utilisateur qui ne s'est pas encore inscrit est redirigé vers l'écran de configuration de la MFA lors de sa prochaine connexion, et **ne peut pas l'ignorer**. Il termine l'inscription, enregistre ses codes de récupération, puis arrive à la destination initialement prévue. + +### Utilisateurs SSO + +La MFA est appliquée par DefectDojo, et non déléguée à votre fournisseur d'identité. Lorsque la MFA globale est exigée, les utilisateurs qui se connectent via le SSO sont également redirigés vers la configuration de la MFA une fois que leur fournisseur les renvoie vers DefectDojo, puis un code leur est demandé lors des connexions suivantes. + +Il n'existe aucun paramètre permettant d'exempter les utilisateurs SSO. Si votre fournisseur d'identité applique déjà sa propre MFA, décidez délibérément si vous souhaitez cumuler les deux — activer la MFA globale entraînera deux invites pour les utilisateurs SSO. + +## Récupérer un utilisateur ayant perdu son appareil MFA + +Procédez dans cet ordre : + +1. **Utiliser un code de récupération.** Si l'utilisateur possède encore ses codes de récupération, il en saisit un à la place d'un code d'application lors de la connexion, puis reconfigure la MFA depuis le début. +2. **S'il est encore connecté quelque part,** il peut se rendre dans **MFA Settings** et cliquer sur **Disable MFA** sans avoir besoin d'un code, puis se réinscrire. +3. **Demander à un administrateur de réinitialiser sa MFA.** Avec un accès serveur, un administrateur peut retirer la MFA d'un compte : + + ``` + python manage.py remove_mfa --username + ``` + + La commande accepte également `--user-id` ou `--email` à la place de `--username` (un seul est requis ; `--email` ne tient pas compte de la casse). Elle demande une confirmation avant d'effectuer la modification. L'utilisateur peut ensuite se connecter avec son seul mot de passe et s'inscrire à nouveau. + + Il s'agit d'une commande shell, qui nécessite donc un accès au conteneur ou à l'hôte DefectDojo. Il n'existe aucun bouton équivalent dans l'interface ni de point de terminaison dans l'API. Sur **DefectDojo Cloud**, contactez le [support DefectDojo](mailto:support@defectdojo.com) pour la faire exécuter. + +Créer un compte de remplacement n'est **pas** nécessaire — la réinitialisation de la MFA préserve les autorisations, l'historique et les attributions existants de l'utilisateur. + +## La MFA et l'API + +Lorsqu'un utilisateur a activé la MFA, les requêtes vers `/api/v2/api-token-auth/` — le point de terminaison qui échange un nom d'utilisateur et un mot de passe contre un jeton API — doivent également inclure un code MFA, dans un champ `mfa_code` aux côtés des identifiants. Un code TOTP actuel ou un code de récupération non utilisé est accepté ; transmettre un code de récupération ici le **consomme**. + +Un code manquant ou incorrect renvoie la même erreur générique *« Unable to log in with provided credentials »* qu'un mot de passe erroné ; c'est donc la première chose à vérifier si les demandes de jeton commencent à échouer après qu'un utilisateur a activé la MFA. + +**Les jetons API existants continuent de fonctionner.** Activer ou désactiver la MFA ne révoque ni ne renouvelle les jetons déjà émis — la vérification MFA s'applique au moment de l'émission d'un jeton, pas à chaque requête effectuée avec celui-ci. Une automatisation de longue durée qui détient déjà un jeton n'est pas affectée par l'inscription d'un utilisateur à la MFA. diff --git a/docs/content/admin/user_management/PRO__mfa.ja.md b/docs/content/admin/user_management/PRO__mfa.ja.md new file mode 100644 index 00000000000..84a18a6bd1a --- /dev/null +++ b/docs/content/admin/user_management/PRO__mfa.ja.md @@ -0,0 +1,84 @@ +--- +title: 多要素認証(MFA) +description: 自分のアカウントでMFAを設定し、インスタンス全体で必須化し、デバイスを紛失したユーザーを復旧する方法 +audience: pro +weight: 3 +--- + +多要素認証は、ログインに2番目のステップを追加します。パスワードの後、DefectDojoは認証アプリからの6桁のコードを要求します。SSOを利用していないインスタンスでは、すべてのユーザーにこれを必須とすることを強くお勧めします。 + +DefectDojo ProのMFAは、**TOTP認証アプリ**を使用します — Google Authenticator、1Password、Authy、または標準のQRコードをスキャンできるその他のアプリです。メールやSMSのオプションはありません。 + +## Setting up MFA on your account + +1. **Connect \> Authorization \> MFA Settings**に移動します。 +2. **Personal Multi-Factor Authentication Settings**で、**Set Up MFA**をクリックします。 +3. 認証アプリでQRコードをスキャンします。スキャンできない場合、セットアップ画面にはキーがテキストとしても表示されるため、アプリに手動で入力できます。 +4. アプリに表示された6桁のコードを入力し、**Verify & enable**をクリックします。 +5. DefectDojoが**リカバリーコード**を表示します。続行する前に、安全な場所に保存してください — 下記参照。**Copy codes**をクリックして保存し、**I've saved them. Continue**をクリックします。 + +これ以降、MFAが有効になります。次回ログイン時には、DefectDojoはパスワードの後にコードを要求します。 + +### Recovery codes + +MFAを有効にすると、**10個の使い捨てリカバリーコード**が発行されます。各コードは、認証アプリのコードの代わりに1回だけ使用でき、使用すると消費されます。 + +これらは、最後のセットアップ画面で**一度だけ**表示されます。それ以降、MFA Settingsページには残りの個数のみが表示され、コード自体は表示されません。 + +リカバリーコードを紛失した場合、またはいくつか使用した後に新しいセットが必要な場合は、MFA Settingsページで**Regenerate Recovery Codes**をクリックします。これにより、**既存のコードはすべて置き換えられます**。以前保存したコードは直ちに使用できなくなるため、新しいセットをすぐに保存してください。 + +リカバリーコードは、電話を紛失した際に再度アクセスできるようにするためのものです。そのため、認証アプリを実行しているデバイスとは別の場所に保管してください。 + +### Turning MFA off + +MFA Settingsページの**Disable MFA**は、自分のアカウントのMFAをオフにします。ログインしているだけでよく、確認のためのコードは求められません。 + +管理者がMFAを必須に設定している場合、次回ログイン時に再度設定するよう求められます。 + +## Logging in with MFA + +ユーザー名とパスワードを入力すると、DefectDojoは6桁のコードを要求します。認証アプリが手元にない場合は、代わりに同じフィールドに**リカバリーコード**のいずれかを入力してください — そのコードはその時点で使用済みになります。 + +## Requiring MFA for everyone + +スーパーユーザーは、インスタンス全体でMFAを必須にすることができます。 + +1. **Connect \> Authorization \> MFA Settings**に移動します。 +2. スーパーユーザーのみに表示される**MFA Settings**カードで、**Require Multi-Factor Authentication Globally**にチェックを入れます。 +3. 送信します。 + +これは**デフォルトではオフ**です。 + +これがオンになると、まだ登録していないユーザーは、次回ログイン時にMFAのセットアップ画面に送られ、**スキップすることはできません**。登録を完了し、リカバリーコードを保存すると、本来向かっていた画面に移動します。 + +### SSO users + +MFAはDefectDojoによって強制されるものであり、IDプロバイダーに委譲されるものではありません。グローバルMFAが必須の場合、SSO経由でサインインするユーザーも、プロバイダーがDefectDojoに戻した後にMFAのセットアップに送られ、以降のログインではコードの入力を求められます。 + +SSOユーザーを除外する設定はありません。IDプロバイダーが既に独自のMFAを強制している場合は、両方を有効にしたいかどうかを慎重に判断してください — グローバルMFAをオンにすると、SSOユーザーには2回のプロンプトが表示されることになります。 + +## Recovering a user who has lost their MFA device + +以下を順番に試してください。 + +1. **リカバリーコードを使用する。** ユーザーがまだリカバリーコードを持っている場合、ログイン時にアプリのコードの代わりにそれを入力し、MFAを最初から再設定します。 +2. **どこかでまだログインしている場合、** **MFA Settings**に移動し、コードを必要とせずに**Disable MFA**をクリックしてから、再登録できます。 +3. **管理者にMFAのクリアを依頼する。** サーバーアクセス権を持つ管理者は、アカウントからMFAを削除できます。 + + ``` + python manage.py remove_mfa --username + ``` + + このコマンドは、`--username`の代わりに`--user-id`または`--email`も受け付けます(いずれか1つが必須で、`--email`では大文字と小文字が区別されません)。変更を行う前に確認を求められます。その後、ユーザーはパスワードのみでログインし、再度登録できます。 + + これはシェルコマンドであるため、DefectDojoのコンテナまたはホストへのアクセスが必要です。UIに相当するボタンやAPIのエンドポイントはありません。**DefectDojo Cloud**では、[DefectDojo Support](mailto:support@defectdojo.com)に連絡して実行を依頼してください。 + +代替アカウントを作成する**必要はありません** — MFAをクリアしても、ユーザーの既存の権限、履歴、割り当ては保持されます。 + +## MFA and the API + +ユーザーがMFAを有効にしている場合、ユーザー名とパスワードをAPIトークンと交換するエンドポイントである`/api/v2/api-token-auth/`へのリクエストには、認証情報と共に`mfa_code`フィールドにMFAコードも含める必要があります。現在のTOTPコードまたは未使用のリカバリーコードのいずれかが受け付けられます。ここでリカバリーコードを渡すと、それは**消費されます**。 + +コードが欠落しているか誤っている場合、パスワードが誤っている場合と同じ一般的な*"Unable to log in with provided credentials"*エラーが返されます。そのため、ユーザーがMFAを有効にした後にトークンリクエストが失敗し始めた場合、まずこれを確認してください。 + +**既存のAPIトークンは引き続き機能します。** MFAの有効化または無効化は、既に発行されたトークンを失効させたりローテーションしたりしません — MFAチェックはトークン発行時に適用されるものであり、トークンを使用した各リクエストごとに適用されるものではありません。ユーザーがMFAに登録しても、既にトークンを保持している長期稼働の自動化処理には影響がありません。 diff --git a/docs/content/admin/user_management/PRO__resetting_user_credentials.de.md b/docs/content/admin/user_management/PRO__resetting_user_credentials.de.md new file mode 100644 index 00000000000..6ff9ef18ba9 --- /dev/null +++ b/docs/content/admin/user_management/PRO__resetting_user_credentials.de.md @@ -0,0 +1,34 @@ +--- +title: Massenhaftes Zurücksetzen von Benutzeranmeldedaten +description: API-Tokens rotieren und Passwort-Resets für viele Benutzer gleichzeitig + über die Benutzerliste erzwingen +audience: pro +weight: 2 +--- + +Die DefectDojo Pro **Benutzer**-Liste ermöglicht es Ihnen, API-Tokens zu rotieren und Passwort-Resets für viele Benutzer gleichzeitig zu erzwingen – nützlich für die regelmäßige Pflege von Anmeldedaten oder als Reaktion auf eine vermutete Kompromittierung von Zugangsdaten. + +Diese Massenaktionen stehen nur **Superusern** und Benutzern mit der Rolle **Global Owner** zur Verfügung. Wenn Sie keine dieser Berechtigungen besitzen, werden die Auswahlkästchen und Massenaktions-Schaltflächen nicht angezeigt. + +## Benutzer auswählen + +Verwenden Sie in der **Benutzer**-Liste die Auswahlkästchen, um einen oder mehrere Benutzer auszuwählen. Es erscheint eine Massenaktionsleiste mit den Reset-Schaltflächen. Jede Aktion fordert Sie vor der Ausführung zur Bestätigung in einem Dialogfeld auf. + +Die Aktion gilt für die Benutzer, die Sie explizit ausgewählt haben. Sie **können Ihr eigenes Konto nicht in einen Massen-Reset einbeziehen**: Befindet sich Ihr Konto unter den ausgewählten Zeilen, werden die Massenaktions-Schaltflächen deaktiviert und eine Warnung angezeigt. + +## API-Tokens zurücksetzen + +**API-Tokens zurücksetzen** rotiert das API-Token jedes ausgewählten Benutzers: DefectDojo löscht das vorhandene Token des Benutzers und stellt ein neues aus. **Das aktuelle Token des Benutzers funktioniert sofort nicht mehr**, daher müssen alle Skripte oder Integrationen, die das alte Token verwenden, mit dem neuen Token aktualisiert werden. + +* Die neuen Token-Werte werden Ihnen als Administrator **nicht** angezeigt. Jeder betroffene Benutzer erhält eine Benachrichtigung **„API Token Reset“**, die ihn darüber informiert, sein neues Token über die Benutzeroberfläche abzurufen (Zustellung gemäß den Benachrichtigungseinstellungen dieses Benutzers). + +## Passwort-Reset erzwingen + +**Passwort-Reset erzwingen** setzt bei jedem ausgewählten Benutzer das Flag *force-password-reset-on-next-login*. Bei der nächsten Anfrage dieses Benutzers leitet DefectDojo ihn auf die Seite **Change Password** um und lässt ihn erst fortfahren, wenn er ein neues Passwort festgelegt hat. Das Flag wird automatisch aufgehoben, sobald dies geschehen ist. + +Beachten Sie, was diese Aktion **nicht** tut: + +* Sie setzt oder generiert **kein** zufälliges temporäres Passwort und gibt Ihnen **keine** Anmeldedaten zurück. +* Sie sendet den betroffenen Benutzern **keine** E-Mail oder Benachrichtigung. Da es keinen automatischen Hinweis gibt, informieren Sie die betroffenen Benutzer außerhalb des Systems darüber, dass sie beim nächsten Login zur Passwortänderung aufgefordert werden. + +> **SSO-Benutzer:** Anders als das Bearbeitungsformular für einzelne Benutzer (das das Force-Reset-Flag für SSO-autorisierte Konten deaktiviert), wendet die Massenaktion das Flag auf **jeden** ausgewählten Benutzer an, unabhängig davon, wie er sich authentifiziert. Da sich SSO-Benutzer über Ihren Identity Provider anmelden und nicht über ein DefectDojo-Passwort, ist ein erzwungener Passwort-Reset bei ihnen in der Regel nicht sinnvoll – vermeiden Sie es, reine SSO-Benutzer in die Auswahl einzubeziehen. diff --git a/docs/content/admin/user_management/PRO__resetting_user_credentials.es.md b/docs/content/admin/user_management/PRO__resetting_user_credentials.es.md new file mode 100644 index 00000000000..d2a93573625 --- /dev/null +++ b/docs/content/admin/user_management/PRO__resetting_user_credentials.es.md @@ -0,0 +1,34 @@ +--- +title: Restablecimiento masivo de credenciales de usuario +description: Rote tokens de API y fuerce el restablecimiento de contraseña de muchos + usuarios a la vez desde la lista de Usuarios +audience: pro +weight: 2 +--- + +La lista de **Usuarios** de DefectDojo Pro le permite rotar tokens de API y forzar el restablecimiento de contraseña de muchos usuarios a la vez, lo que resulta útil para la higiene periódica de credenciales o para responder ante una posible exposición de credenciales. + +Estas acciones masivas solo están disponibles para **Superusuarios** y usuarios con el rol de **Global Owner**. Si no cuenta con ninguno de estos, las casillas de selección y los botones de acciones masivas no aparecerán. + +## Seleccionar usuarios + +En la lista de **Usuarios**, use las casillas de verificación para seleccionar uno o más usuarios. Aparecerá una barra de acciones masivas con los botones de restablecimiento. Cada acción le pedirá confirmación en un cuadro de diálogo antes de ejecutarse. + +La acción se aplica a los usuarios que haya marcado explícitamente. **No puede incluir su propia cuenta** en un restablecimiento masivo: si su cuenta está entre las filas seleccionadas, los botones de acciones masivas se deshabilitan y se muestra una advertencia. + +## Restablecer tokens de API + +**Restablecer tokens de API** rota el token de API de cada usuario seleccionado: DefectDojo elimina el token existente del usuario y emite uno nuevo. **El token actual del usuario deja de funcionar de inmediato**, por lo que cualquier script o integración que use el token anterior debe actualizarse con el nuevo. + +* Los nuevos valores de token **no** se muestran al administrador. Cada usuario afectado recibe una notificación de **"API Token Reset"** que le indica que debe obtener su nuevo token desde la interfaz (entregada según la configuración de notificaciones de ese usuario). + +## Forzar restablecimiento de contraseña + +**Forzar restablecimiento de contraseña** activa el indicador *force-password-reset-on-next-login* en cada usuario seleccionado. La próxima vez que ese usuario realice una solicitud, DefectDojo lo redirigirá a la página **Change Password** y no le permitirá continuar hasta que establezca una nueva contraseña. El indicador se borra automáticamente una vez que lo hace. + +Tenga en cuenta lo que esta acción **no** hace: + +* **No** establece ni genera aleatoriamente una contraseña temporal, y **no** le devuelve ninguna credencial. +* **No** envía a los usuarios afectados ningún correo electrónico ni notificación. Dado que no hay aviso automático, informe a los usuarios afectados por otro medio de que se les pedirá cambiar su contraseña en el próximo inicio de sesión. + +> **Usuarios SSO:** A diferencia del formulario de edición de un solo usuario (que deshabilita el indicador de restablecimiento forzoso para las cuentas autorizadas mediante SSO), la acción masiva aplica el indicador a **todos** los usuarios seleccionados, sin importar cómo se autentiquen. Dado que los usuarios SSO inician sesión a través de su Proveedor de Identidad en lugar de una contraseña de DefectDojo, forzar un restablecimiento de contraseña en ellos generalmente carece de sentido; evite incluir en la selección a usuarios exclusivamente SSO. diff --git a/docs/content/admin/user_management/PRO__resetting_user_credentials.fr.md b/docs/content/admin/user_management/PRO__resetting_user_credentials.fr.md new file mode 100644 index 00000000000..77ecf0f51f0 --- /dev/null +++ b/docs/content/admin/user_management/PRO__resetting_user_credentials.fr.md @@ -0,0 +1,35 @@ +--- +title: Réinitialisation groupée des identifiants utilisateur +description: Faire pivoter les jetons API et forcer la réinitialisation des mots de + passe pour de nombreux utilisateurs à la fois depuis la liste des utilisateurs +audience: pro +weight: 2 +--- + +La liste des **Utilisateurs** de DefectDojo Pro vous permet de faire pivoter les jetons API et de forcer la réinitialisation des mots de passe pour de nombreux utilisateurs à la fois — utile pour l'hygiène périodique des identifiants ou pour répondre à une exposition d'identifiants suspectée. + +Ces actions groupées ne sont disponibles que pour les **Superusers** et les utilisateurs disposant du rôle **Global Owner**. Si vous n'avez pas l'un de ces statuts, les cases à cocher de sélection et les boutons d'action groupée n'apparaissent pas. + +## Sélection des utilisateurs + +Dans la liste des **Utilisateurs**, utilisez les cases à cocher pour sélectionner un ou plusieurs utilisateurs. Une barre d'actions groupées apparaît avec les boutons de réinitialisation. Chaque action vous demande de confirmer dans une boîte de dialogue avant de s'exécuter. + +L'action s'applique aux utilisateurs que vous avez explicitement cochés. Vous **ne pouvez pas inclure votre propre compte** dans une réinitialisation groupée : si votre compte figure parmi les lignes sélectionnées, les boutons d'action groupée sont désactivés et un avertissement s'affiche. + +## Réinitialiser les jetons API + +**Réinitialiser les jetons API** fait pivoter le jeton API de chaque utilisateur sélectionné : DefectDojo supprime le jeton existant de l'utilisateur et en émet un nouveau. **Le jeton actuel de l'utilisateur cesse immédiatement de fonctionner**, donc tout script ou toute intégration utilisant l'ancien jeton doit être mis à jour avec le nouveau. + +* Les nouvelles valeurs de jeton ne vous sont **pas** montrées en tant qu'administrateur. Chaque utilisateur concerné reçoit une notification **« API Token Reset »** lui indiquant de récupérer son nouveau jeton depuis l'interface (envoyée selon les paramètres de notification de cet utilisateur). + +## Forcer la réinitialisation du mot de passe + +**Forcer la réinitialisation du mot de passe** active l'indicateur *force-password-reset-on-next-login* sur chaque utilisateur sélectionné. La prochaine fois que cet utilisateur effectuera une requête, DefectDojo le redirigera vers la page **Change Password** et ne le laissera pas continuer tant qu'il n'aura pas défini un nouveau mot de passe. L'indicateur se réinitialise automatiquement une fois cela fait. + +Gardez à l'esprit ce que cette action ne fait **pas** : + +* Elle ne définit ni ne génère de façon aléatoire un mot de passe temporaire, et elle ne vous retourne aucun identifiant. + +* Elle n'envoie **pas** d'e-mail ni de notification aux utilisateurs concernés. Comme il n'y a pas d'avis automatique, informez les utilisateurs concernés par un autre moyen qu'ils seront invités à changer leur mot de passe lors de leur prochaine connexion. + +> **Utilisateurs SSO :** Contrairement au formulaire d'édition d'un utilisateur unique (qui désactive l'indicateur de réinitialisation forcée pour les comptes autorisés par SSO), l'action groupée applique l'indicateur à **tous** les utilisateurs sélectionnés, quel que soit leur mode d'authentification. Comme les utilisateurs SSO se connectent via votre fournisseur d'identité plutôt qu'avec un mot de passe DefectDojo, forcer une réinitialisation de mot de passe pour eux n'a généralement pas de sens — évitez d'inclure des utilisateurs exclusivement SSO dans la sélection. diff --git a/docs/content/admin/user_management/PRO__resetting_user_credentials.ja.md b/docs/content/admin/user_management/PRO__resetting_user_credentials.ja.md new file mode 100644 index 00000000000..eeaeabf866e --- /dev/null +++ b/docs/content/admin/user_management/PRO__resetting_user_credentials.ja.md @@ -0,0 +1,33 @@ +--- +title: ユーザー認証情報の一括リセット +description: ユーザー一覧から多数のユーザーのAPIトークンをローテーションし、パスワードの再設定を強制します +audience: pro +weight: 2 +--- + +DefectDojoの**ユーザー**一覧では、多数のユーザーのAPIトークンを一括でローテーションしたり、パスワードの再設定を強制したりできます。定期的な認証情報の衛生管理や、認証情報の漏えいが疑われる場合の対応に役立ちます。 + +これらの一括操作は、**スーパーユーザー**と**グローバルオーナー**ロールを持つユーザーのみが利用できます。いずれにも該当しない場合、選択用チェックボックスと一括操作ボタンは表示されません。 + +## ユーザーを選択する + +**ユーザー**一覧で、チェックボックスを使って1人以上のユーザーを選択します。リセットボタンを含む一括操作バーが表示されます。各操作の実行前には、ダイアログでの確認が求められます。 + +この操作は、明示的にチェックしたユーザーにのみ適用されます。**自分自身のアカウントを一括リセットに含めることはできません**。選択した行に自分のアカウントが含まれている場合、一括操作ボタンは無効化され、警告が表示されます。 + +## APIトークンをリセットする + +**APIトークンをリセット**は、選択した各ユーザーのAPIトークンをローテーションします。DefectDojoはユーザーの既存トークンを削除し、新しいトークンを発行します。**ユーザーの現在のトークンは直ちに使用できなくなる**ため、古いトークンを使用しているスクリプトや連携機能はすべて新しいトークンに更新する必要があります。 + +* 新しいトークンの値は、管理者であるあなたには表示され**ません**。影響を受ける各ユーザーには、UIから新しいトークンを取得するよう伝える**「APIトークンのリセット」**通知が送信されます(そのユーザーの通知設定に従って配信されます)。 + +## パスワードのリセットを強制する + +**パスワードのリセットを強制**は、選択した各ユーザーに*次回ログイン時のパスワード再設定を強制する*フラグを設定します。次にそのユーザーがリクエストを行うと、DefectDojoは**パスワードの変更**ページにリダイレクトし、新しいパスワードを設定するまで先に進めません。フラグは設定が完了すると自動的に解除されます。 + +この操作が**行わないこと**にも注意してください。 + +* 一時パスワードの設定やランダム生成は行わず、認証情報をあなたに返すこともありません。 +* 影響を受けるユーザーにメールや通知を送信することもありません。自動通知が行われないため、次回ログイン時にパスワードの変更を求められることを、対象ユーザーに別途伝えてください。 + +> **SSOユーザーについて:** 単一ユーザーの編集フォームでは、SSOで認証されたアカウントに対してこの強制リセットフラグは無効化されますが、一括操作では認証方法にかかわらず、選択した**すべて**のユーザーにフラグが適用されます。SSOユーザーはDefectDojoのパスワードではなくIDプロバイダーを通じてサインインするため、パスワードのリセットを強制することは通常意味がありません。選択対象にSSO専用ユーザーを含めないようにしてください。 diff --git a/docs/content/admin/user_management/_index.de.md b/docs/content/admin/user_management/_index.de.md new file mode 100644 index 00000000000..c98bf7f7b8f --- /dev/null +++ b/docs/content/admin/user_management/_index.de.md @@ -0,0 +1,43 @@ +--- +title: Benutzerverwaltung +description: Benutzer, Zugriffskontrolle und Authentifizierung in DefectDojo verwalten +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 5 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +Die Benutzerverwaltung von DefectDojo unterscheidet sich je nach Edition. Wählen Sie den Abschnitt, der zu Ihrer Installation passt. + +## DefectDojo Open-Source + +Open-Source-DefectDojo verwendet das Modell der **Autorisierten Benutzer**: Ein Benutzer erhält Zugriff auf ein Produkt oder einen Produkttyp, indem er zur Liste der Autorisierten Benutzer dieses Datensatzes hinzugefügt wird. Superuser und Mitarbeiter können alles sehen. + +* [Autorisierte Benutzer](./os__authorized_users/) — wie Sie Zugriff auf Produkte und Produkttypen gewähren + +Die Authentifizierung bei Open-Source-DefectDojo erfolgt über lokalen Benutzernamen/Passwort sowie den Passwort-Reset-Ablauf. + +## DefectDojo Pro + +DefectDojo Pro verwendet ein rollenbasiertes System mit Mitgliedern, Gruppen und globalen Rollen. Benutzer können außerdem SSO-Zugriff über SAML oder einen der unterstützten OAuth-Anbieter erhalten. + +* [Berechtigungen in DefectDojo](./about_perms_and_roles/) — Überblick über Rollen, Mitgliedschaften, globale Rollen und Konfigurationsberechtigungen +* [Berechtigungen eines Benutzers festlegen](./set_user_permissions/) — Zuweisen von Rollen, globalen Rollen und Konfigurationsberechtigungen +* [Berechtigungen teilen: Benutzergruppen](./create_user_group/) — Berechtigungen für viele Benutzer gleichzeitig zuweisen +* [Berechtigungen in Pro festlegen](./pro_permissions_overhaul/) — Pro-spezifische Benutzeroberfläche zur Verwaltung von Mitgliedern und Berechtigungen +* [Massenhaftes Zurücksetzen von Benutzeranmeldedaten](./pro__resetting_user_credentials/) — API-Tokens rotieren und Passwort-Resets für viele Benutzer gleichzeitig erzwingen +* [Aktions-Berechtigungsübersichten](./user_permission_chart/) — vollständige Referenz aller Berechtigungen für jede integrierte Rolle +* [Benutzerdefinierte RBAC-Rollen](./pro__custom_rbac_roles/) — eigene Rollen durch Auswahl einzelner Berechtigungen erstellen +* [Single Sign-On](/admin/sso/) — SAML- und OAuth-Einrichtung für Pro + +## Wechsel zwischen Editionen + +Wenn Sie von den Autorisierten Benutzern der Open-Source-Version zum RBAC von Pro wechseln, oder von einer Open-Source-Version vor 3.0, die RBAC verwendet hat, auf das aktuelle Modell der Autorisierten Benutzer aktualisieren, lesen Sie die [Hinweise zum 3.0-Upgrade](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization). Bestehende Zugriffsrechte bleiben automatisch erhalten. diff --git a/docs/content/admin/user_management/_index.es.md b/docs/content/admin/user_management/_index.es.md new file mode 100644 index 00000000000..8b80640292b --- /dev/null +++ b/docs/content/admin/user_management/_index.es.md @@ -0,0 +1,43 @@ +--- +title: Gestión de usuarios +description: Gestione usuarios, control de acceso y autenticación en DefectDojo +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 5 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +La superficie de gestión de usuarios de DefectDojo difiere según la edición. Elija la sección que corresponda a su instalación. + +## DefectDojo de código abierto + +DefectDojo de código abierto usa el modelo de **Usuarios Autorizados**: se otorga acceso a un usuario a un Producto o un Tipo de Producto al agregarlo a la lista de Usuarios Autorizados de ese registro. Los Superusuarios y el personal pueden ver todo. + +* [Usuarios Autorizados](./os__authorized_users/) — cómo otorgar acceso a Productos y Tipos de Producto + +La autenticación en DefectDojo de código abierto se basa en usuario/contraseña local, junto con el flujo de restablecimiento de contraseña. + +## DefectDojo Pro + +DefectDojo Pro usa un sistema basado en roles con Miembros, Grupos y Roles Globales. Los usuarios también pueden recibir acceso SSO mediante SAML o uno de los proveedores de OAuth compatibles. + +* [Permisos en DefectDojo](./about_perms_and_roles/) — resumen de Roles, Membresías, Roles Globales y Permisos de Configuración +* [Establecer los permisos de un usuario](./set_user_permissions/) — asignación de Roles, Roles Globales y Permisos de Configuración +* [Compartir permisos: Grupos de usuarios](./create_user_group/) — asignar permisos a muchos usuarios a la vez +* [Establecer permisos en Pro](./pro_permissions_overhaul/) — interfaz específica de Pro para gestionar Miembros y Permisos +* [Restablecimiento masivo de credenciales de usuario](./pro__resetting_user_credentials/) — rotar tokens de API y forzar el restablecimiento de contraseña de muchos usuarios a la vez +* [Tablas de permisos por acción](./user_permission_chart/) — referencia completa de cada permiso para cada Rol integrado +* [Roles RBAC personalizados](./pro__custom_rbac_roles/) — cree sus propios roles eligiendo permisos individuales +* [Inicio de sesión único](/admin/sso/) — configuración de SAML y OAuth para Pro + +## Migración entre ediciones + +Si está pasando de los Usuarios Autorizados de código abierto al RBAC de Pro, o si está actualizando desde una versión de código abierto anterior a la 3.0 que usaba RBAC hacia el modelo actual de Usuarios Autorizados, consulte las [notas de actualización de la versión 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization). El acceso existente se conserva automáticamente. diff --git a/docs/content/admin/user_management/_index.fr.md b/docs/content/admin/user_management/_index.fr.md new file mode 100644 index 00000000000..ed2f6234a9c --- /dev/null +++ b/docs/content/admin/user_management/_index.fr.md @@ -0,0 +1,44 @@ +--- +title: Gestion des utilisateurs +description: Gérer les utilisateurs, le contrôle d'accès et l'authentification dans + DefectDojo +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 5 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +La gestion des utilisateurs de DefectDojo diffère selon l'édition. Choisissez la section correspondant à votre installation. + +## DefectDojo Open-Source + +DefectDojo Open-Source utilise le modèle **Authorized Users** : un utilisateur obtient l'accès à un Produit ou à un Type de produit en étant ajouté à la liste des Authorized Users de cet enregistrement. Les Superusers et le personnel (staff) voient tout. + +* [Authorized Users](./os__authorized_users/) — comment accorder l'accès aux Produits et aux Types de produit + +L'authentification sur DefectDojo Open-Source repose sur un identifiant/mot de passe local, complété par le flux de réinitialisation du mot de passe. + +## DefectDojo Pro + +DefectDojo Pro utilise un système basé sur les rôles avec des Members, des Groups et des Global Roles. Les utilisateurs peuvent également se voir accorder un accès SSO via SAML ou l'un des fournisseurs OAuth pris en charge. + +* [Autorisations dans DefectDojo](./about_perms_and_roles/) — présentation des Roles, Memberships, Global Roles et Configuration Permissions +* [Définir les autorisations d'un utilisateur](./set_user_permissions/) — attribution des Roles, Global Roles et Configuration Permissions +* [Partager les autorisations : groupes d'utilisateurs](./create_user_group/) — attribution des autorisations à de nombreux utilisateurs à la fois +* [Définir les autorisations dans Pro](./pro_permissions_overhaul/) — interface spécifique à Pro pour gérer les Members et les Permissions +* [Réinitialisation groupée des identifiants utilisateur](./pro__resetting_user_credentials/) — faire pivoter les jetons API et forcer la réinitialisation des mots de passe pour de nombreux utilisateurs à la fois +* [Tableaux des autorisations par action](./user_permission_chart/) — référence complète de chaque autorisation pour chaque rôle intégré +* [Rôles RBAC personnalisés](./pro__custom_rbac_roles/) — créez vos propres rôles en choisissant des autorisations individuelles +* [Authentification unique (SSO)](/admin/sso/) — configuration SAML et OAuth pour Pro + +## Migration entre éditions + +Si vous passez du modèle Authorized Users de l'Open-Source au RBAC de Pro, ou si vous effectuez une mise à niveau depuis une version Open-Source antérieure à 3.0 qui utilisait le RBAC vers le modèle Authorized Users actuel, consultez les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization). L'accès existant est conservé automatiquement. diff --git a/docs/content/admin/user_management/_index.ja.md b/docs/content/admin/user_management/_index.ja.md new file mode 100644 index 00000000000..636a5fc880f --- /dev/null +++ b/docs/content/admin/user_management/_index.ja.md @@ -0,0 +1,43 @@ +--- +title: ユーザー管理 +description: DefectDojoにおけるユーザー、アクセス制御、認証の管理 +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 5 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +DefectDojoのユーザー管理画面は、エディションごとに異なります。お使いの環境に該当するセクションを選択してください。 + +## DefectDojo Open-Source + +オープンソース版のDefectDojoは**認可済みユーザー**モデルを採用しています。ユーザーは、対象のProductまたはProduct Typeの認可済みユーザーリストに追加されることでアクセス権を得ます。スーパーユーザーとスタッフはすべてを閲覧できます。 + +* [認可済みユーザー](./os__authorized_users/) — ProductとProduct Typeへのアクセス権を付与する方法 + +オープンソース版のDefectDojoにおける認証は、ローカルのユーザー名/パスワードとパスワードリセットフローによって行われます。 + +## DefectDojo Pro + +DefectDojo Proは、メンバー、グループ、グローバルロールによるロールベースのシステムを採用しています。ユーザーには、SAMLまたはサポートされているOAuthプロバイダーの1つを通じてSSOアクセスを付与することもできます。 + +* [DefectDojoにおける権限](./about_perms_and_roles/) — ロール、メンバーシップ、グローバルロール、設定権限の概要 +* [ユーザーの権限を設定する](./set_user_permissions/) — ロール、グローバルロール、設定権限の割り当て +* [権限を共有する: ユーザーグループ](./create_user_group/) — 多数のユーザーに一括で権限を割り当てる +* [Proでの権限設定](./pro_permissions_overhaul/) — メンバーと権限を管理するためのPro専用UI +* [ユーザー認証情報の一括リセット](./pro__resetting_user_credentials/) — 多数のユーザーのAPIトークンをローテーションし、パスワードの再設定を強制する +* [操作権限チャート](./user_permission_chart/) — すべての組み込みロールにおけるすべての権限の完全なリファレンス +* [カスタムRBACロール](./pro__custom_rbac_roles/) — 個別の権限を選択して独自のロールを構築する +* [シングルサインオン](/admin/sso/) — ProにおけるSAMLおよびOAuthの設定 + +## エディション間の移行 + +オープンソース版の認可済みユーザーからProのRBACへ移行する場合や、RBACを使用していた3.0より前のオープンソース版から現在の認可済みユーザーモデルにアップグレードする場合は、[3.0アップグレードノート](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization)を参照してください。既存のアクセス権は自動的に保持されます。 diff --git a/docs/content/admin/user_management/about_perms_and_roles.de.md b/docs/content/admin/user_management/about_perms_and_roles.de.md new file mode 100644 index 00000000000..071c7de96cd --- /dev/null +++ b/docs/content/admin/user_management/about_perms_and_roles.de.md @@ -0,0 +1,118 @@ +--- +title: Berechtigungen in DefectDojo +description: Detaillierte Übersicht aller Berechtigungsoptionen von DefectDojo Pro +weight: 2 +audience: pro +aliases: +- /de/en/customize_dojo/user_management/about_perms_and_roles +--- + +> **DefectDojo-Pro-Funktion.** Das auf dieser Seite beschriebene RBAC-System mit Mitgliedern/Gruppen/globalen Rollen ist Teil von DefectDojo Pro. Open-Source-DefectDojo verwendet das Modell der [Autorisierten Benutzer](../os__authorized_users/) — dort finden Sie Informationen zur Zugriffskontrolle in der Open-Source-Version, sowie die [Hinweise zum 3.0-Upgrade](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization), falls Sie zwischen den Editionen wechseln. + +Wenn Sie in DefectDojo mit einem Team von Benutzern arbeiten, ist es wichtig, die rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) angemessen einzurichten, damit Benutzer nur auf bestimmte Daten zugreifen können. Sicherheitsdaten sind hochsensibel, und die Zugriffskontrolloptionen von DefectDojo ermöglichen es Ihnen, den Zugriff jedes Teammitglieds auf Informationen genau festzulegen. + +Dieser Artikel bietet einen Überblick darüber, wie Berechtigungen in DefectDojo funktionieren. Wenn Sie stattdessen eine detaillierte Aufschlüsselung **jeder Aktion** sehen möchten, die durch Berechtigungen gesteuert werden kann, lesen Sie unseren Artikel **[Berechtigungsübersicht](../user_permission_chart/)**. + +## Arten von Berechtigungen + +DefectDojo verwaltet vier verschiedene Arten von Berechtigungen: + +* Benutzer können als **Mitglieder** zu **Produkten oder Produkttypen** zugewiesen werden. Eine Produktmitgliedschaft ist mit einer **Rolle** verbunden, die es Ihren Benutzern ermöglicht, Datentypen (Produkttypen, Produkte, Engagements, Tests und Befunde) in DefectDojo anzuzeigen und mit ihnen zu interagieren. Benutzer können mehrere Produkt- oder Produkttyp-Mitgliedschaften mit unterschiedlichen Zugriffsebenen haben. + +* Benutzern können außerdem **Konfigurationsberechtigungen** zugewiesen werden, die ihnen den Zugriff auf Konfigurationsseiten in DefectDojo ermöglichen. Konfigurationsberechtigungen stehen in keinem Zusammenhang mit Produkten oder Produkttypen und sind nicht an Rollen gebunden. + +* Benutzern können **globale Rollen** zugewiesen werden, die ihnen ein standardisiertes Zugriffsniveau auf alle Produkte und Produkttypen geben. + +* Benutzer können als **Superuser** eingerichtet werden: Rollen auf Administratorebene, die ihnen Kontrolle über und Zugriff auf alle DefectDojo-Daten und -Konfigurationen geben. + +Jede dieser Berechtigungsarten kann auch einer **Benutzergruppe** zugewiesen werden. Wenn Sie eine große Anzahl an Benutzern in DefectDojo haben, etwa ein dediziertes Testteam für ein bestimmtes Produkt, ermöglichen Ihnen Gruppen, Berechtigungen schnell einzurichten und zu pflegen. + +## Produkt-/Produkttyp-Mitgliedschaft & Rollen + +Wenn Benutzer als Mitglieder zu einem Produkt oder Produkttyp zugewiesen werden, erhalten sie außerdem eine Rolle, die steuert, wie sie mit den zugehörigen Befund-Daten interagieren. + +### Zusammenfassung der Rollen + +DefectDojo Pro liefert fünf **integrierte Rollen**: Reader, Writer, Maintainer, Owner und API Importer. Jede davon kann entweder global oder innerhalb eines Produkts / Produkttyps zugewiesen werden. + +Die integrierten Rollen sind feste Voreinstellungen. Sie können nicht bearbeitet oder gelöscht werden, und ihre Berechtigungen sind auf jeder DefectDojo-Pro-Instanz identisch. Wenn keine davon zur Arbeitsweise Ihres Teams passt, können Sie eine passende Rolle erstellen, indem Sie einzelne Berechtigungen auswählen oder eine integrierte Rolle klonen und anpassen. Siehe [Benutzerdefinierte RBAC-Rollen](../pro__custom_rbac_roles/). + +„Zugrunde liegende Daten“ bezieht sich auf alle Produkte, Engagements, Tests, Befunde oder Endpunkte, die einem Produkt oder Produkttyp untergeordnet sind. + +* **Reader**-Benutzer können die zugrunde liegenden Daten jedes Produkts oder Produkttyps, dem sie zugewiesen sind, einsehen und Kommentare hinzufügen. Sie können die zugrunde liegenden Daten weder bearbeiten, hinzufügen noch anderweitig ändern, können jedoch Berichte exportieren und Notizen zu Daten hinzufügen. + +* **Writer**-Benutzer verfügen über alle Fähigkeiten von Reader, zusätzlich können sie Engagements, Tests und Befunde hinzufügen oder bearbeiten. Sie können keine neuen Produkte hinzufügen und keine zugrunde liegenden Daten löschen. + +* **Maintainer**-Benutzer verfügen über alle Fähigkeiten von Writer, zusätzlich können sie Produkte oder Produkttypen bearbeiten. Sie können dem Produkt oder Produkttyp neue Mitglieder mit Rollen hinzufügen und außerdem Engagements, Tests und Befunde löschen. + +* **Owner**-Benutzer haben die größte Kontrolle über ein Produkt oder einen Produkttyp. Sie können andere Owner benennen und außerdem die Produkte oder Produkttypen löschen, denen sie zugewiesen sind. + +* **API Importer**-Benutzer verfügen über eingeschränkte Fähigkeiten. Diese Rolle erlaubt eingeschränkten API-Zugriff, ohne den Großteil der API-Endpunkte offenzulegen, und ist daher nützlich für Automatisierung oder Benutzer, die gegenüber DefectDojo „extern“ bleiben sollen. Sie können zugrunde liegende Daten einsehen, Engagements hinzufügen/bearbeiten und Scan-Daten importieren. + +Detaillierte Informationen zu den integrierten Rollen finden Sie in unserer **[Rollen-Berechtigungsübersicht](../user_permission_chart/)**. Die vollständige Liste der Berechtigungen, die einer Rolle zugewiesen werden können, sowie Anleitungen zum Erstellen eigener Rollen finden Sie unter **[Benutzerdefinierte RBAC-Rollen](../pro__custom_rbac_roles/)**. + +### Globale Rollen + +Benutzer mit **globalen Rollen** können je nach zugewiesener Rolle jeden Datentyp (Produkttypen, Produkte, Engagements, Tests und Befunde) in DefectDojo einsehen und mit ihm interagieren. + +### Gruppenmitgliedschaften + +Benutzergruppen können als Mitglieder eines Produkts oder Produkttyps hinzugefügt werden. Benutzer, die Teil der Gruppe sind, erben den Zugriff auf alle zugehörigen Produkte oder Produkttypen sowie die der Gruppe zugewiesene Rolle. + +#### Benutzer mit mehreren Rollen + +* Wenn ein Benutzer als Mitglied eines Produkts zugewiesen wird, erhält er standardmäßig keine zugehörigen Produkttyp-Berechtigungen. + +* Wenn ein Benutzer für dasselbe Produkt oder denselben Produkttyp mehr als eine Rolle erhält (zum Beispiel eine direkt zugewiesene und eine von einer Gruppe geerbte), erhält er die **kombinierten** Berechtigungen aller Rollen, die er dort innehat. + +* Die Produktrolle eines Benutzers hat immer Vorrang vor seiner „Standard“-Produkttyprolle. + +* Die Produkt-/Produkttyprolle eines Benutzers hat innerhalb des zugrunde liegenden Produkts oder Produkttyps immer Vorrang vor seiner globalen Rolle. Wenn ein Benutzer beispielsweise die Produkttyprolle Reader hat, aber auch als Owner für ein diesem Produkttyp untergeordnetes Produkt zugewiesen ist, erhält er zusätzliche Owner-Berechtigungen nur für dieses Produkt. + +* Rollen können keine Berechtigungen entziehen, sie können nur zusätzliche hinzufügen. Wenn ein Benutzer beispielsweise die Produkttyprolle oder globale Rolle Owner hat, entzieht ihm die Zuweisung der Rolle Reader für ein bestimmtes Produkt nicht seine Owner-Berechtigungen für dieses Produkt. + +* Der Superuser-Status hat immer Vorrang vor allen zugewiesenen Rollen. + +## Superuser + +Superuser (Admins) haben keinerlei Einschränkungen im System. Sie können alle Einstellungen ändern, Benutzer verwalten und haben Lese-/Schreibzugriff auf alle Daten. Sie können außerdem die Zugriffsregeln für alle Benutzer in DefectDojo ändern. Superuser erhalten zudem Benachrichtigungen zu allen Systemproblemen und Warnmeldungen. + +Standardmäßig erhält das erste auf einer neuen DefectDojo-Instanz erstellte Konto Superuser-Berechtigungen. Dieser Benutzer kann die Berechtigungen aller später erstellten DefectDojo-Benutzer bearbeiten. Nur ein bestehender Superuser kann einen weiteren Superuser hinzufügen oder einem Benutzer eine globale Rolle zuweisen. + +## Konfigurationsberechtigungen + +Konfigurationsberechtigungen ähneln zwar Rollen, stehen aber in keinem Zusammenhang mit Produkten oder Rollen. Sie müssen unabhängig von Rollen zugewiesen werden. **Reguläre Benutzer haben standardmäßig keine Konfigurationsberechtigungen, und die Zuweisung dieser Konfigurationsberechtigungen sollte mit Sorgfalt erfolgen.** + +Benutzern können Konfigurationsberechtigungen auf unterschiedliche Weise zugewiesen werden: + +1. Benutzern können Konfigurationsberechtigungen direkt zugewiesen werden. Bestimmte Berechtigungen können direkt auf einer Benutzerseite konfiguriert werden. + +2. Benutzergruppen können Konfigurationsberechtigungen zugewiesen werden. Wie bei Rollen können bestimmte Konfigurationsberechtigungen zu Gruppen hinzugefügt werden, wodurch alle Gruppenmitglieder diese Berechtigungen erhalten. + +Superuser verfügen über alle Konfigurationsberechtigungen und haben daher keinen Abschnitt für Konfigurationsberechtigungen auf ihrer Benutzerseite. + +### Gruppen-Konfigurationsberechtigungen + +Wenn Benutzer Teil einer Gruppe sind, haben sie außerdem Gruppen-Konfigurationsberechtigungen, die ihr Zugriffsniveau auf die Konfiguration einer Gruppe steuern. Gruppenberechtigungen entsprechen nicht der Produkt- oder Produkttyp-Mitgliedschaft der Gruppe. + +Wenn Benutzer eine neue Gruppe erstellen, erhalten sie standardmäßig die Rolle Owner für die neue Gruppe. + +Weitere Informationen zu Konfigurationsberechtigungen finden Sie in unserer **[Konfigurationsberechtigungsübersicht](../user_permission_chart/#configuration-permission-chart)**. + +## Standardberechtigungen verwalten + +Wenn in DefectDojo ein völlig neuer Benutzer erstellt wird — ob manuell, per SAML / SSO oder über einen Social-Auth-Anbieter —, hat er **standardmäßig keinerlei Berechtigungen**. Bei der ersten Anmeldung sieht er null Produkttypen, null Produkte und null Engagements. Er kann keine Daten einsehen oder mit ihnen interagieren, bis ein Superuser ihm Zugriff gewährt (direkt, über eine globale Rolle, über eine Produkt-/Produkttyp-Mitgliedschaft oder durch Hinzufügen zu einer Gruppe). + +Wenn jeder neu angelegte Benutzer automatisch ein Basiszugriffsniveau erhalten soll — zum Beispiel „jeder neue SSO-Benutzer soll Reader in einer bestimmten Gruppe sein“ —, können Sie auf der Seite System Settings eine **Default group** konfigurieren. + +1. Öffnen Sie **⚙️ Configuration → System Settings** (nur Superuser). +2. Legen Sie unter **Default group** die [Benutzergruppe](../create_user_group/) fest, der neu erstellte Benutzer beitreten sollen. +3. Legen Sie unter **Default group role** die Rolle fest, die sie in dieser Gruppe innehaben sollen (z. B. **Reader**). +4. Legen Sie optional unter **Default group email pattern** einen regulären Ausdruck fest (z. B. `.*@yourcompany\.com$`), damit die Standardgruppe nur auf Benutzer angewendet wird, deren E-Mail-Adresse übereinstimmt. +5. Speichern. + +Sowohl **Default group** als auch **Default group role** müssen festgelegt sein — ist eines der beiden Felder leer, wird die Standardgruppe nicht angewendet. + +Diese Einstellung gilt für jeden Weg der Benutzererstellung: manuelle Erstellung, SAML, OAuth und andere Social-Auth-Anbieter. Sie wird nicht rückwirkend angewendet — bestehende Benutzer behalten ihre aktuellen Gruppenmitgliedschaften, auch wenn Sie diese Einstellung später ändern. + +Spezifische Hinweise zu SSO finden Sie unter [SAML-Konfiguration](/admin/sso/pro__saml/#default-access-for-sso-provisioned-users) oder im Abschnitt Ihres Anbieters unter [SSO-Konfiguration](../configure_sso/). diff --git a/docs/content/admin/user_management/about_perms_and_roles.es.md b/docs/content/admin/user_management/about_perms_and_roles.es.md new file mode 100644 index 00000000000..aed2df6204f --- /dev/null +++ b/docs/content/admin/user_management/about_perms_and_roles.es.md @@ -0,0 +1,119 @@ +--- +title: Permisos en DefectDojo +description: Resumen detallado de todas las opciones de permisos de DefectDojo Pro +weight: 2 +audience: pro +aliases: +- /es/en/customize_dojo/user_management/about_perms_and_roles +--- + +> **Función de DefectDojo Pro.** El sistema RBAC de Miembros / Grupos / Roles Globales descrito en esta página forma parte de DefectDojo Pro. DefectDojo de código abierto usa el modelo de [Usuarios Autorizados](../os__authorized_users/); consulte esa página para conocer el control de acceso de código abierto, y las [notas de actualización de la versión 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si está migrando entre ediciones. + +Si cuenta con un equipo de usuarios trabajando en DefectDojo, es importante configurar adecuadamente el Control de Acceso Basado en Roles (RBAC) para que los usuarios solo puedan acceder a datos específicos. Los datos de seguridad son muy sensibles, y las opciones de control de acceso de DefectDojo le permiten ser específico sobre el acceso de cada miembro del equipo a la información. + +Este artículo ofrece un resumen de cómo funcionan los permisos en DefectDojo. Si prefiere ver un desglose detallado de **cada acción** que puede controlarse mediante Permisos, consulte nuestro artículo **[Tabla de permisos](../user_permission_chart/)**. + +## Tipos de permisos + +DefectDojo gestiona cuatro tipos diferentes de permisos: + +* Los usuarios pueden asignarse como **Miembros** de **Productos o Tipos de Producto**. Una Membresía de Producto viene acompañada de un **Rol** que permite a sus usuarios ver e interactuar con los Tipos de Dato (Tipos de Producto, Productos, Compromisos, Tests y Hallazgos) en DefectDojo. Los usuarios pueden tener varias membresías de Producto o Tipo de Producto, con distintos niveles de acceso. + +* Los usuarios también pueden tener asignados **Permisos de Configuración**, que les permiten acceder a las páginas de configuración de DefectDojo. Los Permisos de Configuración no están relacionados con Productos o Tipos de Producto, ni se asocian a Roles. + +* A los usuarios se les pueden asignar **Roles Globales**, que les otorgan un nivel de acceso estandarizado a todos los Productos y Tipos de Producto. + +* Los usuarios pueden configurarse como **Superusuarios**: roles de nivel administrador que les otorgan control y acceso a todos los datos y la configuración de DefectDojo. + +Cada uno de estos tipos de Permisos también puede asignarse a un **Grupo** de **Usuarios**. Si tiene una gran cantidad de usuarios en DefectDojo, como un equipo de testing dedicado a un Producto en particular, los Grupos le permiten configurar y mantener los permisos rápidamente. + +## Membresía de Producto/Tipo de Producto y Roles + +Cuando los usuarios se asignan como miembros de un Producto o Tipo de Producto, también reciben un rol que controla cómo interactúan con los datos de Hallazgos asociados. + +### Resumen de roles + +DefectDojo Pro incluye cinco **roles integrados**: Reader, Writer, Maintainer, Owner y API Importer. Cualquiera de ellos puede asignarse de forma global o dentro de un Producto / Tipo de Producto. + +Los roles integrados son ajustes preestablecidos y bloqueados. No se pueden editar ni eliminar, y sus permisos son los mismos en todas las instancias de DefectDojo Pro. Si ninguno de ellos se ajusta a la forma de trabajar de su equipo, puede crear un rol que sí lo haga, eligiendo permisos individuales o clonando un rol integrado y ajustándolo. Consulte [Roles RBAC personalizados](../pro__custom_rbac_roles/). + +«Datos subyacentes» hace referencia a todos los Productos, Compromisos, Tests, Hallazgos o Endpoints anidados bajo un Producto o Tipo de Producto. + +* Los **usuarios Reader** pueden ver los datos subyacentes de cualquier Producto o Tipo de Producto al que estén asignados, y agregar comentarios. No pueden editar, agregar ni modificar de ninguna otra forma los datos subyacentes, pero sí pueden exportar Informes y agregar Notas a los datos. + +* Los **usuarios Writer** tienen todas las capacidades de Reader, además de la capacidad de Agregar o Editar Compromisos, Tests y Hallazgos. No pueden agregar nuevos Productos ni Eliminar ningún dato subyacente. + +* Los **usuarios Maintainer** tienen todas las capacidades de Writer, además de la capacidad de editar Productos o Tipos de Producto. Pueden agregar nuevos Miembros con Roles al Producto o Tipo de Producto, y también pueden Eliminar Compromisos, Tests y Hallazgos. + +* Los **usuarios Owner** tienen el mayor nivel de control sobre un Producto o Tipo de Producto. Pueden designar a otros Owners, y también pueden Eliminar los Productos o Tipos de Producto a los que están asignados. + +* Los **usuarios API Importer** tienen capacidades limitadas. Este Rol permite un acceso limitado a la API sin exponer la mayoría de los endpoints de la API, por lo que resulta útil para la automatización o para usuarios que deben ser «externos» a DefectDojo. Pueden ver datos subyacentes, Agregar / Editar Compromisos, e Importar Datos de Escaneo. + +Para obtener información detallada sobre los Roles integrados, consulte nuestra **[Tabla de permisos por rol](../user_permission_chart/)**. Para ver la lista completa de permisos que se pueden otorgar a un rol, y cómo crear el suyo propio, consulte **[Roles RBAC personalizados](../pro__custom_rbac_roles/)**. + +### Roles Globales + +Los usuarios con **Roles Globales** pueden ver e interactuar con cualquier Tipo de Dato (Tipos de Producto, Productos, Compromisos, Tests y Hallazgos) en DefectDojo, según el Rol que tengan asignado. + +### Membresías de Grupo + +Los Grupos de Usuarios pueden agregarse como Miembros de un Producto o Tipo de Producto. Los usuarios que forman parte del Grupo heredarán el acceso a todos los Productos o Tipos de Producto asociados, y heredarán el Rol asignado al Grupo. + +#### Usuarios con varios roles + +* Si un Usuario se asigna como miembro de un Producto, no se le otorgan por defecto los permisos asociados del Tipo de Producto. + +* Si un Usuario termina teniendo más de un rol en el mismo Producto o Tipo de Producto (por ejemplo, uno asignado directamente y otro heredado de un Grupo), recibe los permisos **combinados** de todos los roles que posee allí. + +* El Rol de Producto de un Usuario siempre prevalece sobre su Rol de Tipo de Producto «predeterminado». + +* El Rol de Producto / Tipo de Producto de un Usuario siempre prevalece sobre su Rol Global dentro del Producto o Tipo de Producto subyacente. Por ejemplo, si un Usuario tiene un Rol de Tipo de Producto Reader, pero también está asignado como Owner en un Producto anidado bajo ese Tipo de Producto, tendrá permisos adicionales de Owner agregados únicamente para ese Producto. + +* Los Roles no pueden quitar permisos, solo pueden agregar otros adicionales. Por ejemplo, si un Usuario tiene un Rol de Tipo de Producto o Rol Global de Owner, asignarle un rol Reader en un Producto en particular no le quitará sus permisos de Owner sobre ese Producto. + +* El estado de Superusuario siempre prevalece sobre cualquier Rol asignado. + +## Superusuarios + +Los Superusuarios (Administradores) no tienen limitaciones en el sistema. Pueden cambiar todas las configuraciones, gestionar usuarios y tienen acceso de lectura / escritura a todos los datos. También pueden cambiar las reglas de acceso de todos los usuarios en DefectDojo. Además, los Superusuarios reciben notificaciones de todos los problemas y alertas del sistema. + +De forma predeterminada, la primera cuenta creada en una nueva instancia de DefectDojo tendrá permisos de Superusuario. Ese usuario podrá editar los permisos de todos los usuarios de DefectDojo que se creen posteriormente. Solo un Superusuario existente puede agregar otro superusuario, o agregar un Rol Global a un usuario. + + +## Permisos de Configuración + +Los Permisos de Configuración, aunque similares, no están relacionados con Productos o Roles. Deben asignarse de forma independiente a los Roles. **Los usuarios regulares no tienen ningún Permiso de Configuración de forma predeterminada, y la asignación de estos permisos de configuración debe realizarse con cuidado.** + +Los usuarios pueden tener Permisos de Configuración asignados de diferentes formas: + +1. Los Permisos de Configuración se pueden asignar directamente a los usuarios. Los permisos específicos pueden configurarse directamente en la página de un Usuario. + +2. Los Grupos de Usuarios pueden tener Permisos de Configuración asignados. Al igual que con los Roles, se pueden agregar Permisos de Configuración específicos a los Grupos, lo que otorgará estos permisos a todos los miembros del Grupo. + +Los Superusuarios tienen todos los Permisos de Configuración, por lo que no cuentan con una sección de Permisos de Configuración en su página de Usuario. + +### Permisos de Configuración de Grupo + +Si los usuarios forman parte de un Grupo, también cuentan con Permisos de Configuración de Grupo que controlan su nivel de acceso a la configuración del Grupo. Los Permisos de Grupo no corresponden a la membresía de Producto o Tipo de Producto del Grupo. + +Si los usuarios crean un nuevo Grupo, se les otorgará por defecto el rol Owner de ese nuevo Grupo. + +Para obtener más información sobre los Permisos de Configuración, consulte nuestra **[Tabla de Permisos de Configuración](../user_permission_chart/#configuration-permission-chart)**. + +## Gestionar los permisos predeterminados + +Cuando se crea un usuario completamente nuevo en DefectDojo — ya sea manualmente, mediante SAML / SSO, o a través de cualquier proveedor de autenticación social — **no tiene ningún permiso de forma predeterminada**. Al iniciar sesión por primera vez, verá cero Tipos de Producto, cero Productos y cero Compromisos. No podrá ver ni interactuar con ningún dato hasta que un Superusuario le otorgue acceso (directamente, mediante un Rol Global, mediante una membresía de Producto / Tipo de Producto, o agregándolo a un Grupo). + +Si desea que todo usuario recién aprovisionado reciba automáticamente un nivel de acceso base — por ejemplo, "todo nuevo usuario SSO debe ser Reader en un grupo en particular" — puede configurar un **Grupo predeterminado** en la página de Configuración del sistema. + +1. Abra **⚙️ Configuración → Configuración del sistema** (solo Superusuario). +2. Configure **Grupo predeterminado** con el [Grupo de Usuarios](../create_user_group/) al que deben unirse los usuarios recién creados. +3. Configure **Rol de grupo predeterminado** con el rol que deben tener en ese grupo (por ejemplo, **Reader**). +4. Opcionalmente, configure **Patrón de correo electrónico de grupo predeterminado** con una expresión regular (por ejemplo, `.*@yourcompany\.com$`) para que el grupo predeterminado se aplique solo a los usuarios cuyo correo electrónico coincida. +5. Guarde los cambios. + +Tanto **Grupo predeterminado** como **Rol de grupo predeterminado** deben estar configurados; si alguno de los dos está vacío, el grupo predeterminado no se aplicará. + +Esta configuración se aplica a todas las vías de creación de usuarios: creación manual, SAML, OAuth y otros proveedores de autenticación social. No se aplica de forma retroactiva: los usuarios existentes conservarán sus membresías de grupo actuales aunque cambie esta configuración más adelante. + +Para obtener orientación específica sobre SSO, consulte [Configuración de SAML](/admin/sso/pro__saml/#default-access-for-sso-provisioned-users) o la sección de su proveedor en [Configuración de SSO](../configure_sso/). diff --git a/docs/content/admin/user_management/about_perms_and_roles.fr.md b/docs/content/admin/user_management/about_perms_and_roles.fr.md new file mode 100644 index 00000000000..f8d83a273da --- /dev/null +++ b/docs/content/admin/user_management/about_perms_and_roles.fr.md @@ -0,0 +1,119 @@ +--- +title: Autorisations dans DefectDojo +description: Résumé détaillé de toutes les options d'autorisation de DefectDojo Pro +weight: 2 +audience: pro +aliases: +- /fr/en/customize_dojo/user_management/about_perms_and_roles +--- + +> **Fonctionnalité DefectDojo Pro.** Le système RBAC Members / Groups / Global Roles décrit sur cette page fait partie de DefectDojo Pro. DefectDojo Open-Source utilise le modèle [Authorized Users](../os__authorized_users/) — consultez cette page pour le contrôle d'accès en Open-Source, ainsi que les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si vous passez d'une édition à l'autre. + +Si vous avez une équipe d'utilisateurs travaillant dans DefectDojo, il est important de configurer correctement le contrôle d'accès basé sur les rôles (Role-Based Access Control, RBAC) afin que les utilisateurs n'accèdent qu'à des données spécifiques. Les données de sécurité sont hautement sensibles, et les options de contrôle d'accès de DefectDojo vous permettent de définir précisément l'accès de chaque membre de l'équipe à l'information. + +Cet article donne une vue d'ensemble du fonctionnement des autorisations dans DefectDojo. Si vous préférez consulter une répartition détaillée de **chaque action** pouvant être contrôlée par les autorisations, consultez notre article **[Tableau des autorisations](../user_permission_chart/)**. + +## Types d'autorisations + +DefectDojo gère quatre types d'autorisations différents : + +* Les utilisateurs peuvent être affectés comme **Members** à des **Produits ou des Types de produit**. Un Membership sur un Produit s'accompagne d'un **Role** qui permet à vos utilisateurs de consulter et d'interagir avec les types de données (Types de produit, Produits, Engagements, Tests et Constatations) dans DefectDojo. Les utilisateurs peuvent avoir plusieurs memberships sur des Produits ou des Types de produit, avec différents niveaux d'accès. +​ +* Les utilisateurs peuvent également se voir attribuer des **Configuration Permissions**, qui leur permettent d'accéder aux pages de configuration de DefectDojo. Les Configuration Permissions ne sont pas liées aux Produits ou aux Types de produit, et ne sont pas associées à des Roles. +​ +* Les utilisateurs peuvent se voir attribuer des **Global Roles**, qui leur donnent un niveau d'accès standardisé à tous les Produits et Types de produit. +​ +* Les utilisateurs peuvent être configurés comme **Superusers** : des rôles de niveau administrateur qui leur donnent le contrôle et l'accès à toutes les données et à la configuration de DefectDojo. + +Chacun de ces types d'autorisation peut également être attribué à un **Group** d'**Users**. Si vous avez un grand nombre d'utilisateurs dans DefectDojo, comme une équipe de test dédiée à un Produit particulier, les Groups vous permettent de configurer et de maintenir les autorisations rapidement. + +## Membership Produit/Type de produit et Roles + +Lorsque des utilisateurs sont affectés comme membres à un Produit ou à un Type de produit, ils reçoivent également un rôle qui détermine comment ils interagissent avec les données de Constatation associées. + +### Résumé des rôles + +DefectDojo Pro est livré avec cinq **rôles intégrés** : Reader, Writer, Maintainer, Owner et API Importer. Chacun d'eux peut être attribué globalement ou au sein d'un Produit / Type de produit. + +Les rôles intégrés sont des préréglages verrouillés. Ils ne peuvent être ni modifiés ni supprimés, et leurs autorisations sont identiques sur chaque instance de DefectDojo Pro. Si aucun d'eux ne correspond au fonctionnement de votre équipe, vous pouvez en créer un qui convient, en choisissant des autorisations individuelles ou en clonant un rôle intégré et en l'ajustant. Voir [Rôles RBAC personnalisés](../pro__custom_rbac_roles/). + +Les « données sous-jacentes » désignent l'ensemble des Produits, Engagements, Tests, Constatations ou Points de terminaison rattachés à un Produit ou à un Type de produit. + +* Les **utilisateurs Reader** peuvent consulter les données sous-jacentes de tout Produit ou Type de produit auquel ils sont affectés, et ajouter des commentaires. Ils ne peuvent ni modifier, ni ajouter, ni altérer d'aucune autre façon les données sous-jacentes, mais ils peuvent exporter des Rapports et ajouter des Notes aux données. +​ +* Les **utilisateurs Writer** disposent de toutes les capacités Reader, plus la possibilité d'ajouter ou de modifier des Engagements, des Tests et des Constatations. Ils ne peuvent pas ajouter de nouveaux Produits, ni supprimer de données sous-jacentes. +​ +* Les **utilisateurs Maintainer** disposent de toutes les capacités Writer, plus la possibilité de modifier le Produit ou le Type de produit. Ils peuvent ajouter de nouveaux Members avec des Roles au Produit ou au Type de produit, et peuvent également supprimer des Engagements, des Tests et des Constatations. +​ +* Les **utilisateurs Owner** disposent du plus grand contrôle sur un Produit ou un Type de produit. Ils peuvent désigner d'autres Owners, et peuvent également supprimer les Produits ou Types de produit auxquels ils sont affectés. +​ +* Les utilisateurs **API Importer** disposent de capacités limitées. Ce Role permet un accès API restreint sans exposer la majorité des points de terminaison de l'API ; il est donc utile pour l'automatisation ou pour les utilisateurs censés rester « externes » à DefectDojo. Ils peuvent consulter les données sous-jacentes, ajouter/modifier des Engagements, et importer des données de scan. + +Pour des informations détaillées sur les rôles intégrés, consultez notre **[Tableau des autorisations par rôle](../user_permission_chart/)**. Pour la liste complète des autorisations pouvant être attribuées à un rôle, et pour savoir comment créer le vôtre, consultez **[Rôles RBAC personnalisés](../pro__custom_rbac_roles/)**. + +### Global Roles + +Les utilisateurs disposant de **Global Roles** peuvent consulter et interagir avec tout type de données (Types de produit, Produits, Engagements, Tests et Constatations) dans DefectDojo, en fonction du Role qui leur est attribué. + +### Group Memberships + +Les User Groups peuvent être ajoutés comme Members d'un Produit ou d'un Type de produit. Les utilisateurs faisant partie du Group héritent de l'accès à tous les Produits ou Types de produit associés, ainsi que du Role attribué au Group. + +#### Utilisateurs disposant de plusieurs rôles + +* Si un User est affecté comme membre d'un Produit, il ne reçoit par défaut aucune autorisation associée au Type de produit. + +* Si un User se retrouve avec plusieurs rôles sur le même Produit ou Type de produit (par exemple un attribué directement et un autre hérité d'un Group), il reçoit les autorisations **combinées** de tous les rôles qu'il détient à cet endroit. + +* Le Role Produit d'un User prime toujours sur son Role Type de produit « par défaut ». +​ +* Le Role Produit / Type de produit d'un User prime toujours sur son Global Role au sein du Produit ou Type de produit sous-jacent. Par exemple, si un User a un Role Type de produit Reader, mais est également affecté comme Owner sur un Produit rattaché à ce Type de produit, il obtiendra des autorisations Owner supplémentaires uniquement pour ce Produit. +​ +* Les Roles ne peuvent pas retirer d'autorisations, ils ne peuvent qu'en ajouter. Par exemple, si un User a un Role Type de produit ou un Global Role Owner, lui attribuer un rôle Reader sur un Produit particulier ne lui retirera pas ses autorisations Owner sur ce Produit. +​ +* Le statut Superuser prime toujours sur les Roles attribués. + +## Superusers + +Les Superusers (Admins) n'ont aucune limitation dans le système. Ils peuvent modifier tous les paramètres, gérer les utilisateurs et disposent d'un accès en lecture/écriture à toutes les données. Ils peuvent également modifier les règles d'accès de tous les utilisateurs de DefectDojo. Les Superusers reçoivent également les notifications pour tous les problèmes et alertes système. + +Par défaut, le premier compte créé sur une nouvelle instance DefectDojo dispose des autorisations Superuser. Cet utilisateur pourra modifier les autorisations de tous les utilisateurs DefectDojo créés par la suite. Seul un Superuser existant peut ajouter un autre superuser, ou attribuer un Global Role à un utilisateur. + + +## Configuration Permissions + +Les Configuration Permissions, bien que similaires, ne sont pas liées aux Produits ou aux Roles. Elles doivent être attribuées séparément des Roles. **Les utilisateurs standards n'ont aucune Configuration Permission par défaut, et l'attribution de ces autorisations de configuration doit se faire avec prudence.** + +Les utilisateurs peuvent se voir attribuer des Configuration Permissions de différentes manières : + +1. Les Configuration Permissions peuvent être attribuées directement aux utilisateurs. Des autorisations spécifiques peuvent être configurées directement sur une page User. + +2. Des Configuration Permissions peuvent être attribuées aux User Groups. Comme pour les Roles, des Configuration Permissions spécifiques peuvent être ajoutées aux Groups, ce qui donnera ces autorisations à tous les membres du Group. + +Les Superusers disposent de toutes les Configuration Permissions, ils n'ont donc pas de section Configuration Permission sur leur page User. + +### Group Configuration Permissions + +Si des utilisateurs font partie d'un Group, ils disposent également de Group Configuration Permissions qui contrôlent leur niveau d'accès à la configuration du Group. Les Group Permissions ne correspondent pas au membership du Group sur un Produit ou un Type de produit. + +Si des utilisateurs créent un nouveau Group, ils se voient attribuer par défaut le rôle Owner de ce nouveau Group. + +Pour plus d'informations sur les Configuration Permissions, consultez notre **[Tableau des Configuration Permissions](../user_permission_chart/#configuration-permission-chart)**. + +## Gérer les autorisations par défaut + +Lorsqu'un tout nouvel utilisateur est créé dans DefectDojo — que ce soit manuellement, via SAML / SSO, ou via un fournisseur social-auth — il **ne dispose d'aucune autorisation par défaut**. Il ne verra aucun Type de produit, aucun Produit et aucun Engagement lors de sa première connexion. Il ne peut consulter ni interagir avec aucune donnée tant qu'un Superuser ne lui a pas accordé l'accès (directement, via un Global Role, via un membership Produit / Type de produit, ou en l'ajoutant à un Group). + +Si vous souhaitez que chaque nouvel utilisateur provisionné reçoive automatiquement un niveau d'accès de base — par exemple, « chaque nouvel utilisateur SSO doit être Reader sur un groupe particulier » — vous pouvez configurer un **Default group** sur la page System Settings. + +1. Ouvrez **⚙️ Configuration → System Settings** (réservé aux Superusers). +2. Définissez **Default group** sur le [User Group](../create_user_group/) que les utilisateurs nouvellement créés doivent rejoindre. +3. Définissez **Default group role** sur le rôle qu'ils doivent détenir dans ce groupe (par exemple **Reader**). +4. Définissez éventuellement **Default group email pattern** avec une expression régulière (par exemple `.*@yourcompany\.com$`) afin que le groupe par défaut ne s'applique qu'aux utilisateurs dont l'e-mail correspond. +5. Enregistrez. + +**Default group** et **Default group role** doivent tous deux être définis — si l'un des deux est vide, le groupe par défaut n'est pas appliqué. + +Ce paramètre s'applique à tous les chemins de création d'utilisateur : création manuelle, SAML, OAuth et autres fournisseurs social-auth. Il n'est pas appliqué rétroactivement — les utilisateurs existants conservent leurs memberships de groupe actuels même si vous modifiez ce paramètre ultérieurement. + +Pour des conseils spécifiques au SSO, consultez [Configuration SAML](/admin/sso/pro__saml/#default-access-for-sso-provisioned-users) ou la section de votre fournisseur sous [Configuration SSO](../configure_sso/). diff --git a/docs/content/admin/user_management/about_perms_and_roles.ja.md b/docs/content/admin/user_management/about_perms_and_roles.ja.md new file mode 100644 index 00000000000..f21d84fd314 --- /dev/null +++ b/docs/content/admin/user_management/about_perms_and_roles.ja.md @@ -0,0 +1,119 @@ +--- +title: DefectDojoにおける権限 +description: DefectDojo Proのすべての権限オプションの詳細なまとめ +weight: 2 +audience: pro +aliases: +- /ja/en/customize_dojo/user_management/about_perms_and_roles +--- + +> **DefectDojo Pro機能。** このページで説明しているメンバー/グループ/グローバルロールのRBACシステムは、DefectDojo Proの機能です。オープンソース版のDefectDojoは[認可済みユーザー](../os__authorized_users/)モデルを使用しています。オープンソース版のアクセス制御についてはそちらのページを、エディション間を移行する場合は[3.0アップグレードノート](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization)を参照してください。 + +DefectDojoで作業するユーザーのチームがいる場合、ユーザーが特定のデータにのみアクセスできるように、ロールベースアクセス制御(RBAC)を適切に設定することが重要です。セキュリティデータは非常にセンシティブであり、DefectDojoのアクセス制御オプションを使えば、各チームメンバーの情報アクセスを細かく指定できます。 + +この記事では、DefectDojoにおける権限の仕組みの概要を説明します。権限によって制御できる**各操作**の詳細な内訳を確認したい場合は、**[権限チャート](../user_permission_chart/)**の記事を参照してください。 + +## 権限の種類 + +DefectDojoは4種類の権限を管理しています。 + +* ユーザーは**Product**または**Product Type**に**メンバー**として割り当てることができます。Productのメンバーシップには**ロール**が付属しており、これによりユーザーはDefectDojo内のデータタイプ(Product Type、Product、Engagement、Test、Finding)を閲覧・操作できます。ユーザーは複数のProductまたはProduct Typeのメンバーシップを持つことができ、それぞれ異なるレベルのアクセス権を設定できます。 +​ +* ユーザーには**設定権限**を割り当てることもでき、これによりDefectDojoの設定ページにアクセスできるようになります。設定権限はProductやProduct Typeとは関連がなく、ロールとも紐づいていません。 +​ +* ユーザーには**グローバルロール**を割り当てることができ、これによりすべてのProductとProduct Typeに対して標準化されたレベルのアクセス権が付与されます。 +​ +* ユーザーは**スーパーユーザー**として設定できます。これは、DefectDojoのすべてのデータと設定に対する管理と操作を可能にする、管理者レベルのロールです。 + +これらの権限タイプはいずれも、**ユーザーグループ**に割り当てることも可能です。特定のProduct専用のテストチームなど、DefectDojo内に多数のユーザーがいる場合、グループを使うことで権限をすばやく設定・維持できます。 + +## Product/Product Typeのメンバーシップとロール + +ユーザーがProductまたはProduct Typeのメンバーとして割り当てられると、関連するFindingデータをどのように操作できるかを制御するロールも同時に付与されます。 + +### ロールの概要 + +DefectDojo Proには5つの**組み込みロール**が用意されています: Reader、Writer、Maintainer、Owner、API Importerです。これらはいずれも、グローバルに、またはProduct/Product Type単位で割り当てることができます。 + +組み込みロールは固定のプリセットです。編集や削除はできず、権限の内容はすべてのDefectDojo Proインスタンスで共通です。どれもチームの運用に合わない場合は、個別の権限を選択するか、組み込みロールを複製して調整することで、独自のロールを作成できます。[カスタムRBACロール](../pro__custom_rbac_roles/)を参照してください。 + +「基盤となるデータ」とは、ProductまたはProduct Typeの配下にあるすべてのProduct、Engagement、Test、Finding、Endpointを指します。 + +* **Reader**ユーザーは、割り当てられたProductまたはProduct Typeの基盤となるデータを閲覧し、コメントを追加できます。基盤となるデータの編集、追加、その他の変更はできませんが、レポートのエクスポートやデータへのメモの追加は可能です。 +​ +* **Writer**ユーザーは、Readerのすべての機能に加えて、Engagement、Test、Findingの追加・編集が可能です。新しいProductを追加することはできず、基盤となるデータの削除もできません。 +​ +* **Maintainer**ユーザーは、Writerのすべての機能に加えて、ProductまたはProduct Typeの編集が可能です。ProductまたはProduct Typeに対して、ロールを持つ新しいメンバーを追加でき、Engagement、Test、Findingの削除も可能です。 +​ +* **Owner**ユーザーは、ProductまたはProduct Typeに対して最も強い権限を持ちます。他のOwnerを指定でき、割り当てられたProductまたはProduct Type自体を削除することもできます。 +​ +* **API Importer**ユーザーの権限は限定的です。このロールは、APIエンドポイントの大部分を公開することなく限定的なAPIアクセスを許可するため、自動化や、DefectDojoに対して「外部」となることを意図したユーザーに有用です。基盤となるデータの閲覧、Engagementの追加・編集、スキャンデータのインポートが可能です。 + +組み込みロールの詳細については、**[ロール権限チャート](../user_permission_chart/)**を参照してください。ロールに付与できる権限の全リストと、独自のロールの作り方については、**[カスタムRBACロール](../pro__custom_rbac_roles/)**を参照してください。 + +### グローバルロール + +**グローバルロール**を持つユーザーは、割り当てられたロールに応じて、DefectDojo内のあらゆるデータタイプ(Product Type、Product、Engagement、Test、Finding)を閲覧・操作できます。 + +### グループメンバーシップ + +ユーザーグループは、ProductまたはProduct Typeのメンバーとして追加できます。グループに属するユーザーは、そのグループに関連付けられたすべてのProductまたはProduct Typeへのアクセス権と、グループに割り当てられたロールを継承します。 + +#### 複数のロールを持つユーザー + +* ユーザーがProductのメンバーとして割り当てられても、デフォルトでは関連するProduct Typeの権限は付与されません。 + +* 同じProductまたはProduct Type上でユーザーが複数のロールを持つことになった場合(例えば、直接割り当てられたロールとグループから継承したロールがある場合)、そのユーザーはそこで保持するすべてのロールの権限を**合算**して受け取ります。 + +* ユーザーのProductロールは、常に「デフォルト」のProduct Typeロールに優先します。 +​ +* ユーザーのProduct/Product Typeロールは、その基盤となるProductまたはProduct Type内において、常にグローバルロールに優先します。例えば、あるユーザーがProduct TypeロールとしてReaderを持っていても、そのProduct Type配下のあるProductにOwnerとして割り当てられている場合、そのProductに限り追加のOwner権限が付与されます。 +​ +* ロールは権限を取り除くことはできず、追加することしかできません。例えば、あるユーザーがProduct TypeロールまたはグローバルロールとしてOwnerを持っている場合、特定のProductにReaderロールを割り当てても、そのProductにおけるOwner権限が失われることはありません。 +​ +* スーパーユーザーのステータスは、割り当てられたどのロールよりも常に優先されます。 + +## スーパーユーザー + +スーパーユーザー(管理者)にはシステム上の制限が一切ありません。すべての設定を変更し、ユーザーを管理し、すべてのデータへの読み取り/書き込みアクセス権を持ちます。DefectDojoの全ユーザーに対するアクセスルールを変更することもできます。また、スーパーユーザーはすべてのシステム上の問題やアラートに関する通知も受け取ります。 + +デフォルトでは、新しいDefectDojoインスタンスで最初に作成されたアカウントがスーパーユーザー権限を持ちます。そのユーザーは、それ以降に作成されるすべてのDefectDojoユーザーの権限を編集できます。新たなスーパーユーザーの追加や、ユーザーへのグローバルロールの追加は、既存のスーパーユーザーのみが行えます。 + + +## 設定権限 + +設定権限は似てはいますが、Productやロールとは関連がありません。ロールとは別に割り当てる必要があります。**通常のユーザーにはデフォルトで設定権限が一切付与されておらず、これらの設定権限の割り当ては慎重に行う必要があります。** + +ユーザーへの設定権限の割り当ては、いくつかの方法で行えます。 + +1. ユーザーに直接、設定権限を割り当てることができます。特定の権限は、ユーザーページで直接設定できます。 + +2. ユーザーグループに設定権限を割り当てることができます。ロールと同様に、特定の設定権限をグループに追加すると、そのグループの全メンバーにこれらの権限が付与されます。 + +スーパーユーザーはすべての設定権限を持つため、ユーザーページに設定権限セクションは表示されません。 + +### グループの設定権限 + +ユーザーがグループに属している場合、そのグループの設定へのアクセスレベルを制御するグループ設定権限も持つことになります。グループ権限は、グループのProductまたはProduct Typeのメンバーシップとは対応していません。 + +ユーザーが新しいグループを作成すると、デフォルトでその新しいグループのOwnerロールが付与されます。 + +設定権限の詳細については、**[設定権限チャート](../user_permission_chart/#configuration-permission-chart)**を参照してください。 + +## デフォルトの権限を管理する + +DefectDojoで新規ユーザーが作成されると(手動作成、SAML/SSO経由、または任意のソーシャル認証プロバイダー経由のいずれであっても)、そのユーザーには**デフォルトで権限が一切ありません**。初回ログイン時には、Product Type、Product、Engagementのいずれも0件として表示されます。スーパーユーザーがアクセス権を付与するまで(直接、グローバルロール経由、Product/Product Typeのメンバーシップ経由、またはグループへの追加のいずれかによって)、どのデータも閲覧・操作できません。 + +新規に作成されたすべてのユーザーに、自動的にベースラインのアクセス権を付与したい場合(例えば「新規SSOユーザーは全員、特定のグループのReaderにする」など)、System Settingsページで**デフォルトグループ**を設定できます。 + +1. **⚙️ Configuration → System Settings**を開きます(スーパーユーザーのみ)。 +2. **デフォルトグループ**に、新規作成されたユーザーが参加すべき[ユーザーグループ](../create_user_group/)を設定します。 +3. **デフォルトグループロール**に、そのグループでユーザーが持つべきロール(例: **Reader**)を設定します。 +4. 必要に応じて、**デフォルトグループのメールパターン**に正規表現(例: `.*@yourcompany\.com$`)を設定すると、メールアドレスが一致するユーザーにのみデフォルトグループが適用されます。 +5. 保存します。 + +**デフォルトグループ**と**デフォルトグループロール**はどちらも設定する必要があります。いずれかが空の場合、デフォルトグループは適用されません。 + +この設定は、手動作成、SAML、OAuth、その他のソーシャル認証プロバイダーなど、すべてのユーザー作成経路に適用されます。これは遡って適用されるものではありません。既存のユーザーは、この設定を後で変更しても、現在のグループメンバーシップをそのまま維持します。 + +SSO固有のガイダンスについては、[SAML設定](/admin/sso/pro__saml/#default-access-for-sso-provisioned-users)、またはお使いのプロバイダーのセクションについては[SSO設定](../configure_sso/)を参照してください。 diff --git a/docs/content/admin/user_management/create_user_group.de.md b/docs/content/admin/user_management/create_user_group.de.md new file mode 100644 index 00000000000..b4a79457e30 --- /dev/null +++ b/docs/content/admin/user_management/create_user_group.de.md @@ -0,0 +1,137 @@ +--- +title: 'Berechtigungen teilen: Benutzergruppen' +description: Berechtigungen für viele Benutzer in DefectDojo Pro teilen und pflegen +weight: 3 +audience: pro +aliases: +- /de/en/customize_dojo/user_management/create_user_group +--- + +> **DefectDojo-Pro-Funktion.** Benutzergruppen und das zugrunde liegende RBAC-System sind Teil von DefectDojo Pro. Open-Source-DefectDojo verwendet das Modell der [Autorisierten Benutzer](../os__authorized_users/) — dort finden Sie Informationen zur Zugriffskontrolle in der Open-Source-Version, sowie die [Hinweise zum 3.0-Upgrade](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization), falls Sie zwischen den Editionen wechseln. + +Wenn Sie eine erhebliche Anzahl an DefectDojo-Benutzern haben, möchten Sie möglicherweise eine oder mehrere **Gruppen** erstellen, um für viele Benutzer gleichzeitig dieselben Regeln der rollenbasierten Zugriffskontrolle (RBAC) festzulegen. Nur Superuser können Benutzergruppen erstellen. + +Gruppen können auf verschiedene Weise eingesetzt werden: + +* Legen Sie eine oder mehrere verschiedene Rollen auf Produkt- oder Produkttyp-Ebene für alle Gruppenmitglieder fest, um genau zu steuern, auf welche Produkte oder Produkttypen die Gruppe zugreifen und welche sie bearbeiten kann. +* Legen Sie eine globale Rolle für alle Gruppenmitglieder fest, die ihnen Einsicht in und Zugriff auf alle Produkte oder Produkttypen gibt. +* Legen Sie Konfigurationsberechtigungen für eine Gruppe fest, die es ihr ermöglichen, bestimmte Funktionen in DefectDojo zu ändern. + +Weitere Informationen zu Rollen finden Sie in unserem Artikel **Introduction To Roles**. + +## Die Seite „All Groups“ + +Navigieren Sie in der Seitenleiste zu 👤**Users \> Groups**, um eine Liste aller aktiven und inaktiven Benutzergruppen anzuzeigen. + +![Bild](images/Create_a_User_Group_for_shared_permissions.png) +Von hier aus können Sie Ihre einzelnen Gruppenseiten erstellen, löschen oder anzeigen. + +Für DefectDojo Pro-Benutzer bietet die Seite „All Groups“ der Pro-Benutzeroberfläche einige zusätzliche Optionen. +* Sie können diese Tabelle nach Gruppenname, Beschreibung, E-Mail-Adresse, globaler Rolle sowie der Gesamtzahl der mit der Gruppe verknüpften Benutzer, Produkttypen und Produkte filtern. +* Sie können außerdem die Berechtigungen oder andere Einstellungen einer Gruppe anpassen, indem Sie auf die Schaltfläche „⋮“ neben der zu bearbeitenden Gruppe klicken. + +![Bild](images/all_groups_pro.png) + +## Eine Gruppe anzeigen + +Beim Anzeigen einer Gruppe werden alle Gruppeninformationen angezeigt, etwa ID, Name, Beschreibung, globale Rolle usw. Außerdem werden die Gruppenmitglieder sowie die mit der Gruppe verknüpften Produkttypen und Produkte angezeigt. Zusätzlich können die mit einer Gruppe verbundenen Konfigurationsberechtigungen direkt auf der Seite „View Group“ aktualisiert werden. + +Für DefectDojo Pro-Benutzer ermöglicht die Gruppenansicht der Pro-Benutzeroberfläche, Anpassungen der Konfigurationsberechtigungen auf leicht abweichende Weise vorzunehmen. + +![Bild](images/group_view_pro_ui.png) + +* Alle Konfigurationsberechtigungen werden in einem Dropdown-Menü angezeigt, das in Unterkategorien gegliedert ist. Wenn sich die Auswahl der Konfigurationsberechtigungen von ihrem aktuellen Wert unterscheidet, wird eine Schaltfläche „Update Configuration Permissions“ angezeigt. + +![Bild](images/groups_pro_configuration_permissions.png) + +* Sobald einige zusätzliche Berechtigungen ausgewählt wurden, wird der Benutzer gebeten zu bestätigen, dass er die Berechtigungen für die ausgewählte Gruppe aktualisieren möchte, bevor die Aktualisierung durchgeführt wird. + +## Eine Benutzergruppe erstellen/bearbeiten + +1. Navigieren Sie in der Seitenleiste zur Seite 👤**Users \> Groups**. Sie sehen eine Liste aller vorhandenen Benutzergruppen, einschließlich ihres Namens, ihrer Beschreibung, der Anzahl der Benutzer, der globalen Rolle (falls zutreffend) und der E-Mail-Adresse. + +![Bild](images/Create_a_User_Group_for_shared_permissions_2.png) + +2. Klicken Sie auf die Schaltfläche **🛠️** neben der Überschrift „All Groups“ und wählen Sie **+ New Group**. + +![Bild](images/Create_a_User_Group_for_shared_permissions_3.png) + +3. Dadurch gelangen Sie auf eine Seite, auf der Sie eine neue Gruppe erstellen können. Legen Sie den Namen für diese Gruppe fest und fügen Sie bei Bedarf eine Beschreibung hinzu. + +Sie können bei Bedarf auch eine globale Rolle auswählen, die Sie auf diese Gruppe anwenden möchten. Das Hinzufügen einer globalen Rolle zur Gruppe gibt allen Gruppenmitgliedern Zugriff auf alle DefectDojo-Daten, zusammen mit einem begrenzten Bearbeitungszugriff, abhängig von der gewählten globalen Rolle. Weitere Informationen finden Sie in unserem Artikel **Introduction To Roles**. + +Das Konto, das eine Gruppe ursprünglich erstellt, erhält standardmäßig die Rolle Owner für diese Gruppe. + +### E-Mail-Adresse für den Berichtsversand festlegen + +Der Weekly Digest ist ein Bericht über alle der Gruppe zugewiesenen Produkte/Produkttypen. Um einen wöchentlichen Digest versenden zu lassen, geben Sie im Formular zum Erstellen/Bearbeiten der Gruppe die gewünschte Ziel-E-Mail-Adresse ein. Gruppenmitglieder erhalten weiterhin wie gewohnt Benachrichtigungen. + +### Eine Gruppenseite anzeigen + +Sobald Sie eine Gruppe erstellt haben, können Sie darauf zugreifen, indem Sie sie im Menü unter **Users \> Groups** auswählen. + +Die Gruppenseite kann mit einer **Beschreibung** individuell gestaltet werden. Sie enthält eine Liste aller **Gruppenmitglieder** sowie der zugewiesenen **Produkte** und **Produkttypen** und der jeweils zugehörigen **Rolle**. + +Hier werden außerdem die **Konfigurationsberechtigungen** der Gruppe aufgeführt. + +## Die Benutzer einer Gruppe verwalten + +Die Gruppenmitgliedschaft wird auf der jeweiligen Gruppenseite verwaltet, die Sie aus der Liste auf der Seite **Users \> Groups** auswählen können. Klicken Sie auf den hervorgehobenen Gruppennamen, um auf die Gruppenseite zuzugreifen, die Sie bearbeiten möchten. + +Um die Mitgliedschaft einer Gruppe anzuzeigen oder zu bearbeiten, muss ein Benutzer über die entsprechenden aktivierten Konfigurationsberechtigungen sowie eine Mitgliedschaft in der Gruppe (oder Superuser-Status) verfügen. + +### **Einen Benutzer zu einer Gruppe hinzufügen** + +Benutzergruppen können beliebig viele Benutzer zugewiesen bekommen. Alle Benutzer einer Gruppe erhalten die zugehörige Rolle für jedes aufgeführte Produkt oder jeden Produkttyp, Benutzer können jedoch auch individuelle Rollen haben, die die Gruppenrolle überschreiben. + +1. Wählen Sie auf der Gruppenseite über die Schaltfläche **☰** am Rand der Überschrift **Members** die Option **+ Add Users**. + +![Bild](images/Create_a_User_Group_for_shared_permissions_4.png) + +2. Dadurch gelangen Sie zum Bildschirm **Add Some Group Members**. Öffnen Sie das Dropdown-Menü Users und wählen Sie jeden Benutzer aus, den Sie der Gruppe hinzufügen möchten. + +![Bild](images/Create_a_User_Group_for_shared_permissions_5.png) + +3. Wählen Sie die Gruppenrolle, die Sie diesen Benutzern zuweisen möchten. Diese bestimmt ihre Möglichkeit, die Gruppe zu konfigurieren. + +Beachten Sie, dass das Hinzufügen eines Mitglieds zu einer Gruppe ihm standardmäßig keinen Zugriff auf die eigene Gruppenseite gewährt. Dies ist eine separate Konfigurationsberechtigung, die zuerst aktiviert werden muss. + +### **Ein Mitglied einer Benutzergruppe bearbeiten oder löschen** + +1. Wählen Sie auf der Gruppenseite das ⋮ neben dem Namen des Benutzers, den Sie bearbeiten oder aus der Gruppe löschen möchten. + +**📝 Edit** führt Sie zum Bildschirm Edit Member, auf dem Sie die Rolle dieses Benutzers ändern können (von Reader, Maintainer oder Owner zu einer anderen Option). + +**🗑️ Delete** entfernt die Mitgliedschaft eines Benutzers vollständig. Beiträge oder Änderungen, die der Benutzer am Produkt oder Produkttyp vorgenommen hat, werden dadurch nicht entfernt. + +![Bild](images/Create_a_User_Group_for_shared_permissions_6.png) + +## Die Berechtigungen einer Gruppe verwalten + +Gruppenberechtigungen werden auf der jeweiligen Gruppenseite verwaltet, die Sie aus der Liste auf der Seite **Users \> Groups** auswählen können. Klicken Sie auf den hervorgehobenen Gruppennamen, um auf die Gruppenseite zuzugreifen, die Sie bearbeiten möchten. + +Beachten Sie, dass nur Superuser die Berechtigungen einer Gruppe (Produkt/Produkttyp oder Konfiguration) bearbeiten können. + +### **Produktrollen oder Produkttyprollen für eine Gruppe hinzufügen** + +Sie können jeder Gruppe beliebig viele Produktrollen oder Produkttyprollen zuweisen. + +1. Wählen Sie auf der Gruppenseite unter der entsprechenden Überschrift (Product Type Groups oder Product Groups) **+ Add Product Types** oder **+ Add Product**. + +![Bild](images/Create_a_User_Group_for_shared_permissions_7.png) + +2. Dadurch gelangen Sie auf die Seite **Register New Products / Product Types**, auf der Sie über das Dropdown-Menü ein Produkt oder einen Produkttyp zum Hinzufügen auswählen können. + +![Bild](images/Create_a_User_Group_for_shared_permissions_8.png) + +3. Wählen Sie die Rolle aus, die alle Gruppenmitglieder für dieses spezielle Produkt oder diesen Produkttyp haben sollen. + +Gruppen können Produkten oder Produkttypen nicht ohne Rolle zugewiesen werden. Wenn Sie nicht sicher sind, welche Rolle eine Gruppe haben soll, ist Reader eine gute „Standard“-Option. So bleibt der Zustand Ihres Produkts sicher, bis Sie sich endgültig für die Gruppenrolle entschieden haben. + +### **Konfigurationsberechtigungen einer Gruppe zuweisen** + +Wenn die Mitglieder Ihrer Gruppe auf Konfigurationsfunktionen zugreifen und bestimmte Aspekte von DefectDojo steuern können sollen, können Sie diese Verantwortlichkeiten auf der Gruppenseite zuweisen. + +Weisen Sie über das Menü in der unteren rechten Ecke die Rechte View, Add, Edit oder Delete zu. Das Aktivieren einer Konfigurationsberechtigung gibt der Gruppe sofort Zugriff auf diese bestimmte Funktion. + +![Bild](images/Create_a_User_Group_for_shared_permissions_9.png) diff --git a/docs/content/admin/user_management/create_user_group.es.md b/docs/content/admin/user_management/create_user_group.es.md new file mode 100644 index 00000000000..7b3c680e629 --- /dev/null +++ b/docs/content/admin/user_management/create_user_group.es.md @@ -0,0 +1,137 @@ +--- +title: 'Compartir permisos: Grupos de usuarios' +description: Comparta y mantenga permisos para muchos usuarios en DefectDojo Pro +weight: 3 +audience: pro +aliases: +- /es/en/customize_dojo/user_management/create_user_group +--- + +> **Función de DefectDojo Pro.** Los Grupos de Usuarios y el sistema RBAC subyacente forman parte de DefectDojo Pro. DefectDojo de código abierto usa el modelo de [Usuarios Autorizados](../os__authorized_users/); consulte esa página para conocer el control de acceso de código abierto, y las [notas de actualización de la versión 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si está migrando entre ediciones. + +Si tiene una cantidad significativa de usuarios de DefectDojo, es posible que desee crear uno o más **Grupos**, con el fin de establecer las mismas reglas de Control de Acceso Basado en Roles (RBAC) para muchos usuarios simultáneamente. Solo los Superusuarios pueden crear Grupos de Usuarios. + +Los Grupos pueden funcionar de varias formas: + +* Establecer uno o varios Roles a nivel de Producto o Tipo de Producto para todos los Miembros del Grupo, lo que permite un control específico sobre qué Productos o Tipos de Producto puede acceder y editar el Grupo. +* Establecer un Rol Global para todos los Miembros del Grupo, otorgándoles visibilidad y acceso a todos los Productos o Tipos de Producto. +* Establecer Permisos de Configuración para un Grupo, permitiéndoles cambiar funcionalidades específicas de DefectDojo. + +Para obtener más información sobre los Roles, consulte nuestro artículo **Introducción a los Roles**. + +## La página Todos los Grupos + +Desde la barra lateral, navegue a 👤**Usuarios > Grupos** para ver una lista de todos los grupos de usuarios activos e inactivos. + +![image](images/Create_a_User_Group_for_shared_permissions.png) +Desde aquí, puede crear, eliminar o ver sus páginas de Grupo individuales. + +Para los usuarios de DefectDojo Pro, la página Todos los Grupos de la interfaz Pro cuenta con algunas opciones adicionales. +* Puede filtrar esta tabla por Nombre de Grupo, Descripción, Dirección de correo electrónico, Rol Global, así como por el número total de Usuarios, Tipos de Producto y Productos asociados al Grupo. +* También puede ajustar los Permisos u otras configuraciones de un Grupo haciendo clic en el botón "⋮" junto al Grupo que desea editar. + +![image](images/all_groups_pro.png) + +## Ver un Grupo + +Al ver un grupo se muestra toda la información del Grupo, como ID, nombre, descripción, rol global, etc. También se muestran los Miembros del Grupo, los Tipos de Producto y los Productos asociados al grupo. Además, los permisos de configuración vinculados a un Grupo pueden actualizarse directamente desde la página "Ver Grupo". + +Para los usuarios de DefectDojo Pro, la vista de Grupo de la interfaz Pro permite asignar ajustes de Permisos de Configuración de una forma ligeramente distinta. + +![image](images/group_view_pro_ui.png) + +* Todos los permisos de configuración se muestran en un menú desplegable agrupado en subcategorías. Si la selección de permisos de configuración difiere de su valor actual, se muestra un botón "Actualizar Permisos de Configuración". + +![image](images/groups_pro_configuration_permissions.png) + +* Una vez seleccionados algunos permisos adicionales, se le pedirá al usuario que confirme si desea actualizar los permisos del grupo seleccionado antes de realizar la actualización. + +## Crear/Editar un Grupo de Usuarios + +1. Navegue a la página 👤**Usuarios > Grupos** en la barra lateral. Verá una lista de todos los Grupos de Usuarios existentes, incluyendo su Nombre, Descripción, Número de Usuarios, Rol Global (si corresponde) y Correo electrónico. + +![image](images/Create_a_User_Group_for_shared_permissions_2.png) + +2. Haga clic en el **botón 🛠️** junto al encabezado Todos los Grupos, y seleccione **+ Nuevo Grupo.** + +![image](images/Create_a_User_Group_for_shared_permissions_3.png) + +3. Esto lo llevará a una página donde puede crear un nuevo Grupo. Establezca el Nombre de este Grupo y agregue una Descripción si lo desea. + +También puede seleccionar un Rol Global que desee aplicar a este Grupo, si lo desea. Agregar un Rol Global al Grupo otorgará a todos los Miembros del Grupo acceso a todos los datos de DefectDojo, junto con una cantidad limitada de acceso de edición según el Rol Global que elija. Consulte nuestro artículo **Introducción a los Roles** para obtener más información. + +La cuenta que crea inicialmente un Grupo tendrá, por defecto, el Rol Owner para ese Grupo. + +### Establecer una dirección de correo electrónico para recibir informes + +El Resumen Semanal es un informe sobre todos los Productos / Tipos de Producto asignados al Grupo. Para que se envíe un Resumen semanal, ingrese la dirección de correo electrónico de destino que desea usar en el formulario Crear/Editar Grupo. Los miembros del Grupo seguirán recibiendo notificaciones como de costumbre. + +### Ver una página de Grupo + +Una vez que haya creado un Grupo, puede acceder a él seleccionándolo en el menú que se encuentra en **Usuarios > Grupos.** + +La página del Grupo puede personalizarse con una **Descripción**. Incluye una lista de todos los **Miembros del Grupo**, así como los **Productos y Tipos de Producto** asignados, y el **Rol** asociado a cada uno de ellos. + +Aquí también puede ver los **Permisos de Configuración** del Grupo. + +## Gestionar los Usuarios de un Grupo + +La Membresía del Grupo se gestiona desde la página individual del Grupo, que puede seleccionar en la lista de la página **Usuarios > Grupos**. Haga clic en el Nombre del Grupo resaltado para acceder a la página del Grupo que desea editar. + +Para ver o editar la Membresía de un Grupo, un Usuario debe tener habilitados los permisos de Configuración correspondientes, además de ser Miembro del Grupo (o tener estado de Superusuario). + +### **Agregar un Usuario a un Grupo** + +Los Grupos de Usuarios pueden tener tantos Usuarios asignados como desee. Todos los Usuarios de un Grupo recibirán el Rol asociado en cada Producto o Tipo de Producto listado, pero los Usuarios también pueden tener Roles Individuales que prevalecen sobre el rol del Grupo. + +1. Desde la página del Grupo, seleccione **+ Agregar Usuarios** en el botón **☰** ubicado en el extremo del encabezado **Miembros**. + +![image](images/Create_a_User_Group_for_shared_permissions_4.png) + +2. Esto lo llevará a la pantalla **Agregar algunos Miembros del Grupo**. Abra el menú desplegable de Usuarios y marque cada usuario que desee agregar al Grupo. + +![image](images/Create_a_User_Group_for_shared_permissions_5.png) + +3. Seleccione el Rol de Grupo que desea asignar a estos Usuarios. Esto determina su capacidad para configurar el Grupo. + +Tenga en cuenta que agregar un miembro a un Grupo no le otorgará, por defecto, acceso a su propia página de Grupo. Se trata de un permiso de Configuración independiente que debe habilitarse primero. + +### **Editar o Eliminar un Miembro de un Grupo de Usuarios** + +1. Desde la página del Grupo, seleccione el ⋮ junto al Nombre del Usuario que desea Editar o Eliminar del Grupo. + +**📝 Edit** lo llevará a la pantalla Editar Miembro, donde puede cambiar el Rol de este usuario (de Reader, Maintainer u Owner a otra opción). + +**🗑️ Delete** elimina por completo la Membresía de un Usuario. No eliminará ninguna contribución ni cambio que el Usuario haya realizado en el Producto o Tipo de Producto. + +![image](images/Create_a_User_Group_for_shared_permissions_6.png) + +## Gestionar los Permisos de un Grupo + +Los Permisos del Grupo se gestionan desde la página individual del Grupo, que puede seleccionar en la lista de la página **Usuarios > Grupos**. Haga clic en el Nombre del Grupo resaltado para acceder a la página del Grupo que desea editar. + +Tenga en cuenta que solo los Superusuarios pueden editar los permisos de un Grupo (de Producto / Tipo de Producto, o de Configuración). + +### **Agregar Roles de Producto o Roles de Tipo de Producto para un Grupo** + +Puede registrar tantos Roles de Producto o Roles de Tipo de Producto como desee en cada Grupo. + +1. Desde la página del Grupo, seleccione **+ Agregar Tipos de Producto**, o **+ Agregar Producto** en el encabezado correspondiente (Grupos de Tipo de Producto o Grupos de Producto). + +![image](images/Create_a_User_Group_for_shared_permissions_7.png) + +2. Esto lo llevará a una página **Registrar nuevos Productos / Tipos de Producto**, donde puede seleccionar un Producto o Tipo de Producto para agregar desde el menú desplegable. + +![image](images/Create_a_User_Group_for_shared_permissions_8.png) + +3. Seleccione el Rol que desea que tengan todos los miembros del Grupo respecto a este Producto o Tipo de Producto en particular. + +Los Grupos no pueden asignarse a Productos o Tipos de Producto sin un Rol. Si no está seguro de qué Rol desea que tenga un Grupo, Reader es una buena opción "predeterminada". Esto mantendrá el estado de su Producto seguro hasta que tome la decisión final sobre el Rol del Grupo. + +### **Asignar Permisos de Configuración a un Grupo** + +Si desea que los Miembros de su Grupo accedan a funciones de Configuración y controlen ciertos aspectos de DefectDojo, puede asignar estas responsabilidades desde la página del Grupo. + +Asigne los roles Ver, Agregar, Editar o Eliminar desde el menú en la esquina inferior derecha. Marcar un Permiso de Configuración otorgará de inmediato al Grupo acceso a esa función en particular. + +![image](images/Create_a_User_Group_for_shared_permissions_9.png) diff --git a/docs/content/admin/user_management/create_user_group.fr.md b/docs/content/admin/user_management/create_user_group.fr.md new file mode 100644 index 00000000000..d0d6dc950ae --- /dev/null +++ b/docs/content/admin/user_management/create_user_group.fr.md @@ -0,0 +1,139 @@ +--- +title: 'Partager les autorisations : groupes d''utilisateurs' +description: Partager et maintenir les autorisations pour de nombreux utilisateurs + dans DefectDojo Pro +weight: 3 +audience: pro +aliases: +- /fr/en/customize_dojo/user_management/create_user_group +--- + +> **Fonctionnalité DefectDojo Pro.** Les User Groups et le système RBAC sous-jacent font partie de DefectDojo Pro. DefectDojo Open-Source utilise le modèle [Authorized Users](../os__authorized_users/) — consultez cette page pour le contrôle d'accès en Open-Source, ainsi que les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si vous passez d'une édition à l'autre. + +Si vous avez un nombre important d'utilisateurs DefectDojo, vous pouvez souhaiter créer un ou plusieurs **Groups**, afin de définir les mêmes règles de contrôle d'accès basé sur les rôles (RBAC) pour de nombreux utilisateurs simultanément. Seuls les Superusers peuvent créer des User Groups. + +Les Groups peuvent fonctionner de plusieurs manières : + +* Définir un ou plusieurs Roles au niveau Produit ou Type de produit pour tous les Group Members, permettant un contrôle précis des Produits ou Types de produit accessibles et modifiables par le Group. +* Définir un Global Role pour tous les Group Members, leur donnant une visibilité et un accès à tous les Produits ou Types de produit. +* Définir des Configuration Permissions pour un Group, leur permettant de modifier des fonctionnalités spécifiques de DefectDojo. + +Pour plus d'informations sur les Roles, veuillez consulter notre article **Introduction aux rôles**. + +## La page Tous les groupes + +Depuis la barre latérale, accédez à 👤**Utilisateurs \> Groupes** pour voir la liste de tous les groupes d'utilisateurs actifs et inactifs. + +![image](images/Create_a_User_Group_for_shared_permissions.png) +Depuis cet écran, vous pouvez créer, supprimer ou consulter vos pages de Groupe individuelles. + +Pour les utilisateurs DefectDojo Pro, la page Tous les groupes de l'interface Pro propose quelques options supplémentaires. +* Vous pouvez filtrer ce tableau par nom de groupe, description, adresse e-mail, Global Role, ainsi que par le nombre total d'Utilisateurs, de Types de produit et de Produits associés au Groupe. +* Vous pouvez également ajuster les autorisations d'un Groupe ou d'autres paramètres en cliquant sur le bouton « ⋮ » à côté du Groupe que vous souhaitez modifier. + +![image](images/all_groups_pro.png) + +## Consulter un groupe + +La consultation d'un groupe affiche toutes ses informations : ID, nom, description, Global Role, etc. Les Group Members, Types de produit et Produits associés au groupe sont également affichés. De plus, les Configuration Permissions liées à un Groupe peuvent être mises à jour directement depuis la page « View Group ». + +Pour les utilisateurs DefectDojo Pro, la vue Groupe de l'interface Pro vous permet d'ajuster les Configuration Permissions d'une manière légèrement différente. + +![image](images/group_view_pro_ui.png) + +* Toutes les Configuration Permissions sont affichées dans un menu déroulant regroupé en sous-catégories. Si la sélection des Configuration Permissions diffère de leur valeur actuelle, un bouton « Update Configuration Permissions » s'affiche. + +![image](images/groups_pro_configuration_permissions.png) + +* Une fois quelques autorisations supplémentaires sélectionnées, il sera demandé à l'utilisateur de confirmer qu'il souhaite mettre à jour les autorisations du groupe sélectionné avant que la mise à jour ne soit effectuée. + +## Créer / modifier un groupe d'utilisateurs + +1. Accédez à la page 👤**Utilisateurs \> Groupes** dans la barre latérale. Vous verrez une liste de tous les groupes d'utilisateurs existants, avec leur nom, description, nombre d'utilisateurs, Global Role (le cas échéant) et e-mail. +​ +![image](images/Create_a_User_Group_for_shared_permissions_2.png) + +2. Cliquez sur le **bouton 🛠️** à côté du titre Tous les groupes, puis sélectionnez **\+ Nouveau groupe.** +​ +![image](images/Create_a_User_Group_for_shared_permissions_3.png) + + +3. Vous accédez alors à une page où vous pouvez créer un nouveau Groupe. Définissez le nom de ce Groupe, et ajoutez une description si vous le souhaitez. + +Vous pouvez également sélectionner un Global Role que vous souhaitez appliquer à ce Groupe, si vous le désirez. L'ajout d'un Global Role au Groupe donnera à tous les Group Members l'accès à toutes les données DefectDojo, ainsi qu'un accès en modification limité selon le Global Role choisi. Consultez notre article **Introduction aux rôles** pour plus d'informations. + +Le compte qui crée initialement un Groupe se voit attribuer par défaut le Role Owner pour ce Groupe. + +### Définir une adresse e-mail pour recevoir les rapports + +Le Weekly Digest est un rapport portant sur tous les Produits / Types de produit assignés au Groupe. Pour recevoir un Weekly Digest, saisissez l'adresse e-mail de destination que vous souhaitez utiliser dans le formulaire de création/modification du Groupe. Les membres du Groupe continueront de recevoir les notifications comme d'habitude. + +### Consulter la page d'un groupe + +Une fois que vous avez créé un Groupe, vous pouvez y accéder en le sélectionnant dans le menu **Utilisateurs \> Groupes.** + +La page du Groupe peut être personnalisée avec une **Description**. Elle affiche la liste de tous les **Group Members**, ainsi que les **Produits** et **Types de produit** attribués, et le **Role** associé à chacun d'eux**.** + +Vous pouvez également y consulter les **Configuration Permissions** du Groupe. + +## Gérer les utilisateurs d'un groupe + +Le Group Membership se gère depuis la page individuelle du Groupe, accessible depuis la liste de la page **Utilisateurs \> Groupes**. Cliquez sur le nom du Groupe en surbrillance pour accéder à la page du Groupe que vous souhaitez modifier. + +Pour consulter ou modifier le Membership d'un Groupe, un User doit disposer des Configuration Permissions appropriées activées ainsi que d'un Membership dans le Groupe (ou du statut Superuser). + +### **Ajouter un utilisateur à un groupe** + +Les User Groups peuvent avoir autant d'Users assignés que vous le souhaitez. Tous les Users d'un Groupe se voient attribuer le Role associé à chaque Produit ou Type de produit listé, mais les Users peuvent également avoir des Roles individuels qui priment sur le Role du Groupe. + +1. Depuis la page du Groupe, sélectionnez **\+ Add Users** dans le bouton **☰** situé au bord du titre **Members**. +​ +![image](images/Create_a_User_Group_for_shared_permissions_4.png) + +2. Vous accédez alors à l'écran **Add Some Group Members**. Ouvrez le menu déroulant Users, puis cochez chaque utilisateur que vous souhaitez ajouter au Groupe. +​ +![image](images/Create_a_User_Group_for_shared_permissions_5.png) + +3. Sélectionnez le Group Role que vous souhaitez attribuer à ces Users. Cela détermine leur capacité à configurer le Groupe. + +Notez que l'ajout d'un membre à un Groupe ne lui donne pas accès par défaut à sa propre page de Groupe. Il s'agit d'une Configuration Permission distincte qui doit être activée au préalable. + +### **Modifier ou supprimer un membre d'un groupe d'utilisateurs** + +1. Depuis la page du Groupe, sélectionnez le ⋮ à côté du nom de l'User que vous souhaitez modifier ou supprimer du Groupe. + +**📝 Edit** vous amène à l'écran Edit Member, où vous pouvez modifier le Role de cet utilisateur (de Reader, Maintainer ou Owner vers un autre choix). + +**🗑️ Delete** supprime entièrement le Membership de l'User. Cela ne supprime pas les contributions ou modifications que l'User a apportées au Produit ou au Type de produit. + +![image](images/Create_a_User_Group_for_shared_permissions_6.png) + +## Gérer les autorisations d'un groupe + +Les Group Permissions se gèrent depuis la page individuelle du Groupe, accessible depuis la liste de la page **Utilisateurs \> Groupes**. Cliquez sur le nom du Groupe en surbrillance pour accéder à la page du Groupe que vous souhaitez modifier. + +Notez que seuls les Superusers peuvent modifier les autorisations d'un Groupe (Produit / Type de produit, ou Configuration). +​ +### **Ajouter des Roles Produit ou des Roles Type de produit pour un groupe** + +Vous pouvez enregistrer autant de Roles Produit ou de Roles Type de produit que vous le souhaitez dans chaque Groupe. + +1. Depuis la page du Groupe, sélectionnez **\+ Add Product Types**, ou \+ **Add Product** dans le titre correspondant (Product Type Groups ou Product Groups). +​ +![image](images/Create_a_User_Group_for_shared_permissions_7.png) + +2. Vous accédez alors à une page **Register New Products / Product Types**, où vous pouvez sélectionner dans le menu déroulant un Produit ou un Type de produit à ajouter. + +![image](images/Create_a_User_Group_for_shared_permissions_8.png) + +3. Sélectionnez le Role que vous souhaitez que tous les membres du Groupe possèdent pour ce Produit ou ce Type de produit en particulier. + +Les Groupes ne peuvent pas être affectés à des Produits ou des Types de produit sans Role. Si vous ne savez pas quel Role attribuer à un Groupe, Reader constitue une bonne option « par défaut ». Cela permet de garder votre Produit sécurisé en attendant votre décision finale concernant le Group Role. + +### **Attribuer des Configuration Permissions à un groupe** + +Si vous souhaitez que les Members de votre Groupe accèdent aux fonctions de Configuration et contrôlent certains aspects de DefectDojo, vous pouvez attribuer ces responsabilités depuis la page du Groupe. + +Attribuez les rôles View, Add, Edit ou Delete depuis le menu situé dans le coin inférieur droit. Cocher une Configuration Permission donne immédiatement au Groupe l'accès à cette fonction particulière. + +![image](images/Create_a_User_Group_for_shared_permissions_9.png) diff --git a/docs/content/admin/user_management/create_user_group.ja.md b/docs/content/admin/user_management/create_user_group.ja.md new file mode 100644 index 00000000000..6849bf5361e --- /dev/null +++ b/docs/content/admin/user_management/create_user_group.ja.md @@ -0,0 +1,138 @@ +--- +title: '権限を共有する: ユーザーグループ' +description: DefectDojo Proで多数のユーザーの権限を共有・維持する +weight: 3 +audience: pro +aliases: +- /ja/en/customize_dojo/user_management/create_user_group +--- + +> **DefectDojo Pro機能。** ユーザーグループおよびその基盤となるRBACシステムは、DefectDojo Proの機能です。オープンソース版のDefectDojoは[認可済みユーザー](../os__authorized_users/)モデルを使用しています。オープンソース版のアクセス制御についてはそちらのページを、エディション間を移行する場合は[3.0アップグレードノート](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization)を参照してください。 + +DefectDojoのユーザー数が多い場合は、多数のユーザーに同じロールベースアクセス制御(RBAC)ルールを一括で設定するために、1つ以上の**グループ**を作成するとよいでしょう。ユーザーグループを作成できるのはスーパーユーザーのみです。 + +グループは複数の方法で機能します。 + +* すべてのグループメンバーに対して、1つまたは複数の異なるProductレベルまたはProduct TypeレベルのRoleを設定し、そのグループがどのProductまたはProduct Typeにアクセス・編集できるかを細かく制御できます。 +* すべてのグループメンバーにグローバルロールを設定し、すべてのProductまたはProduct Typeへの可視性とアクセス権を付与できます。 +* グループに設定権限を設定し、DefectDojoの特定機能を変更できるようにします。 + +ロールの詳細については、**Introduction To Roles**の記事を参照してください。 + +## The All Groupsページ + +サイドバーから👤**Users \> Groups**に移動すると、アクティブおよび非アクティブなすべてのユーザーグループの一覧が表示されます。 + +![image](images/Create_a_User_Group_for_shared_permissions.png) +ここから、個々のグループページの作成、削除、閲覧を行えます。 + +DefectDojo Proのユーザーの場合、Pro UIのAll Groupsにはいくつか追加のオプションがあります。 +* このテーブルは、グループ名、説明、メールアドレス、グローバルロールに加え、グループに関連付けられたユーザー数、Product Type数、Product数の合計でフィルタリングできます。 +* 編集したいグループの隣にある「⋮」ボタンをクリックすることで、グループの権限やその他の設定を調整することもできます。 + +![image](images/all_groups_pro.png) + +## グループを表示する + +グループを表示すると、ID、名前、説明、グローバルロールなど、グループのすべての情報が表示されます。また、そのグループに関連付けられたグループメンバー、Product Type、Productも表示されます。さらに、グループに紐づく設定権限は、「View Group」ページから直接更新できます。 + +DefectDojo Proのユーザーの場合、Pro UIのGroup Viewでは、設定権限の調整を少し異なる方法で割り当てることができます。 + +![image](images/group_view_pro_ui.png) + +* すべての設定権限は、サブカテゴリごとにグループ化されたドロップダウンに表示されます。選択した設定権限が現在の値と異なる場合、「Update Configuration Permissions」ボタンが表示されます。 + +![image](images/groups_pro_configuration_permissions.png) + +* いくつかの追加の権限を選択すると、更新を行う前に、選択したグループの権限を更新してよいかどうかの確認が求められます。 + +## ユーザーグループを作成/編集する + +1. サイドバーの👤**Users \> Groups**ページに移動します。名前、説明、ユーザー数、グローバルロール(該当する場合)、メールアドレスを含む、既存のすべてのユーザーグループの一覧が表示されます。 +​ +![image](images/Create_a_User_Group_for_shared_permissions_2.png) + +2. All Groupsの見出しの隣にある**🛠️ボタン**をクリックし、**\+ New Group**を選択します。 +​ +![image](images/Create_a_User_Group_for_shared_permissions_3.png) + + +3. これにより、新しいグループを作成できるページに移動します。このグループの名前を設定し、必要に応じて説明を追加します。 + +必要であれば、このグループに適用したいグローバルロールも選択できます。グループにグローバルロールを追加すると、すべてのグループメンバーに、選択したグローバルロールに応じた一定の編集アクセス権とともに、DefectDojoの全データへのアクセス権が付与されます。詳細については**Introduction To Roles**の記事を参照してください。 + +グループを最初に作成したアカウントには、デフォルトでそのグループのOwnerロールが付与されます。 + +### レポートを受け取るメールアドレスを設定する + +Weekly Digestは、グループに割り当てられたすべてのProduct/Product Typeに関するレポートです。Weekly Digestを送信するには、Create/Edit Groupフォームで使用したい送信先メールアドレスを入力します。グループメンバーは、これまでどおり通知を受け取り続けます。 + +### グループページを表示する + +グループを作成すると、**Users \> Groups**の下に表示されるメニューから選択してアクセスできます。 + +グループページは**説明**でカスタマイズできます。すべての**グループメンバー**、割り当てられた**Product、Product Type**、およびそれぞれに関連付けられた**ロール**の一覧が表示されます。 + +グループの**設定権限**もここに表示されます。 + +## グループのユーザーを管理する + +グループメンバーシップは、**Users \> Groups**ページの一覧から選択できる個々のグループページから管理します。編集したいグループページにアクセスするには、ハイライトされたグループ名をクリックします。 + +グループのメンバーシップを閲覧または編集するには、ユーザーが適切な設定権限を有効にしていることに加えて、そのグループのメンバーであること(またはスーパーユーザーのステータスを持つこと)が必要です。 + +### **グループにユーザーを追加する** + +ユーザーグループには、好きなだけ多くのユーザーを割り当てることができます。グループ内のすべてのユーザーには、記載された各ProductまたはProduct Typeに対応するロールが付与されますが、ユーザーはグループのロールに優先する個別のロールを持つこともできます。 + +1. グループページで、**Members**見出しの端にある**☰**ボタンから**\+ Add Users**を選択します。 +​ +![image](images/Create_a_User_Group_for_shared_permissions_4.png) + +2. これにより**Add Some Group Members**画面に移動します。Usersのドロップダウンメニューを開き、グループに追加したい各ユーザーにチェックを入れます。 +​ +![image](images/Create_a_User_Group_for_shared_permissions_5.png) + +3. これらのユーザーに割り当てたいグループロールを選択します。これにより、そのユーザーがグループを設定できる範囲が決まります。 + +グループにメンバーを追加しても、デフォルトではそのメンバー自身のグループページへのアクセス権は付与されない点に注意してください。これは別の設定権限であり、先に有効化しておく必要があります。 + +### **ユーザーグループのメンバーを編集/削除する** + +1. グループページで、グループから編集または削除したいユーザーの名前の隣にある⋮を選択します。 + +**📝 Edit**を選択すると編集画面に移動し、そのユーザーのロール(Reader、Maintainer、Ownerから別の選択肢へ)を変更できます。 + +**🗑️ Delete**は、ユーザーのメンバーシップを完全に削除します。そのユーザーがProductまたはProduct Typeに対して行った貢献や変更が削除されることはありません。 + +![image](images/Create_a_User_Group_for_shared_permissions_6.png) + +## グループの権限を管理する + +グループの権限は、**Users \> Groups**ページの一覧から選択できる個々のグループページから管理します。編集したいグループページにアクセスするには、ハイライトされたグループ名をクリックします。 + +グループの権限(Product/Product Type、または設定権限)を編集できるのはスーパーユーザーのみである点に注意してください。 +​ +### **グループにProductロールまたはProduct Typeロールを追加する** + +各グループには、好きなだけ多くのProductロールまたはProduct Typeロールを登録できます。 + +1. グループページで、該当する見出し(Product Type GroupsまたはProduct Groups)から**\+ Add Product Types**または\+ **Add Product**を選択します。 +​ +![image](images/Create_a_User_Group_for_shared_permissions_7.png) + +2. これにより**Register New Products / Product Types**ページに移動し、ドロップダウンメニューから追加したいProductまたはProduct Typeを選択できます。 + +![image](images/Create_a_User_Group_for_shared_permissions_8.png) + +3. この特定のProductまたはProduct Typeについて、すべてのグループメンバーに持たせたいロールを選択します。 + +ロールなしでグループをProductまたはProduct Typeに割り当てることはできません。グループにどのロールを持たせるか迷った場合は、Readerが良い「デフォルト」の選択肢です。これにより、グループロールについて最終決定を行うまで、Productの状態を安全に保つことができます。 + +### **グループに設定権限を割り当てる** + +グループ内のメンバーに設定機能へのアクセスを許可し、DefectDojoの特定の側面を制御させたい場合は、グループページからこれらの責任を割り当てることができます。 + +右下隅のメニューから、View、Add、Edit、Deleteのロールを割り当てます。設定権限にチェックを入れると、そのグループには直ちにその機能へのアクセス権が付与されます。 + +![image](images/Create_a_User_Group_for_shared_permissions_9.png) diff --git a/docs/content/admin/user_management/pro_permissions_overhaul.de.md b/docs/content/admin/user_management/pro_permissions_overhaul.de.md new file mode 100644 index 00000000000..76e4f6ae2b4 --- /dev/null +++ b/docs/content/admin/user_management/pro_permissions_overhaul.de.md @@ -0,0 +1,54 @@ +--- +title: Berechtigungen in Pro festlegen +description: Überarbeitung, Pro-Funktion +weight: 3 +audience: pro +aliases: +- /de/en/customize_dojo/user_management/pro_permissions_overhaul +--- + +## Einführung in die Berechtigungstypen + +Einzelnen Benutzern können vier verschiedene Arten von Berechtigungen zugewiesen werden: + +* Benutzer können als **Mitglieder von Produkten oder Produkttypen** eingetragen werden. Dadurch können sie Datentypen (Produkttypen, Produkte, Engagements, Tests und Befunde) in DefectDojo ansehen und damit arbeiten, abhängig von der Rolle, die ihnen für das jeweilige Produkt zugewiesen ist. Benutzer können mehrere Produkt- oder Produkttyp-Mitgliedschaften mit unterschiedlichen Zugriffsebenen haben. +​ +* Benutzern können außerdem **Konfigurationsberechtigungen** zugewiesen werden, die ihnen Zugriff auf Konfigurationsseiten in DefectDojo geben. Konfigurationsberechtigungen sind nicht mit Produkten oder Produkttypen verknüpft. +​ +* Benutzern können **globale Rollen** zugewiesen werden, die ihnen eine einheitliche Zugriffsebene auf alle Produkte und Produkttypen geben. +​ +* Benutzer können als **Superuser** eingerichtet werden: Rollen auf Administratorebene, die Kontrolle über und Zugriff auf alle Daten und Konfigurationen von DefectDojo geben. + +Sie können auch Gruppen erstellen, wenn Sie Produktmitgliedschaften, Konfigurationsberechtigungen oder globale Rollen mehreren Benutzern gleichzeitig zuweisen möchten. Wenn Sie sehr viele Benutzer in DefectDojo haben, etwa ein eigenes Testteam für ein bestimmtes Produkt, sind Gruppen möglicherweise die praktischere Funktion. + +## Superuser \& globale Rollen + +Im Rahmen Ihrer Konfiguration der rollenbasierten Zugriffskontrolle (RBAC) kann es erforderlich sein, weitere Superuser oder Benutzer mit globalen Rollen zu erstellen. + +* Superuser (Admins) unterliegen keinen Einschränkungen im System. Sie können alle Einstellungen ändern, Benutzer verwalten und haben Lese- und Schreibzugriff auf alle Daten. Sie können außerdem die Zugriffsregeln für alle Benutzer in DefectDojo ändern. Superuser erhalten zudem Benachrichtigungen zu allen Systemproblemen und Warnungen. +* Benutzer mit globalen Rollen können jeden Datentyp (Produkttypen, Produkte, Engagements, Tests und Befunde) in DefectDojo entsprechend ihrer zugewiesenen Rolle ansehen und damit arbeiten. Weitere Informationen zu den einzelnen Rollen und den zugehörigen Rechten finden Sie in unserem Artikel „Einführung in Rollen“. +* Benutzern können außerdem bestimmte Konfigurationsberechtigungen zugewiesen werden, die ihnen Zugriff auf einzelne Konfigurationsseiten von DefectDojo geben. Standardmäßig haben Benutzer keine Konfigurationsberechtigungen. + +Standardmäßig verfügt das erste Konto, das auf einer neuen DefectDojo-Instanz erstellt wird, über Superuser-Berechtigungen. Dieser Benutzer kann die Berechtigungen aller weiteren DefectDojo-Benutzer bearbeiten. Nur ein bestehender Superuser kann einen weiteren Superuser anlegen oder einem Benutzer eine globale Rolle zuweisen. + +Die Berechtigungen in DefectDojo Pro wurden vereinfacht, damit sich der Zugriff auf Objekte leichter zuweisen lässt. Diese Funktion ist über die [Pro-UI](/get_started/about/ui_pro_vs_os/) erreichbar. + +### Das Berechtigungsfenster öffnen + +![image](images/pro_permissions.png) + +Wenn Sie einen Produkttyp oder ein Produkt betrachten, können Sie das Berechtigungsfenster öffnen, um Berechtigungen schnell festzulegen. In einer Tabelle finden Sie dieses Menü über die Punkte **„⋮“**. Auf der Seite eines einzelnen **Produkts** oder **Produkttyps** finden Sie dieses Menü unter dem blauen Zahnrad „⚙️“. + +## Berechtigungen über das Berechtigungsfenster festlegen + +![image](images/pro_permissions_2.png) + +1. Am oberen Rand dieses Fensters können Sie wählen, ob Sie die Berechtigungen für einen einzelnen Benutzer oder für eine [Benutzergruppe](../create_user_group) verwalten möchten. +2. Hier können Sie einen Benutzer oder eine Gruppe auswählen, die dem Produkt hinzugefügt werden soll, und die [Rolle](../about_perms_and_roles) festlegen, die dieser Benutzer haben soll. +3. In der unteren Tabelle sehen Sie eine Liste aller Benutzer und Gruppen, die Zugriff auf dieses Objekt haben. Über das Dropdown-Menü können Sie einem dieser Benutzer oder einer dieser Gruppen außerdem schnell eine neue Rolle zuweisen. + +## Konfigurationsberechtigungen über die Benutzeransicht festlegen + +Die Konfigurationsberechtigungen eines Benutzers lassen sich jetzt benutzerfreundlicher festlegen. In der Benutzeransicht werden alle Konfigurationsberechtigungen in einem Dropdown-Menü angezeigt und nach Berechtigungstyp gruppiert. Wenn die Auswahl der Konfigurationsberechtigungen vom aktuellen Wert abweicht, wird die Schaltfläche „Konfigurationsberechtigungen aktualisieren“ angezeigt. Nach dem Klicken wird der Benutzer gebeten zu bestätigen, dass er die Berechtigungen für die ausgewählte Gruppe aktualisieren möchte, bevor die Aktualisierung durchgeführt wird. + +![image](images/pro_user_view.png) diff --git a/docs/content/admin/user_management/pro_permissions_overhaul.es.md b/docs/content/admin/user_management/pro_permissions_overhaul.es.md new file mode 100644 index 00000000000..8c744268e66 --- /dev/null +++ b/docs/content/admin/user_management/pro_permissions_overhaul.es.md @@ -0,0 +1,54 @@ +--- +title: Establecer permisos en Pro +description: Renovación, función de Pro +weight: 3 +audience: pro +aliases: +- /es/en/customize_dojo/user_management/pro_permissions_overhaul +--- + +## Introducción a los Tipos de Permisos + +Los usuarios individuales pueden tener asignados cuatro tipos diferentes de permisos: + +* Los usuarios pueden asignarse como **Miembros de Productos o Tipos de Producto**. Esto les permite ver e interactuar con los Tipos de Dato (Tipos de Producto, Productos, Compromisos, Tests y Hallazgos) en DefectDojo, según el rol que tengan asignado en el Producto específico. Los usuarios pueden tener varias membresías de Producto o Tipo de Producto, con distintos niveles de acceso. + +* Los usuarios también pueden tener asignados **Permisos de Configuración**, que les permiten acceder a las páginas de configuración de DefectDojo. Los Permisos de Configuración no están relacionados con Productos o Tipos de Producto. + +* A los usuarios se les pueden asignar **Roles Globales**, que les otorgan un nivel de acceso estandarizado a todos los Productos y Tipos de Producto. + +* Los usuarios pueden configurarse como **Superusuarios**: roles de nivel administrador que les otorgan control y acceso a todos los datos y la configuración de DefectDojo. + +También puede crear Grupos si desea asignar Membresía de Producto, Permisos de Configuración o Roles Globales a un grupo de usuarios al mismo tiempo. Si tiene una gran cantidad de usuarios en DefectDojo, como un equipo de testing dedicado a un Producto en particular, los Grupos pueden ser una función más útil. + +## Superusuarios y Roles Globales + +Parte de la configuración de su Control de Acceso Basado en Roles (RBAC) puede requerir que cree Superusuarios adicionales, o usuarios con Roles Globales. + +* Los Superusuarios (Administradores) no tienen limitaciones en el sistema. Pueden cambiar todas las configuraciones, gestionar usuarios y tienen acceso de lectura / escritura a todos los datos. También pueden cambiar las reglas de acceso de todos los usuarios en DefectDojo. Además, los Superusuarios reciben notificaciones de todos los problemas y alertas del sistema. +* Los usuarios con Roles Globales pueden ver e interactuar con cualquier Tipo de Dato (Tipos de Producto, Productos, Compromisos, Tests y Hallazgos) en DefectDojo, según el Rol que tengan asignado. Para obtener más información sobre cada Rol y los privilegios asociados, consulte nuestro artículo Introducción a los Roles. +* Los usuarios también pueden tener Permisos de Configuración específicos asignados, lo que les permite acceder a ciertas páginas de configuración de DefectDojo. Los usuarios no tienen Permisos de Configuración de forma predeterminada. + +De forma predeterminada, la primera cuenta creada en una nueva instancia de DefectDojo tendrá permisos de Superusuario. Ese usuario podrá editar los permisos de todos los usuarios de DefectDojo que se creen posteriormente. Solo un Superusuario existente puede agregar otro superusuario, o agregar un Rol Global a un usuario. + +Los permisos en DefectDojo Pro se han simplificado, para facilitar la asignación de acceso a los objetos. Esta función puede accederse a través de la [interfaz Pro](/get_started/about/ui_pro_vs_os/). + +### Abrir la ventana de Permisos + +![image](images/pro_permissions.png) + +Al ver un Tipo de Producto o Producto, puede abrir la ventana de Permisos para establecer permisos rápidamente. Este menú se encuentra en una Tabla al hacer clic en los puntos horizontales **"⋮"**. Si está viendo una página individual de **Producto** o **Tipo de Producto**, este menú se encuentra bajo el engranaje azul "⚙️". + +## Establecer permisos a través de la ventana de permisos + +![image](images/pro_permissions_2.png) + +1. En la parte superior de esta ventana, puede elegir gestionar los permisos de un usuario individual o de un [grupo de usuarios](../create_user_group). +2. Aquí puede seleccionar un usuario o grupo para agregar al Producto, y seleccionar el [Rol](../about_perms_and_roles) que desea que tenga ese usuario. +3. En la tabla inferior, puede ver una lista de todos los usuarios o grupos que tienen acceso a este objeto. También puede asignar rápidamente un nuevo rol a uno de estos usuarios o grupos desde el menú desplegable. + +## Establecer Permisos de Configuración a través de la vista de Usuario + +Ahora los permisos de configuración de un usuario pueden establecerse de una forma más sencilla. Desde la Vista de Usuarios, todos los permisos de configuración se muestran en un menú desplegable, agrupados por tipo de permiso. Si la selección de permisos de configuración difiere de su valor actual, se muestra un botón "Actualizar Permisos de Configuración". Al hacer clic en él, se le pedirá al usuario que confirme si desea actualizar los permisos del grupo seleccionado antes de realizar la actualización. + +![image](images/pro_user_view.png) diff --git a/docs/content/admin/user_management/pro_permissions_overhaul.fr.md b/docs/content/admin/user_management/pro_permissions_overhaul.fr.md new file mode 100644 index 00000000000..49f2909e79f --- /dev/null +++ b/docs/content/admin/user_management/pro_permissions_overhaul.fr.md @@ -0,0 +1,54 @@ +--- +title: Définir les autorisations dans Pro +description: Refonte, fonctionnalité Pro +weight: 3 +audience: pro +aliases: +- /fr/en/customize_dojo/user_management/pro_permissions_overhaul +--- + +## Introduction aux types d'autorisations + +Chaque utilisateur peut se voir attribuer quatre types d'autorisations différents : + +* Les utilisateurs peuvent être affectés comme **Members à des Produits ou des Types de produit**. Cela leur permet de consulter et d'interagir avec les types de données (Types de produit, Produits, Engagements, Tests et Constatations) dans DefectDojo, selon le rôle qui leur est attribué sur le Produit spécifique. Les utilisateurs peuvent avoir plusieurs memberships sur des Produits ou des Types de produit, avec différents niveaux d'accès. +​ +* Les utilisateurs peuvent également se voir attribuer des **Configuration Permissions**, qui leur permettent d'accéder aux pages de configuration de DefectDojo. Les Configuration Permissions ne sont pas liées aux Produits ou aux Types de produit. +​ +* Les utilisateurs peuvent se voir attribuer des **Global Roles**, qui leur donnent un niveau d'accès standardisé à tous les Produits et Types de produit. +​ +* Les utilisateurs peuvent être configurés comme **Superusers** : des rôles de niveau administrateur qui leur donnent le contrôle et l'accès à toutes les données et à la configuration de DefectDojo. + +Vous pouvez également créer des Groups si vous souhaitez attribuer un Product Membership, des Configuration Permissions ou des Global Roles à un groupe d'utilisateurs en même temps. Si vous avez un grand nombre d'utilisateurs dans DefectDojo, comme une équipe de test dédiée à un Produit particulier, les Groups peuvent être une fonctionnalité plus pratique. + +## Superusers et Global Roles + +Une partie de votre configuration de contrôle d'accès basé sur les rôles (RBAC) peut nécessiter la création de Superusers supplémentaires, ou d'utilisateurs disposant de Global Roles. + +* Les Superusers (Admins) n'ont aucune limitation dans le système. Ils peuvent modifier tous les paramètres, gérer les utilisateurs et disposent d'un accès en lecture/écriture à toutes les données. Ils peuvent également modifier les règles d'accès de tous les utilisateurs de DefectDojo. Les Superusers reçoivent également les notifications pour tous les problèmes et alertes système. +* Les utilisateurs disposant de Global Roles peuvent consulter et interagir avec tout type de données (Types de produit, Produits, Engagements, Tests et Constatations) dans DefectDojo, selon le Role qui leur est attribué. Pour plus d'informations sur chaque Role et les privilèges associés, veuillez consulter notre article Introduction aux rôles. +* Les utilisateurs peuvent également se voir attribuer des Configuration Permissions spécifiques, leur permettant d'accéder à certaines pages de configuration de DefectDojo. Les utilisateurs ne disposent d'aucune Configuration Permission par défaut. + +Par défaut, le premier compte créé sur une nouvelle instance DefectDojo dispose des autorisations Superuser. Cet utilisateur pourra modifier les autorisations de tous les utilisateurs DefectDojo créés par la suite. Seul un Superuser existant peut ajouter un autre superuser, ou attribuer un Global Role à un utilisateur. + +Les autorisations dans DefectDojo Pro ont été simplifiées, afin de faciliter l'attribution de l'accès aux objets. Cette fonctionnalité est accessible via l'[interface Pro](/get_started/about/ui_pro_vs_os/). + +### Ouvrir la fenêtre des autorisations + +![image](images/pro_permissions.png) + +Lorsque vous consultez un Type de produit ou un Produit, vous pouvez ouvrir la fenêtre des autorisations pour définir rapidement les autorisations. Ce menu se trouve dans un tableau en cliquant sur les points horizontaux **"⋮"**. Si vous consultez une page individuelle **Produit** ou **Type de produit**, ce menu se trouve sous l'icône d'engrenage bleue ‘⚙️’. + +## Définir les autorisations depuis la fenêtre des autorisations + +![image](images/pro_permissions_2.png) + +1. En haut de cette fenêtre, vous pouvez choisir de gérer les autorisations pour un utilisateur individuel ou pour un [groupe d'utilisateurs](../create_user_group). +2. Ici, vous pouvez sélectionner un utilisateur ou un groupe à ajouter au Produit, et sélectionner le [Role](../about_perms_and_roles) que vous souhaitez attribuer à cet utilisateur. +3. Dans le tableau du bas, vous pouvez voir la liste de tous les utilisateurs ou groupes ayant accès à cet objet. Vous pouvez également attribuer rapidement un nouveau rôle à l'un de ces utilisateurs ou groupes depuis le menu déroulant. + +## Définir les Configuration Permissions depuis la vue Utilisateur + +Les Configuration Permissions d'un utilisateur peuvent désormais être définies de manière plus conviviale. Depuis la vue Users, toutes les Configuration Permissions sont affichées dans un menu déroulant, puis regroupées par type d'autorisation. Si la sélection des Configuration Permissions diffère de leur valeur actuelle, un bouton « Update Configuration Permissions » s'affiche. Lorsqu'on clique dessus, il est demandé à l'utilisateur de confirmer qu'il souhaite mettre à jour les autorisations du groupe sélectionné avant que la mise à jour ne soit effectuée. + +![image](images/pro_user_view.png) diff --git a/docs/content/admin/user_management/pro_permissions_overhaul.ja.md b/docs/content/admin/user_management/pro_permissions_overhaul.ja.md new file mode 100644 index 00000000000..bcdc8dccad7 --- /dev/null +++ b/docs/content/admin/user_management/pro_permissions_overhaul.ja.md @@ -0,0 +1,54 @@ +--- +title: Proで権限を設定する +description: 権限設定の刷新、Pro機能 +weight: 3 +audience: pro +aliases: +- /ja/en/customize_dojo/user_management/pro_permissions_overhaul +--- + +## 権限の種類の概要 + +個々のユーザーには、割り当てることができる4種類の権限があります。 + +* ユーザーは**ProductまたはProduct Typeのメンバー**として割り当てることができます。これにより、特定のProductに割り当てられたロールに応じて、DefectDojo内のデータタイプ(Product Type、Product、Engagement、Test、Finding)を閲覧・操作できます。ユーザーは複数のProductまたはProduct Typeのメンバーシップを持つことができ、それぞれ異なるレベルのアクセス権を設定できます。 +​ +* ユーザーには**設定権限**を割り当てることもでき、これによりDefectDojoの設定ページにアクセスできるようになります。設定権限はProductやProduct Typeとは関連がありません。 +​ +* ユーザーには**グローバルロール**を割り当てることができ、これによりすべてのProductとProduct Typeに対して標準化されたレベルのアクセス権が付与されます。 +​ +* ユーザーは**スーパーユーザー**として設定できます。これは、DefectDojoのすべてのデータと設定に対する管理と操作を可能にする、管理者レベルのロールです。 + +Product membership、設定権限、またはグローバルロールを複数のユーザーに同時に割り当てたい場合は、グループを作成することもできます。特定のProduct専用のテストチームなど、DefectDojo内に多数のユーザーがいる場合、グループの方が便利な機能となることがあります。 + +## スーパーユーザーとグローバルロール + +ロールベースアクセス制御(RBAC)の構成の一部として、追加のスーパーユーザーや、グローバルロールを持つユーザーの作成が必要になる場合があります。 + +* スーパーユーザー(管理者)にはシステム上の制限が一切ありません。すべての設定を変更し、ユーザーを管理し、すべてのデータへの読み取り/書き込みアクセス権を持ちます。DefectDojoの全ユーザーに対するアクセスルールを変更することもできます。また、スーパーユーザーはすべてのシステム上の問題やアラートに関する通知も受け取ります。 +* グローバルロールを持つユーザーは、割り当てられたロールに応じて、DefectDojo内のあらゆるデータタイプ(Product Type、Product、Engagement、Test、Finding)を閲覧・操作できます。各ロールおよび関連する権限の詳細については、Introduction to Rolesの記事を参照してください。 +* ユーザーには特定の設定権限を割り当てることもでき、これにより特定のDefectDojo設定ページにアクセスできるようになります。ユーザーにはデフォルトで設定権限がありません。 + +デフォルトでは、新しいDefectDojoインスタンスで最初に作成されたアカウントがスーパーユーザー権限を持ちます。そのユーザーは、それ以降に作成されるすべてのDefectDojoユーザーの権限を編集できます。新たなスーパーユーザーの追加や、ユーザーへのグローバルロールの追加は、既存のスーパーユーザーのみが行えます。 + +DefectDojo Proの権限は、オブジェクトへのアクセス割り当てをより簡単にするために簡素化されています。この機能は[Pro UI](/get_started/about/ui_pro_vs_os/)からアクセスできます。 + +### Permissionsウィンドウを開く + +![image](images/pro_permissions.png) + +Product TypeまたはProductを表示しているとき、Permissionsウィンドウを開いて権限をすばやく設定できます。このメニューは、テーブル上で横向きの点**「⋮」**をクリックすると表示されます。個々の**Product**または**Product Type**ページを表示している場合は、このメニューは青い歯車「⚙️」の下にあります。 + +## Permissionsウィンドウから権限を設定する + +![image](images/pro_permissions_2.png) + +1. このウィンドウの上部で、個々のユーザー、または[ユーザーグループ](../create_user_group)のいずれかを対象に権限を管理するかを選択できます。 +2. ここで、Productに追加するユーザーまたはグループを選択し、そのユーザーに持たせたい[ロール](../about_perms_and_roles)を選択します。 +3. 下部のテーブルには、このオブジェクトへのアクセス権を持つすべてのユーザーまたはグループの一覧が表示されます。ドロップダウンメニューから、これらのユーザーまたはグループのいずれかに新しいロールをすばやく割り当てることもできます。 + +## User viewから設定権限を設定する + +ユーザーの設定権限は、より分かりやすい方法で設定できるようになりました。Users Viewでは、すべての設定権限がドロップダウンに表示され、権限の種類ごとにグループ化されます。選択した設定権限が現在の値と異なる場合、「Update Configuration Permissions」ボタンが表示されます。これをクリックすると、更新を行う前に、選択したグループの権限を更新してよいかどうかの確認が求められます。 + +![image](images/pro_user_view.png) diff --git a/docs/content/admin/user_management/set_user_permissions.de.md b/docs/content/admin/user_management/set_user_permissions.de.md new file mode 100644 index 00000000000..445b78841d9 --- /dev/null +++ b/docs/content/admin/user_management/set_user_permissions.de.md @@ -0,0 +1,154 @@ +--- +title: Berechtigungen eines Benutzers festlegen +description: So gewähren Sie einem Benutzer Rollen und Berechtigungen sowie Superuser-Status +weight: 2 +audience: pro +aliases: +- /de/en/customize_dojo/user_management/set_user_permissions +--- + +> **DefectDojo Pro-Funktion.** Das auf dieser Seite beschriebene RBAC-System für Mitglieder/Gruppen/Globale Rollen ist Teil von DefectDojo Pro. Open-Source-DefectDojo verwendet das Modell [Autorisierte Benutzer](../os__authorized_users/) — siehe diese Seite für die Zugriffskontrolle in der Open-Source-Version sowie die [3.0-Upgrade-Hinweise](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization), wenn Sie zwischen den Editionen wechseln. + +## Einführung in die Berechtigungstypen + +Einzelne Benutzer können vier verschiedene Arten von Berechtigungen zugewiesen bekommen: + +* Benutzer können als **Mitglieder von Produkten oder Produkttypen** zugewiesen werden. Dies ermöglicht ihnen, je nach der ihnen für das jeweilige Produkt zugewiesenen Rolle, Datentypen (Produkttypen, Produkte, Engagements, Tests und Befunde) in DefectDojo anzuzeigen und mit ihnen zu interagieren. Benutzer können mehrere Produkt- oder Produkttyp-Mitgliedschaften mit unterschiedlichen Zugriffsebenen haben. + +* Benutzern können außerdem **Konfigurationsberechtigungen** zugewiesen werden, die ihnen Zugriff auf Konfigurationsseiten in DefectDojo gewähren. Konfigurationsberechtigungen stehen in keinem Zusammenhang mit Produkten oder Produkttypen. + +* Benutzern können **Globale Rollen** zugewiesen werden, die ihnen ein standardisiertes Zugriffsniveau auf alle Produkte und Produkttypen gewähren. + +* Benutzer können als **Superuser** eingerichtet werden: Administratorrollen, die ihnen Kontrolle über und Zugriff auf alle Daten und Konfigurationen von DefectDojo geben. + +Sie können auch Gruppen erstellen, wenn Sie einer Gruppe von Benutzern gleichzeitig Produktmitgliedschaft, Konfigurationsberechtigungen oder Globale Rollen zuweisen möchten. Wenn Sie eine große Anzahl von Benutzern in DefectDojo haben, etwa ein dediziertes Testteam für ein bestimmtes Produkt, können Gruppen eine hilfreichere Funktion sein. + +## Superuser \& Globale Rollen + +Ein Teil Ihrer Rollenbasierten Zugriffskontrolle (RBAC)-Konfiguration erfordert möglicherweise die Erstellung zusätzlicher Superuser oder Benutzer mit Globalen Rollen. + +* Superuser (Admins) unterliegen keinerlei Einschränkungen im System. Sie können alle Einstellungen ändern, Benutzer verwalten und haben Lese-/Schreibzugriff auf alle Daten. Sie können auch Zugriffsregeln für alle Benutzer in DefectDojo ändern. Superuser erhalten außerdem Benachrichtigungen zu allen Systemproblemen und -warnungen. +* Benutzer mit Globalen Rollen können je nach ihrer zugewiesenen Rolle jeden Datentyp (Produkttypen, Produkte, Engagements, Tests und Befunde) in DefectDojo anzeigen und mit ihm interagieren. Weitere Informationen zu den einzelnen Rollen und den damit verbundenen Berechtigungen finden Sie in unserem Artikel „Einführung in die Rollen". +* Benutzern können außerdem bestimmte Konfigurationsberechtigungen zugewiesen werden, die ihnen Zugriff auf bestimmte Konfigurationsseiten von DefectDojo gewähren. Benutzer haben standardmäßig keine Konfigurationsberechtigungen. + +Standardmäßig erhält das erste auf einer neuen DefectDojo-Instanz erstellte Konto Superuser-Berechtigungen. Dieser Benutzer kann die Berechtigungen für alle nachfolgenden DefectDojo-Benutzer bearbeiten. Nur ein bestehender Superuser kann einen weiteren Superuser hinzufügen oder einem Benutzer eine Globale Rolle zuweisen. + +### Einem bestehenden Benutzer den Status Superuser oder Globale Rolle hinzufügen + +1. Navigieren Sie in der Seitenleiste zur Seite 👤 Benutzer \> Benutzer. Sie sehen eine Liste aller registrierten Konten in DefectDojo, zusammen mit dem Aktiv-Status, den Globalen Rollen und weiteren relevanten Benutzerdaten des jeweiligen Kontos. + +![image](images/Set_a_User's_Permissions.png) + +2. Klicken Sie auf den Namen des Kontos, dem Sie Superuser-Berechtigungen erteilen möchten. Dadurch gelangen Sie auf die Benutzerseite dieses Kontos. + +3. Öffnen Sie im Abschnitt „Standardinformationen" der Benutzerseite das ☰-Menü und wählen Sie Bearbeiten. + +![image](images/Set_a_User's_Permissions_2.png) + +4. Auf der Seite „Benutzer bearbeiten": + +Aktivieren Sie für den Superuser-Status das Kontrollkästchen ☑️ Superuser-Status, das sich in den Standardinformationen des Benutzers befindet. + +Um eine Globale Rolle zuzuweisen, wählen Sie im Dropdown-Menü „Globale Rolle" am unteren Rand der Seite eine Rolle aus. + +![image](images/Set_a_User's_Permissions_3.png) + +5. Klicken Sie auf Absenden, um diese Änderungen zu übernehmen. + +## Produkt- \& Produkttyp-Mitgliedschaft + +Standardmäßig hat jedes neu erstellte Konto in DefectDojo keine Berechtigung, Daten auf Produktebene anzuzeigen. Diese Konten müssen jedem Produkt, das sie anzeigen und mit dem sie interagieren möchten, als Mitglied zugewiesen werden. + +* Die Produkt- \& Produkttyp-Mitgliedschaft kann nur von **Superusern, Maintainern oder Ownern** konfiguriert werden. +* **Maintainer \& Owner** können die Mitgliedschaft nur für Produkte/Produkttypen konfigurieren, denen sie bereits zugewiesen sind. +* **Globale Maintainer \& Owner** können die Mitgliedschaft für jedes Produkt oder jeden Produkttyp konfigurieren, ebenso wie **Superuser**. + +Benutzer können auf **Produkt**-Ebene gleichzeitig zwei Arten von Mitgliedschaft haben: + +* Die Rolle, die ihnen durch ihre zugrunde liegende Produkttyp-Mitgliedschaft verliehen wird, falls zutreffend +* Ihre produktspezifische Rolle, falls vorhanden. + +Wenn ein Benutzer bereits als Produkttyp-Mitglied hinzugefügt wurde und keine zusätzliche Berechtigungsebene für ein bestimmtes Produkt benötigt, ist es nicht nötig, ihn als Produktmitglied hinzuzufügen. + +### Ein neues Mitglied hinzufügen + +1. Navigieren Sie zu dem Produkt oder Produkttyp, dem Sie einen Benutzer zuweisen möchten. Sie können das Produkt aus der Liste unter **Produkte \> Alle Produkte** auswählen. + +![image](images/Set_a_User's_Permissions_4.png) + +2. Suchen Sie die Überschrift **Mitglieder**, klicken Sie auf das Menü **☰** und wählen Sie **\+ Benutzer hinzufügen**. +3. Dadurch gelangen Sie auf eine Seite, auf der Sie **neue Mitglieder registrieren** können. Wählen Sie einen Benutzer aus dem Dropdown-Menü „Benutzer" aus. +4. Wählen Sie die Rolle aus, die dieser Benutzer für dieses Produkt oder diesen Produkttyp haben soll: **API Importer, Reader, Writer, Maintainer** oder **Owner.** + +![image](images/Set_a_User's_Permissions_5.png) + +Benutzer können einem Produkt oder Produkttyp nicht als Mitglied zugewiesen werden, ohne auch eine Rolle zu erhalten. Wenn Sie nicht sicher sind, welche Rolle Sie einem neuen Benutzer zuweisen möchten, ist **Reader** eine gute „Standard"-Option. Dadurch bleibt der Zustand Ihres Produkts sicher, bis Sie Ihre endgültige Entscheidung über die Rolle getroffen haben. + +### Ein Mitglied bearbeiten oder löschen + +Die Rolle von Mitgliedern kann innerhalb eines Produkts oder Produkttyps geändert werden. + +Navigieren Sie auf der Seite **Produkt** oder **Produkttyp** zur Überschrift **Mitglieder** und klicken Sie auf die Schaltfläche **⋮** neben dem Benutzer, den Sie bearbeiten oder löschen möchten. + +![image](images/Set_a_User's_Permissions_6.png) + +📝 **Bearbeiten** führt Sie zum Bildschirm **Mitglied bearbeiten**, auf dem Sie die **Rolle** dieses Benutzers ändern können (von **API Importer, Reader, Writer, Maintainer** oder **Owner** zu einer anderen Auswahl). + +🗑️ **Löschen** entfernt die Mitgliedschaft eines Benutzers vollständig. Dadurch werden keine Beiträge oder Änderungen entfernt, die der Benutzer am Produkt oder Produkttyp vorgenommen hat. + +* Wenn Sie die Mitgliedschaft eines Benutzers nicht bearbeiten oder löschen können (das Symbol **⋮** ist nicht sichtbar), liegt das daran, dass diese Mitgliedschaft auf **Produkttyp**-Ebene verliehen wurde. +* Ein Benutzer kann innerhalb eines Produkts zwei Mitgliedschaftsebenen haben \- eine auf **Produkttyp**-Ebene zugewiesene und eine weitere auf **Produkt**-Ebene zugewiesene. + +#### Einem Benutzer mit einer zugehörigen Produkttyp-Rolle eine zusätzliche Produktrolle hinzufügen + +Wenn ein Benutzer eine Rolle auf Produkttyp-Ebene hat, wird ihm auch für jedes zugrunde liegende Produkt innerhalb dieser Kategorie eine Mitgliedschaft mit dieser Rolle zugewiesen. Wenn dieser Benutzer jedoch für ein bestimmtes Produkt innerhalb dieses Produkttyps eine besondere Rolle haben soll, können Sie ihm auf Produktebene eine zusätzliche Rolle geben. + +1. Navigieren Sie auf der Produktseite zur Überschrift **Mitglieder**, klicken Sie auf das Menü **☰** und wählen Sie **\+ Benutzer hinzufügen** (so, als würden Sie einen neuen Benutzer zum Produkt hinzufügen). +2. Wählen Sie den Namen des Benutzers aus dem Dropdown-Menü aus und wählen Sie die Produktrolle, die diesem Benutzer zugewiesen werden soll. + +Eine Produktrolle setzt die Standard-Produkttyp-Rolle oder Globale Rolle eines Benutzers außer Kraft. Wenn ein Benutzer beispielsweise eine Produkttyp-Rolle als **Reader** hat, aber auch als **Owner** für ein unter diesem Produkttyp verschachteltes Produkt zugewiesen ist, erhält er nur für dieses Produkt zusätzliche **Owner**-Berechtigungen. + +Dies funktioniert jedoch nicht umgekehrt. Wenn ein Benutzer eine Produkttyp-Rolle oder Globale Rolle als **Owner** hat, entzieht ihm die Zuweisung einer **Reader**-Rolle für ein bestimmtes Produkt nicht seine **Owner**-Berechtigungen. **Rollen können einem Benutzer keine durch andere Rollen gewährten Berechtigungen entziehen, sie können nur zusätzliche Berechtigungen hinzufügen.** + +## Konfigurationsberechtigungen + +Viele Konfigurationsdialoge und API-Endpunkte können für Benutzer oder Benutzergruppen aktiviert werden, unabhängig von deren Superuser-Status. Diese Konfigurationsberechtigungen ermöglichen es regulären Benutzern, auf Teile von DefectDojo außerhalb ihrer standardmäßigen Produkt- oder Produktrollen-Zuweisung zuzugreifen und zu diesen beizutragen. + +Konfigurationsberechtigungen stehen in keinem Zusammenhang mit einem bestimmten Produkt oder Produkttyp \- Benutzern können Konfigurationsberechtigungen zugewiesen werden, ohne dass andere Status oder eine Produkt-/Produkttyp-Mitgliedschaft erforderlich sind. + +### Liste der Konfigurationsberechtigungen + +* **Credential Manager:** Zugriff auf die Seite ⚙️Konfiguration \> Credential Manager +* **Entwicklungsumgebungen:** Verwaltung der Liste Engagements \> Umgebungen +* **Finding-Vorlagen:** Zugriff auf die Seite Befunde \> Finding-Vorlagen +* **Gruppen**: Zugriff auf die Seite 👤Benutzer \> Gruppen +* **Jira-Instanzen:** Zugriff auf die Seite ⚙️Konfiguration \> JIRA +* **Sprachtypen**: Zugriff auf den [Language Types](/automation/api/languages/)-API-Endpunkt +* **Login-Banner**: Bearbeiten der Seite ⚙️Konfiguration \> Login-Banner +* **Ankündigungen**: Zugriff auf ⚙️Konfiguration \> Ankündigungen +* **Notiztypen:** Zugriff auf die Seite ⚙️Konfiguration \> Notiztypen +* **Produkttypen:** entfällt +* **Fragebögen**: Zugriff auf die Seite Fragebögen \> Alle Fragebögen +* **Fragen**: Zugriff auf die Seite Fragebögen \> Fragen +* **Regularien**: Zugriff auf die Seite ⚙️Konfiguration \> Regularien +* **SLA-Konfiguration:** Zugriff auf die Seite ⚙️Konfiguration \> SLA-Konfiguration +* **Testtypen:** Hinzufügen oder Bearbeiten eines Testtyps (unter Engagements \> Testtypen) +* **Tool-Konfiguration:** Zugriff auf die Seite **⚙️Konfiguration \> Tool-Typen** +* **Tool-Typen:** Zugriff auf die Seite ⚙️Konfiguration \> Tool-Typen +* **Benutzer:** Zugriff auf die Seite 👤Benutzer \> Benutzer + +### Konfigurationsberechtigungen zu einem Benutzer hinzufügen + +**Nur Superuser können einem Benutzer Konfigurationsberechtigungen hinzufügen**. + +1. Navigieren Sie in der Seitenleiste zur Seite 👤 Benutzer \> Benutzer. Sie sehen eine Liste aller registrierten Konten in DefectDojo, zusammen mit dem Aktiv-Status, den Globalen Rollen und weiteren relevanten Benutzerdaten des jeweiligen Kontos. + +![image](images/Set_a_User's_Permissions_7.png) + +2. Klicken Sie auf den Namen des Kontos, das Sie bearbeiten möchten. + +3. Navigieren Sie zur Liste der Konfigurationsberechtigungen. Diese befindet sich auf der rechten Seite der Benutzerseite. + +4. Wählen Sie die Benutzerkonfigurationsberechtigungen aus, die Sie hinzufügen möchten. + +Eine detaillierte Aufschlüsselung der Benutzerkonfigurationsberechtigungen finden Sie in unserer [Berechtigungsübersicht](../user_permission_chart/). diff --git a/docs/content/admin/user_management/set_user_permissions.es.md b/docs/content/admin/user_management/set_user_permissions.es.md new file mode 100644 index 00000000000..37202f2fda6 --- /dev/null +++ b/docs/content/admin/user_management/set_user_permissions.es.md @@ -0,0 +1,154 @@ +--- +title: Configurar los permisos de un usuario +description: Cómo otorgar Roles y Permisos a un usuario, así como el estado de superusuario +weight: 2 +audience: pro +aliases: +- /es/en/customize_dojo/user_management/set_user_permissions +--- + +> **Función de DefectDojo Pro.** El sistema RBAC de Miembros / Grupos / Roles Globales descrito en esta página forma parte de DefectDojo Pro. DefectDojo de código abierto utiliza el modelo de [Usuarios Autorizados](../os__authorized_users/) — consulte esa página para el control de acceso de código abierto, y las [notas de actualización a 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si está migrando entre ediciones. + +## Introducción a los tipos de permisos + +Los usuarios individuales tienen cuatro tipos diferentes de permisos que se les pueden asignar: + +* Los usuarios pueden asignarse como **Miembros de Productos o Tipos de Producto**. Esto les permite ver e interactuar con Tipos de Datos (Tipos de Producto, Productos, Compromisos, Tests y Hallazgos) en DefectDojo según el rol que se les asigne en el Producto específico. Los usuarios pueden tener varias membresías de Producto o Tipo de Producto, con distintos niveles de acceso. +​ +* Los usuarios también pueden tener asignados **Permisos de Configuración**, que les permiten acceder a páginas de configuración en DefectDojo. Los Permisos de Configuración no están relacionados con Productos ni Tipos de Producto. +​ +* A los usuarios se les pueden asignar **Roles Globales**, que les otorgan un nivel de acceso estandarizado a todos los Productos y Tipos de Producto. +​ +* Los usuarios pueden configurarse como **Superusuarios**: roles de nivel administrador que les dan control y acceso a todos los datos y la configuración de DefectDojo. + +También puede crear Grupos si desea asignar Membresía de Producto, Permisos de Configuración o Roles Globales a un grupo de usuarios al mismo tiempo. Si tiene un gran número de usuarios en DefectDojo, como un equipo de testing dedicado a un Producto en particular, los Grupos pueden ser una función más útil. + +## Superusuarios \& Roles Globales + +Parte de su configuración de Control de Acceso Basado en Roles (RBAC) puede requerir que cree Superusuarios adicionales, o usuarios con Roles Globales. + +* Los Superusuarios (Administradores) no tienen limitaciones en el sistema. Pueden cambiar toda la configuración, gestionar usuarios y tienen acceso de lectura/escritura a todos los datos. También pueden cambiar las reglas de acceso de todos los usuarios en DefectDojo. Los Superusuarios también recibirán notificaciones de todos los problemas y alertas del sistema. +* Los usuarios con Roles Globales pueden ver e interactuar con cualquier Tipo de Dato (Tipos de Producto, Productos, Compromisos, Tests y Hallazgos) en DefectDojo según el Rol que tengan asignado. Para más información sobre cada Rol y los privilegios asociados, consulte nuestro artículo de Introducción a los Roles. +* Los usuarios también pueden tener Permisos de Configuración específicos asignados, lo que les permite acceder a determinadas páginas de configuración de DefectDojo. Por defecto, los usuarios no tienen ningún Permiso de Configuración. + +Por defecto, la primera cuenta creada en una nueva instancia de DefectDojo tendrá permisos de Superusuario. Ese usuario podrá editar los permisos de todos los usuarios de DefectDojo que se creen posteriormente. Solo un Superusuario existente puede añadir otro superusuario, o añadir un Rol Global a un usuario. + +### Añadir el estado de Superusuario o Rol Global a un usuario existente + +1. Vaya a la página 👤 Users \> Users en la barra lateral. Verá una lista de todas las cuentas registradas en DefectDojo, junto con el estado Activo de cada cuenta, sus Roles Globales y otros datos relevantes del Usuario. +​ +![image](images/Set_a_User's_Permissions.png) +​ +2. Haga clic en el nombre de la cuenta a la que desea otorgar privilegios de Superusuario. Esto le llevará a su página de Usuario. +​ +3. En la sección Información Predeterminada de su página de Usuario, abra el menú ☰ y seleccione Editar. +​ +![image](images/Set_a_User's_Permissions_2.png) + +4. En la página Editar Usuario: +​ +Para el Estado de Superusuario, marque la casilla ☑️ Estado de Superusuario, ubicada en la Información Predeterminada del usuario. +​ +Para asignar un Rol Global, seleccione uno en el menú desplegable Rol Global, en la parte inferior de la página. +​ +![image](images/Set_a_User's_Permissions_3.png) +​ +5. Haga clic en Enviar para aceptar estos cambios. + +## Membresía de Producto \& Tipo de Producto + +Por defecto, ninguna cuenta nueva creada en DefectDojo tendrá permiso para ver ningún Dato de nivel de Producto. Será necesario asignarles membresía a cada Producto que quieran ver y con el que quieran interactuar. + +* La membresía de Producto \& Tipo de Producto solo puede configurarla **Superusuarios, Maintainers u Owners**. +* Los **Maintainers \& Owners** solo pueden configurar la membresía en Productos / Tipos de Producto a los que ya estén asignados. +* Los **Global Maintainers \& Owners** pueden configurar la membresía en cualquier Producto o Tipo de Producto, al igual que los **Superusuarios**. + +Los usuarios pueden tener dos tipos de membresía simultáneamente a nivel de **Producto**: + +* El Rol conferido por su membresía subyacente de Tipo de Producto, si corresponde +* Su Rol específico de Producto, si existe alguno. + +Si un usuario ya se ha añadido como miembro de un Tipo de Producto, y no necesita un nivel de permisos adicional en un Producto específico, no es necesario añadirlo como Miembro del Producto. + +### Añadir un nuevo Miembro + +1. Vaya al Producto o Tipo de Producto al que desea asignar un usuario. Puede seleccionar el Producto de la lista en **Products \> All Products**. + +![image](images/Set_a_User's_Permissions_4.png) + +2. Localice el encabezado **Members**, haga clic en el menú **☰** y seleccione **\+ Add Users**. +3. Esto le llevará a una página donde puede **registrar nuevos Miembros**. Seleccione un Usuario en el menú desplegable Users. +4. Seleccione el Rol que desea que tenga ese Usuario en este Producto o Tipo de Producto: **API Importer, Reader, Writer, Maintainer** u **Owner.** +​ +![image](images/Set_a_User's_Permissions_5.png) + +Los usuarios no pueden asignarse como Miembros de un Producto o Tipo de Producto sin tener también un Rol. Si no está seguro de qué Rol desea dar a un nuevo usuario, **Reader** es una buena opción "por defecto". Esto mantendrá el estado de su Producto seguro hasta que tome su decisión final sobre su Rol. + +### Editar o eliminar un Miembro + +Los Miembros pueden tener su Rol modificado dentro de un Producto o Tipo de Producto. + +Dentro de la página de **Producto** o **Tipo de Producto**, vaya al encabezado **Members** y haga clic en el botón **⋮** junto al Usuario que desea Editar o Eliminar. + +![image](images/Set_a_User's_Permissions_6.png) + +📝 **Edit** le llevará a la pantalla **Edit Member**, donde puede cambiar el **Rol** de este usuario (de **API Importer, Reader, Writer, Maintainer** u **Owner** a otra opción). + +🗑️ **Delete** elimina por completo la Membresía de un Usuario. No eliminará ninguna contribución ni cambio que el Usuario haya realizado en el Producto o Tipo de Producto. + +* Si no puede Editar ni Eliminar la Membresía de un usuario (el **⋮** no es visible) es porque esta Membresía le fue conferida a nivel de **Tipo de Producto**. +* Un usuario puede tener dos niveles de membresía dentro de un Producto: uno asignado a nivel de **Tipo de Producto** y otro asignado a nivel de **Producto**. + +#### Añadir un Rol de Producto adicional a un usuario con un Rol de Tipo de Producto relacionado + +Si un Usuario tiene un Rol a nivel de Tipo de Producto, también se le asignará Membresía con ese Rol en todos los Productos subyacentes dentro de esa categoría. Sin embargo, si desea que este Usuario tenga un Rol especial en un Producto específico dentro de ese Tipo de Producto, puede darle un Rol adicional a nivel de Producto. + +1. Desde la página del Producto, vaya al encabezado **Members**, haga clic en el menú **☰** y seleccione **\+ Add Users** (como si estuviera añadiendo un nuevo Usuario al Producto). +2. Seleccione el nombre del Usuario en el menú desplegable, y seleccione el Rol de Producto que desea asignar a ese Usuario. + +Un Rol de Producto tendrá prioridad sobre el Rol estándar de Tipo de Producto o el Rol Global de un usuario. Por ejemplo, si un Usuario tiene un Rol de Tipo de Producto de **Reader**, pero también está asignado como **Owner** en un Producto anidado bajo ese Tipo de Producto, tendrá permisos adicionales de **Owner** añadidos únicamente para ese Producto. + +Sin embargo, esto no funciona a la inversa. Si un Usuario tiene un Rol de Tipo de Producto o Rol Global de **Owner**, asignarle un rol de **Reader** en un Producto en particular no le quitará sus permisos de **Owner**. **Los Roles no pueden quitar permisos otorgados a un Usuario por otros Roles, solo pueden añadir permisos adicionales.** + +## Permisos de Configuración + +Muchos cuadros de diálogo de configuración y endpoints de la API pueden habilitarse para usuarios o grupos de usuarios, independientemente de su estado de superusuario. Estos Permisos de Configuración permiten a los usuarios habituales acceder y contribuir a partes de DefectDojo fuera de su asignación estándar de Producto o Rol de Producto. + +Los Permisos de Configuración no están relacionados con un Producto o Tipo de Producto específico: los usuarios pueden tener permisos de configuración asignados sin necesidad de otros estados o de Membresía de Producto / Tipo de Producto. +​ +### Lista de Permisos de Configuración + +* **Credential Manager:** Acceso a la página ⚙️Configuration \> Credential Manager +* **Development Environments:** Gestionar la lista Engagements \> Environments +* **Finding Templates:** Acceso a la página Findings \> Finding Templates +* **Groups**: Acceso a la página 👤Users \> Groups +* **Jira Instances:** Acceso a la página ⚙️Configuration \> JIRA +* **Language Types**: Acceso al endpoint de la API [Language Types](/automation/api/languages/) +* **Login Banner**: Editar la página ⚙️Configuration \> Login Banner +* **Announcements**: Acceso a ⚙️Configuration \> Announcements +* **Note Types:** Acceso a la página ⚙️Configuration \> Note Types +* **Product Types:** n/a +* **Questionnaires**: Acceso a la página Questionnaires \> All Questionnaires +* **Questions**: Acceso a la página Questionnaires \> Questions +* **Regulations**: Acceso a la página ⚙️Configuration \> Regulations +* **SLA Configuration:** Acceso a la página ⚙️Configuration \> SLA Configuration +* **Test Types:** Añadir o editar un Test Type (en Engagements \> Test Types) +* **Tool Configuration:** Acceso a la página **⚙️Configuration \> Tool Types** +* **Tool Types:** Acceso a la página ⚙️Configuration \> Tool Types +* **Users:** Acceso a la página 👤Users \> Users + +### Añadir Permisos de Configuración a un Usuario + +**Solo los Superusuarios pueden añadir Permisos de Configuración a un Usuario**. + +1. Vaya a la página 👤 Users \> Users en la barra lateral. Verá una lista de todas las cuentas registradas en DefectDojo, junto con el estado Activo de cada cuenta, sus Roles Globales y otros datos relevantes del Usuario. +​ +![image](images/Set_a_User's_Permissions_7.png) + +2. Haga clic en el nombre de la cuenta que desea editar. +​ +3. Vaya a la Lista de Permisos de Configuración. Se encuentra en el lado derecho de la página del Usuario. +​ +4. Seleccione los Permisos de Configuración de Usuario que desea añadir. +​ +Para un desglose detallado de los Permisos de Configuración de Usuario, consulte nuestro [Cuadro de Permisos](../user_permission_chart/). diff --git a/docs/content/admin/user_management/set_user_permissions.fr.md b/docs/content/admin/user_management/set_user_permissions.fr.md new file mode 100644 index 00000000000..dd580c0c486 --- /dev/null +++ b/docs/content/admin/user_management/set_user_permissions.fr.md @@ -0,0 +1,155 @@ +--- +title: Définir les autorisations d'un utilisateur +description: Comment attribuer des rôles et des autorisations à un utilisateur, ainsi + que le statut de superutilisateur +weight: 2 +audience: pro +aliases: +- /fr/en/customize_dojo/user_management/set_user_permissions +--- + +> **Fonctionnalité DefectDojo Pro.** Le système RBAC Membres / Groupes / Rôles globaux décrit sur cette page fait partie de DefectDojo Pro. La version open source de DefectDojo utilise le modèle [Utilisateurs autorisés](../os__authorized_users/) — consultez cette page pour le contrôle d'accès en version open source, ainsi que les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si vous passez d'une édition à l'autre. + +## Introduction aux types d'autorisations + +Chaque utilisateur peut se voir attribuer quatre types d'autorisations différents : + +* Les utilisateurs peuvent être ajoutés en tant que **Membres de Produits ou de Types de produit**. Cela leur permet de consulter et d'interagir avec les types de données (Types de produit, Produits, Engagements, Tests et Constatations) dans DefectDojo, selon le rôle qui leur est attribué sur le Produit concerné. Un utilisateur peut avoir plusieurs adhésions à des Produits ou Types de produit, avec des niveaux d'accès différents. +​ +* Les utilisateurs peuvent également se voir attribuer des **Autorisations de configuration**, qui leur permettent d'accéder aux pages de configuration de DefectDojo. Les Autorisations de configuration ne sont pas liées aux Produits ou aux Types de produit. +​ +* Les utilisateurs peuvent se voir attribuer des **Rôles globaux**, qui leur donnent un niveau d'accès standardisé à tous les Produits et Types de produit. +​ +* Les utilisateurs peuvent être configurés en tant que **Superutilisateurs** : des rôles de niveau administrateur qui leur donnent le contrôle et l'accès à toutes les données et à la configuration de DefectDojo. + +Vous pouvez également créer des Groupes si vous souhaitez attribuer une adhésion à un Produit, des Autorisations de configuration ou des Rôles globaux à un groupe d'utilisateurs en même temps. Si vous avez un grand nombre d'utilisateurs dans DefectDojo, comme une équipe de test dédiée à un Produit particulier, les Groupes peuvent être une fonctionnalité plus utile. + +## Superutilisateurs \& Rôles globaux + +Une partie de votre configuration de Contrôle d'accès basé sur les rôles (RBAC) peut nécessiter la création de Superutilisateurs supplémentaires, ou d'utilisateurs disposant de Rôles globaux. + +* Les Superutilisateurs (Admins) n'ont aucune limitation dans le système. Ils peuvent modifier tous les paramètres, gérer les utilisateurs et disposent d'un accès en lecture / écriture à toutes les données. Ils peuvent également modifier les règles d'accès de tous les utilisateurs de DefectDojo. Les Superutilisateurs reçoivent également les notifications pour tous les problèmes système et alertes. +* Les utilisateurs disposant de Rôles globaux peuvent consulter et interagir avec tout type de données (Types de produit, Produits, Engagements, Tests et Constatations) dans DefectDojo, selon le Rôle qui leur est attribué. Pour en savoir plus sur chaque Rôle et les privilèges associés, veuillez consulter notre article Introduction aux rôles. +* Les utilisateurs peuvent également se voir attribuer des Autorisations de configuration spécifiques, leur permettant d'accéder à certaines pages de configuration de DefectDojo. Par défaut, les utilisateurs ne disposent d'aucune Autorisation de configuration. + +Par défaut, le premier compte créé sur une nouvelle instance DefectDojo dispose des autorisations de Superutilisateur. Cet utilisateur pourra modifier les autorisations de tous les utilisateurs DefectDojo créés par la suite. Seul un Superutilisateur existant peut ajouter un autre superutilisateur, ou attribuer un Rôle global à un utilisateur. + +### Attribuer le statut de Superutilisateur ou un Rôle global à un utilisateur existant + +1. Accédez à la page 👤 Utilisateurs \> Utilisateurs dans la barre latérale. Vous verrez une liste de tous les comptes enregistrés dans DefectDojo, ainsi que le statut Actif, les Rôles globaux et les autres données pertinentes de chaque compte. +​ +![image](images/Set_a_User's_Permissions.png) +​ +2. Cliquez sur le nom du compte auquel vous souhaitez accorder les privilèges de Superutilisateur. Vous accéderez ainsi à sa Page utilisateur. +​ +3. Dans la section Informations par défaut de sa Page utilisateur, ouvrez le menu ☰ et sélectionnez Modifier. +​ +![image](images/Set_a_User's_Permissions_2.png) + +4. Depuis la page Modifier l'utilisateur : +​ +Pour le Statut de superutilisateur, cochez la case ☑️ Statut de superutilisateur, située dans les Informations par défaut de l'utilisateur. +​ +Pour attribuer un Rôle global, sélectionnez-en un dans le menu déroulant Rôle global en bas de la page. +​ +![image](images/Set_a_User's_Permissions_3.png) +​ +5. Cliquez sur Envoyer pour valider ces modifications. + +## Adhésion à un Produit et à un Type de produit + +Par défaut, tout nouveau compte créé dans DefectDojo n'a pas l'autorisation de consulter les données au niveau des Produits. Il devra se voir attribuer une adhésion à chaque Produit qu'il souhaite consulter et avec lequel il souhaite interagir. + +* L'adhésion à un Produit et à un Type de produit ne peut être configurée que par des **Superutilisateurs, Mainteneurs ou Propriétaires**. +* Les **Mainteneurs et Propriétaires** ne peuvent configurer l'adhésion que sur les Produits / Types de produit auxquels ils sont déjà affectés. +* Les **Mainteneurs et Propriétaires globaux** peuvent configurer l'adhésion sur n'importe quel Produit ou Type de produit, tout comme les **Superutilisateurs**. + +Les utilisateurs peuvent avoir deux types d'adhésion simultanément au niveau du **Produit** : + +* Le Rôle conféré par leur adhésion au Type de produit sous-jacent, le cas échéant +* Leur Rôle spécifique au Produit, s'il en existe un. + +Si un utilisateur a déjà été ajouté en tant que membre d'un Type de produit et n'a pas besoin d'un niveau d'autorisation supplémentaire sur un Produit spécifique, il n'est pas nécessaire de l'ajouter en tant que Membre du Produit. + +### Ajouter un nouveau Membre + +1. Accédez au Produit ou au Type de produit auquel vous souhaitez affecter un utilisateur. Vous pouvez sélectionner le Produit dans la liste sous **Produits \> Tous les produits**. + +![image](images/Set_a_User's_Permissions_4.png) + +2. Repérez le titre **Membres**, cliquez sur le menu **☰**, puis sélectionnez **\+ Ajouter des utilisateurs**. +3. Vous accéderez ainsi à une page où vous pouvez **Enregistrer de nouveaux Membres**. Sélectionnez un Utilisateur dans le menu déroulant Utilisateurs. +4. Sélectionnez le Rôle que vous souhaitez attribuer à cet Utilisateur sur ce Produit ou ce Type de produit : **Importateur API, Lecteur, Rédacteur, Mainteneur** ou **Propriétaire.** +​ +![image](images/Set_a_User's_Permissions_5.png) + +Un utilisateur ne peut pas être ajouté en tant que Membre d'un Produit ou d'un Type de produit sans se voir également attribuer un Rôle. Si vous ne savez pas quel Rôle attribuer à un nouvel utilisateur, **Lecteur** est une bonne option « par défaut ». Cela permettra de garder l'état de votre Produit sécurisé jusqu'à ce que vous ayez pris votre décision finale concernant son Rôle. + +### Modifier ou Supprimer un Membre + +Le Rôle des Membres peut être modifié au sein d'un Produit ou d'un Type de produit. + +Sur la page **Produit** ou **Type de produit**, accédez au titre **Membres** et cliquez sur le bouton **⋮** à côté de l'Utilisateur que vous souhaitez Modifier ou Supprimer. + +![image](images/Set_a_User's_Permissions_6.png) + +📝 **Modifier** vous amène à l'écran **Modifier le membre**, où vous pouvez changer le **Rôle** de cet utilisateur (parmi **Importateur API, Lecteur, Rédacteur, Mainteneur** ou **Propriétaire**, vers un autre choix). + +🗑️ **Supprimer** retire entièrement l'adhésion d'un Utilisateur. Cela ne supprime pas les contributions ni les modifications que l'Utilisateur a apportées au Produit ou au Type de produit. + +* Si vous ne pouvez pas Modifier ou Supprimer l'adhésion d'un utilisateur (le **⋮** n'est pas visible), c'est parce que cette adhésion lui est conférée au niveau du **Type de produit**. +* Un utilisateur peut avoir deux niveaux d'adhésion au sein d'un Produit \- l'un attribué au niveau du **Type de produit** et l'autre au niveau du **Produit**. + +#### Attribuer un rôle Produit supplémentaire à un utilisateur ayant un rôle Type de produit associé + +Si un Utilisateur dispose d'un Rôle au niveau du Type de produit, il se verra également attribuer une adhésion avec ce Rôle sur chaque Produit sous-jacent de la catégorie. Cependant, si vous souhaitez que cet Utilisateur dispose d'un Rôle spécial sur un Produit particulier au sein de ce Type de produit, vous pouvez lui attribuer un Rôle supplémentaire au niveau du Produit. + +1. Depuis la page du Produit, accédez au titre **Membres**, cliquez sur le menu **☰**, puis sélectionnez **\+ Ajouter des utilisateurs** (comme si vous ajoutiez un nouvel Utilisateur au Produit). +2. Sélectionnez le nom de l'Utilisateur dans le menu déroulant, puis sélectionnez le Rôle Produit que vous souhaitez lui attribuer. + +Un Rôle Produit prévaut sur le Rôle Type de produit ou le Rôle global standard d'un utilisateur. Par exemple, si un Utilisateur a un Rôle Type de produit de **Lecteur**, mais est également désigné comme **Propriétaire** sur un Produit imbriqué dans ce Type de produit, il disposera d'autorisations **Propriétaire** supplémentaires pour ce Produit uniquement. + +Cependant, cela ne fonctionne pas dans l'autre sens. Si un Utilisateur a un Rôle Type de produit ou un Rôle global de **Propriétaire**, lui attribuer un rôle **Lecteur** sur un Produit particulier ne lui retirera pas ses autorisations de **Propriétaire**. **Les Rôles ne peuvent pas retirer les autorisations accordées à un Utilisateur par d'autres Rôles, ils ne peuvent qu'ajouter des autorisations supplémentaires.** + +## Autorisations de configuration + +De nombreuses boîtes de dialogue de configuration et points de terminaison API peuvent être activés pour des utilisateurs ou des groupes d'utilisateurs, indépendamment de leur statut de superutilisateur. Ces Autorisations de configuration permettent aux utilisateurs standard d'accéder à certaines parties de DefectDojo et d'y contribuer, en dehors de leur affectation habituelle à un Produit ou un Rôle Produit. + +Les Autorisations de configuration ne sont pas liées à un Produit ou à un Type de produit spécifique \- les utilisateurs peuvent se voir attribuer des autorisations de configuration sans avoir besoin d'autres statuts ou d'une adhésion à un Produit / Type de produit. +​ +### Liste des Autorisations de configuration + +* **Gestionnaire d'identifiants :** Accès à la page ⚙️Configuration \> Gestionnaire d'identifiants +* **Environnements de développement :** Gérer la liste Engagements \> Environnements +* **Modèles de constatation :** Accès à la page Constatations \> Modèles de constatation +* **Groupes** : Accéder à la page 👤Utilisateurs \> Groupes +* **Instances Jira :** Accéder à la page ⚙️Configuration \> JIRA +* **Types de langage** : Accéder au point de terminaison API [Types de langage](/automation/api/languages/) +* **Bannière de connexion** : Modifier la page ⚙️Configuration \> Bannière de connexion +* **Annonces** : Accéder à ⚙️Configuration \> Annonces +* **Types de note :** Accéder à la page ⚙️Configuration \> Types de note +* **Types de produit :** n/a +* **Questionnaires** : Accéder à la page Questionnaires \> Tous les questionnaires +* **Questions** : Accéder à la page Questionnaires \> Questions +* **Réglementations** : Accéder à la page ⚙️Configuration \> Réglementations +* **Configuration SLA :** Accéder à la page ⚙️Configuration \> Configuration SLA +* **Types de test :** Ajouter ou modifier un Type de test (sous Engagements \> Types de test) +* **Configuration des outils :** Accéder à la page **⚙️Configuration \> Types d'outils** +* **Types d'outils :** Accéder à la page ⚙️Configuration \> Types d'outils +* **Utilisateurs :** Accéder à la page 👤Utilisateurs \> Utilisateurs + +### Attribuer des Autorisations de configuration à un Utilisateur + +**Seuls les Superutilisateurs peuvent attribuer des Autorisations de configuration à un Utilisateur**. + +1. Accédez à la page 👤 Utilisateurs \> Utilisateurs dans la barre latérale. Vous verrez une liste de tous les comptes enregistrés dans DefectDojo, ainsi que le statut Actif, les Rôles globaux et les autres données pertinentes de chaque compte. +​ +![image](images/Set_a_User's_Permissions_7.png) + +2. Cliquez sur le nom du compte que vous souhaitez modifier. +​ +3. Accédez à la Liste des Autorisations de configuration. Elle se trouve sur le côté droit de la Page utilisateur. +​ +4. Sélectionnez les Autorisations de configuration utilisateur que vous souhaitez ajouter. +​ +Pour une répartition détaillée des Autorisations de configuration utilisateur, veuillez consulter notre [Tableau des autorisations](../user_permission_chart/). diff --git a/docs/content/admin/user_management/set_user_permissions.ja.md b/docs/content/admin/user_management/set_user_permissions.ja.md new file mode 100644 index 00000000000..a496b9aa25b --- /dev/null +++ b/docs/content/admin/user_management/set_user_permissions.ja.md @@ -0,0 +1,154 @@ +--- +title: ユーザーの権限を設定する +description: ユーザーにロールと権限、およびスーパーユーザー権限を付与する方法 +weight: 2 +audience: pro +aliases: +- /ja/en/customize_dojo/user_management/set_user_permissions +--- + +> **DefectDojo Pro の機能です。** このページで説明する メンバー / グループ / グローバルロール のRBACシステムは、DefectDojo Pro の一部です。オープンソース版のDefectDojoでは、[Authorized Users](../os__authorized_users/) モデルを使用します — オープンソース版のアクセス制御についてはそのページを、エディション間を移行する場合は [3.0 アップグレードノート](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) を参照してください。 + +## パーミッションタイプの概要 + +個々のユーザーには、割り当て可能な4種類の権限があります。 + +* ユーザーは **製品または製品タイプのメンバー** として割り当てることができます。これにより、特定の製品で割り当てられたロールに応じて、DefectDojo内のデータタイプ(製品タイプ、製品、エンゲージメント、テスト、検出事項)を閲覧し、操作できるようになります。ユーザーは複数の製品または製品タイプのメンバーシップを持つことができ、それぞれ異なるレベルのアクセス権を設定できます。 +​ +* ユーザーには **コンフィギュレーション権限**(Configuration Permissions)を割り当てることもでき、これによりDefectDojoの設定ページにアクセスできるようになります。コンフィギュレーション権限は製品や製品タイプとは関連していません。 +​ +* ユーザーには **グローバルロール** を割り当てることができ、これによりすべての製品および製品タイプに対して標準化されたレベルのアクセス権が付与されます。 +​ +* ユーザーは **スーパーユーザー** として設定できます。これは管理者レベルのロールであり、DefectDojoのすべてのデータと設定に対する制御とアクセス権を付与します。 + +製品メンバーシップ、コンフィギュレーション権限、またはグローバルロールを複数のユーザーに同時に割り当てたい場合は、グループを作成することもできます。特定の製品専用のテストチームなど、DefectDojoに多数のユーザーがいる場合は、グループ機能の方が便利な場合があります。 + +## スーパーユーザー \& グローバルロール + +ロールベースアクセス制御(RBAC)の設定の一環として、追加のスーパーユーザーやグローバルロールを持つユーザーを作成する必要がある場合があります。 + +* スーパーユーザー(管理者)には、システム内での制限がありません。すべての設定を変更し、ユーザーを管理し、すべてのデータへの読み取り/書き込みアクセス権を持ちます。また、DefectDojo内のすべてのユーザーのアクセスルールを変更することもできます。スーパーユーザーは、すべてのシステム上の問題やアラートについての通知も受け取ります。 +* グローバルロールを持つユーザーは、割り当てられたロールに応じて、DefectDojo内の任意のデータタイプ(製品タイプ、製品、エンゲージメント、テスト、検出事項)を閲覧し、操作できます。各ロールと関連する権限の詳細については、「ロールの概要」の記事を参照してください。 +* ユーザーには特定のコンフィギュレーション権限を割り当てることもでき、これにより特定のDefectDojo設定ページにアクセスできるようになります。ユーザーにはデフォルトでコンフィギュレーション権限はありません。 + +デフォルトでは、新しいDefectDojoインスタンスで最初に作成されたアカウントにはスーパーユーザー権限が付与されます。そのユーザーは、以降に作成されるすべてのDefectDojoユーザーの権限を編集できます。既存のスーパーユーザーのみが、他のスーパーユーザーを追加したり、ユーザーにグローバルロールを追加したりできます。 + +### 既存のユーザーにスーパーユーザーまたはグローバルロールのステータスを追加する + +1. サイドバーの 👤 Users \> Users ページに移動します。DefectDojoに登録されているすべてのアカウントの一覧が、各アカウントのアクティブ状態、グローバルロール、その他の関連ユーザーデータとともに表示されます。 +​ +![image](images/Set_a_User's_Permissions.png) +​ +2. スーパーユーザー権限を付与したいアカウントの名前をクリックします。これにより、そのユーザーのユーザーページに移動します。 +​ +3. ユーザーページの「Default Information」セクションから、☰ メニューを開き、「Edit」を選択します。 +​ +![image](images/Set_a_User's_Permissions_2.png) + +4. 「Edit User」ページで: +​ +スーパーユーザーステータスを設定するには、ユーザーの「Default Information」内にある ☑️「Superuser Status」ボックスにチェックを入れます。 +​ +グローバルロールを割り当てるには、ページ下部のドロップダウンの「Global Role」メニューから選択します。 +​ +![image](images/Set_a_User's_Permissions_3.png) +​ +5. 「Submit」をクリックして変更を確定します。 + +## 製品 \& 製品タイプ のメンバーシップ + +デフォルトでは、DefectDojoで新規作成されたアカウントには、製品レベルのデータを閲覧する権限がありません。閲覧・操作したい各製品にメンバーシップを割り当てる必要があります。 + +* 製品 \& 製品タイプ のメンバーシップは、**スーパーユーザー、メンテナー、またはオーナー** のみが設定できます。 +* **メンテナー \& オーナー** は、自分が既に割り当てられている製品/製品タイプのメンバーシップのみを設定できます。 +* **グローバルメンテナー \& オーナー** は、**スーパーユーザー** と同様に、任意の製品または製品タイプのメンバーシップを設定できます。 + +ユーザーは **製品** レベルで、同時に2種類のメンバーシップを持つことができます。 + +* 該当する場合、基盤となる製品タイプメンバーシップによって付与されるロール +* 存在する場合、その製品固有のロール + +ユーザーがすでに製品タイプのメンバーとして追加されており、特定の製品に対して追加の権限レベルを必要としない場合は、そのユーザーを製品メンバーとして追加する必要はありません。 + +### 新しいメンバーを追加する + +1. ユーザーを割り当てたい製品または製品タイプに移動します。製品は **Products \> All Products** の下の一覧から選択できます。 + +![image](images/Set_a_User's_Permissions_4.png) + +2. **Members** の見出しを見つけ、**☰** メニューをクリックして **\+ Add Users** を選択します。 +3. これにより、**新しいメンバーを登録** できるページに移動します。ドロップダウンの Users メニューからユーザーを選択します。 +4. この製品または製品タイプでそのユーザーに持たせたいロールを選択します: **API Importer、Reader、Writer、Maintainer**、または **Owner** です。 +​ +![image](images/Set_a_User's_Permissions_5.png) + +ロールを持たずに、ユーザーを製品または製品タイプのメンバーとして割り当てることはできません。新しいユーザーにどのロールを持たせるべきか分からない場合は、**Reader** が「デフォルト」の選択肢として適しています。これにより、ロールについて最終的な決定を下すまでの間、製品の状態を安全に保つことができます。 + +### メンバーを編集または削除する + +メンバーのロールは、製品または製品タイプ内で変更できます。 + +**Product** または **Product Type** ページ内で、**Members** の見出しに移動し、編集または削除したいユーザーの横にある **⋮** ボタンをクリックします。 + +![image](images/Set_a_User's_Permissions_6.png) + +📝 **Edit** をクリックすると **Edit Member** 画面に移動し、このユーザーの **Role** を変更できます(**API Importer、Reader、Writer、Maintainer**、または **Owner** から別の選択肢へ)。 + +🗑️ **Delete** はユーザーのメンバーシップを完全に削除します。これにより、そのユーザーが製品または製品タイプに対して行った貢献や変更が削除されることはありません。 + +* ユーザーのメンバーシップを編集または削除できない場合(**⋮** が表示されない場合)、それはそのメンバーシップが **Product Type** レベルで付与されているためです。 +* ユーザーは製品内で2つのレベルのメンバーシップを持つことができます \- 1つは **Product Type** レベルで割り当てられたもの、もう1つは **Product** レベルで割り当てられたものです。 + +#### 関連する製品タイプロールを持つユーザーに追加の製品ロールを付与する + +ユーザーが製品タイプレベルのロールを持っている場合、そのカテゴリー内のすべての基盤となる製品に対しても、そのロールでメンバーシップが割り当てられます。ただし、その製品タイプ内の特定の製品でこのユーザーに特別なロールを持たせたい場合は、製品レベルで追加のロールを付与できます。 + +1. 製品ページから **Members** の見出しに移動し、**☰** メニューをクリックして **\+ Add Users** を選択します(製品に新しいユーザーを追加する場合と同様です)。 +2. ドロップダウンメニューからユーザーの名前を選択し、そのユーザーに割り当てたい製品ロールを選択します。 + +製品ロールは、ユーザーの標準的な製品タイプロールやグローバルロールよりも優先されます。例えば、あるユーザーが製品タイプロールとして **Reader** を持っているが、その製品タイプの下にネストされた製品で **Owner** としても割り当てられている場合、その製品に限り追加の **Owner** 権限が付与されます。 + +ただし、これは逆には機能しません。ユーザーが製品タイプロールまたはグローバルロールとして **Owner** を持っている場合、特定の製品に **Reader** ロールを割り当てても、その **Owner** 権限が失われることはありません。**ロールは、他のロールによってユーザーに付与された権限を取り消すことはできず、権限を追加することしかできません。** + +## コンフィギュレーション権限 + +多くの設定ダイアログやAPIエンドポイントは、スーパーユーザーであるかどうかに関わらず、ユーザーやユーザーグループに対して有効化できます。これらのコンフィギュレーション権限により、通常のユーザーが標準の製品や製品ロールの割り当て範囲外のDefectDojoの部分にアクセスし、貢献できるようになります。 + +コンフィギュレーション権限は特定の製品や製品タイプとは関連していません \- ユーザーは、他のステータスや製品/製品タイプのメンバーシップを必要とせずに、コンフィギュレーション権限を割り当てられます。 +​ +### コンフィギュレーション権限の一覧 + +* **Credential Manager:** ⚙️Configuration \> Credential Manager ページへのアクセス +* **Development Environments:** Engagements \> Environments リストの管理 +* **Finding Templates:** Findings \> Finding Templates ページへのアクセス +* **Groups**: 👤Users \> Groups ページへのアクセス +* **Jira Instances:** ⚙️Configuration \> JIRA ページへのアクセス +* **Language Types**:[Language Types](/automation/api/languages/) APIエンドポイントへのアクセス +* **Login Banner**: ⚙️Configuration \> Login Banner ページの編集 +* **Announcements**: ⚙️Configuration \> Announcements へのアクセス +* **Note Types:** ⚙️Configuration \> Note Types ページへのアクセス +* **Product Types:** 該当なし +* **Questionnaires**: Questionnaires \> All Questionnaires ページへのアクセス +* **Questions**: Questionnaires \> Questions ページへのアクセス +* **Regulations**: ⚙️Configuration \> Regulations ページへのアクセス +* **SLA Configuration:** ⚙️Configuration \> SLA Configuration ページへのアクセス +* **Test Types:** テストタイプの追加または編集(Engagements \> Test Types 内) +* **Tool Configuration:** **⚙️Configuration \> Tool Types** ページへのアクセス +* **Tool Types:** ⚙️Configuration \> Tool Types ページへのアクセス +* **Users:** 👤Users \> Users ページへのアクセス + +### ユーザーにコンフィギュレーション権限を追加する + +**ユーザーにコンフィギュレーション権限を追加できるのはスーパーユーザーのみです**。 + +1. サイドバーの 👤 Users \> Users ページに移動します。DefectDojoに登録されているすべてのアカウントの一覧が、各アカウントのアクティブ状態、グローバルロール、その他の関連ユーザーデータとともに表示されます。 +​ +![image](images/Set_a_User's_Permissions_7.png) + +2. 編集したいアカウントの名前をクリックします。 +​ +3. コンフィギュレーション権限の一覧に移動します。これはユーザーページの右側に配置されています。 +​ +4. 追加したいユーザーコンフィギュレーション権限を選択します。 +​ +ユーザーコンフィギュレーション権限の詳細な内訳については、[Permission Chart](../user_permission_chart/) を参照してください。 diff --git a/docs/content/admin/user_management/user_permission_chart.de.md b/docs/content/admin/user_management/user_permission_chart.de.md new file mode 100644 index 00000000000..6efd00e7041 --- /dev/null +++ b/docs/content/admin/user_management/user_permission_chart.de.md @@ -0,0 +1,99 @@ +--- +title: Berechtigungsübersichten für Aktionen +description: Alle Benutzerberechtigungen von DefectDojo Pro im Detail +weight: 4 +audience: pro +aliases: +- /de/en/customize_dojo/user_management/user_permission_chart +--- + +> **DefectDojo Pro-Funktion.** Das auf dieser Seite beschriebene RBAC-System für Mitglieder/Gruppen/Globale Rollen ist Teil von DefectDojo Pro. Open-Source-DefectDojo verwendet das Modell [Autorisierte Benutzer](../os__authorized_users/) — siehe diese Seite für die Zugriffskontrolle in der Open-Source-Version sowie die [3.0-Upgrade-Hinweise](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization), wenn Sie zwischen den Editionen wechseln. + +## Rollen-Berechtigungsübersicht + +Diese Übersicht listet alle Berechtigungen auf, die sich auf ein Produkt oder einen Produkttyp beziehen, sowie welche Berechtigungen für welche Rolle verfügbar sind. + +Die folgenden fünf Rollen sind die **integrierten Rollen** von DefectDojo Pro. Es handelt sich um feste Voreinstellungen: Ihre Berechtigungen sind auf jeder Instanz identisch und können nicht geändert werden. Wenn Sie eigene Rollen erstellt haben, beschreibt diese Übersicht die integrierten Rollen, aus denen sie geklont wurden, und nicht die Rollen selbst. Den vollständigen Katalog der Berechtigungen, die einer Rolle zugewiesen werden können, finden Sie unter [Benutzerdefinierte RBAC-Rollen](../pro__custom_rbac_roles/#choosing-permissions). + +| **Abschnitt** | **Berechtigung** | Reader | Writer | Maintainer | Owner | API Importer | +| --- | --- | --- | --- | --- | --- | --- | +| **Produkt-/Produkttyp-Zugriff** | Zugewiesenes Produkt oder Produkttyp anzeigen ¹ | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Verschachtelte Produkte, Engagements, Tests, Befunde, Endpunkte anzeigen | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Neue Produkte hinzufügen (innerhalb des zugewiesenen Produkttyps) ² | | | ☑️ | ☑️ | | +| | Zugewiesene Produkte oder Produkttypen löschen | | | | ☑️ | | +| **Produkt-/Produkttyp-Mitgliedschaft** | Benutzer als Mitglieder hinzufügen (ohne Owner-Rolle) | | | ☑️ | ☑️ | | +| | Rollen von Mitgliedern bearbeiten (ohne Owner-Rolle) | | | ☑️ | ☑️ | | +| | Rollen von Mitgliedern bearbeiten (einschließlich Owner-Rolle) | | | | ☑️ | | +| | Sich selbst aus der Produkt-/Produkttyp-Mitgliedschaft entfernen | ☑️ | ☑️ | ☑️ | ☑️ | | +| | Einem anderen Benutzer eine Owner-Rolle zuweisen | | | | ☑️ | | +| | Eine zugehörige Produkt-/Produkttyp-Mitgliedschaft innerhalb einer Gruppe bearbeiten³ | | | | ☑️ | | +| | Eine zugehörige Produkt-/Produkttyp-Mitgliedschaft innerhalb einer Gruppe löschen³ | | | | | | +| **Engagements** (innerhalb eines Produkts) | Engagements hinzufügen, bearbeiten | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Risikoakzeptanzen anzeigen ⁴ | | ☑️ | ☑️ | ☑️ | | +| | Risikoakzeptanzen hinzufügen, bearbeiten | | ☑️ | ☑️ | ☑️ | | +| | Engagements löschen | | | ☑️ | ☑️ | | +| **Tests** (innerhalb eines Produkts) | Tests hinzufügen | | ☑️ | ☑️ | ☑️ | | +| | Tests bearbeiten | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Tests löschen | | | ☑️ | ☑️ | | +| **Befunde** (innerhalb eines Produkts) | Befunde hinzufügen | | ☑️ | ☑️ | ☑️ | | +| | Befunde bearbeiten | | ☑️ | ☑️ | ☑️ | | +| | Scan-Ergebnisse importieren, erneut importieren | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Befunde löschen | | | ☑️ | ☑️ | | +| | Finding-Gruppen hinzufügen, bearbeiten, löschen | | ☑️ | ☑️ | ☑️ | | +| **Weitere Daten** (innerhalb eines Produkts) | Endpunkte hinzufügen, bearbeiten | | ☑️ | ☑️ | ☑️ | | +| | Endpunkte löschen | | | ☑️ | ☑️ | | +| | Benchmarks bearbeiten | | ☑️ | ☑️ | ☑️ | | +| | Benchmarks löschen | | | ☑️ | ☑️ | | +| | Notizverlauf anzeigen | ☑️ | ☑️ | ☑️ | ☑️ | | +| | Eigene Notizen hinzufügen, bearbeiten, löschen | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Notizen anderer bearbeiten | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Notizen anderer löschen | | | ☑️ | ☑️ | | + +1. Ein Benutzer, dem nur auf Produktebene Berechtigungen zugewiesen wurden, kann den Produkttyp, dem das Produkt zugeordnet ist, nicht einsehen. +2. Wenn ein neues Produkt unter einem Produkttyp hinzugefügt wird, werden alle Benutzer auf Produkttyp-Ebene mit ihrer Produkttyp-Rolle als Mitglieder des neuen Produkts hinzugefügt. +3. Der Benutzer, der Änderungen an einer Gruppe vornehmen möchte, muss außerdem über die **Konfigurationsberechtigung** **Gruppe bearbeiten** sowie über die **Gruppen-Konfigurationsrolle** **Maintainer oder Owner** in der Gruppe verfügen, die er bearbeiten möchte. +4. Die Sichtbarkeit von Risikoakzeptanzen wird durch eine eigene Mindestberechtigung geregelt, die sich von der Sichtbarkeit von Befunden unterscheidet — ein Reader für das Produkt kann die zugrunde liegenden Befunde einsehen, aber **nicht** die Risikoakzeptanzen, zu denen diese Befunde gehören. Details zu Berechtigungen für Risikoakzeptanzen, dem Verhalten des Ablaufdatums und den Workflows zur Wiedereinsetzung finden Sie unter [Risikoakzeptanzen (Pro)](/triage_findings/findings_workflows/pro__risk_acceptance/#risk-acceptance-permissions-and-visibility). + +## Konfigurationsberechtigungsübersicht + +Jede Konfigurationsberechtigung bezieht sich auf eine bestimmte Funktion der Software und ist mit einer Reihe von Aktionen verknüpft, die ein Benutzer im Zusammenhang mit dieser Funktion ausführen kann. + +Die meisten Konfigurationsberechtigungen gewähren Benutzern Zugriff auf bestimmte Seiten der Benutzeroberfläche. + +| **Konfigurationsberechtigung** | **Anzeigen ☑️** | **Hinzufügen ☑️** | **Bearbeiten ☑️** | **Löschen ☑️** | +| --- | --- | --- | --- | --- | +| Credential Manager | Zugriff auf die Seite **⚙️Konfiguration \> Credential Manager** | Neue Einträge im Credential Manager hinzufügen | Einträge im Credential Manager bearbeiten | Einträge im Credential Manager löschen | +| Entwicklungsumgebungen | entfällt | Neue Entwicklungsumgebungen zur Liste 🗓️**Engagements \> Umgebungen** hinzufügen | Entwicklungsumgebungen in der Liste 🗓️**Engagements \> Umgebungen** bearbeiten | Entwicklungsumgebungen aus der Liste **🗓️Engagements \> Umgebungen** löschen | +| Finding-Vorlagen¹ | Zugriff auf die Seite **Befunde \> Finding-Vorlagen** | Eine Finding-Vorlage hinzufügen | Eine Finding-Vorlage bearbeiten | Eine Finding-Vorlage löschen | +| Gruppen | Zugriff auf die Seite **👤Benutzer \> Gruppen** | Eine neue Benutzergruppe hinzufügen | Nur Superuser | Nur Superuser | +| Jira-Instanzen | Zugriff auf die **Seite ⚙️Konfiguration \> JIRA** | Eine neue JIRA-Konfiguration hinzufügen | Eine bestehende JIRA-Konfiguration bearbeiten | Eine JIRA-Konfiguration löschen | +| Sprachtypen | | | | | +| Login-Banner | entfällt | entfällt | Das Login-Banner bearbeiten, zu finden unter **⚙️Konfiguration \> Login-Banner** | entfällt | +| Ankündigungen | entfällt | entfällt | Ankündigungen konfigurieren, zu finden unter **⚙️Konfiguration \> Ankündigungen** | entfällt | +| Notiztypen | Zugriff auf die Seite ⚙️Konfiguration \> Notiztypen | Einen Notiztyp hinzufügen | Einen Notiztyp bearbeiten | Einen Notiztyp löschen | +| Priorisierungs-Engines | Zugriff auf die Konfigurationsseite der Priorisierungs-Engine | Eine neue Priorisierungs-Engine hinzufügen | Eine bestehende Priorisierungs-Engine bearbeiten | Eine Priorisierungs-Engine löschen | +| Produkttypen | entfällt | Einen neuen Produkttyp hinzufügen (unter Produkte \> Produkttyp) | entfällt | entfällt | +| Fragebögen | Zugriff auf die Seite **Fragebögen \> Alle Fragebögen** | Einen neuen Fragebogen hinzufügen | Einen bestehenden Fragebogen bearbeiten | Einen Fragebogen löschen | +| Fragen | Zugriff auf die Seite **Fragebögen \> Fragen** | Eine neue Frage hinzufügen | Eine bestehende Frage bearbeiten | entfällt | +| Regularien | entfällt | Eine Regularie zur Seite **⚙️Konfiguration \> Regularien** hinzufügen | Eine bestehende Regularie bearbeiten | Eine Regularie löschen | +| Scheduling Service Schedule | Zugriff auf die Seite **Scheduling** | Nur Superuser | Einen bestehenden Zeitplan bearbeiten (Trigger ändern, aktivieren/deaktivieren) | Einen Zeitplan löschen | +| SLA-Konfiguration | Zugriff auf die Seite **⚙️Konfiguration \> SLA-Konfiguration** | Eine neue SLA-Konfiguration hinzufügen | Eine bestehende SLA-Konfiguration bearbeiten | Eine SLA-Konfiguration löschen | +| Testtypen | entfällt | Einen neuen Testtyp hinzufügen (unter **Engagements \> Testtypen**) | Einen bestehenden Testtyp bearbeiten | entfällt | +| Tool-Konfiguration | Zugriff auf die Seite **⚙️Konfiguration \> Tool-Konfiguration** | Eine neue Tool-Konfiguration hinzufügen | Eine bestehende Tool-Konfiguration bearbeiten | Eine Tool-Konfiguration löschen | +| Tool-Typen | Zugriff auf die Seite **⚙️Konfiguration \> Tool-Typen** | Einen neuen Tool-Typ hinzufügen | Einen bestehenden Tool-Typ bearbeiten | Einen Tool-Typ löschen | +| Benutzer | Zugriff auf die Seite **👤Benutzer \> Benutzer** | Einen neuen Benutzer zu DefectDojo hinzufügen | Einen bestehenden Benutzer bearbeiten | Einen Benutzer löschen | + +1. Der Zugriff auf die Seite Finding-Vorlagen erfordert für diesen Benutzer außerdem die Globale Rolle **Writer, Maintainer** oder **Owner**. + +## Gruppen-Konfigurationsberechtigungen + +| Konfigurationsberechtigung | **Reader** | **Maintainer** | **Owner** | +| --- | --- | --- | --- | +| Gruppe anzeigen | ☑️ | ☑️ | ☑️ | +| Sich selbst aus der Gruppe entfernen | ☑️ | ☑️ | ☑️ | +| Die Rolle eines Mitglieds in einer Gruppe bearbeiten | | ☑️ | ☑️ | +| Eine Produkt- oder Produkttyp-Mitgliedschaft aus einer Gruppe bearbeiten oder löschen¹ | | ☑️ | ☑️ | +| Die Rolle eines Gruppenmitglieds zu Owner ändern | | | ☑️ | +| Gruppe löschen | | | ☑️ | + +1. Dies erfordert außerdem, dass der Benutzer mindestens die Rolle Maintainer für das Produkt oder den Produkttyp hat, das bzw. den er bearbeiten möchte. diff --git a/docs/content/admin/user_management/user_permission_chart.es.md b/docs/content/admin/user_management/user_permission_chart.es.md new file mode 100644 index 00000000000..a6ddeb90f23 --- /dev/null +++ b/docs/content/admin/user_management/user_permission_chart.es.md @@ -0,0 +1,99 @@ +--- +title: Cuadros de permisos por acción +description: Todos los permisos de usuario de DefectDojo Pro en detalle +weight: 4 +audience: pro +aliases: +- /es/en/customize_dojo/user_management/user_permission_chart +--- + +> **Función de DefectDojo Pro.** El sistema RBAC de Miembros / Grupos / Roles Globales descrito en esta página forma parte de DefectDojo Pro. DefectDojo de código abierto utiliza el modelo de [Usuarios Autorizados](../os__authorized_users/) — consulte esa página para el control de acceso de código abierto, y las [notas de actualización a 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si está migrando entre ediciones. + +## Cuadro de permisos por Rol + +Este cuadro pretende enumerar todos los permisos relacionados con un Producto o Tipo de Producto, así como qué permisos están disponibles para cada rol. + +Los cinco roles siguientes son los **roles integrados** de DefectDojo Pro. Son preajustes fijos: sus permisos son los mismos en cada instancia y no se pueden modificar. Si ha creado sus propios roles, este cuadro describe los roles integrados a partir de los cuales se clonaron, no los roles en sí. Para ver el catálogo completo de permisos que se le pueden otorgar a un rol, consulte [Roles RBAC personalizados](../pro__custom_rbac_roles/#choosing-permissions). + +| **Sección** | **Permiso** | Reader | Writer | Maintainer | Owner | API Importer | +| --- | --- | --- | --- | --- | --- | --- | +| **Acceso a Producto / Tipo de Producto** | Ver el Producto o Tipo de Producto asignado ¹ | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Ver los Productos, Compromisos, Tests, Hallazgos y Endpoints anidados | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Añadir nuevos Productos (dentro del Tipo de Producto asignado) ² | | | ☑️ | ☑️ | | +| | Eliminar los Productos o Tipos de Producto asignados | | | | ☑️ | | +| **Membresía de Producto / Tipo de Producto** | Añadir Usuarios como Miembros (excluyendo el Rol Owner) | | | ☑️ | ☑️ | | +| | Editar Roles de miembros (excluyendo el Rol Owner) | | | ☑️ | ☑️ | | +| | Editar Roles de miembros (incluyendo el Rol Owner) | | | | ☑️ | | +| | Eliminarse a sí mismo de la membresía de Producto / Tipo de Producto | ☑️ | ☑️ | ☑️ | ☑️ | | +| | Añadir un Rol Owner a otro Usuario | | | | ☑️ | | +| | Editar una Membresía de Producto/Tipo de Producto asociada dentro de un Grupo³ | | | | ☑️ | | +| | Eliminar una Membresía de Producto/Tipo de Producto asociada dentro de un Grupo³ | | | | | | +| **Compromisos** (dentro de un Producto) | Añadir, Editar Compromisos | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Ver Aceptaciones de Riesgo ⁴ | | ☑️ | ☑️ | ☑️ | | +| | Añadir, Editar Aceptaciones de Riesgo | | ☑️ | ☑️ | ☑️ | | +| | Eliminar Compromisos | | | ☑️ | ☑️ | | +| **Tests** (dentro de un Producto) | Añadir Tests | | ☑️ | ☑️ | ☑️ | | +| | Editar Tests | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Eliminar Tests | | | ☑️ | ☑️ | | +| **Hallazgos** (dentro de un Producto) | Añadir Hallazgos | | ☑️ | ☑️ | ☑️ | | +| | Editar Hallazgos | | ☑️ | ☑️ | ☑️ | | +| | Importar, Reimportar Resultados de Escaneo | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Eliminar Hallazgos | | | ☑️ | ☑️ | | +| | Añadir, Editar, Eliminar Grupos de Hallazgos | | ☑️ | ☑️ | ☑️ | | +| **Otros Datos** (dentro de un Producto) | Añadir, Editar Endpoints | | ☑️ | ☑️ | ☑️ | | +| | Eliminar Endpoints | | | ☑️ | ☑️ | | +| | Editar Benchmarks | | ☑️ | ☑️ | ☑️ | | +| | Eliminar Benchmarks | | | ☑️ | ☑️ | | +| | Ver el Historial de Notas | ☑️ | ☑️ | ☑️ | ☑️ | | +| | Añadir, Editar, Eliminar Notas propias | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Editar Notas de otros | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Eliminar Notas de otros | | | ☑️ | ☑️ | | + +1. Un usuario al que se le asignan permisos únicamente a nivel de Producto no puede ver el Tipo de Producto que lo contiene. +2. Cuando se añade un nuevo Producto bajo un Tipo de Producto, todos los Usuarios a nivel de Tipo de Producto se añadirán como Miembros del nuevo Producto con su Rol de nivel de Tipo de Producto. +3. El usuario que desee realizar cambios en un Grupo también debe tener **Permisos de Configuración de Edición de Grupo**, y un **Rol de Configuración de Grupo de Maintainer u Owner** en el Grupo que desea editar. +4. La visibilidad de las Aceptaciones de Riesgo está controlada por un permiso mínimo distinto al de la visibilidad de Hallazgos: un Reader en el Producto puede ver los Hallazgos subyacentes, pero **no puede** ver las Aceptaciones de Riesgo a las que pertenecen esos Hallazgos. Para más detalles sobre los permisos de Aceptación de Riesgo, el comportamiento de la fecha de expiración y los flujos de reinstauración, consulte [Aceptaciones de Riesgo (Pro)](/triage_findings/findings_workflows/pro__risk_acceptance/#risk-acceptance-permissions-and-visibility). + +## Cuadro de Permisos de Configuración + +Cada Permiso de Configuración se refiere a una función particular del software, y tiene asociado un conjunto de acciones que un usuario puede realizar relacionadas con esa función. + +La mayoría de los Permisos de Configuración dan a los usuarios acceso a determinadas páginas de la interfaz. + +| **Permiso de Configuración** | **Ver ☑️** | **Añadir ☑️** | **Editar ☑️** | **Eliminar ☑️** | +| --- | --- | --- | --- | --- | +| Credential Manager | Acceso a la página **⚙️Configuration \> Credential Manager** | Añadir nuevas entradas al Credential Manager | Editar entradas del Credential Manager | Eliminar entradas del Credential Manager | +| Development Environments | n/a | Añadir nuevos Entornos de Desarrollo a la lista 🗓️**Engagements \> Environments** | Editar Entornos de Desarrollo en la lista 🗓️**Engagements \> Environments** | Eliminar Entornos de Desarrollo de la lista **🗓️Engagements \> Environments** | +| Finding Templates¹ | Acceso a la página **Findings \> Finding Templates** | Añadir una Plantilla de Hallazgo | Editar una Plantilla de Hallazgo | Eliminar una Plantilla de Hallazgo | +| Groups | Acceso a la página **👤Users \> Groups** | Añadir un nuevo Grupo de Usuarios | Solo Superusuario | Solo Superusuario | +| Jira Instances | Acceso a la **página ⚙️Configuration \> JIRA** | Añadir una nueva Configuración de JIRA | Editar una Configuración de JIRA existente | Eliminar una Configuración de JIRA | +| Language Types | | | | | +| Login Banner | n/a | n/a | Editar el banner de inicio de sesión, ubicado en **⚙️Configuration \> Login Banner** | n/a | +| Announcements | n/a | n/a | Configurar los Anuncios, ubicados en **⚙️Configuration \> Announcements** | n/a | +| Note Types | Acceso a la página ⚙️Configuration \> Note Types | Añadir un Tipo de Nota | Editar un Tipo de Nota | Eliminar un Tipo de Nota | +| Prioritization Engines | Acceso a la página de configuración de Prioritization Engine | Añadir un nuevo Prioritization Engine | Editar un Prioritization Engine existente | Eliminar un Prioritization Engine | +| Product Types | n/a | Añadir un nuevo Tipo de Producto (en Products \> Product Type) | n/a | n/a | +| Questionnaires | Acceso a la página **Questionnaires \> All Questionnaires** | Añadir un nuevo Cuestionario | Editar un Cuestionario existente | Eliminar un Cuestionario | +| Questions | Acceso a la página **Questionnaires \> Questions** | Añadir una nueva Pregunta | Editar una Pregunta existente | n/a | +| Regulations | n/a | Añadir una Regulación a la página **⚙️Configuration \> Regulations** | Editar una Regulación existente | Eliminar una Regulación | +| Scheduling Service Schedule | Acceso a la página **Scheduling** | Solo Superusuario | Editar una Programación existente (cambiar el disparador, habilitar/deshabilitar) | Eliminar una Programación | +| SLA Configuration | Acceso a la página **⚙️Configuration \> SLA Configuration** | Añadir una nueva Configuración de SLA | Editar una Configuración de SLA existente | Eliminar una Configuración de SLA | +| Test Types | n/a | Añadir un nuevo Test Type (en **Engagements \> Test Types**) | Editar un Test Type existente | n/a | +| Tool Configuration | Acceso a la página **⚙️Configuration \> Tool Configuration** | Añadir una nueva Configuración de Herramienta | Editar una Configuración de Herramienta existente | Eliminar una Configuración de Herramienta | +| Tool Types | Acceso a la página **⚙️Configuration \> Tool Types** | Añadir un nuevo Tipo de Herramienta | Editar un Tipo de Herramienta existente | Eliminar un Tipo de Herramienta | +| Users | Acceso a la página **👤Users \> Users** | Añadir un nuevo Usuario a DefectDojo | Editar un Usuario existente | Eliminar un Usuario | + +1. El acceso a la página Finding Templates también requiere el Rol Global **Writer, Maintainer** u **Owner** para este usuario. + +## Permisos de Configuración de Grupo + +| Permiso de Configuración | **Reader** | **Maintainer** | **Owner** | +| --- | --- | --- | --- | +| Ver Grupo | ☑️ | ☑️ | ☑️ | +| Eliminarse a sí mismo del Grupo | ☑️ | ☑️ | ☑️ | +| Editar el rol de un Miembro en un Grupo | | ☑️ | ☑️ | +| Editar o Eliminar una Membresía de Producto o Tipo de Producto de un Grupo¹ | | ☑️ | ☑️ | +| Cambiar el rol de un Miembro del Grupo a Owner | | | ☑️ | +| Eliminar Grupo | | | ☑️ | + +1. Esto también requiere que el Usuario tenga al menos un Rol de Maintainer en el Producto o Tipo de Producto que desea editar. diff --git a/docs/content/admin/user_management/user_permission_chart.fr.md b/docs/content/admin/user_management/user_permission_chart.fr.md new file mode 100644 index 00000000000..d5f83d12488 --- /dev/null +++ b/docs/content/admin/user_management/user_permission_chart.fr.md @@ -0,0 +1,99 @@ +--- +title: Tableaux des autorisations d'action +description: Toutes les autorisations utilisateur de DefectDojo Pro en détail +weight: 4 +audience: pro +aliases: +- /fr/en/customize_dojo/user_management/user_permission_chart +--- + +> **Fonctionnalité DefectDojo Pro.** Le système RBAC Membres / Groupes / Rôles globaux décrit sur cette page fait partie de DefectDojo Pro. La version open source de DefectDojo utilise le modèle [Utilisateurs autorisés](../os__authorized_users/) — consultez cette page pour le contrôle d'accès en version open source, ainsi que les [notes de mise à niveau 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) si vous passez d'une édition à l'autre. + +## Tableau des autorisations par rôle + +Ce tableau vise à répertorier toutes les autorisations liées à un Produit ou à un Type de produit, ainsi que les autorisations disponibles pour chaque rôle. + +Les cinq rôles ci-dessous sont les **rôles intégrés** de DefectDojo Pro. Ce sont des préréglages verrouillés : leurs autorisations sont identiques sur chaque instance et ne peuvent pas être modifiées. Si vous avez créé vos propres rôles, ce tableau décrit les rôles intégrés dont ils ont été clonés, plutôt que les rôles eux-mêmes. Pour le catalogue complet des autorisations qu'un rôle peut recevoir, voir [Rôles RBAC personnalisés](../pro__custom_rbac_roles/#choosing-permissions). + +| **Section** | **Autorisation** | Lecteur | Rédacteur | Mainteneur | Propriétaire | Importateur API | +| --- | --- | --- | --- | --- | --- | --- | +| **Accès au Produit / Type de produit** | Consulter le Produit ou le Type de produit assigné ¹ | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Consulter les Produits, Engagements, Tests, Constatations, Points de terminaison imbriqués | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Ajouter de nouveaux Produits (au sein du Type de produit assigné) ² | | | ☑️ | ☑️ | | +| | Supprimer les Produits ou Types de produit assignés | | | | ☑️ | | +| **Adhésion au Produit / Type de produit** | Ajouter des Utilisateurs en tant que Membres (à l'exclusion du Rôle Propriétaire) | | | ☑️ | ☑️ | | +| | Modifier les Rôles des membres (à l'exclusion du Rôle Propriétaire) | | | ☑️ | ☑️ | | +| | Modifier les Rôles des membres (y compris le Rôle Propriétaire) | | | | ☑️ | | +| | Se retirer soi-même de l'adhésion au Produit / Type de produit | ☑️ | ☑️ | ☑️ | ☑️ | | +| | Attribuer un Rôle Propriétaire à un autre Utilisateur | | | | ☑️ | | +| | Modifier une adhésion Produit/Type de produit associée au sein d'un Groupe³ | | | | ☑️ | | +| | Supprimer une adhésion Produit/Type de produit associée au sein d'un Groupe³ | | | | | | +| **Engagements** (Au sein d'un Produit) | Ajouter, Modifier des Engagements | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Consulter les Acceptations du risque ⁴ | | ☑️ | ☑️ | ☑️ | | +| | Ajouter, Modifier des Acceptations du risque | | ☑️ | ☑️ | ☑️ | | +| | Supprimer des Engagements | | | ☑️ | ☑️ | | +| **Tests** (Au sein d'un Produit) | Ajouter des Tests | | ☑️ | ☑️ | ☑️ | | +| | Modifier des Tests | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Supprimer des Tests | | | ☑️ | ☑️ | | +| **Constatations** (Au sein d'un Produit) | Ajouter des Constatations | | ☑️ | ☑️ | ☑️ | | +| | Modifier des Constatations | | ☑️ | ☑️ | ☑️ | | +| | Importer, Réimporter des Résultats de scan | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Supprimer des Constatations | | | ☑️ | ☑️ | | +| | Ajouter, Modifier, Supprimer des Groupes de constatations | | ☑️ | ☑️ | ☑️ | | +| **Autres données** (Au sein d'un Produit) | Ajouter, Modifier des Points de terminaison | | ☑️ | ☑️ | ☑️ | | +| | Supprimer des Points de terminaison | | | ☑️ | ☑️ | | +| | Modifier des Référentiels | | ☑️ | ☑️ | ☑️ | | +| | Supprimer des Référentiels | | | ☑️ | ☑️ | | +| | Consulter l'historique des notes | ☑️ | ☑️ | ☑️ | ☑️ | | +| | Ajouter, Modifier, Supprimer ses propres Notes | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Modifier les Notes d'autres utilisateurs | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Supprimer les Notes d'autres utilisateurs | | | ☑️ | ☑️ | | + +1. Un utilisateur qui se voit attribuer des autorisations uniquement au niveau du Produit ne peut pas consulter le Type de produit dans lequel il est contenu. +2. Lorsqu'un nouveau Produit est ajouté sous un Type de produit, tous les Utilisateurs au niveau du Type de produit seront ajoutés en tant que Membres du nouveau Produit avec leur Rôle au niveau du Type de produit. +3. L'utilisateur qui souhaite apporter des modifications à un Groupe doit également disposer des **Autorisations de configuration** **Modifier le Groupe**, ainsi que d'un **Rôle de configuration de Groupe** **Mainteneur ou Propriétaire** dans le Groupe qu'il souhaite modifier. +4. La visibilité des Acceptations du risque est conditionnée par une autorisation minimale distincte de celle des Constatations — un Lecteur sur le Produit peut consulter les Constatations sous-jacentes mais **ne peut pas** consulter les Acceptations du risque auxquelles ces Constatations appartiennent. Pour plus de détails sur les autorisations liées aux Acceptations du risque, le comportement de la date d'expiration et les processus de réinstatement, voir [Acceptations du risque (Pro)](/triage_findings/findings_workflows/pro__risk_acceptance/#risk-acceptance-permissions-and-visibility). + +## Tableau des Autorisations de configuration + +Chaque Autorisation de configuration se rapporte à une fonction particulière du logiciel, et dispose d'un ensemble d'actions associées qu'un utilisateur peut effectuer en lien avec cette fonction. + +La majorité des Autorisations de configuration donnent aux utilisateurs l'accès à certaines pages de l'interface. + +| **Autorisation de configuration** | **Consulter ☑️** | **Ajouter ☑️** | **Modifier ☑️** | **Supprimer ☑️** | +| --- | --- | --- | --- | --- | +| Gestionnaire d'identifiants | Accéder à la page **⚙️Configuration \> Gestionnaire d'identifiants** | Ajouter de nouvelles entrées au Gestionnaire d'identifiants | Modifier les entrées du Gestionnaire d'identifiants | Supprimer les entrées du Gestionnaire d'identifiants | +| Environnements de développement | n/a | Ajouter de nouveaux Environnements de développement à la liste 🗓️**Engagements \> Environnements** | Modifier les Environnements de développement dans la liste 🗓️**Engagements \> Environnements** | Supprimer des Environnements de développement de la liste **🗓️Engagements \> Environnements** | +| Modèles de constatation¹ | Accéder à la page **Constatations \> Modèles de constatation** | Ajouter un Modèle de constatation | Modifier un Modèle de constatation | Supprimer un Modèle de constatation | +| Groupes | Accéder à la page **👤Utilisateurs \> Groupes** | Ajouter un nouveau Groupe d'utilisateurs | Superutilisateur uniquement | Superutilisateur uniquement | +| Instances Jira | Accéder à la page **⚙️Configuration \> JIRA** | Ajouter une nouvelle Configuration JIRA | Modifier une Configuration JIRA existante | Supprimer une Configuration JIRA | +| Types de langage | | | | | +| Bannière de connexion | n/a | n/a | Modifier la bannière de connexion, située sous **⚙️Configuration \> Bannière de connexion** | n/a | +| Annonces | n/a | n/a | Configurer les Annonces, situées sous **⚙️Configuration \> Annonces** | n/a | +| Types de note | Accéder à la page ⚙️Configuration \> Types de note | Ajouter un Type de note | Modifier un Type de note | Supprimer un Type de note | +| Moteurs de priorisation | Accéder à la page de configuration du Moteur de priorisation | Ajouter un nouveau Moteur de priorisation | Modifier un Moteur de priorisation existant | Supprimer un Moteur de priorisation | +| Types de produit | n/a | Ajouter un nouveau Type de produit (sous Produits \> Type de produit) | n/a | n/a | +| Questionnaires | Accéder à la page **Questionnaires \> Tous les questionnaires** | Ajouter un nouveau Questionnaire | Modifier un Questionnaire existant | Supprimer un Questionnaire | +| Questions | Accéder à la page **Questionnaires \> Questions** | Ajouter une nouvelle Question | Modifier une Question existante | n/a | +| Réglementations | n/a | Ajouter une Réglementation à la page **⚙️Configuration \> Réglementations** | Modifier une Réglementation existante | Supprimer une Réglementation | +| Planification du service de planification | Accéder à la page **Planification** | Superutilisateur uniquement | Modifier une Planification existante (changer le déclencheur, activer/désactiver) | Supprimer une Planification | +| Configuration SLA | Accéder à la page **⚙️Configuration \> Configuration SLA** | Ajouter une nouvelle Configuration SLA | Modifier une Configuration SLA existante | Supprimer une Configuration SLA | +| Types de test | n/a | Ajouter un nouveau Type de test (sous **Engagements \> Types de test**) | Modifier un Type de test existant | n/a | +| Configuration des outils | Accéder à la page **⚙️Configuration \> Configuration des outils** | Ajouter une nouvelle Configuration d'outil | Modifier une Configuration d'outil existante | Supprimer une Configuration d'outil | +| Types d'outils | Accéder à la page **⚙️Configuration \> Types d'outils** | Ajouter un nouveau Type d'outil | Modifier un Type d'outil existant | Supprimer un Type d'outil | +| Utilisateurs | Accéder à la page **👤Utilisateurs \> Utilisateurs** | Ajouter un nouvel Utilisateur à DefectDojo | Modifier un Utilisateur existant | Supprimer un Utilisateur | + +1. L'accès à la page Modèles de constatation nécessite également le Rôle global **Rédacteur, Mainteneur** ou **Propriétaire** pour cet utilisateur. + +## Autorisations de configuration de Groupe + +| Configuration Permission | **Lecteur** | **Mainteneur** | **Propriétaire** | +| --- | --- | --- | --- | +| Consulter le Groupe | ☑️ | ☑️ | ☑️ | +| Se retirer soi-même du Groupe | ☑️ | ☑️ | ☑️ | +| Modifier le rôle d'un Membre dans un Groupe | | ☑️ | ☑️ | +| Modifier ou Supprimer une adhésion à un Produit ou à un Type de produit depuis un Groupe¹ | | ☑️ | ☑️ | +| Changer le rôle d'un Membre du Groupe en Propriétaire | | | ☑️ | +| Supprimer le Groupe | | | ☑️ | + +1. Cela nécessite également que l'Utilisateur dispose au moins d'un Rôle Mainteneur sur le Produit ou le Type de produit qu'il souhaite modifier. diff --git a/docs/content/admin/user_management/user_permission_chart.ja.md b/docs/content/admin/user_management/user_permission_chart.ja.md new file mode 100644 index 00000000000..adfc7886f4a --- /dev/null +++ b/docs/content/admin/user_management/user_permission_chart.ja.md @@ -0,0 +1,99 @@ +--- +title: アクション権限チャート +description: DefectDojo Pro のすべてのユーザー権限の詳細 +weight: 4 +audience: pro +aliases: +- /ja/en/customize_dojo/user_management/user_permission_chart +--- + +> **DefectDojo Pro の機能です。** このページで説明する メンバー / グループ / グローバルロール のRBACシステムは、DefectDojo Pro の一部です。オープンソース版のDefectDojoでは、[Authorized Users](../os__authorized_users/) モデルを使用します — オープンソース版のアクセス制御についてはそのページを、エディション間を移行する場合は [3.0 アップグレードノート](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) を参照してください。 + +## ロール権限チャート + +このチャートは、製品または製品タイプに関連するすべての権限と、各ロールで利用可能な権限を一覧にすることを目的としています。 + +以下の5つのロールは、DefectDojo Pro の **組み込みロール**(built-in roles)です。これらはロックされたプリセットであり、権限はすべてのインスタンスで同一で変更できません。独自のロールを作成している場合、このチャートはそのロール自体ではなく、複製元となった組み込みロールについて説明しています。ロールに付与できる権限の全カタログについては、[Custom RBAC Roles](../pro__custom_rbac_roles/#choosing-permissions) を参照してください。 + +| **セクション** | **権限** | Reader | Writer | Maintainer | Owner | API Importer | +| --- | --- | --- | --- | --- | --- | --- | +| **製品 / 製品タイプ へのアクセス** | 割り当てられた製品または製品タイプの閲覧 ¹ | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | ネストされた製品、エンゲージメント、テスト、検出事項、エンドポイントの閲覧 | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | 新しい製品の追加(割り当てられた製品タイプ内) ² | | | ☑️ | ☑️ | | +| | 割り当てられた製品または製品タイプの削除 | | | | ☑️ | | +| **製品 / 製品タイプ のメンバーシップ** | ユーザーをメンバーとして追加(Owner ロールを除く) | | | ☑️ | ☑️ | | +| | メンバーのロールを編集(Owner ロールを除く) | | | ☑️ | ☑️ | | +| | メンバーのロールを編集(Owner ロールを含む) | | | | ☑️ | | +| | 製品 / 製品タイプ のメンバーシップから自身を削除 | ☑️ | ☑️ | ☑️ | ☑️ | | +| | 他のユーザーに Owner ロールを追加 | | | | ☑️ | | +| | グループ内で関連付けられた製品/製品タイプのメンバーシップを編集³ | | | | ☑️ | | +| | グループ内で関連付けられた製品/製品タイプのメンバーシップを削除³ | | | | | | +| **エンゲージメント**(製品内) | エンゲージメントの追加、編集 | | ☑️ | ☑️ | ☑️ | ☑️ | +| | リスク受容の閲覧 ⁴ | | ☑️ | ☑️ | ☑️ | | +| | リスク受容の追加、編集 | | ☑️ | ☑️ | ☑️ | | +| | エンゲージメントの削除 | | | ☑️ | ☑️ | | +| **テスト**(製品内) | テストの追加 | | ☑️ | ☑️ | ☑️ | | +| | テストの編集 | | ☑️ | ☑️ | ☑️ | ☑️ | +| | テストの削除 | | | ☑️ | ☑️ | | +| **検出事項**(製品内) | 検出事項の追加 | | ☑️ | ☑️ | ☑️ | | +| | 検出事項の編集 | | ☑️ | ☑️ | ☑️ | | +| | スキャン結果のインポート、再インポート | | ☑️ | ☑️ | ☑️ | ☑️ | +| | 検出事項の削除 | | | ☑️ | ☑️ | | +| | 検出事項グループの追加、編集、削除 | | ☑️ | ☑️ | ☑️ | | +| **その他のデータ**(製品内) | エンドポイントの追加、編集 | | ☑️ | ☑️ | ☑️ | | +| | エンドポイントの削除 | | | ☑️ | ☑️ | | +| | ベンチマークの編集 | | ☑️ | ☑️ | ☑️ | | +| | ベンチマークの削除 | | | ☑️ | ☑️ | | +| | メモ履歴の閲覧 | ☑️ | ☑️ | ☑️ | ☑️ | | +| | 自身のメモの追加、編集、削除 | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | 他者のメモの編集 | | ☑️ | ☑️ | ☑️ | ☑️ | +| | 他者のメモの削除 | | | ☑️ | ☑️ | | + +1. 製品レベルのみで権限を割り当てられたユーザーは、その製品が含まれる製品タイプを閲覧できません。 +2. 製品タイプの下に新しい製品が追加されると、その製品タイプレベルのすべてのユーザーが、その製品タイプレベルのロールで新しい製品のメンバーとして追加されます。 +3. グループに変更を加えたいユーザーは、**Edit Group** **コンフィギュレーション権限** と、編集したいグループにおける **Maintainer または Owner** の **グループコンフィギュレーションロール** の両方を持っている必要があります。 +4. リスク受容の閲覧可否は、検出事項の閲覧可否とは異なる最小権限によって制御されます — 製品の Reader は基盤となる検出事項を閲覧できますが、その検出事項が属するリスク受容は閲覧**できません**。リスク受容の権限、有効期限の動作、再適用のワークフローの詳細については、[Risk Acceptances (Pro)](/triage_findings/findings_workflows/pro__risk_acceptance/#risk-acceptance-permissions-and-visibility) を参照してください。 + +## コンフィギュレーション権限チャート + +各コンフィギュレーション権限は、ソフトウェア内の特定の機能を指し、その機能に関連してユーザーが実行できる一連のアクションが紐づいています。 + +コンフィギュレーション権限の大部分は、UI内の特定のページへのアクセスをユーザーに付与します。 + +| **コンフィギュレーション権限** | **閲覧 ☑️** | **追加 ☑️** | **編集 ☑️** | **削除 ☑️** | +| --- | --- | --- | --- | --- | +| Credential Manager | **⚙️Configuration \> Credential Manager** ページへのアクセス | Credential Manager に新しいエントリを追加 | Credential Manager のエントリを編集 | Credential Manager のエントリを削除 | +| Development Environments | 該当なし | 🗓️**Engagements \> Environments** リストに新しい Development Environment を追加 | 🗓️**Engagements \> Environments** リストの Development Environment を編集 | **🗓️Engagements \> Environments** リストから Development Environment を削除 | +| Finding Templates¹ | **Findings \> Finding Templates** ページへのアクセス | Finding Template を追加 | Finding Template を編集 | Finding Template を削除 | +| Groups | **👤Users \> Groups** ページへのアクセス | 新しい User Group を追加 | スーパーユーザーのみ | スーパーユーザーのみ | +| Jira Instances | **⚙️Configuration \> JIRA page** へのアクセス | 新しい JIRA Configuration を追加 | 既存の JIRA Configuration を編集 | JIRA Configuration を削除 | +| Language Types | | | | | +| Login Banner | 該当なし | 該当なし | **⚙️Configuration \> Login Banner** にあるログインバナーを編集 | 該当なし | +| Announcements | 該当なし | 該当なし | **⚙️Configuration \> Announcements** にある Announcements を設定 | 該当なし | +| Note Types | ⚙️Configuration \> Note Types ページへのアクセス | Note Type を追加 | Note Type を編集 | Note Type を削除 | +| Prioritization Engines | Prioritization Engine 設定ページへのアクセス | 新しい Prioritization Engine を追加 | 既存の Prioritization Engine を編集 | Prioritization Engine を削除 | +| Product Types | 該当なし | 新しい Product Type を追加(Products \> Product Type 内) | 該当なし | 該当なし | +| Questionnaires | **Questionnaires \> All Questionnaires** ページへのアクセス | 新しい Questionnaire を追加 | 既存の Questionnaire を編集 | Questionnaire を削除 | +| Questions | **Questionnaires \> Questions** ページへのアクセス | 新しい Question を追加 | 既存の Question を編集 | 該当なし | +| Regulations | 該当なし | **⚙️Configuration \> Regulations** ページに Regulation を追加 | 既存の Regulation を編集 | Regulation を削除 | +| Scheduling Service Schedule | **Scheduling** ページへのアクセス | スーパーユーザーのみ | 既存の Schedule を編集(トリガーの変更、有効/無効化) | Schedule を削除 | +| SLA Configuration | **⚙️Configuration \> SLA Configuration** ページへのアクセス | 新しい SLA Configuration を追加 | 既存の SLA Configuration を編集 | SLA Configuration を削除 | +| Test Types | 該当なし | 新しい Test Type を追加(**Engagements \> Test Types** 内) | 既存の Test Type を編集 | 該当なし | +| Tool Configuration | **⚙️Configuration \> Tool Configuration** ページへのアクセス | 新しい Tool Configuration を追加 | 既存の Tool Configuration を編集 | Tool Configuration を削除 | +| Tool Types | **⚙️Configuration \> Tool Types** ページへのアクセス | 新しい Tool Type を追加 | 既存の Tool Type を編集 | Tool Type を削除 | +| Users | **👤Users \> Users** ページへのアクセス | DefectDojo に新しい User を追加 | 既存の User を編集 | User を削除 | + +1. Finding Templates ページへのアクセスには、このユーザーに **Writer、Maintainer**、または **Owner** のグローバルロールも必要です。 + +## グループコンフィギュレーション権限 + +| Configuration Permission | **Reader** | **Maintainer** | **Owner** | +| --- | --- | --- | --- | +| グループの閲覧 | ☑️ | ☑️ | ☑️ | +| グループから自身を削除 | ☑️ | ☑️ | ☑️ | +| グループ内のメンバーのロールを編集 | | ☑️ | ☑️ | +| グループから製品または製品タイプのメンバーシップを編集または削除¹ | | ☑️ | ☑️ | +| グループメンバーのロールを Owner に変更 | | | ☑️ | +| グループを削除 | | | ☑️ | + +1. これには、編集したい製品または製品タイプにおいて、ユーザーが少なくとも Maintainer ロールを持っている必要もあります。 diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.de.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.de.md new file mode 100644 index 00000000000..5eebc5f393a --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.de.md @@ -0,0 +1,39 @@ +--- +title: Asset-Zustandsbewertung +description: Wie DefectDojo eine Asset-Zustandsbewertung berechnet +weight: 7 +audience: opensource +aliases: +- /de/asset_modelling/os_hierarchy/product_health_grade/ +- /de/en/asset_modelling/os_hierarchy/product_health_grade/ +--- + +DefectDojo kann für Ihre Assets eine Bewertung anhand der Anzahl der darin enthaltenen Befunde berechnen. Die Bewertungen reichen von A \- F. + +Beachten Sie, dass nur aktive \& verifizierte Befunde zu einer Asset-Bewertung beitragen \- nicht verifizierte Befunde wirken sich nicht aus. + +*Die Zustandsbewertung (A \- F) jedes Assets wird neben seinem Namen in der Asset-Liste angezeigt.* + +![Asset-Zustandsbewertungen neben jedem Asset in der Asset-Liste](images/asset-health-grade.png) + +## Berechnung der Asset-Bewertung + +Jede Asset-Bewertung beginnt bei 100 (ohne Befunde). + +Die Berechnung der Bewertung beginnt damit, den höchsten **Schweregrad** eines Befunds in einem Asset zu betrachten und den Asset-Zustand auf ein Grundniveau zu reduzieren. + +| **Höchster Schweregrad eines Befunds** | **Maximale Bewertung** | +| --- | --- | +| **Kritisch** | **40** | +| **Hoch** | **60** | +| **Mittel** | **80** | +| **Niedrig** | **95** | + +Anschließend werden für jeden weiteren Befund zusätzliche Punkte von der Bewertung abgezogen: + +| **Schweregrad eines weiteren Befunds** | **Bewertung reduziert um** | +| --- | --- | +| **Kritisch** | **5** | +| **Hoch** | **3** | +| **Mittel** | **2** | +| **Niedrig** | **1** | diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.es.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.es.md new file mode 100644 index 00000000000..13978f4e42b --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.es.md @@ -0,0 +1,39 @@ +--- +title: Calificación de estado del Activo +description: Cómo calcula DefectDojo la calificación de estado de un Activo +weight: 7 +audience: opensource +aliases: +- /es/asset_modelling/os_hierarchy/product_health_grade/ +- /es/en/asset_modelling/os_hierarchy/product_health_grade/ +--- + +DefectDojo puede calcular una calificación para sus Activos según la cantidad de Hallazgos que contengan. Las calificaciones van de A \- F. + +Tenga en cuenta que solo los Hallazgos Activos \& Verificados contribuyen a la calificación de un Activo \- los Hallazgos no verificados no tienen ningún impacto. + +*La calificación de estado de cada Activo (A \- F) aparece junto a su nombre en la lista de Activos.* + +![Calificaciones de estado de los Activos que se muestran junto a cada Activo en la lista de Activos](images/asset-health-grade.png) + +## Cálculo de la calificación del Activo + +Toda calificación de Activo comienza en 100 (sin Hallazgos). + +El cálculo de la calificación comienza observando el nivel de **Severidad** más alto de un Hallazgo en un Activo, y reduciendo el estado del Activo a un nivel base. + +| **Nivel de Severidad más alto de un Hallazgo** | **Calificación máxima** | +| --- | --- | +| **Crítica** | **40** | +| **Alta** | **60** | +| **Media** | **80** | +| **Baja** | **95** | + +Luego se restan puntos adicionales de la calificación por cada Hallazgo adicional: + +| **Nivel de Severidad de un Hallazgo adicional** | **Reducción de la calificación** | +| --- | --- | +| **Crítica** | **5** | +| **Alta** | **3** | +| **Media** | **2** | +| **Baja** | **1** | diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.fr.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.fr.md new file mode 100644 index 00000000000..692111587a0 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.fr.md @@ -0,0 +1,39 @@ +--- +title: Note de santé de l'Actif +description: Comment DefectDojo calcule la Note de santé d'un Actif +weight: 7 +audience: opensource +aliases: +- /fr/asset_modelling/os_hierarchy/product_health_grade/ +- /fr/en/asset_modelling/os_hierarchy/product_health_grade/ +--- + +DefectDojo peut calculer une note pour vos Actifs en fonction du nombre de Constatations qu'ils contiennent. Les notes vont de A à F. + +Notez que seules les Constatations Actives et Vérifiées contribuent à la note d'un Actif : les Constatations non vérifiées n'ont aucun impact. + +*La note de santé de chaque Actif (A à F) apparaît à côté de son nom dans la liste des Actifs.* + +![Notes de santé des Actifs affichées à côté de chaque Actif dans la liste des Actifs](images/asset-health-grade.png) + +## Calcul de la note d'un Actif + +Chaque note d'Actif commence à 100 (sans Constatations). + +Le calcul de la note commence par examiner le niveau de **Sévérité** le plus élevé d'une Constatation dans un Actif, puis réduit la santé de l'Actif à un niveau de base. + +| **Niveau de Sévérité le plus élevé d'une Constatation** | **Note maximale** | +| --- | --- | +| **Critique** | **40** | +| **Élevée** | **60** | +| **Moyenne** | **80** | +| **Faible** | **95** | + +Des points supplémentaires sont ensuite déduits de la note pour chaque Constatation additionnelle : + +| **Niveau de Sévérité d'une Constatation additionnelle** | **Réduction de la note** | +| --- | --- | +| **Critique** | **5** | +| **Élevée** | **3** | +| **Moyenne** | **2** | +| **Faible** | **1** | diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.ja.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.ja.md new file mode 100644 index 00000000000..16be2dc8963 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.ja.md @@ -0,0 +1,39 @@ +--- +title: アセットヘルスグレード +description: DefectDojoがアセットヘルスグレードを算出する方法 +weight: 7 +audience: opensource +aliases: +- /ja/asset_modelling/os_hierarchy/product_health_grade/ +- /ja/en/asset_modelling/os_hierarchy/product_health_grade/ +--- + +DefectDojoは、アセットに含まれる検出事項の量に基づいてアセットのグレードを算出できます。グレードはAからFの範囲でランク付けされます。 + +アセットのグレードに影響するのは、アクティブかつ検証済みの検出事項のみである点に注意してください。未検証の検出事項は影響しません。 + +*各アセットのヘルスグレード(A - F)は、アセットリスト内でその名前の横に表示されます。* + +![アセットリスト内で各アセットの横に表示されるアセットヘルスグレード](images/asset-health-grade.png) + +## アセットグレードの計算 + +すべてのアセットグレードは(検出事項がない状態で)100から始まります。 + +グレードの計算では、まずアセット内の検出事項の中で最も高い**深刻度**レベルを確認し、アセットのヘルスをベースレベルまで引き下げます。 + +| **検出事項の最高深刻度レベル** | **最大グレード** | +| --- | --- | +| **重大** | **40** | +| **高** | **60** | +| **中** | **80** | +| **低** | **95** | + +さらに、追加の検出事項ごとにグレードから点数が減点されます。 + +| **追加の検出事項の深刻度レベル** | **減点数** | +| --- | --- | +| **重大** | **5** | +| **高** | **3** | +| **中** | **2** | +| **低** | **1** | diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.de.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.de.md new file mode 100644 index 00000000000..931d5b214ca --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.de.md @@ -0,0 +1,216 @@ +--- +title: 'Asset-Hierarchie: Übersicht' +description: Organizations, Assets, Engagements, Tests und Findings verstehen +weight: 1 +audience: opensource +aliases: +- /de/en/working_with_findings/organizing_engagements_tests/product_hierarchy +- /de/asset_modelling/os_hierarchy/product_hierarchy/ +- /de/en/asset_modelling/os_hierarchy/product_hierarchy/ +--- + +DefectDojo verwendet fünf Hauptdatenklassen zur Organisation Ihrer Arbeit: **Organizations, Assets**, **Engagements**, **Tests** und **Findings**. + +DefectDojo ist so konzipiert, dass es sich flexibel an Ihr Team anpasst, anstatt Ihr Team an das Tool anzupassen. Sobald Sie verstehen, wie sich diese Datenklassen zur Organisation Ihrer Arbeit nutzen lassen, können Sie einen robusten, anpassungsfähigen Arbeitsbereich gestalten. + +### Asset-Hierarchie-Diagramm +![image](images/Asset_Hierarchy_Full.png) + + +## **Organizations** + +Die erste Datenkategorie, die Sie in DefectDojo einrichten müssen, ist eine Organisation. Organizations dienen dazu, Assets auf eine bestimmte Weise zu kategorisieren. Das kann sein: + +* nach Geschäftsbereich +* nach Entwicklungsteam +* nach Sicherheitsteam + +![image](images/Asset_Hierarchy_Overview.png) +*Assets werden gruppiert und unter ihrer Organization verschachtelt.* + +Für Organizations können rollenbasierte Zugriffskontrollregeln (Role-Based Access Control) festgelegt werden, die einschränken, inwieweit Teammitglieder deren Daten einsehen und damit interagieren können (einschließlich aller zugrunde liegenden Assets mit Engagement-, Test- und Finding-Daten). Weitere Informationen zu Benutzerrollen finden Sie in unserem Artikel **Einführung in Rollen**. + +#### Wofür kann eine Organization stehen? + +* Wenn ein bestimmtes Softwareprojekt viele unterschiedliche Deployments oder Versionen hat, kann es sinnvoll sein, eine einzelne Organization anzulegen, die den gesamten Projektumfang abdeckt, wobei jede Version als eigenes Asset existiert. +​ +* Sie können Organizations auch verwenden, um Phasen Ihres Softwareentwicklungsprozesses abzubilden: eine Organization für 'In Development', eine Organization für 'In Production' usw. +​ +* Letztendlich liegt es bei Ihnen, wie Sie Ihre Assets organisieren möchten und wofür Ihre Organizations stehen sollen. Ihre DefectDojo-Hierarchie muss möglicherweise angepasst werden, um den Anforderungen Ihrer Sicherheitsteams gerecht zu werden. + +## **Assets** + +Ein **Asset** in DefectDojo steht für ein beliebiges Projekt, Programm oder eine Anwendung, das bzw. die Sie gerade testen. Das Asset enthält die gesamte Sicherheitsarbeit und den Testverlauf zum jeweiligen Ziel. + +![image](images/Asset_Hierarchy_Overview_2.png) + +* einen eindeutigen **Namen** +* eine **Beschreibung** +* eine **Organization** +* eine zugewiesene **SLA-Konfiguration** + +Assets können in ihrem Umfang so weit gefasst oder so spezifisch sein, wie Sie möchten. Standardmäßig sind Assets vollständig eigenständige Objekte innerhalb der Hierarchie, können aber über eine **Organization** gruppiert werden. + +Assets sind voneinander „abgeschottet" und interagieren nicht mit anderen Assets. Die intelligenten Funktionen von DefectDojo, wie zum Beispiel die **Deduplizierung**, gelten jeweils nur innerhalb eines einzelnen Assets. + +Wie bei **Organizations** können auch für **Assets** rollenbasierte Zugriffskontrollregeln festgelegt werden, die einschränken, inwieweit Teammitglieder sie einsehen und damit interagieren können (sowie alle zugrunde liegenden Engagement-, Test- und Finding-Daten). Weitere Informationen zu Benutzerrollen finden Sie in unserem Artikel **Einführung in Rollen**. + +#### Wofür kann ein Asset stehen? + +Das Konzept eines „Assets" in DefectDojo entspricht nicht zwangsläufig 1:1 dem, was Ihre Organization als „Produkt" bezeichnen würde. Softwareentwicklung ist komplex, und die Sicherheitsanforderungen können selbst innerhalb einer einzelnen Software stark variieren. + +Die folgenden Szenarien sind gute Gründe, ein separates DefectDojo-Asset in Betracht zu ziehen: + +* „**ExampleAsset**" hat eine Windows-Version, eine Mac-Version und eine Cloud-Version +* „**ExampleAsset 1\.0**" verwendet völlig andere Softwarekomponenten als „**ExampleAsset 2\.0**", und beide Versionen werden von Ihrem Unternehmen aktiv unterstützt. +* Das Team, das für die Arbeit an „**ExampleAsset Version A**" zuständig ist, unterscheidet sich von dem Asset-Team, das für „**ExampleAsset Version B**" zuständig ist, und benötigt daher unterschiedliche zugewiesene Sicherheitsberechtigungen. + +Diese Variationen innerhalb eines einzelnen Assets können auch auf Engagement-Ebene gehandhabt werden. Beachten Sie, dass Engagements nicht über eine Zugriffskontrolle verfügen wie Assets und Organizations. + +## **Engagements** + +Sobald ein Asset eingerichtet ist, können Sie mit dem Erstellen und Planen von Engagements beginnen. Engagements sollen Zeitpunkte abbilden, zu denen Tests stattfinden, und enthalten einen oder mehrere **Tests**. + +Engagements haben immer: + +* einen eindeutigen **Namen** +* geplante **Start- und Enddaten** +* einen **Status** (Not Started, In Progress, Cancelled, Completed...) +* eine zugewiesene **Testing Lead** +* ein zugehöriges **Asset** + +Es gibt zwei Arten von Engagements: **Interactive** und **CI/CD**. + +* Ein **Interactive Engagement** wird typischerweise von einem Engineer durchgeführt. Interactive Engagements konzentrieren sich darauf, die Anwendung während der Laufzeit zu testen, sei es durch einen automatisierten Test, einen menschlichen Tester oder jede andere Aktivität, die mit der Anwendungsfunktionalität „interagiert". Siehe [OWASPs Definition von IAST](https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing#:~:text=Interactive%20Application%20Security%20Testing,interacting%E2%80%9D%20with%20the%20application%20functionality.). +* Ein **CI/CD Engagement** dient der automatisierten Integration mit einer CI/CD-Pipeline. CI/CD Engagements sollen Daten als automatisierte Aktion importieren, ausgelöst durch einen Schritt im Release-Prozess. + +Engagements können über die **Kalender**-Ansicht von DefectDojo verfolgt werden. + +#### Wofür kann ein Engagement stehen? + +Engagements sollen Gruppen zusammengehöriger Testaktivitäten abbilden. Wie Sie Ihre Testaktivitäten gruppieren möchten, hängt von Ihrem Ansatz ab. + +Wenn Sie eine geplante Testaktivität terminiert haben, bietet Ihnen ein Engagement einen Ort, um alle zugehörigen Ergebnisse zu speichern. Hier ist ein Beispiel für diese Art von Engagement: + +#### **Engagement:** ExampleSoftware 1\.5\.2 \- Interactive Testing Effort + +*In diesem Beispiel führt ein Sicherheitsteam im Rahmen eines Software-Releases mehrere Tests am selben Tag durch.* + +* **Test:** Nessus Scan Results (12. März) +* **Test:** NPM Scan Audit Results (12. März) +* **Test:** Snyk Scan Results (12. März) +​ +Sie können auch CI/CD-Testergebnisse innerhalb eines Engagements organisieren. Diese Art von Engagements ist „Open-Ended", das heißt, sie haben kein Datum und erhalten stattdessen jedes Mal zusätzliche Daten, wenn die zugehörigen CI/CD-Aktionen ausgeführt werden. + +#### Engagement: ExampleSoftware CI/CD Testing + +*In diesem Beispiel werden bei jeder Erstellung eines neuen Software-Releases automatisch mehrere CI/CD-Scans als Tests importiert.* + +* Test: 1\.5\.2 Scan Results (12. März) +* Test: 1\.5\.1 Scan Results (3. März) +* Test: 1\.5\.0 Scan Results (14. Februar) + +Engagements können so organisiert werden, wie es für Ihr Team am besten funktioniert. Alle einem Asset untergeordneten Engagements können von dem Team eingesehen werden, das für die Arbeit an diesem Asset zuständig ist. + +## **Tests** + +Tests sind eine Gruppierung von Aktivitäten, die von Engineers durchgeführt werden, um Schwachstellen in einem Asset aufzudecken. + +Tests haben immer: + +* einen eindeutigen **Test Title** +* einen bestimmten **Test Type** (API Test, Nessus Scan usw.) +* eine zugehörige Test-**Umgebung** +* ein zugehöriges **Engagement** + +Tests können auf unterschiedliche Weise erstellt werden. Sie können automatisch erstellt werden, wenn Scan-Daten direkt in ein Engagement importiert werden, wodurch ein neuer Test mit den Scan-Daten entsteht. Tests können auch im Vorgriff auf die Planung zukünftiger Engagements erstellt werden oder für manuell erfasste Sicherheitsbefunde, die nachverfolgt und behoben werden müssen. + +### **Test Types** + +DefectDojo unterstützt zwei Kategorien von Test Types: + +1. **Parser-basierte Test Types**: Diese entsprechen bestimmten Sicherheitsscannern, die ihre Ausgabe in Formaten wie XML, JSON oder CSV erzeugen. Beim Importieren von Scan-Ergebnissen verwendet DefectDojo spezialisierte Parser, um die Scanner-Ausgabe in Findings umzuwandeln. + +2. **Non-parser Test Types**: Diese werden für manuell erstellte Findings verwendet, die nicht aus Scan-Dateien importiert wurden. Diese Test Types nutzen die Methode [Generic Findings Import](/supported_tools/parsers/generic_findings_import/), um Findings und Metadaten darzustellen. + +Die folgenden Test Types erscheinen im Dropdown-Menü „Scan Type", wenn Sie einen neuen Test erstellen. + * API Test + * Static Check + * Pen Test + * Web Application Test + * Security Research + * Threat Modeling + * Manual Code Review + +Non-parser Test Types sollten verwendet werden, wenn Sie manuell Findings erstellen müssen, die behoben werden müssen, aber nicht aus einer automatisierten Scanner-Ausgabe stammen. + +#### **Parser-basierte Test Types** + +Parser-basierte Test Types lassen sich danach kategorisieren, wie ihr Testtypname ermittelt wird: + +- **Feste Testtypnamen**: Der Testtypname ist vordefiniert und vor dem Import bekannt (z. B. „ZAP Scan", „Nessus Scan"). + +- **Report-definierte Testtypnamen**: Der Testtypname wird zum Zeitpunkt des Imports aus dem Inhalt des Scan-Reports extrahiert. + +Beispiele dafür sind: + - **Generic Findings Import**: Erstellt Test Types basierend auf dem Feld `type` in JSON-Reports + - **SARIF**: Erstellt Test Types basierend auf Tool-Namen im SARIF-Report (z. B. „Dockle Scan (SARIF)") + - **OpenReports**: Erstellt für jede im Report gefundene Quelle einen separaten Test Type + +**Regeln für report-definierte Testtypnamen:** +- Wenn das Feld `type` des Reports dem Scan-Typ entspricht → wird der Scan-Typ direkt verwendet (z. B. „Generic Findings Import") +- Wenn das Feld `type` des Reports abweicht → wird das Format „{type} Scan ({scan_type})" erzeugt (z. B. „Tool1 Scan (Generic Findings Import)") +- Wenn das Feld `type` des Reports bereits mit dem Suffix „ ({scan_type})" endet → wird es unverändert übernommen, sodass das Suffix nie doppelt vorkommt (z. B. bleibt „Tool1 (Generic Findings Import)" als „Tool1 (Generic Findings Import)" erhalten) +- Wenn kein Feld `type` angegeben ist → wird der Scan-Typ direkt verwendet + +**Wichtige Hinweise:** +- Report-definierte Test Types werden automatisch erstellt, wenn beim Import oder Reimport ein neuer Typ erkannt wird. +- Bei Reimports muss der Testtypname exakt übereinstimmen - Abweichungen führen zu einem Validierungsfehler +- Die Deduplizierungseinstellungen (`HASHCODE_FIELDS_PER_SCANNER`) verwenden Testtypnamen als Schlüssel. Report-definierte Namen müssen daher entsprechend konfiguriert werden, wenn Sie ein individuelles Deduplizierungsverhalten wünschen + +#### **Wie interagieren Tests miteinander?** + +Tests fassen Ihre Testdaten zu Findings zusammen. In der Regel führen Sicherheitsteams dieselbe Testaktivität wiederholt durch, und Tests in DefectDojo ermöglichen es Ihnen, diesen Prozess elegant zu handhaben. + +**Bereits importierte Tests können reimportiert werden** \- Wenn Sie denselben Testtyp innerhalb desselben Engagement-Kontexts ausführen, können Sie die Testergebnisse nach jedem abgeschlossenen Scan reimportieren. DefectDojo vergleicht die reimportierten Daten mit dem vorhandenen Ergebnis und erstellt keine neuen Findings, wenn in den Scan-Daten Duplikate vorhanden sind. + +**Tests können separat importiert werden** \- Wenn Sie denselben Test für ein Asset innerhalb separater Engagements ausführen, vergleicht DefectDojo die Daten trotzdem mit vorherigen Tests, um doppelte Findings zu finden. Auf diese Weise behalten Sie den Überblick über zuvor behobene oder als Risiko akzeptierte Findings. + +Wenn ein Test direkt zu einem Asset ohne Engagement hinzugefügt wird, wird automatisch ein generisches Engagement erstellt, das den Test enthält. Dies ermöglicht Ad\-hoc-Datenimporte. + +**Beispiele für Tests:** + +* Burp Scan vom 29.10.2015 bis 29.10.2015 +* Nessus Scan vom 31.10.2015 bis 31.10.2015 +* API Test vom 15.10.2015 bis 20.10.2015 + +## **Findings** + +Sobald Daten zu einem Test hochgeladen wurden, werden die Ergebnisse dieser Daten im Test als einzelne **Findings** zur Überprüfung aufgelistet. + +Ein Finding stellt eine bestimmte Schwachstelle dar, die beim Testen entdeckt wurde. + +Findings haben immer: + +* einen eindeutigen **Finding Name** +* das **Datum**, an dem sie entdeckt wurden +* mehrere zugehörige **Status**, wie zum Beispiel Active, Verified oder False Positive +* einen zugehörigen **Test** +* einen **Severity**-Level: Critical, High, Medium, Low und Informational (Info). + +Findings können durch einen Datenimport hinzugefügt werden, aber auch manuell zu einem Test hinzugefügt werden. + +**Beispiele für Findings:** + +* OpenSSL ‘ChangeCipherSpec’ MiTM Potential Vulnerability +* Web Application Potentially Vulnerable to Clickjacking +* Web Browser XSS Protection Not Enabled + +## **Endpoints** + +Scan-Daten enthalten in der Regel Verweise auf die Hosts oder Endpoints, die von einem bestimmten Finding betroffen sind. DefectDojo aggregiert Findings automatisch pro Endpoint, sodass Sie über die Endpoint-Ansicht alle Findings einsehen können, die einen bestimmten Endpoint oder Hostnamen betreffen. + +Beispiele: +- https://www.example.com +- https://www.example.com:8080/products +- 192.168.0.36 diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.es.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.es.md new file mode 100644 index 00000000000..d96f15e3240 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.es.md @@ -0,0 +1,217 @@ +--- +title: 'Jerarquía de Activos: Descripción general' +description: Comprenda las Organizaciones, los Activos, los Compromisos, los Tests + y los Hallazgos +weight: 1 +audience: opensource +aliases: +- /es/en/working_with_findings/organizing_engagements_tests/product_hierarchy +- /es/asset_modelling/os_hierarchy/product_hierarchy/ +- /es/en/asset_modelling/os_hierarchy/product_hierarchy/ +--- + +DefectDojo utiliza cinco clases de datos principales para organizar su trabajo: **Organizaciones, Activos**, **Compromisos**, **Tests** y **Hallazgos**. + +DefectDojo está diseñado para adaptarse a su equipo, en lugar de obligar a su equipo a adaptarse a la herramienta. Podrá diseñar un espacio de trabajo robusto y adaptable una vez que comprenda cómo se pueden usar estas clases de datos para organizar su trabajo. + +### Diagrama de jerarquía de Activos +![image](images/Asset_Hierarchy_Full.png) + + +## **Organizaciones** + +La primera categoría de datos que deberá configurar en DefectDojo es una Organización. Las Organizaciones están pensadas para categorizar los Activos de una manera específica. Esto podría ser: + +* por dominio de negocio +* por equipo de desarrollo +* por equipo de seguridad + +![image](images/Asset_Hierarchy_Overview.png) +*Los Activos se agrupan y anidan dentro de su Organización.* + +A las Organizaciones se les pueden aplicar reglas de Control de Acceso Basado en Roles, que limitan la capacidad de los miembros del equipo para ver e interactuar con sus datos (incluidos los Activos subyacentes con datos de Compromisos, Tests y Hallazgos). Para obtener más información sobre los roles de usuario, consulte nuestro artículo **Introducción a los Roles**. + +#### ¿Qué puede representar una Organización? + +* Si un proyecto de software en particular tiene muchos despliegues o versiones distintas, puede valer la pena crear una única Organización que cubra el alcance de todo el proyecto, y hacer que cada versión exista como Activos individuales. +​ +* También podría considerar usar las Organizaciones para representar etapas de su proceso de desarrollo de software: una Organización para 'En desarrollo', otra Organización para 'En producción', etc. +​ +* En última instancia, depende de usted decidir cómo desea organizar sus Activos y qué quiere que representen sus Organizaciones. Es posible que su jerarquía de DefectDojo deba cambiar para adaptarse a las necesidades de sus equipos de seguridad. + +## **Activos** + +Un **Activo** en DefectDojo está pensado para representar cualquier proyecto, programa o aplicación que esté probando actualmente. El Activo alberga todo el trabajo de seguridad y el historial de testing relacionado con el objetivo subyacente. + +![image](images/Asset_Hierarchy_Overview_2.png) + +* un **Nombre** único +* una **Descripción** +* una **Organización** +* una **Configuración de SLA** asignada + +Los Activos pueden tener un alcance tan amplio o específico como desee. Por defecto, los Activos son objetos completamente independientes en la jerarquía, pero se pueden agrupar mediante una **Organización**. + +Los Activos están 'aislados' y no interactúan con otros Activos. Las Funciones Inteligentes de DefectDojo, como la **Deduplicación**, solo se aplican dentro del contexto de un único Activo. + +Al igual que las **Organizaciones**, a los **Activos** se les pueden aplicar reglas de Control de Acceso Basado en Roles, que limitan la capacidad de los miembros del equipo para verlos e interactuar con ellos (así como con los datos subyacentes de Compromisos, Tests y Hallazgos). Para obtener más información sobre los roles de usuario, consulte nuestro artículo **Introducción a los Roles**. + +#### ¿Qué puede representar un Activo? + +El concepto de 'Activo' de DefectDojo no necesariamente corresponde 1:1 con lo que su organización denominaría un 'Producto'. El desarrollo de software es complejo, y las necesidades de seguridad pueden variar mucho incluso dentro del alcance de una sola pieza de software. + +Los siguientes escenarios son buenas razones para considerar la creación de un Activo de DefectDojo independiente: + +* “**ExampleAsset**” tiene una versión para Windows, una versión para Mac y una versión en la nube +* “**ExampleAsset 1\.0**” utiliza componentes de software completamente diferentes de “**ExampleAsset 2\.0**”, y ambas versiones cuentan con soporte activo de su empresa. +* El equipo asignado para trabajar en “**ExampleAsset version A**” es diferente del equipo de Activo asignado para trabajar en “**ExampleAsset version B**”, y como resultado necesita tener asignados permisos de seguridad diferentes. + +Estas variaciones dentro de un único Activo también se pueden gestionar a nivel de Compromiso. Tenga en cuenta que los Compromisos no tienen control de acceso de la misma manera que los Activos y las Organizaciones. + +## **Compromisos** + +Una vez configurado un Activo, puede comenzar a crear y programar Compromisos. Los Compromisos están pensados para representar momentos en el tiempo en los que se realiza testing, y contienen uno o más **Tests**. + +Los Compromisos siempre tienen: + +* un **Nombre** único +* **Fechas de inicio y fin** objetivo +* **Estado** (Not Started, In Progress, Cancelled, Completed...) +* un **Testing Lead** asignado +* un **Activo** asociado + +Existen dos tipos de Compromiso: **Interactive** y **CI/CD**. + +* Un **Interactive Engagement** normalmente lo ejecuta un ingeniero. Los Interactive Engagements se centran en probar la aplicación mientras esta se está ejecutando, usando una prueba automatizada, un tester humano o cualquier actividad que “interactúe” con la funcionalidad de la aplicación. Consulte la [definición de IAST de OWASP](https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing#:~:text=Interactive%20Application%20Security%20Testing,interacting%E2%80%9D%20with%20the%20application%20functionality.). +* Un **CI/CD Engagement** es para la integración automatizada con un pipeline de CI/CD. Los CI/CD Engagements están pensados para importar datos como una acción automatizada, activada por un paso del proceso de release. + +Los Compromisos se pueden seguir usando la vista de **Calendario** de DefectDojo. + +#### ¿Qué puede representar un Compromiso? + +Los Compromisos están pensados para representar grupos de esfuerzos de testing relacionados. La forma en que desee agrupar sus esfuerzos de testing depende de su enfoque. + +Si tiene un esfuerzo de testing planificado y programado, un Compromiso le ofrece un lugar para almacenar todos los resultados relacionados. Aquí tiene un ejemplo de este tipo de Compromiso: + +#### **Compromiso:** ExampleSoftware 1\.5\.2 \- Esfuerzo de testing interactivo + +*En este ejemplo, un equipo de seguridad ejecuta múltiples tests el mismo día como parte de un release de software.* + +* **Test:** Resultados de Nessus Scan (12 de marzo\) +* **Test:** Resultados de NPM Scan Audit (12 de marzo\) +* **Test:** Resultados de Snyk Scan (12 de marzo\) +​ +También puede organizar los resultados de Tests de CI/CD dentro de un Compromiso. Este tipo de Compromisos son de 'duración abierta' ('Open\-Ended'), lo que significa que no tienen una fecha, y en su lugar añadirán datos adicionales cada vez que se ejecuten las acciones de CI/CD asociadas. + +#### Compromiso: ExampleSoftware CI/CD Testing + +*En este ejemplo, varios escaneos de CI/CD se importan automáticamente como Tests cada vez que se crea un nuevo release de software.* + +* Test: Resultados de escaneo 1\.5\.2 (12 de marzo\) +* Test: Resultados de escaneo 1\.5\.1 (3 de marzo\) +* Test: Resultados de escaneo 1\.5\.0 (14 de febrero\) + +Los Compromisos se pueden organizar de la manera que mejor funcione para su equipo. Todos los Compromisos anidados bajo un Activo pueden ser vistos por el equipo asignado para trabajar en el Activo. + +## **Tests** + +Los Tests son una agrupación de actividades realizadas por ingenieros para intentar descubrir fallos en un Activo. + +Los Tests siempre tienen: + +* un **Título de Test** único +* un **Test Type** específico (API Test, Nessus Scan, etc) +* un **Entorno** de test asociado +* un **Compromiso** asociado + +Los Tests se pueden crear de diferentes maneras. Los Tests pueden crearse automáticamente cuando los datos de escaneo se importan directamente en un Compromiso, lo que da como resultado un nuevo Test que contiene los datos del escaneo. Los Tests también pueden crearse anticipándose a la planificación de futuros compromisos, o para hallazgos de seguridad ingresados manualmente que requieran seguimiento y remediación. + +### **Tipos de Test** + +DefectDojo admite dos categorías de Test Types: + +1. **Test Types basados en parser**: Corresponden a escáneres de seguridad específicos que producen salidas en formatos como XML, JSON o CSV. Al importar resultados de escaneo, DefectDojo utiliza parsers especializados para convertir la salida del escáner en Hallazgos. + +2. **Test Types sin parser**: Se utilizan para Hallazgos creados manualmente que no se importan desde archivos de escaneo. Estos Test Types utilizan el método [Generic Findings Import](/supported_tools/parsers/generic_findings_import/) para representar los Hallazgos y sus metadatos. + +Los siguientes Test Types aparecen en el menú desplegable “Scan Type” al crear un nuevo test. + * API Test + * Static Check + * Pen Test + * Web Application Test + * Security Research + * Threat Modeling + * Manual Code Review + +Los Test Types sin parser deben usarse cuando necesita crear manualmente hallazgos que requieran remediación pero que no se originen en la salida de un escáner automatizado. + +#### **Test Types basados en parser** + +Los test types basados en parser se pueden categorizar según cómo se determina el nombre de su test type: + +- **Nombres de Test Type fijos**: El nombre del test type está predefinido y se conoce antes de la importación (por ejemplo, “ZAP Scan”, “Nessus Scan”). + +- **Nombres de Test Type definidos por el informe**: El nombre del test type se extrae del contenido del informe de escaneo en el momento de la importación. + +Algunos ejemplos incluyen: + - **Generic Findings Import**: Crea test types basados en el campo `type` de los informes JSON + - **SARIF**: Crea test types basados en los nombres de herramientas del informe SARIF (por ejemplo, “Dockle Scan (SARIF)”) + - **OpenReports**: Crea test types independientes por cada fuente encontrada en el informe + +**Reglas de nomenclatura de Test Type definidos por el informe:** +- Si el campo `type` del informe es igual al tipo de escaneo → se usa el tipo de escaneo directamente (por ejemplo, “Generic Findings Import”) +- Si el campo `type` del informe es diferente → se crea el formato “{type} Scan ({scan_type})” (por ejemplo, “Tool1 Scan (Generic Findings Import)”) +- Si el campo `type` del informe ya termina con el sufijo “ ({scan_type})” → se usa tal cual, de modo que el sufijo nunca se duplica (por ejemplo, “Tool1 (Generic Findings Import)” permanece como “Tool1 (Generic Findings Import)”) +- Si no se proporciona ningún campo `type` → se usa el tipo de escaneo directamente + +**Consideraciones importantes:** +- Los test types definidos por el informe se crean automáticamente cuando se detecta un tipo nuevo durante la importación o reimportación. +- En las reimportaciones, el nombre del test type debe coincidir exactamente - las discrepancias generarán un error de validación +- La configuración de Deduplicación (`HASHCODE_FIELDS_PER_SCANNER`) usa los nombres de test type como claves, por lo que los nombres definidos por el informe deben configurarse en consecuencia si desea un comportamiento de deduplicación personalizado + +#### **¿Cómo interactúan los Tests entre sí?** + +Los Tests toman sus datos de testing y los agrupan en Hallazgos. Por lo general, los equipos de seguridad ejecutan el mismo esfuerzo de testing de manera repetida, y los Tests en DefectDojo le permiten gestionar este proceso de forma elegante. + +**Los tests importados previamente se pueden reimportar** \- Si está ejecutando el mismo tipo de test dentro del mismo contexto de Compromiso, puede Reimportar los resultados del test después de cada escaneo completado. DefectDojo comparará los datos Reimportados con el resultado existente, y no creará nuevos Hallazgos si existen duplicados en los datos del escaneo. + +**Los Tests se pueden importar por separado** \- Si ejecuta el mismo test en un Activo dentro de Compromisos separados, DefectDojo igualmente comparará los datos con Tests anteriores para encontrar Hallazgos duplicados. Esto le permite hacer seguimiento de los Hallazgos previamente mitigados o con riesgo aceptado. + +Si se agrega un Test directamente a un Activo sin un Compromiso, se creará automáticamente un Compromiso genérico para contenerlo. Esto permite importaciones de datos ad\-hoc. + +**Ejemplos de Tests:** + +* Burp Scan del 29 de oct. de 2015 al 29 de oct. de 2015 +* Nessus Scan del 31 de oct. de 2015 al 31 de oct. de 2015 +* API Test del 15 de oct. de 2015 al 20 de oct. de 2015 + +## **Hallazgos** + +Una vez que se han añadido y cargado datos en un Test, los resultados de esos datos se enumerarán en el Test como **Hallazgos** individuales para su revisión. + +Un hallazgo representa un fallo específico descubierto durante el testing. + +Los Hallazgos siempre tienen: + +* un **Nombre de Hallazgo** único +* la **Fecha** en que fueron descubiertos +* múltiples **Estados** asociados, como Activo, Verificado o Falso positivo +* un **Test** asociado +* un nivel de **Severidad**: Crítica, Alta, Media, Baja e Informativa (Info). + +Los Hallazgos se pueden agregar mediante una importación de datos, pero también se pueden agregar manualmente a un Test. + +**Ejemplos de Hallazgos:** + +* OpenSSL 'ChangeCipherSpec' Vulnerabilidad potencial de MiTM +* Aplicación web potencialmente vulnerable a Clickjacking +* Protección XSS del navegador web no habilitada + +## **Endpoints** + +Los datos de escaneo generalmente contienen referencias a los hosts o endpoints afectados por un Hallazgo determinado. DefectDojo agrega automáticamente los Hallazgos por endpoint, por lo que puede usar la vista de Endpoint para ver todos los Hallazgos que afectan a un Endpoint o Hostname determinado. + +Ejemplos: +- https://www.example.com +- https://www.example.com:8080/products +- 192.168.0.36 diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.fr.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.fr.md new file mode 100644 index 00000000000..c5117485628 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.fr.md @@ -0,0 +1,216 @@ +--- +title: 'Hiérarchie des Actifs : Aperçu' +description: Comprendre les Organisations, Actifs, Engagements, Tests et Constatations +weight: 1 +audience: opensource +aliases: +- /fr/en/working_with_findings/organizing_engagements_tests/product_hierarchy +- /fr/asset_modelling/os_hierarchy/product_hierarchy/ +- /fr/en/asset_modelling/os_hierarchy/product_hierarchy/ +--- + +DefectDojo utilise cinq classes de données principales pour organiser votre travail : les **Organisations, Actifs**, **Engagements**, **Tests**, et **Constatations**. + +DefectDojo est conçu pour s'adapter à votre équipe, plutôt que de forcer votre équipe à s'adapter à l'outil. Vous pourrez concevoir un espace de travail robuste et adaptable une fois que vous aurez compris comment ces classes de données peuvent être utilisées pour organiser votre travail. + +### Diagramme de la hiérarchie des Actifs +![image](images/Asset_Hierarchy_Full.png) + + +## **Organisations** + +La première catégorie de données que vous devrez configurer dans DefectDojo est une Organisation. Les Organisations sont destinées à catégoriser les Actifs d'une manière spécifique. Cela peut être : + +* par domaine d'activité +* par équipe de développement +* par équipe de sécurité + +![image](images/Asset_Hierarchy_Overview.png) +*Les Actifs sont regroupés et imbriqués sous leur Organisation.* + +Des règles de Contrôle d'Accès Basé sur les Rôles peuvent être appliquées aux Organisations, ce qui limite la capacité des membres de l'équipe à consulter et interagir avec leurs données (y compris les Actifs sous-jacents avec les données d'Engagement, de Test et de Constatation). Pour plus d'informations sur les rôles utilisateur, consultez notre article **Introduction aux rôles**. + +#### Que peut représenter une Organisation ? + +* Si un projet logiciel particulier comporte de nombreux déploiements ou versions distincts, il peut être utile de créer une seule Organisation couvrant l'ensemble du périmètre du projet, chaque version existant comme un Actif individuel. +​ +* Vous pourriez également envisager d'utiliser les Organisations pour représenter les étapes de votre processus de développement logiciel : une Organisation pour « En développement », une Organisation pour « En production », etc. +​ +* En fin de compte, c'est à vous de décider comment organiser vos Actifs et ce que vous souhaitez que vos Organisations représentent. Votre hiérarchie DefectDojo devra peut-être évoluer pour répondre aux besoins de vos équipes de sécurité. + +## **Actifs** + +Un **Actif** dans DefectDojo est destiné à représenter tout projet, programme ou application que vous testez actuellement. L'Actif héberge l'ensemble du travail de sécurité et de l'historique de test relatifs à l'objectif sous-jacent. + +![image](images/Asset_Hierarchy_Overview_2.png) + +* un **Nom** unique +* une **Description** +* une **Organisation** +* une **Configuration SLA** assignée + +Les Actifs peuvent avoir un périmètre aussi large ou aussi spécifique que vous le souhaitez. Par défaut, les Actifs sont des objets totalement distincts dans la hiérarchie, mais ils peuvent être regroupés par **Organisation**. + +Les Actifs sont « cloisonnés » et n'interagissent pas avec d'autres Actifs. Les fonctionnalités intelligentes de DefectDojo, telles que la **Déduplication**, ne s'appliquent que dans le contexte d'un seul Actif. + +Comme les **Organisations**, les **Actifs** peuvent avoir des règles de Contrôle d'Accès Basé sur les Rôles appliquées, ce qui limite la capacité des membres de l'équipe à les consulter et à interagir avec eux (ainsi qu'avec les données d'Engagement, de Test et de Constatation sous-jacentes). Pour plus d'informations sur les rôles utilisateur, consultez notre article **Introduction aux rôles**. + +#### Que peut représenter un Actif ? + +Le concept d'« Actif » de DefectDojo ne correspond pas nécessairement de façon exacte à ce que votre organisation appellerait un « Produit ». Le développement logiciel est complexe, et les besoins de sécurité peuvent varier considérablement même au sein d'un seul logiciel. + +Les scénarios suivants sont de bonnes raisons d'envisager la création d'un Actif DefectDojo distinct : + +* « **ExampleAsset** » possède une version Windows, une version Mac et une version Cloud +* « **ExampleAsset 1.0** » utilise des composants logiciels complètement différents de « **ExampleAsset 2.0** », et les deux versions sont activement prises en charge par votre entreprise. +* L'équipe chargée de travailler sur « **ExampleAsset version A** » est différente de l'équipe chargée de « **ExampleAsset version B** », et doit par conséquent se voir attribuer des permissions de sécurité différentes. + +Ces variations au sein d'un même Actif peuvent également être gérées au niveau de l'Engagement. Notez que les Engagements ne disposent pas de contrôle d'accès de la même manière que les Actifs et les Organisations. + +## **Engagements** + +Une fois qu'un Actif est configuré, vous pouvez commencer à créer et planifier des Engagements. Les Engagements sont destinés à représenter des moments dans le temps où des tests ont lieu, et contiennent un ou plusieurs **Tests**. + +Les Engagements ont toujours : + +* un **Nom** unique +* des **dates de début et de fin** cibles +* un **Statut** (Not Started, In Progress, Cancelled, Completed...) +* un **Responsable de test** assigné +* un **Actif** associé + +Il existe deux types d'Engagement : **Interactif** et **CI/CD**. + +* Un **Engagement Interactif** est généralement mené par un ingénieur. Les Engagements Interactifs se concentrent sur le test de l'application pendant son exécution, à l'aide d'un test automatisé, d'un testeur humain, ou de toute activité « interagissant » avec les fonctionnalités de l'application. Voir la [définition de l'IAST par l'OWASP](https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing#:~:text=Interactive%20Application%20Security%20Testing,interacting%E2%80%9D%20with%20the%20application%20functionality.). +* Un **Engagement CI/CD** est destiné à l'intégration automatisée avec un pipeline CI/CD. Les Engagements CI/CD sont destinés à importer des données en tant qu'action automatisée, déclenchée par une étape du processus de mise en production. + +Les Engagements peuvent être suivis à l'aide de la vue **Calendrier** de DefectDojo. + +#### Que peut représenter un Engagement ? + +Les Engagements sont destinés à représenter des groupes d'efforts de test liés entre eux. La manière dont vous souhaitez regrouper vos efforts de test dépend de votre approche. + +Si vous avez un effort de test planifié, un Engagement vous offre un endroit pour stocker tous les résultats associés. Voici un exemple de ce type d'Engagement : + +#### **Engagement :** ExampleSoftware 1.5.2 - Effort de test interactif + +*Dans cet exemple, une équipe de sécurité exécute plusieurs tests le même jour dans le cadre d'une mise en production logicielle.* + +* **Test :** Résultats du scan Nessus (12 mars) +* **Test :** Résultats de l'audit de scan NPM (12 mars) +* **Test :** Résultats du scan Snyk (12 mars) +​ +Vous pouvez également organiser les résultats de Test CI/CD au sein d'un Engagement. Ce type d'Engagement est « Open-Ended » (à durée indéterminée), ce qui signifie qu'il n'a pas de date, et ajoutera plutôt des données supplémentaires chaque fois que les actions CI/CD associées seront exécutées. + +#### Engagement : ExampleSoftware CI/CD Testing + +*Dans cet exemple, plusieurs scans CI/CD sont automatiquement importés en tant que Tests à chaque création d'une nouvelle version logicielle.* + +* Test : Résultats du scan 1.5.2 (12 mars) +* Test : Résultats du scan 1.5.1 (3 mars) +* Test : Résultats du scan 1.5.0 (14 février) + +Les Engagements peuvent être organisés de la manière qui convient le mieux à votre équipe. Tous les Engagements imbriqués sous un Actif peuvent être consultés par l'équipe chargée de travailler sur cet Actif. + +## **Tests** + +Les Tests sont un regroupement d'activités menées par des ingénieurs pour tenter de découvrir des failles dans un Actif. + +Les Tests ont toujours : + +* un **Titre de Test** unique +* un **Type de Test** spécifique (API Test, Nessus Scan, etc) +* un **Environnement** de test associé +* un **Engagement** associé + +Les Tests peuvent être créés de différentes manières. Les Tests peuvent être créés automatiquement lorsque des données de scan sont importées directement dans un Engagement, ce qui donne lieu à un nouveau Test contenant les données de scan. Les Tests peuvent également être créés en prévision de la planification d'Engagements futurs, ou pour des constatations de sécurité saisies manuellement nécessitant un suivi et une remédiation. + +### **Types de Test** + +DefectDojo prend en charge deux catégories de Types de Test : + +1. **Types de Test basés sur un analyseur** : ils correspondent à des scanners de sécurité spécifiques produisant une sortie dans des formats tels que XML, JSON ou CSV. Lors de l'import des résultats de scan, DefectDojo utilise des analyseurs spécialisés pour convertir la sortie du scanner en Constatations. + +2. **Types de Test sans analyseur** : ils sont utilisés pour les Constatations créées manuellement, non importées depuis des fichiers de scan. Ces Types de Test utilisent la méthode [Generic Findings Import](/supported_tools/parsers/generic_findings_import/) pour afficher les Constatations et les métadonnées. + +Les Types de Test suivants apparaissent dans le menu déroulant « Scan Type » lors de la création d'un nouveau test. + * API Test + * Static Check + * Pen Test + * Web Application Test + * Security Research + * Threat Modeling + * Manual Code Review + +Les Types de Test sans analyseur doivent être utilisés lorsque vous devez créer manuellement des constatations nécessitant une remédiation, mais qui ne proviennent pas d'une sortie de scanner automatisée. + +#### **Types de Test basés sur un analyseur** + +Les types de test basés sur un analyseur peuvent être catégorisés selon la façon dont le nom de leur type de test est déterminé : + +- **Noms de Type de Test fixes** : le nom du type de test est prédéfini et connu avant l'import (par ex. « ZAP Scan », « Nessus Scan »). + +- **Noms de Type de Test définis par le rapport** : le nom du type de test est extrait du contenu du rapport de scan au moment de l'import. + +Exemples : + - **Generic Findings Import** : crée des types de test basés sur le champ `type` dans les rapports JSON + - **SARIF** : crée des types de test basés sur les noms d'outils dans le rapport SARIF (par ex. « Dockle Scan (SARIF) ») + - **OpenReports** : crée des types de test distincts pour chaque source trouvée dans le rapport + +**Règles de nommage des Types de Test définis par le rapport :** +- Si le champ `type` du rapport est identique au type de scan → le type de scan est utilisé directement (par ex. « Generic Findings Import ») +- Si le champ `type` du rapport diffère → un format « {type} Scan ({scan_type}) » est créé (par ex. « Tool1 Scan (Generic Findings Import) ») +- Si le champ `type` du rapport se termine déjà par le suffixe « ({scan_type}) » → il est utilisé tel quel, de sorte que le suffixe n'est jamais dupliqué (par ex. « Tool1 (Generic Findings Import) » reste « Tool1 (Generic Findings Import) ») +- Si aucun champ `type` n'est fourni → le type de scan est utilisé directement + +**Points importants à considérer :** +- Les types de test définis par le rapport sont créés automatiquement lorsqu'un nouveau type est détecté lors de l'import ou du réimport. +- Pour les réimports, le nom du type de test doit correspondre exactement - toute discordance déclenchera une erreur de validation +- Les paramètres de déduplication (`HASHCODE_FIELDS_PER_SCANNER`) utilisent les noms de type de test comme clés ; les noms définis par le rapport doivent donc être configurés en conséquence si vous souhaitez un comportement de déduplication personnalisé + +#### **Comment les Tests interagissent-ils entre eux ?** + +Les Tests prennent vos données de test et les regroupent en Constatations. En général, les équipes de sécurité répètent le même effort de test à plusieurs reprises, et les Tests dans DefectDojo permettent de gérer ce processus de manière élégante. + +**Les tests précédemment importés peuvent être réimportés** - Si vous exécutez le même type de test dans le même contexte d'Engagement, vous pouvez réimporter les résultats du test après chaque scan terminé. DefectDojo comparera les données réimportées au résultat existant, et ne créera pas de nouvelles Constatations si des doublons existent dans les données de scan. + +**Les Tests peuvent être importés séparément** - Si vous exécutez le même test sur un Actif au sein d'Engagements distincts, DefectDojo comparera tout de même les données avec les Tests précédents pour trouver les Constatations en double. Cela vous permet de garder une trace des Constatations précédemment atténuées ou dont le risque a été accepté. + +Si un Test est ajouté directement à un Actif sans Engagement, un Engagement générique sera créé automatiquement pour contenir le Test. Cela permet des imports de données ad hoc. + +**Exemples de Tests :** + +* Scan Burp du 29 oct. 2015 au 29 oct. 2015 +* Scan Nessus du 31 oct. 2015 au 31 oct. 2015 +* API Test du 15 oct. 2015 au 20 oct. 2015 + +## **Constatations** + +Une fois que des données ont été téléversées dans un Test, les résultats de ces données seront répertoriés dans le Test sous forme de **Constatations** individuelles à examiner. + +Une constatation représente une faille spécifique découverte lors des tests. + +Les Constatations ont toujours : + +* un **Nom de Constatation** unique +* la **Date** à laquelle elles ont été découvertes +* plusieurs **Statuts** associés, tels que Actif, Vérifié ou Faux positif +* un **Test** associé +* un niveau de **Sévérité** : Critique, Élevée, Moyenne, Faible, et Informationnel (Info). + +Les Constatations peuvent être ajoutées via un import de données, mais elles peuvent également être ajoutées manuellement à un Test. + +**Exemples de Constatations :** + +* Vulnérabilité potentielle MiTM OpenSSL « ChangeCipherSpec » +* Application Web potentiellement vulnérable au Clickjacking +* Protection XSS du navigateur Web non activée + +## **Points de terminaison** + +Les données de scan contiennent généralement des références aux hôtes ou points de terminaison affectés par une Constatation donnée. DefectDojo agrège automatiquement les Constatations par point de terminaison, ce qui vous permet d'utiliser la vue Point de terminaison pour consulter toutes les Constatations affectant un Point de terminaison ou un nom d'hôte donné. + +Exemples : +- https://www.example.com +- https://www.example.com:8080/products +- 192.168.0.36 diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.ja.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.ja.md new file mode 100644 index 00000000000..844cdafb56e --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.ja.md @@ -0,0 +1,216 @@ +--- +title: 'アセット階層: 概要' +description: 組織、アセット、エンゲージメント、テスト、検出事項を理解する +weight: 1 +audience: opensource +aliases: +- /ja/en/working_with_findings/organizing_engagements_tests/product_hierarchy +- /ja/asset_modelling/os_hierarchy/product_hierarchy/ +- /ja/en/asset_modelling/os_hierarchy/product_hierarchy/ +--- + +DefectDojoは、作業を整理するために5つの主要なデータクラスを使用します: **組織、アセット**、**エンゲージメント**、**テスト**、**検出事項**です。 + +DefectDojoは、チームをツールに合わせるのではなく、ツールをチームに合わせて柔軟に運用できるように設計されています。これらのデータクラスを使って作業をどのように整理できるかを理解すれば、堅牢で柔軟なワークスペースを設計できるようになります。 + +### アセット階層図 +![image](images/Asset_Hierarchy_Full.png) + + +## **組織** + +DefectDojoでまず設定する必要があるデータのカテゴリは組織です。組織は、特定の方法でアセットを分類することを目的としています。例えば以下のような分類が考えられます。 + +* 事業ドメイン別 +* 開発チーム別 +* セキュリティチーム別 + +![image](images/Asset_Hierarchy_Overview.png) +*アセットは、それぞれの組織の下にグループ化されてネストされます。* + +組織にはロールベースアクセス制御のルールを適用でき、チームメンバーがそのデータ(配下のエンゲージメント、テスト、検出事項データを含むアセット)を閲覧・操作できる範囲を制限できます。ユーザーロールの詳細については、**Introduction To Roles**の記事を参照してください。 + +#### 組織は何を表すことができますか? + +* 特定のソフトウェアプロジェクトに多数の異なるデプロイやバージョンがある場合、プロジェクト全体のスコープをカバーする単一の組織を作成し、各バージョンを個別のアセットとして存在させる方法が有効な場合があります。 +​ +* また、ソフトウェア開発プロセスの各段階を表すために組織を使用することも考えられます。例えば「In Development」用の組織と「In Production」用の組織を分けるといった方法です。 +​ +* 最終的には、アセットをどのように整理し、組織に何を表現させたいかはあなた次第です。DefectDojoの階層は、セキュリティチームのニーズに合わせて変更する必要があるかもしれません。 + +## **アセット** + +DefectDojoにおける**アセット**は、現在テストしているプロジェクト、プログラム、またはアプリケーションを表すことを目的としています。アセットは、その対象に関連するすべてのセキュリティ作業とテスト履歴を保持します。 + +![image](images/Asset_Hierarchy_Overview_2.png) + +* 一意の**名前** +* **説明** +* **組織** +* 割り当てられた**SLA設定** + +アセットのスコープは、広範囲にも特定の範囲にも自由に設定できます。デフォルトでは、アセットは階層内で完全に独立したオブジェクトですが、**組織**によってグループ化することができます。 + +アセットは「壁で仕切られた」存在であり、他のアセットとは相互作用しません。**重複排除**などのDefectDojoのスマート機能は、単一のアセットの範囲内でのみ適用されます。 + +**組織**と同様に、**アセット**にもロールベースアクセス制御のルールを適用でき、チームメンバーがそのアセット(および配下のエンゲージメント、テスト、検出事項データ)を閲覧・操作できる範囲を制限できます。ユーザーロールの詳細については、**Introduction To Roles**の記事を参照してください。 + +#### アセットは何を表すことができますか? + +DefectDojoにおける「アセット」という概念は、あなたの組織が「製品」と呼ぶものと必ずしも1対1で対応するとは限りません。ソフトウェア開発は複雑であり、セキュリティ上のニーズは、単一のソフトウェアの範囲内であっても大きく異なる場合があります。 + +以下のようなシナリオは、別のDefectDojoアセットを作成することを検討すべき良い理由です。 + +* 「**ExampleAsset**」にWindows版、Mac版、Cloud版がある場合 +* 「**ExampleAsset 1.0**」が「**ExampleAsset 2.0**」とはまったく異なるソフトウェアコンポーネントを使用しており、両方のバージョンが自社によって積極的にサポートされている場合 +* 「**ExampleAsset version A**」の担当チームが「**ExampleAsset version B**」を担当するアセットチームと異なり、その結果として異なるセキュリティ権限を割り当てる必要がある場合 + +単一のアセット内でのこうしたバリエーションは、エンゲージメントレベルで扱うこともできます。ただし、エンゲージメントにはアセットや組織のようなアクセス制御機能がない点に注意してください。 + +## **エンゲージメント** + +アセットを設定したら、エンゲージメントの作成とスケジュール設定を開始できます。エンゲージメントは、テストが実施される特定の期間を表すことを目的としており、1つ以上の**テスト**を含みます。 + +エンゲージメントには常に以下が含まれます。 + +* 一意の**名前** +* 目標となる**開始日と終了日** +* **ステータス**(Not Started、In Progress、Cancelled、Completedなど) +* 割り当てられた**テストリード** +* 関連付けられた**アセット** + +エンゲージメントには**Interactive**と**CI/CD**の2種類があります。 + +* **Interactive Engagement**は、通常はエンジニアによって実施されます。Interactive Engagementは、自動テスト、人間によるテスター、またはアプリケーションの機能と「対話する」その他の活動を用いて、アプリケーションが稼働している状態でのテストに重点を置きます。詳細は[OWASPによるIASTの定義](https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing#:~:text=Interactive%20Application%20Security%20Testing,interacting%E2%80%9D%20with%20the%20application%20functionality.)を参照してください。 +* **CI/CD Engagement**は、CI/CDパイプラインとの自動連携を目的としています。CI/CD Engagementは、リリースプロセスの一部としてトリガーされる自動アクションとしてデータをインポートすることを想定しています。 + +エンゲージメントは、DefectDojoの**Calendar**ビューを使用して追跡できます。 + +#### エンゲージメントは何を表すことができますか? + +エンゲージメントは、関連するテスト作業のグループを表すことを目的としています。テスト作業をどのようにグループ化するかは、あなたのアプローチ次第です。 + +計画されたテスト作業がスケジュールされている場合、エンゲージメントは関連するすべての結果を保存する場所を提供します。この種のエンゲージメントの例を以下に示します。 + +#### **エンゲージメント:** ExampleSoftware 1.5.2 - Interactive Testing Effort + +*この例では、セキュリティチームがソフトウェアリリースの一環として同じ日に複数のテストを実施しています。* + +* **テスト:** Nessus Scan Results (3月12日) +* **テスト:** NPM Scan Audit Results (3月12日) +* **テスト:** Snyk Scan Results (3月12日) +​ +CI/CDのテスト結果もエンゲージメント内で整理できます。この種のエンゲージメントは「オープンエンド」であり、日付を持たず、関連するCI/CDアクションが実行されるたびにデータが追加されていきます。 + +#### エンゲージメント: ExampleSoftware CI/CD Testing + +*この例では、新しいソフトウェアリリースが作成されるたびに、複数のCI/CDスキャンが自動的にテストとしてインポートされます。* + +* テスト: 1.5.2 Scan Results (3月12日) +* テスト: 1.5.1 Scan Results (3月3日) +* テスト: 1.5.0 Scan Results (2月14日) + +エンゲージメントは、チームにとって最適な方法で整理できます。アセットの下にネストされたすべてのエンゲージメントは、そのアセットの作業を担当するチームが閲覧できます。 + +## **テスト** + +テストは、アセット内の欠陥を発見するためにエンジニアが実施する活動のグループです。 + +テストには常に以下が含まれます。 + +* 一意の**テストタイトル** +* 特定の**テストタイプ**(API Test、Nessus Scanなど) +* 関連付けられたテストの**環境** +* 関連付けられた**エンゲージメント** + +テストの作成方法にはいくつかの種類があります。スキャンデータがエンゲージメントに直接インポートされると、そのスキャンデータを含む新しいテストが自動的に作成されます。また、今後のエンゲージメントを計画する目的や、追跡・修復が必要な手動入力のセキュリティ検出事項のために、あらかじめテストを作成しておくこともできます。 + +### **テストタイプ** + +DefectDojoは2種類のテストタイプをサポートしています。 + +1. **パーサーベースのテストタイプ**: XML、JSON、CSVなどの形式で出力を生成する特定のセキュリティスキャナーに対応しています。スキャン結果をインポートする際、DefectDojoは専用のパーサーを使ってスキャナーの出力を検出事項に変換します。 + +2. **非パーサー型のテストタイプ**: スキャンファイルからインポートされない、手動で作成された検出事項に使用されます。これらのテストタイプは、[Generic Findings Import](/supported_tools/parsers/generic_findings_import/)方式を使用して検出事項とメタデータを表示します。 + +新しいテストを作成する際、「Scan Type」ドロップダウンには以下のテストタイプが表示されます。 + * API Test + * Static Check + * Pen Test + * Web Application Test + * Security Research + * Threat Modeling + * Manual Code Review + +非パーサー型のテストタイプは、修復が必要でありながら自動化されたスキャナーの出力に由来しない検出事項を手動で作成する必要がある場合に使用します。 + +#### **パーサーベースのテストタイプ** + +パーサーベースのテストタイプは、テストタイプ名がどのように決定されるかによって分類できます。 + +- **固定のテストタイプ名**: テストタイプ名はあらかじめ定義されており、インポート前から判明しています(例:「ZAP Scan」、「Nessus Scan」)。 + +- **レポート定義のテストタイプ名**: テストタイプ名は、インポート時にスキャンレポートの内容から抽出されます。 + +例としては以下のものがあります。 + - **Generic Findings Import**: JSONレポート内の`type`フィールドに基づいてテストタイプを作成します + - **SARIF**: SARIFレポート内のツール名に基づいてテストタイプを作成します(例:「Dockle Scan (SARIF)」) + - **OpenReports**: レポート内で見つかったソースごとに個別のテストタイプを作成します + +**レポート定義のテストタイプ命名ルール:** +- レポートの`type`フィールドがスキャンタイプと同じ場合 → スキャンタイプがそのまま使用されます(例:「Generic Findings Import」) +- レポートの`type`フィールドが異なる場合 → 「{type} Scan ({scan_type})」という形式で作成されます(例:「Tool1 Scan (Generic Findings Import)」) +- レポートの`type`フィールドがすでに「 ({scan_type})」というサフィックスで終わっている場合 → そのまま使用され、サフィックスが二重になることはありません(例:「Tool1 (Generic Findings Import)」は「Tool1 (Generic Findings Import)」のままです) +- `type`フィールドが指定されていない場合 → スキャンタイプがそのまま使用されます + +**重要な考慮事項:** +- レポート定義のテストタイプは、インポートまたは再インポート時に新しいタイプが検出されると自動的に作成されます。 +- 再インポートの場合、テストタイプ名は完全に一致している必要があります。一致しない場合は検証エラーが発生します +- 重複排除設定(`HASHCODE_FIELDS_PER_SCANNER`)はテストタイプ名をキーとして使用するため、カスタムの重複排除の動作を求める場合は、レポート定義の名前もそれに合わせて設定する必要があります + +#### **テスト同士はどのように相互作用しますか?** + +テストはテストデータを取り込み、それを検出事項としてグループ化します。一般的に、セキュリティチームは同じテスト作業を繰り返し実施することになりますが、DefectDojoのテストはこのプロセスをうまく処理できるようにします。 + +**以前にインポートしたテストは再インポートできます** - 同じエンゲージメントの文脈で同種のテストを実行している場合、スキャンが完了するたびにテスト結果を再インポートできます。DefectDojoは再インポートされたデータを既存の結果と比較し、スキャンデータ内に重複が存在する場合は新しい検出事項を作成しません。 + +**テストは個別にインポートすることもできます** - 別々のエンゲージメント内で同じテストをアセットに対して実行した場合でも、DefectDojoはデータを以前のテストと比較して重複する検出事項を見つけます。これにより、以前に緩和済みまたはリスク受容済みとなった検出事項を追跡し続けることができます。 + +エンゲージメントを介さずにテストが直接アセットに追加された場合、そのテストを格納する汎用のエンゲージメントが自動的に作成されます。これにより、アドホックなデータインポートが可能になります。 + +**テストの例:** + +* 2015年10月29日から2015年10月29日までのBurp Scan +* 2015年10月31日から2015年10月31日までのNessus Scan +* 2015年10月15日から2015年10月20日までのAPI Test + +## **検出事項** + +データがテストにアップロードされて追加されると、そのデータの結果は、レビュー対象の個々の**検出事項**としてテスト内に一覧表示されます。 + +検出事項は、テスト中に発見された特定の欠陥を表します。 + +検出事項には常に以下が含まれます。 + +* 一意の**検出事項名** +* 発見された**日付** +* アクティブ、検証済み、誤検知など、複数の関連する**ステータス** +* 関連付けられた**テスト** +* **深刻度**レベル: 重大、高、中、低、情報(Info) + +検出事項はデータのインポートを通じて追加できますが、テストに手動で追加することもできます。 + +**検出事項の例:** + +* OpenSSL 'ChangeCipherSpec' MiTM Potential Vulnerability +* Web Application Potentially Vulnerable to Clickjacking +* Web Browser XSS Protection Not Enabled + +## **エンドポイント** + +スキャンデータには通常、特定の検出事項の影響を受けるホストやエンドポイントへの参照が含まれます。DefectDojoは検出事項をエンドポイントごとに自動的に集約するため、エンドポイントビューを使用して、特定のエンドポイントまたはホスト名に影響するすべての検出事項を確認できます。 + +例: +- https://www.example.com +- https://www.example.com:8080/products +- 192.168.0.36 diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.de.md b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.de.md new file mode 100644 index 00000000000..bea4236e7de --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.de.md @@ -0,0 +1,79 @@ +--- +title: SLA-Konfiguration +description: Service Level Agreements für verschiedene Produkte konfigurieren +weight: 2 +audience: opensource +aliases: +- /de/en/working_with_findings/sla_configuration +--- + +Jedes Product in DefectDojo kann über eine eigene Service Level Agreement (SLA)-Konfiguration verfügen, die angibt, wie viele Tage Ihrer Organisation zur Behebung oder anderweitigen Bearbeitung eines Findings zur Verfügung stehen. + +Die SLA kann entweder anhand des **[Severity des Findings](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** oder des **[Risikos des Findings](/asset_modelling/pro_hierarchy/priority_sla/)** (in DefectDojo Pro) festgelegt werden. + +![image](images/sla_multiple.png) + +SLAs wenden auf ein Finding einen Tage-Countdown an, basierend auf dem Tag, an dem das Finding in DefectDojo erstellt wurde. Wenn ein Finding innerhalb des Countdowns nicht geschlossen wird, wird das Finding als SLA-Verstoß gekennzeichnet. + +## Arbeiten mit SLAs + +Sie können SLAs verwenden, um die Behebungsrichtlinien Ihrer Organisation abzubilden. Sie können sie auch nutzen, um die am längsten aktiven, kritischsten Findings in Ihrer DefectDojo-Instanz zu priorisieren. + +* Sie können Finding-Tabellen nach SLA-Tagen sortieren oder filtern. +* SLA-Verstöße können so konfiguriert werden, dass sie [Notifications](/admin/notifications/about_notifications/) an die dem betreffenden Product zugewiesenen DefectDojo-Benutzer auslösen. +* In **DefectDojo Pro** wird die SLA-Performance auch auf den Metrics-Dashboards [Executive Insights and Remediation](/metrics_reports/pro_metrics/pro__overview/) erfasst. +* Die SLA-Einhaltung kann in **DefectDojo Pro** auch auf einem individuellen [Dashboard](/metrics_reports/dashboards/custom-dashboards/) angezeigt werden — zum Beispiel mit einem SLA Burndown oder einem gefilterten Count-Widget. + +### Status „Mitigated Within SLA“ + +Wenn ein Finding vor Ablauf der SLA-Frist erfolgreich Mitigated wird, erhält das Finding in der Spalte „Mitigated Within SLA" ein grünes Häkchen ✅. + +![image](images/sla_mitigated_within.png) + +Wenn ein Finding Mitigated wurde, jedoch nicht bevor die SLA verletzt wurde, erhält das Finding in der Spalte „Mitigated Within SLA" ein rotes X ❌. + +### SLA-Verstöße + +Wenn die SLA für ein bestimmtes Finding verletzt wird (das Finding wird nicht innerhalb des SLA-Zeitrahmens geschlossen), wechselt das grüne Häkchen ✅ zu einem roten X ❌. Die SLA wird weiterhin mit einer negativen Zahl verfolgt, die angibt, um wie viele Tage die SLA bereits überschritten wurde. + +![image](images/sla_breached.png) + +## Verwalten von SLA-Konfigurationen (Pro) + +In DefectDojo Pro werden eine oder mehrere SLA-Konfigurationen unter **Configuration > Service Level Agreements** in der Seitenleiste verwaltet. Sie können ein **New Service Level Agreement** erstellen oder auf der Seite **All Service Level Agreements** mit vorhandenen SLA-Konfigurationen arbeiten. + +![image](images/pro_sla_risk.png) + +SLA-Konfigurationen können nur von Superusern oder von einem Benutzer mit der entsprechenden [Configuration Permission](/admin/user_management/user_permission_chart/#configuration-permission-chart) bearbeitet werden. + +### SLA konfigurieren + +SLA-Konfigurationen enthalten die Tage, die jedem **Severity**- oder **Risk**-Wert in DefectDojo zugewiesen sind. + +![image](images/pro_new_sla.png) + +Jedes Service Level Agreement kann einen eindeutigen Namen sowie eine optionale Beschreibung haben. + +**Restart SLA on Finding Reactivation**: Wenn diese Option aktiviert ist, beginnt die SLA von Neuem, sobald ein Finding wieder geöffnet (Reopened) wird. Andernfalls basiert die SLA auf dem Erstellungsdatum des Findings. + +Beim Bearbeiten einer SLA können Sie auswählen, ob diese SLA **Severity** oder **Risk** als Grundlage für die Zuweisung der Days To Remediate verwendet. Dies geschieht durch Auswahl der entsprechenden Option im Abschnitt **Service Level configuration Type** des Formulars. + +Von hier aus können Sie die Anzahl der zulässigen Tage für jeden **Severity**- oder **Risk**-Level festlegen. Sie können SLAs auch selektiv erzwingen; indem Sie das Kontrollkästchen **Enforce ___ Finding Days** deaktivieren, können Sie die SLA-Berechnung für diese Severity- oder Risk-Stufen ignorieren. + +## Eine SLA-Konfiguration auf ein Product anwenden (Pro) + +Neu erstellte Products in DefectDojo verwenden immer die **Default SLA Configuration**, deren Werte Sie bei Bedarf anpassen können. + +Wenn Sie SLA-Konfigurationen angelegt haben, können Sie im Formular **Edit Product** auswählen, welche davon auf Ihr Product angewendet wird. + +![image](images/pro_sla_product.png) + +### SLA-Neuberechnung + +Sobald für ein Product eine neue SLA ausgewählt wurde, müssen die SLAs aller zugehörigen Findings von DefectDojo neu berechnet werden. Während dieser Vorgang läuft, kann die SLA eines Products nicht geändert werden. + +## Hinweise zu SLAs + +* SLAs können optional neu gestartet werden, sobald ein Finding mit dem Status [Risiko akzeptiert](/triage_findings/findings_workflows/os__risk_acceptance/) reaktiviert wird. Dies wird beim Erstellen der Risikoakzeptanz über das Feld **Restart SLA Expired** festgelegt. +* Ein Reimport eines Findings startet die SLA nicht neu - SLAs werden immer ab dem Zeitpunkt berechnet, an dem ein Finding erstmals erkannt wurde, es sei denn, **Restart SLA on Finding Reactivation** ist aktiviert. +* Der Ablauf einer Risikoakzeptanz oder die Reaktivierung eines geschlossenen Findings sind die einzigen Möglichkeiten, eine SLA für ein bereits erstelltes Finding zurückzusetzen oder neu zu berechnen (ohne die SLA-Konfiguration des Products zu ändern). diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.es.md b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.es.md new file mode 100644 index 00000000000..36bffb1ab5d --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.es.md @@ -0,0 +1,79 @@ +--- +title: Configuración de SLA +description: Configure Acuerdos de Nivel de Servicio para diferentes Productos +weight: 2 +audience: opensource +aliases: +- /es/en/working_with_findings/sla_configuration +--- + +Cada Producto en DefectDojo puede tener su propia configuración de Acuerdo de Nivel de Servicio (SLA), que representa los días que tiene su organización para remediar o gestionar de otro modo un Hallazgo. + +El SLA se puede configurar según la **[Severidad del Hallazgo](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** o el **[Riesgo del Hallazgo](/asset_modelling/pro_hierarchy/priority_sla/)** (en DefectDojo Pro). + +![image](images/sla_multiple.png) + +Los SLA aplican una cuenta regresiva de días a un Hallazgo según el día en que el Hallazgo fue creado en DefectDojo. Si un Hallazgo no se Cierra dentro de la cuenta regresiva, se etiquetará como en incumplimiento del SLA. + +## Trabajar con SLAs + +Puede usar los SLA como una forma de representar las políticas de remediación de su organización. También puede usarlos como una forma de priorizar los Hallazgos más críticos y con más tiempo activo en su instancia de DefectDojo. + +* Puede ordenar o filtrar las tablas de Hallazgos por días de SLA. +* Las infracciones de SLA se pueden configurar para activar [Notificaciones](/admin/notifications/about_notifications/) a los usuarios de DefectDojo asignados al Producto relacionado. +* En **DefectDojo Pro**, el rendimiento del SLA también se registra en los Paneles de métricas de [Executive Insights and Remediation](/metrics_reports/pro_metrics/pro__overview/). +* El cumplimiento del SLA también se puede mostrar en un [panel](/metrics_reports/dashboards/custom-dashboards/) personalizado en **DefectDojo Pro** — por ejemplo, con un SLA Burndown o un widget de Count filtrado. + +### Estado Mitigated Within SLA + +Si un Hallazgo pasa a estar Mitigado antes de la fecha límite del SLA, el Hallazgo registrará una marca de verificación verde ✅ en la columna Mitigated Within SLA. + +![image](images/sla_mitigated_within.png) + +Si un Hallazgo quedó Mitigado, pero no antes de que se incumpliera el SLA, el Hallazgo registrará una X roja ❌ en la columna Mitigated Within SLA. + +### Incumplimiento de SLAs + +Cuando se incumple el SLA de un Hallazgo determinado (el Hallazgo no se Cierra dentro del plazo del SLA), la marca verde ✅ cambiará a una X roja ❌. El SLA seguirá registrándose con un número negativo, para representar cuántos días lleva incumplido el SLA. + +![image](images/sla_breached.png) + +## Gestionar configuraciones de SLA (Pro) + +En DefectDojo Pro, una o más configuraciones de SLA se gestionan en la sección **Configuration > Service Level Agreements** de la barra lateral. Puede crear un **New Service Level Agreement** o trabajar con las configuraciones de SLA existentes desde la página **All Service Level Agreements**. + +![image](images/pro_sla_risk.png) + +Las configuraciones de SLA solo pueden ser editadas por Superusers o por un usuario con el [Permiso de configuración](/admin/user_management/user_permission_chart/#configuration-permission-chart) correspondiente. + +### Configurar el SLA + +Las configuraciones de SLA contienen los días asignados a cada valor de **Severidad** o **Riesgo** de DefectDojo. + +![image](images/pro_new_sla.png) + +Cada Service Level Agreement puede tener un nombre único, junto con una descripción opcional. + +**Restart SLA on Finding Reactivation**: si está habilitada, esta opción reiniciará el SLA cuando un Hallazgo se Reabra. De lo contrario, el SLA se basará en el momento en que se creó el Hallazgo. + +Al editar un SLA, puede elegir si ese SLA usará la **Severidad** o el **Riesgo** como referencia para asignar los Days To Remediate. Esto se hace seleccionando la opción correspondiente en la sección **Service Level configuration Type** del formulario. + +Desde aquí, puede establecer la cantidad de días permitidos para cada nivel de **Severidad** o **Riesgo**. También puede aplicar los SLA de forma selectiva; al desmarcar **Enforce ___ Finding Days** puede omitir el cálculo del SLA para esos niveles de Severidad o Riesgo. + +## Aplicar una configuración de SLA a un Producto (Pro) + +Los Productos recién creados en DefectDojo siempre aplicarán la **Default SLA Configuration**, que se puede configurar con valores diferentes si lo desea. + +Si tiene configuraciones de SLA, puede elegir cuál de ellas se aplica a su Producto desde el formulario **Edit Product**. + +![image](images/pro_sla_product.png) + +### Recálculo del SLA + +Una vez que se ha seleccionado un nuevo SLA para un Producto, DefectDojo deberá recalcular los SLA de todos los Hallazgos asociados. Mientras se ejecuta este proceso, no se puede cambiar el SLA de un Producto. + +## Notas sobre los SLAs + +* Los SLA se pueden reiniciar opcionalmente una vez que un Hallazgo con [Riesgo aceptado](/triage_findings/findings_workflows/os__risk_acceptance/) se reactiva. Esto se configura al crear la Aceptación de riesgo mediante el campo **Restart SLA Expired**. +* Reimportar un Hallazgo no reinicia el SLA - los SLA siempre se calculan desde el momento en que el Hallazgo se detectó por primera vez, a menos que esté habilitada la opción **Restart SLA on Finding Reactivation**. +* La expiración de la Aceptación de riesgo o la reactivación de un Hallazgo Cerrado son las únicas formas de restablecer o recalcular el SLA de un Hallazgo una vez creado (sin cambiar la configuración de SLA del Producto). diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.fr.md b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.fr.md new file mode 100644 index 00000000000..adbfca23957 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.fr.md @@ -0,0 +1,79 @@ +--- +title: Configuration SLA +description: Configurer les accords de niveau de service (SLA) pour différents Produits +weight: 2 +audience: opensource +aliases: +- /fr/en/working_with_findings/sla_configuration +--- + +Chaque Produit dans DefectDojo peut avoir sa propre configuration d'accord de niveau de service (SLA), qui représente le nombre de jours dont dispose votre organisation pour remédier à une Constatation ou la gérer autrement. + +Le SLA peut être défini en fonction de la **[Sévérité de la Constatation](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** ou du **[Risque de la Constatation](/asset_modelling/pro_hierarchy/priority_sla/)** (dans DefectDojo Pro). + +![image](images/sla_multiple.png) + +Les SLA appliquent un compte à rebours de jours à une Constatation, basé sur le jour où la Constatation a été créée dans DefectDojo. Si une Constatation n'est pas clôturée avant l'expiration du délai, elle sera étiquetée comme étant en violation du SLA. + +## Utilisation des SLA + +Vous pouvez utiliser les SLA pour représenter les politiques de remédiation de votre organisation. Vous pouvez également les utiliser pour prioriser les Constatations les plus critiques et actives depuis le plus longtemps dans votre instance DefectDojo. + +* Vous pouvez trier ou filtrer les tableaux de Constatations par jours de SLA. +* Les violations de SLA peuvent être configurées pour déclencher des [Notifications](/admin/notifications/about_notifications/) aux utilisateurs DefectDojo assignés au Produit concerné. +* Dans **DefectDojo Pro**, la performance du SLA est également suivie sur les tableaux de bord de métriques [Executive Insights and Remediation](/metrics_reports/pro_metrics/pro__overview/). +* La conformité SLA peut également être affichée sur un [tableau de bord](/metrics_reports/dashboards/custom-dashboards/) personnalisé dans **DefectDojo Pro** — par exemple avec un widget SLA Burndown ou un widget Count filtré. + +### Statut Atténué dans les délais du SLA + +Si une Constatation est atténuée avec succès avant l'échéance du SLA, elle enregistrera une coche verte ✅ dans la colonne Atténué dans les délais du SLA. + +![image](images/sla_mitigated_within.png) + +Si une Constatation a été atténuée, mais pas avant que le SLA ne soit violé, elle enregistrera un X rouge ❌ dans la colonne Atténué dans les délais du SLA. + +### Violation des SLA + +Lorsque le SLA d'une Constatation donnée est violé (la Constatation n'est pas clôturée dans le délai du SLA), la coche verte ✅ se transformera en X rouge ❌. Le SLA continuera d'être suivi avec un nombre négatif, représentant le nombre de jours de dépassement du SLA. + +![image](images/sla_breached.png) + +## Gestion des configurations SLA (Pro) + +Dans DefectDojo Pro, une ou plusieurs configurations SLA sont gérées dans la section **Configuration > Service Level Agreements** de la barre latérale. Vous pouvez créer un **New Service Level Agreement** ou travailler avec les configurations SLA existantes depuis la page **All Service Level Agreements**. + +![image](images/pro_sla_risk.png) + +Les configurations SLA ne peuvent être modifiées que par des Superusers ou par un utilisateur disposant de la [permission de Configuration](/admin/user_management/user_permission_chart/#configuration-permission-chart) correspondante. + +### Configurer le SLA + +Les configurations SLA contiennent le nombre de jours attribué à chaque valeur de **Sévérité** ou de **Risque** de DefectDojo. + +![image](images/pro_new_sla.png) + +Chaque accord de niveau de service peut avoir un nom unique, ainsi qu'une description optionnelle. + +**Restart SLA on Finding Reactivation** : si cette option est activée, elle relancera le SLA à zéro lorsqu'une Constatation est rouverte. Sinon, le SLA sera basé sur la date de création de la Constatation. + +Lors de la modification d'un SLA, vous pouvez choisir si ce SLA utilisera la **Sévérité** ou le **Risque** comme référence pour l'attribution des jours de remédiation. Cela se fait en sélectionnant l'option correspondante dans la section **Service Level configuration Type** du formulaire. + +À partir de là, vous pouvez définir le nombre de jours autorisé pour chaque niveau de **Sévérité** ou de **Risque**. Vous pouvez également appliquer les SLA de manière sélective ; en décochant **Enforce ___ Finding Days**, vous pouvez ignorer le calcul du SLA pour ces niveaux de Sévérité ou de Risque. + +## Appliquer une configuration SLA à un Produit (Pro) + +Les Produits nouvellement créés dans DefectDojo appliqueront toujours la **Default SLA Configuration**, qui peut être définie sur des valeurs différentes si vous le souhaitez. + +Si vous disposez de configurations SLA, vous pouvez choisir celle qui est appliquée à votre Produit depuis le formulaire **Edit Product**. + +![image](images/pro_sla_product.png) + +### Recalcul du SLA + +Une fois qu'un nouveau SLA a été sélectionné pour un Produit, les SLA de toutes les Constatations associées devront être recalculés par DefectDojo. Pendant l'exécution de ce processus, le SLA d'un Produit ne peut pas être modifié. + +## Remarques sur les SLA + +* Les SLA peuvent être optionnellement relancés lorsqu'une Constatation [Risque accepté](/triage_findings/findings_workflows/os__risk_acceptance/) se réactive. Cela se configure lors de la création de l'Acceptation du risque en définissant le champ **Restart SLA Expired**. +* Réimporter une Constatation ne relance pas le SLA - les SLA sont toujours calculés à partir du moment où une Constatation a été détectée pour la première fois, sauf si **Restart SLA on Finding Reactivation** est activé. +* L'expiration de l'Acceptation du risque ou la réactivation d'une Constatation clôturée sont les seuls moyens de réinitialiser ou de recalculer le SLA d'une Constatation une fois celle-ci créée (sans modifier la configuration SLA du Produit). diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.ja.md b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.ja.md new file mode 100644 index 00000000000..38ff8842e5a --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.ja.md @@ -0,0 +1,79 @@ +--- +title: SLA設定 +description: 製品ごとにサービスレベルアグリーメントを設定する +weight: 2 +audience: opensource +aliases: +- /ja/en/working_with_findings/sla_configuration +--- + +DefectDojoの各製品には、独自のサービスレベルアグリーメント(SLA)設定を持たせることができます。これは、検出事項を修復またはその他の方法で管理するために組織に与えられた日数を表します。 + +SLAは、**[検出事項の深刻度](/asset_modelling/os_hierarchy/product_hierarchy/#findings)**、または(DefectDojo Proの場合)**[検出事項のリスク](/asset_modelling/pro_hierarchy/priority_sla/)**のいずれかに基づいて設定できます。 + +![image](images/sla_multiple.png) + +SLAは、DefectDojo内で検出事項が作成された日を基準として、検出事項に日数のカウントダウンを適用します。カウントダウン期間内に検出事項がクローズされない場合、その検出事項はSLA違反としてラベル付けされます。 + +## SLAの操作 + +SLAは、組織の修復ポリシーを表現する手段として使用できます。また、DefectDojoインスタンス内で最も長くアクティブな状態にある、最も重大な検出事項を優先順位付けする手段としても使用できます。 + +* 検出事項テーブルをSLA日数でソートまたはフィルタリングできます。 +* SLA違反が発生した際に、関連する製品に割り当てられたDefectDojoユーザーへ[通知](/admin/notifications/about_notifications/)をトリガーするよう設定できます。 +* **DefectDojo Pro**では、SLAのパフォーマンスは[Executive InsightsおよびRemediation](/metrics_reports/pro_metrics/pro__overview/)メトリクスダッシュボードでも追跡されます。 +* **DefectDojo Pro**では、SLAの遵守状況をカスタム[ダッシュボード](/metrics_reports/dashboards/custom-dashboards/)上に表示することもできます。例えば、SLA BurndownウィジェットやフィルタリングされたCountウィジェットを使用します。 + +### Mitigated Within SLAステータス + +検出事項がSLAの期限までに正常に緩和された場合、その検出事項にはMitigated Within SLA列に✅の緑色のチェックマークが記録されます。 + +![image](images/sla_mitigated_within.png) + +検出事項が緩和されたものの、SLA違反となった後だった場合、その検出事項にはMitigated Within SLA列に❌の赤色のXが記録されます。 + +### SLA違反 + +ある検出事項のSLAが違反された場合(SLAの期限内に検出事項がクローズされなかった場合)、✅の緑色のチェックは❌の赤色のXに切り替わります。SLAは引き続き負の数値で追跡され、SLAが何日超過しているかを示します。 + +![image](images/sla_breached.png) + +## SLA設定の管理(Pro) + +DefectDojo Proでは、1つ以上のSLA設定がサイドバーの**Configuration > Service Level Agreements**部分で管理されます。**New Service Level Agreement**を作成することも、**All Service Level Agreements**ページから既存のSLA設定を操作することもできます。 + +![image](images/pro_sla_risk.png) + +SLA設定は、スーパーユーザー、または対応する[Configuration Permission](/admin/user_management/user_permission_chart/#configuration-permission-chart)を持つユーザーのみが編集できます。 + +### SLAの設定 + +SLA設定には、DefectDojoの各**深刻度**または**リスク**の値に割り当てられた日数が含まれます。 + +![image](images/pro_new_sla.png) + +各サービスレベルアグリーメントには、一意の名前と、任意の説明を設定できます。 + +**Restart SLA on Finding Reactivation**: このオプションを有効にすると、検出事項が再オープンされた際にSLAが最初からやり直されます。無効の場合、SLAは検出事項が作成された時点を基準とします。 + +SLAを編集する際、そのSLAが修復までの日数を割り当てる基準として**深刻度**と**リスク**のどちらを使用するかを選択できます。これは、フォームの**Service Level configuration Type**セクションから該当するオプションを選択することで行います。 + +ここから、各**深刻度**または**リスク**レベルに許容される日数を設定できます。また、SLAを選択的に適用することもできます。**Enforce ___ Finding Days**のチェックを外すことで、該当する深刻度またはリスクのレベルについてSLA計算を無視できます。 + +## 製品へのSLA設定の適用(Pro) + +DefectDojoで新規作成された製品には、常に**Default SLA Configuration**が適用されますが、必要に応じて異なる値に設定することもできます。 + +SLA設定がある場合、**Edit Product**フォームから、どの設定を製品に適用するかを選択できます。 + +![image](images/pro_sla_product.png) + +### SLAの再計算 + +製品に新しいSLAが選択されると、関連するすべての検出事項のSLAをDefectDojoが再計算する必要があります。この処理が実行されている間は、製品のSLAを変更することはできません。 + +## SLAに関する補足事項 + +* [リスク受容済み](/triage_findings/findings_workflows/os__risk_acceptance/)の検出事項が再度アクティブ化した場合、SLAを再開するかどうかを任意で設定できます。これは、リスク受容を作成する際に**Restart SLA Expired**フィールドを設定することで行います。 +* 検出事項を再インポートしてもSLAは再開されません。**Restart SLA on Finding Reactivation**が有効になっていない限り、SLAは検出事項が最初に検出された時点から常に計算されます。 +* 検出事項が作成された後にSLAをリセットまたは再計算する方法は、リスク受容の期限切れ、またはクローズされた検出事項の再アクティブ化のみです(製品のSLA設定を変更しない場合)。 diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.de.md b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.de.md new file mode 100644 index 00000000000..9bfe44dba96 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.de.md @@ -0,0 +1,59 @@ +--- +title: Befunde mit Quellcode verknüpfen +description: Integration von Repositories, um zur Stelle der Befunde im Quellcode + zu navigieren. +draft: false +weight: 5 +audience: opensource +aliases: +- /de/en/working_with_findings/organizing_engagements_tests/source-code-repositories +--- + +Bestimmte Tools (insbesondere SAST-Tools) geben in den Schwachstellendaten den zugehörigen Dateinamen und die Zeilennummer an. Wenn das Repository des Quellcodes im Engagement angegeben ist, stellt DefectDojo den Dateipfad als Link dar, sodass der Benutzer direkt zur Stelle der Schwachstelle navigieren kann. + +## Festlegen des Repositorys im Engagement und Test + +### Engagement + +Beim Bearbeiten des Engagements können Benutzer die URL des spezifischen Source-Code-Management-Repositorys festlegen. **(In der Pro-UI kann dieses Feld unter Engagement bearbeiten > Optionale Felder > Repo festgelegt werden)**. + +Bei einem Interactive Engagement muss es sich um eine URL handeln, die den Branch angibt: +- für GitHub - z. B. https://github.com/DefectDojo/django-DefectDojo/tree/dev +![Engagement bearbeiten (GitHub)](images/source-code-repositories_1.png) +- für GitLab - z. B. https://gitlab.com/gitlab-org/gitlab/-/tree/master +![Engagement bearbeiten (Gitlab)](images/source-code-repositories-gitlab_1.png) +- für öffentliches BitBucket - z. B. (wie eine Git-Clone-URL) +![Engagement bearbeiten (Bitbucket öffentlich)](images/source-code-repositories-bitbucket_1.png) +- für eigenständiges/On-Premise-BitBucket https://bb.example.com/scm/some-project/some-repo.git oder https://bb.example.com/scm/some-user-name/some-repo.git für ein öffentliches Benutzer-Repository (wie eine Git-Clone-URL) +![Engagement bearbeiten (Bitbucket eigenständig)](images/source-code-repositories-bitbucket-onpremise_1.png) + +Bei CI/CD-Engagements können Commit-Hash, Branch/Tag und Codezeile variieren, sodass Sie nur die URL des Repositorys angeben müssen. +- für GitHub - z. B. `https://github.com/DefectDojo/django-DefectDojo` +- für GitLab - z. B. `https://gitlab.com/gitlab-org/gitlab` +- für öffentliches BitBucket, Gitea und Codeberg - z. B. `https://bitbucket.org/some-user/some-project.git` (wie eine Git-Clone-URL) +- für eigenständiges/On-Premise-BitBucket `https://bb.example.com/scm/some-project.git` oder `https://bb.example.com/scm/some-user-name/some-repo.git` für ein öffentliches Benutzer-Repository (wie eine Git-Clone-URL) + +In einem CI/CD-Engagement können Sie im Formular **Edit Engagement** einen Commit-Hash oder Branch/Tag angeben, der an alle von DefectDojo dargestellten Links angehängt wird. Wenn diese nicht festgelegt sind, muss die SCM-URL einen vollständigen Link enthalten, der den Code-Branch einschließt. + +Die SCM-Navigations-URL wird anhand des SCM-Typs aus der Repo-URL zusammengesetzt. Ein bestimmter SCM-Typ kann im benutzerdefinierten Asset-Feld „scm-type“ festgelegt werden. Ist kein „scm-type“ festgelegt und enthält die URL „https://github.com“, wird der SCM-Typ „github“ angenommen. + +Benutzerdefinierte Asset-Felder: + +![Benutzerdefinierte Asset-Felder](images/asset-custom-fields_1.png) + +SCM-Typ zum Asset hinzufügen: + +![Asset-SCM-Typ](images/asset-scm-type_1.png) + +Mögliche SCM-Typen sind 'github', 'gitlab', 'bitbucket', 'bitbucket-standalone', 'gitea', 'codeberg' oder keine Angabe (für den Standard github). + + +## Quellcode-Links in Befunden + +Beim Anzeigen eines Befunds wird die Stelle als Link dargestellt, sofern das Repository des Quellcodes im Engagement festgelegt wurde: + +![Link zur Stelle](images/source-code-repositories_2.png) + +Durch Klicken auf diesen Link wird ein neuer Tab im Browser geöffnet, in dem die Quelldatei der Schwachstelle bei der entsprechenden Zeilennummer angezeigt wird: + +![Im Repository anzeigen](images/source-code-repositories_3.png) diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.es.md b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.es.md new file mode 100644 index 00000000000..b29c6c98483 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.es.md @@ -0,0 +1,59 @@ +--- +title: Vincular Hallazgos al código fuente +description: Integración de repositorios para navegar hasta la ubicación de los hallazgos + en el código fuente. +draft: false +weight: 5 +audience: opensource +aliases: +- /es/en/working_with_findings/organizing_engagements_tests/source-code-repositories +--- + +Ciertas herramientas (particularmente las herramientas SAST) incluirán el nombre de archivo asociado y el número de línea en los datos de la vulnerabilidad. Si el repositorio del código fuente está especificado en el Compromiso, DefectDojo presentará la ruta del archivo como un enlace y el usuario podrá navegar directamente hasta la ubicación de la vulnerabilidad. + +## Configurar el repositorio en el Compromiso y el Test + +### Compromiso + +Al editar el Compromiso, los usuarios pueden establecer la URL del repositorio específico de gestión de código fuente. **(En la interfaz de Pro, este campo se puede configurar en Editar Compromiso > Campos opcionales > Repo)**. + +Para un Compromiso Interactivo, debe ser una URL que especifique la rama: +- para GitHub - como https://github.com/DefectDojo/django-DefectDojo/tree/dev +![Editar Compromiso (GitHub)](images/source-code-repositories_1.png) +- para GitLab - como https://gitlab.com/gitlab-org/gitlab/-/tree/master +![Editar Compromiso (Gitlab)](images/source-code-repositories-gitlab_1.png) +- para BitBucket público - como (como una URL de git clone) +![Editar Compromiso (Bitbucket público)](images/source-code-repositories-bitbucket_1.png) +- para BitBucket independiente/on-premise https://bb.example.com/scm/some-project/some-repo.git o https://bb.example.com/scm/some-user-name/some-repo.git para un repositorio público de usuario (como una URL de git clone) +![Editar Compromiso (Bitbucket independiente)](images/source-code-repositories-bitbucket-onpremise_1.png) + +Para Compromisos de CI/CD, el hash de commit, la rama/tag y la línea de código pueden variar, por lo que solo es necesario incluir la URL del repositorio. +- para GitHub - como `https://github.com/DefectDojo/django-DefectDojo` +- para GitLab - como `https://gitlab.com/gitlab-org/gitlab` +- para BitBucket público, Gitea y Codeberg - como `https://bitbucket.org/some-user/some-project.git` (como una URL de git clone) +- para BitBucket independiente/on-premise `https://bb.example.com/scm/some-project.git` o `https://bb.example.com/scm/some-user-name/some-repo.git` para un repositorio público de usuario (como una URL de git clone) + +En un Compromiso de CI/CD, puede especificar un hash de commit o una rama/tag en el formulario **Editar Compromiso**, que se añadirá a los enlaces generados por DefectDojo. Si estos no se configuran, la URL del SCM deberá contener un enlace completo que incluya la rama del código. + +La URL de navegación del SCM se compone a partir de la URL del repositorio utilizando el tipo de SCM. Se puede establecer un tipo de SCM específico en el campo personalizado del Activo "scm-type". Si no se establece ningún "scm-type" y la URL contiene "https://github.com", se asume un tipo de SCM "github". + +Campos personalizados del Activo: + +![Campos personalizados del Activo](images/asset-custom-fields_1.png) + +Agregar tipo de SCM del Activo: + +![Tipo de SCM del Activo](images/asset-scm-type_1.png) + +Los tipos de SCM posibles pueden ser 'github', 'gitlab', 'bitbucket', 'bitbucket-standalone', 'gitea', 'codeberg' o ninguno (para GitHub por defecto). + + +## Enlaces al código fuente en los Hallazgos + +Al visualizar un hallazgo, la ubicación se presentará como un enlace, si el repositorio del código fuente se ha establecido en el Compromiso: + +![Enlace a la ubicación](images/source-code-repositories_2.png) + +Al hacer clic en este enlace se abrirá una nueva pestaña en el navegador, con el archivo fuente de la vulnerabilidad en el número de línea correspondiente: + +![Ver en el repositorio](images/source-code-repositories_3.png) diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.fr.md b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.fr.md new file mode 100644 index 00000000000..9c954e85522 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.fr.md @@ -0,0 +1,59 @@ +--- +title: Associer les constatations au code source +description: Intégration des dépôts pour accéder directement à l'emplacement des constatations + dans le code source. +draft: false +weight: 5 +audience: opensource +aliases: +- /fr/en/working_with_findings/organizing_engagements_tests/source-code-repositories +--- + +Certains outils (notamment les outils SAST) incluent le nom de fichier et le numéro de ligne associés dans les données de vulnérabilité. Si le dépôt du code source est spécifié dans l'Engagement, DefectDojo affiche le chemin du fichier sous forme de lien et l'utilisateur peut accéder directement à l'emplacement de la vulnérabilité. + +## Définir le dépôt dans l'Engagement et le Test + +### Engagement + +Lors de la modification de l'Engagement, les utilisateurs peuvent définir l'URL du dépôt de gestion de code source spécifique. **(Dans l'interface Pro, ce champ se trouve sous Edit Engagement > Optional Fields > Repo)**. + +Pour un Engagement interactif, il doit s'agir d'une URL qui précise la branche : +- pour GitHub - par exemple https://github.com/DefectDojo/django-DefectDojo/tree/dev +![Modifier l'Engagement (GitHub)](images/source-code-repositories_1.png) +- pour GitLab - par exemple https://gitlab.com/gitlab-org/gitlab/-/tree/master +![Modifier l'Engagement (Gitlab)](images/source-code-repositories-gitlab_1.png) +- pour BitBucket public - par exemple (comme une URL de clonage git) +![Modifier l'Engagement (Bitbucket public)](images/source-code-repositories-bitbucket_1.png) +- pour BitBucket autonome/sur site https://bb.example.com/scm/some-project/some-repo.git ou https://bb.example.com/scm/some-user-name/some-repo.git pour un dépôt public utilisateur (comme une URL de clonage git) +![Modifier l'Engagement (Bitbucket autonome)](images/source-code-repositories-bitbucket-onpremise_1.png) + +Pour les Engagements CI/CD, le hash de commit, la branche/tag et la ligne de code peuvent varier ; il suffit donc d'indiquer l'URL du dépôt. +- pour GitHub - par exemple `https://github.com/DefectDojo/django-DefectDojo` +- pour GitLab - par exemple `https://gitlab.com/gitlab-org/gitlab` +- pour BitBucket public, Gitea et Codeberg - par exemple `https://bitbucket.org/some-user/some-project.git` (comme une URL de clonage git) +- pour BitBucket autonome/sur site `https://bb.example.com/scm/some-project.git` ou `https://bb.example.com/scm/some-user-name/some-repo.git` pour un dépôt public utilisateur (comme une URL de clonage git) + +Dans un Engagement CI/CD, vous pouvez indiquer un hash de commit ou une branche/tag dans le formulaire **Edit Engagement**, qui sera ajouté à tous les liens générés par DefectDojo. Si ces informations ne sont pas définies, l'URL SCM devra contenir un lien complet incluant la branche de code. + +L'URL de navigation SCM est construite à partir de l'URL du dépôt en fonction du type de SCM. Un type de SCM spécifique peut être défini dans le champ personnalisé de l'Actif « scm-type ». Si aucun « scm-type » n'est défini et que l'URL contient « https://github.com », un type de SCM « github » est présumé. + +Champs personnalisés de l'Actif : + +![Champs personnalisés de l'Actif](images/asset-custom-fields_1.png) + +Ajout du type SCM de l'Actif : + +![Type SCM de l'Actif](images/asset-scm-type_1.png) + +Les types de SCM possibles sont 'github', 'gitlab', 'bitbucket', 'bitbucket-standalone', 'gitea', 'codeberg' ou aucun (github par défaut). + + +## Liens vers le code source dans les Constatations + +Lors de la consultation d'une constatation, l'emplacement est présenté sous forme de lien si le dépôt du code source a été défini dans l'Engagement : + +![Lien vers l'emplacement](images/source-code-repositories_2.png) + +Cliquer sur ce lien ouvre un nouvel onglet dans le navigateur, affichant le fichier source de la vulnérabilité à la ligne correspondante : + +![Afficher dans le dépôt](images/source-code-repositories_3.png) diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.ja.md b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.ja.md new file mode 100644 index 00000000000..14682a272a1 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.ja.md @@ -0,0 +1,58 @@ +--- +title: 検出事項をソースコードにリンクする +description: 検出事項のソースコード内の場所へ移動するためのリポジトリ統合。 +draft: false +weight: 5 +audience: opensource +aliases: +- /ja/en/working_with_findings/organizing_engagements_tests/source-code-repositories +--- + +一部のツール（特にSASTツール）は、脆弱性データに関連するファイル名と行番号を含みます。エンゲージメントでソースコードのリポジトリが指定されている場合、DefectDojoはファイルパスをリンクとして表示し、ユーザーは脆弱性の場所に直接移動できます。 + +## エンゲージメントとテストでのリポジトリの設定 + +### エンゲージメント + +エンゲージメントの編集中に、ユーザーは特定のソースコード管理リポジトリのURLを設定できます。**（Pro UIでは、このフィールドは編集エンゲージメント > オプションフィールド > Repo で設定できます）**。 + +インタラクティブエンゲージメントの場合、ブランチを指定するURLである必要があります。 +- GitHubの場合 - https://github.com/DefectDojo/django-DefectDojo/tree/dev のような形式 +![エンゲージメントの編集（GitHub）](images/source-code-repositories_1.png) +- GitLabの場合 - https://gitlab.com/gitlab-org/gitlab/-/tree/master のような形式 +![エンゲージメントの編集（Gitlab）](images/source-code-repositories-gitlab_1.png) +- パブリックBitBucketの場合 - （git cloneのURLと同様） +![エンゲージメントの編集（Bitbucket public）](images/source-code-repositories-bitbucket_1.png) +- スタンドアロン/オンプレミスBitBucketの場合、パブリックなユーザーリポジトリでは https://bb.example.com/scm/some-project/some-repo.git または https://bb.example.com/scm/some-user-name/some-repo.git （git cloneのURLと同様） +![エンゲージメントの編集（Bitbucket standalone）](images/source-code-repositories-bitbucket-onpremise_1.png) + +CI/CDエンゲージメントの場合、コミットハッシュ、ブランチ/タグ、コード行が変わる可能性があるため、リポジトリのURLのみを含める必要があります。 +- GitHubの場合 - `https://github.com/DefectDojo/django-DefectDojo` のような形式 +- GitLabの場合 - `https://gitlab.com/gitlab-org/gitlab` のような形式 +- パブリックBitBucket、Gitea、Codebergの場合 - `https://bitbucket.org/some-user/some-project.git` のような形式（git cloneのURLと同様） +- スタンドアロン/オンプレミスBitBucketの場合、パブリックなユーザーリポジトリでは `https://bb.example.com/scm/some-project.git` または `https://bb.example.com/scm/some-user-name/some-repo.git` （git cloneのURLと同様） + +CI/CDエンゲージメントでは、**エンゲージメントの編集**フォームでコミットハッシュやブランチ/タグを指定でき、これはDefectDojoが表示するすべてのリンクに付加されます。これらが設定されていない場合、SCMのURLにはコードブランチを含む完全なリンクが含まれている必要があります。 + +SCMナビゲーションURLは、SCMタイプを使用してリポジトリURLから構成されます。特定のSCMタイプは、アセットのカスタムフィールド「scm-type」で設定できます。「scm-type」が設定されておらず、URLに「https://github.com」が含まれている場合は、「github」のSCMタイプが想定されます。 + +アセットのカスタムフィールド: + +![アセットのカスタムフィールド](images/asset-custom-fields_1.png) + +アセットのSCMタイプの追加: + +![アセットのSCMタイプ](images/asset-scm-type_1.png) + +利用可能なSCMタイプは、「github」、「gitlab」、「bitbucket」、「bitbucket-standalone」、「gitea」、「codeberg」、または未設定（デフォルトのgithub）です。 + + +## 検出事項内のソースコードリンク + +検出事項を表示する際、エンゲージメントでソースコードのリポジトリが設定されていれば、場所はリンクとして表示されます。 + +![場所へのリンク](images/source-code-repositories_2.png) + +このリンクをクリックすると、ブラウザで新しいタブが開き、対応する行番号の脆弱性のソースファイルが表示されます。 + +![リポジトリで表示](images/source-code-repositories_3.png) diff --git a/docs/content/asset_modelling/OS_hierarchy/_index.de.md b/docs/content/asset_modelling/OS_hierarchy/_index.de.md new file mode 100644 index 00000000000..121a5b02e96 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/_index.de.md @@ -0,0 +1,11 @@ +--- +title: Asset-Hierarchie +audience: opensource +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/OS_hierarchy/_index.es.md b/docs/content/asset_modelling/OS_hierarchy/_index.es.md new file mode 100644 index 00000000000..c7f5ae31d2c --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/_index.es.md @@ -0,0 +1,11 @@ +--- +title: Jerarquía de Activos +audience: opensource +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/OS_hierarchy/_index.fr.md b/docs/content/asset_modelling/OS_hierarchy/_index.fr.md new file mode 100644 index 00000000000..7059f34f835 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/_index.fr.md @@ -0,0 +1,11 @@ +--- +title: Hiérarchie des Actifs +audience: opensource +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/OS_hierarchy/_index.ja.md b/docs/content/asset_modelling/OS_hierarchy/_index.ja.md new file mode 100644 index 00000000000..d05f98df6bc --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/_index.ja.md @@ -0,0 +1,11 @@ +--- +title: アセット階層 +audience: opensource +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/OS_hierarchy/benchmarks.de.md b/docs/content/asset_modelling/OS_hierarchy/benchmarks.de.md new file mode 100644 index 00000000000..6daeeab2de2 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/benchmarks.de.md @@ -0,0 +1,39 @@ +--- +title: OWASP-ASVS-Benchmarks +description: Ein Produkt anhand des OWASP Application Security Verification Standard + benchmarken +weight: 6 +audience: opensource +--- + +DefectDojo unterstützt das Benchmarking von Produkten anhand des [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/), der eine Grundlage für die Prüfung technischer Sicherheitskontrollen von Webanwendungen bietet. + +Mit Benchmarks können Sie messen, wie gut ein Produkt die von Ihrer Organisation festgelegten Sicherheitsanforderungen erfüllt, und einen Score zur besseren Sichtbarkeit auf der Produktseite veröffentlichen. + +## Zugriff auf Benchmarks + +Benchmarks sind über die Seite **Product** verfügbar. Um die Benchmarks-Ansicht zu öffnen, wählen Sie das Dropdown-Menü oben rechts auf der Produktseite und wählen Sie unten im Menü **OWASP ASVS v.3.1** aus. + +## Benchmark-Stufen + +OWASP ASVS definiert drei Stufen der Verifizierungsabdeckung: + +- **Stufe 1** – Für jede Software. Deckt die kritischsten Sicherheitsanforderungen mit dem geringsten Prüfaufwand ab. Dies ist die Standardstufe in DefectDojo. +- **Stufe 2** – Für Anwendungen, die sensible Daten enthalten. Geeignet für die meisten Anwendungen. +- **Stufe 3** – Für die kritischsten Anwendungen, etwa solche, die hochwertige Transaktionen durchführen oder sensible medizinische, finanzielle oder sicherheitsrelevante Daten speichern. + +Sie können mithilfe des Dropdown-Menüs oben rechts in der Benchmarks-Ansicht zwischen den Stufen wechseln. + +## Benchmark-Score + +Auf der linken Seite der Benchmarks-Ansicht wird der aktuelle Score Ihres Produkts für die ausgewählte ASVS-Stufe angezeigt: + +- Der **gewünschte Score**, den Ihre Organisation als Ziel festgelegt hat +- Der **Prozentsatz der bestandenen Benchmarks** auf dem Weg zu diesem Score +- Die **Gesamtzahl der aktivierten Benchmarks** für die ausgewählte Stufe + +Wenn Sie das Kontrollkästchen **Publish** aktivieren, wird der ASVS-Score direkt auf der Produktseite angezeigt. + +## Verwalten von Benchmark-Einträgen + +Einzelne Benchmark-Einträge können als bestanden oder nicht bestanden markiert werden, während Ihr Team die ASVS-Kontrollen durchgeht. Zusätzliche Benchmark-Einträge über den Standard-ASVS-Satz hinaus können über die **Django-Admin-Site** hinzugefügt oder aktualisiert werden. diff --git a/docs/content/asset_modelling/OS_hierarchy/benchmarks.es.md b/docs/content/asset_modelling/OS_hierarchy/benchmarks.es.md new file mode 100644 index 00000000000..4fbe6f4c6ff --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/benchmarks.es.md @@ -0,0 +1,39 @@ +--- +title: Benchmarks de OWASP ASVS +description: Compare un Producto con el OWASP Application Security Verification Standard + (ASVS). +weight: 6 +audience: opensource +--- + +DefectDojo permite comparar Productos con el [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/), que proporciona una base para probar los controles técnicos de seguridad de las aplicaciones web. + +Los Benchmarks le permiten medir en qué medida un Producto cumple con los requisitos de seguridad definidos por su organización, y publicar una puntuación en la página del Producto para mayor visibilidad. + +## Acceder a los Benchmarks + +Los Benchmarks están disponibles desde la página del **Producto**. Para abrir la vista de Benchmarks, seleccione el menú desplegable en la parte superior derecha de la página del Producto y elija **OWASP ASVS v.3.1** cerca de la parte inferior del menú. + +## Niveles de Benchmark + +OWASP ASVS define tres niveles de cobertura de verificación: + +- **Nivel 1** – Para todo el software. Cubre los requisitos de seguridad más críticos con el menor costo de verificación. Este es el nivel predeterminado en DefectDojo. +- **Nivel 2** – Para aplicaciones que contienen datos sensibles. Adecuado para la mayoría de las aplicaciones. +- **Nivel 3** – Para las aplicaciones más críticas, como aquellas que realizan transacciones de alto valor o almacenan datos médicos, financieros o de seguridad sensibles. + +Puede alternar entre niveles utilizando el menú desplegable en la parte superior derecha de la vista de Benchmarks. + +## Puntuación del Benchmark + +El lado izquierdo de la vista de Benchmarks muestra la puntuación actual de su Producto en el nivel de ASVS seleccionado: + +- La **puntuación deseada** que su organización ha establecido como objetivo +- El **porcentaje de benchmarks aprobados** para alcanzar dicha puntuación +- El **número total de benchmarks habilitados** para el nivel seleccionado + +Al habilitar la casilla **Publicar**, la puntuación de ASVS se mostrará directamente en la página del Producto. + +## Gestionar entradas de Benchmark + +Las entradas individuales de benchmark pueden marcarse como aprobadas o no aprobadas a medida que su equipo avanza en los controles de ASVS. Se pueden añadir o actualizar entradas de benchmark adicionales, más allá del conjunto predeterminado de ASVS, a través del **sitio de administración de Django**. diff --git a/docs/content/asset_modelling/OS_hierarchy/benchmarks.fr.md b/docs/content/asset_modelling/OS_hierarchy/benchmarks.fr.md new file mode 100644 index 00000000000..0a7f0086954 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/benchmarks.fr.md @@ -0,0 +1,39 @@ +--- +title: Benchmarks OWASP ASVS +description: Comparer un Produit à la norme OWASP Application Security Verification + Standard (ASVS) +weight: 6 +audience: opensource +--- + +DefectDojo permet de comparer les Produits à la [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/), qui fournit une base pour tester les contrôles de sécurité technique des applications web. + +Les Benchmarks vous permettent de mesurer dans quelle mesure un Produit répond aux exigences de sécurité définies par votre organisation, et de publier un score sur la page du Produit pour plus de visibilité. + +## Accéder aux Benchmarks + +Les Benchmarks sont accessibles depuis la page **Produit**. Pour ouvrir la vue Benchmarks, sélectionnez le menu déroulant en haut à droite de la page Produit et choisissez **OWASP ASVS v.3.1** vers le bas du menu. + +## Niveaux de Benchmark + +OWASP ASVS définit trois niveaux de couverture de vérification : + +- **Niveau 1** – Pour tous les logiciels. Couvre les exigences de sécurité les plus critiques avec le coût de vérification le plus faible. Il s'agit du niveau par défaut dans DefectDojo. +- **Niveau 2** – Pour les applications contenant des données sensibles. Adapté à la plupart des applications. +- **Niveau 3** – Pour les applications les plus critiques, telles que celles effectuant des transactions à forte valeur ou stockant des données médicales, financières ou de sécurité sensibles. + +Vous pouvez basculer entre les niveaux à l'aide du menu déroulant en haut à droite de la vue Benchmarks. + +## Score de Benchmark + +Le côté gauche de la vue Benchmarks affiche le score actuel de votre Produit au niveau ASVS sélectionné : + +- Le **score souhaité** que votre organisation a défini comme objectif +- Le **pourcentage de benchmarks réussis** pour atteindre ce score +- Le **nombre total de benchmarks activés** pour le niveau sélectionné + +Activer la case à cocher **Publish** affichera le score ASVS directement sur la page du Produit. + +## Gestion des entrées de Benchmark + +Les entrées individuelles de benchmark peuvent être marquées comme réussies ou échouées au fur et à mesure que votre équipe traite les contrôles ASVS. Des entrées de benchmark supplémentaires, au-delà de l'ensemble ASVS par défaut, peuvent être ajoutées ou mises à jour via le **site d'administration Django**. diff --git a/docs/content/asset_modelling/OS_hierarchy/benchmarks.ja.md b/docs/content/asset_modelling/OS_hierarchy/benchmarks.ja.md new file mode 100644 index 00000000000..1dcc98a4760 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/benchmarks.ja.md @@ -0,0 +1,38 @@ +--- +title: OWASP ASVSベンチマーク +description: OWASPアプリケーションセキュリティ検証標準に対して製品をベンチマークする +weight: 6 +audience: opensource +--- + +DefectDojoは、Webアプリケーションの技術的なセキュリティ管理をテストするための基準を提供する[OWASPアプリケーションセキュリティ検証標準（ASVS）](https://owasp.org/www-project-application-security-verification-standard/)に対して、製品をベンチマークすることをサポートしています。 + +ベンチマークを使用すると、製品が組織の定めたセキュリティ要件をどの程度満たしているかを測定し、その可視性のためにスコアを製品ページに公開できます。 + +## ベンチマークへのアクセス + +ベンチマークは**製品**ページから利用できます。ベンチマークビューを開くには、製品ページの右上にあるドロップダウンメニューを選択し、メニューの下部にある**OWASP ASVS v.3.1**を選択します。 + +## ベンチマークレベル + +OWASP ASVSは、検証範囲の3つのレベルを定義しています。 + +- **レベル1** – すべてのソフトウェアが対象です。最も重大なセキュリティ要件を最も低いコストで検証します。これはDefectDojoのデフォルトレベルです。 +- **レベル2** – 機密データを含むアプリケーションが対象です。ほとんどのアプリケーションに適しています。 +- **レベル3** – 高額な取引を扱う、または機密性の高い医療・財務・安全データを保存するなど、最も重要なアプリケーションが対象です。 + +ベンチマークビューの右上にあるドロップダウンを使用して、レベルを切り替えることができます。 + +## ベンチマークスコア + +ベンチマークビューの左側には、選択したASVSレベルにおける製品の現在のスコアが表示されます。 + +- 組織が目標として設定した**希望スコア** +- そのスコアに対する**合格したベンチマークの割合** +- 選択したレベルの**有効なベンチマークの総数** + +**公開**チェックボックスを有効にすると、ASVSスコアが製品ページに直接表示されます。 + +## ベンチマークエントリの管理 + +チームがASVSコントロールに取り組む中で、個々のベンチマークエントリを合格または不合格としてマークできます。デフォルトのASVSセット以外の追加のベンチマークエントリは、**Django管理サイト**を通じて追加または更新できます。 diff --git a/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.de.md b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.de.md new file mode 100644 index 00000000000..a3258fa2b99 --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.de.md @@ -0,0 +1,274 @@ +--- +title: Fragebögen +description: Fragebögen in OS DefectDojo verstehen +audience: opensource +weight: 2 +--- + +In DefectDojo ist ein Fragebogen ein wiederverwendbarer Satz von Fragen, mit dem Informationen von Entwicklern, Teams sowie internen und externen Beteiligten erfasst werden. Damit lassen sich vor Beginn der Arbeit Informationen einholen, während der Arbeit die Abstimmung zwischen Personen und Teams sicherstellen und nach Abschluss der Arbeit rückblickende Analysen durchführen. + +## Fragebogenvorlagen + +Eine Fragebogenvorlage legt Struktur und Inhalt des Fragebogens fest, einschließlich Name, Beschreibung und zugehöriger Fragen. Das Erstellen einer Fragebogenvorlage macht sie nicht automatisch für Antworten verfügbar. Um Antworten zu erfassen, muss eine Fragebogenvorlage entweder als **allgemeiner Fragebogen** oder als **verknüpfter Fragebogen** bereitgestellt werden. + +### Allgemeine und verknüpfte Fragebögen + +Allgemeine und verknüpfte Fragebögen unterscheiden sich in mehreren Punkten, unter anderem darin, wie sie verteilt werden, wer antworten kann und wo die Antworten gespeichert werden. + +| Allgemeine Fragebögen | Verknüpfte Fragebögen | +|---|---| +| Müssen veröffentlicht werden | Müssen nicht veröffentlicht werden | +| Benötigen ein Ablaufdatum | Bleiben aktiv, solange das Engagement aktiv ist | +| Erlauben anonyme Antworten | Erlauben keine anonymen Antworten | +| Sind intern und extern teilbar | Sind nur intern teilbar | +| Erlauben kein Ändern von Antworten | Erlauben das Ändern von Antworten | +| Antworten sind erst nach Ablauf sichtbar | Antworten sind sofort sichtbar | +| Antworten sind unter „Alle Fragebögen“ sichtbar | Antworten sind im Engagement sichtbar | +| Können in ein Engagement umgewandelt werden | Sind bereits mit einem Engagement verknüpft | + +#### Lebenszyklus der Fragebogen-Bereitstellung + +Fragebogenvorlagen folgen je nach Art der Bereitstellung unterschiedlichen Lebenszyklen: + +**Allgemeine Fragebögen** +Vorlage → Veröffentlicht → Antworten annehmen → Ablauf → Optionale Umwandlung in ein Engagement + +**Verknüpfte Fragebögen** +Vorlage → Mit Engagement verknüpft → Antworten annehmen → Bleiben aktiv, solange das Engagement aktiv ist + +#### Trennung der Antworten + +Eine einzelne Fragebogenvorlage kann mehrfach gleichzeitig bereitgestellt werden, sowohl als allgemeiner als auch als verknüpfter Fragebogen. Jede Bereitstellung erzeugt einen eigenen, unabhängigen Satz von Antworten. + +Wenn dieselbe Fragebogenvorlage als allgemeiner Fragebogen bereitgestellt und zusätzlich mit einem Engagement verknüpft wird, werden die über die jeweilige Bereitstellung übermittelten Antworten unabhängig gespeichert und nicht zusammengeführt. So kann dieselbe Fragebogenvorlage in verschiedenen Kontexten wiederverwendet werden, während die Antwortsätze getrennt bleiben. + +## Zugriff auf Fragebögen und Fragen + +Fragebögen und Fragen erreichen Sie über die Seitenleiste, indem Sie auf **Fragebögen** klicken. Das Untermenü führt zu **Alle Fragebögen** und **Alle Fragen**. + +![image](images/q_ss1.png) + +Der Zugriff auf die Ansichten „Alle Fragebögen“ und „Alle Fragen“ ist ausschließlich Benutzern mit Superuser-Status vorbehalten. Nur Superuser können Fragebogenvorlagen und Fragen erstellen sowie Fragebögen bereitstellen. Benutzer ohne Superuser-Status können weiterhin allgemeine Fragebögen beantworten, die mit ihnen geteilt werden, und auch die verknüpften Fragebögen von Engagements beantworten, auf die sie Zugriff haben, sie können sie jedoch nicht erstellen oder verwalten. + +### Fragebögen + +Die Ansicht „Alle Fragebögen“ enthält zwei Tabellen: +- **Fragebögen** + - Dieser Bereich enthält alle vorhandenen Fragebogenvorlagen. +- **Allgemeine Fragebögen** + - Dieser Bereich enthält alle allgemeinen Fragebögen, die derzeit für Antworten offen sind. + +Beide Bereiche können nach Name, Beschreibung oder Aktivstatus gefiltert werden. + +### Fragen + +Die Ansicht „Alle Fragen“ enthält eine Tabelle mit Fragen, die derzeit einem Fragebogen hinzugefügt werden können. Sie lässt sich außerdem nach dem Optional-Status, dem Inhalt oder dem Fragetyp (z. B. Textfrage oder Auswahlfrage) filtern. + +## Fragebogenvorlagen verwalten + +### Fragebögen erstellen + +Neue Fragebögen können über die Schaltfläche „Fragebogen erstellen“ in der Ansicht „Alle Fragebögen“ angelegt werden. + +![image](images/q_ss2.png) + +Nach der Eingabe von Name und Beschreibung kann der Fragebogen entweder ohne Fragen erstellt werden (diese können später hinzugefügt werden) oder es können sofort Fragen hinzugefügt werden. + +#### Fragen sofort zu einem neuen Fragebogen hinzufügen + +Wenn Fragen sofort hinzugefügt werden, wählen Sie alle passenden Fragen im daraufhin angezeigten Dropdown-Menü aus. Über das Pluszeichen rechts neben dem Dropdown-Menü können Sie auch eine neue Frage erstellen und dem Fragebogen hinzufügen. + +![image](images/q_ss12.png) + +Sobald alle passenden Fragen ausgewählt sind, klicken Sie auf **Fragen des Fragebogens aktualisieren**, um alle ausgewählten Fragen dem Fragebogen hinzuzufügen. + +#### Fragen zu einem bestehenden Fragebogen hinzufügen + +Um Fragen zu einem bestehenden Fragebogen hinzuzufügen, klicken Sie in der Tabelle „Fragebögen“ auf den Namen des Fragebogens, klicken Sie auf **Fragen bearbeiten**, wählen Sie im Dropdown-Menü die neuen Fragen für den Fragebogen aus und klicken Sie dann auf **Fragen des Fragebogens aktualisieren**. + +### Fragen erstellen + +Neue Fragen können über die Schaltfläche **Frage erstellen** in der Ansicht „Alle Fragen“ angelegt werden. + +![image](images/q_ss3.png) + +Darüber hinaus können Fragen auch bei der Auswahl der Fragen für einen Fragebogen erstellt werden, indem Sie auf das Pluszeichen rechts neben dem Dropdown-Menü klicken. + +#### Fragetypen + +Beim Erstellen einer neuen Frage kann diese als Textfrage oder als Auswahlfrage angelegt werden, indem im Dropdown-Menü entweder **Text** oder **Choice** ausgewählt wird. + +#### Mehrfachantworten und optionale Antworten zulassen + +Die maximale Anzahl zulässiger Antworten in einer Auswahlfrage beträgt sechs. Über das Kontrollkästchen **Multichoice** können mehrere Antworten ausgewählt werden (nur bei Auswahlfragen verfügbar). Fragen können über das entsprechende Kontrollkästchen außerdem als **Optional** markiert werden. + +Wie Sie einer Auswahlfrage weitere Antworten hinzufügen, erfahren Sie im Abschnitt [Fragen bearbeiten](#editing-questions). + +#### Reihenfolge der Fragen + +Legen Sie die Reihenfolge einer Frage über eine Ordnungsnummer fest. Steht im Feld „Reihenfolge“ beispielsweise 1, erscheint diese Frage über einer Frage mit 2 im Feld „Reihenfolge“. + +![image](images/q_ss13.png) + +### Fragen bearbeiten + +Nachdem eine Frage erstellt wurde, kann sie über das Untermenü „Alle Fragen“ bearbeitet werden, indem Sie auf die zu ändernde Frage klicken. Fragen können nicht gelöscht werden. + +Vermeiden Sie es, Fragen zu bearbeiten, die Teil aktiver Fragebögen sind. Wird ein Teil einer Frage geändert (z. B. Reihenfolge, Optional-Status, Korrektur eines Tippfehlers, Hinzufügen einer möglichen Antwort usw.) und war diese Frage Teil eines aktiven Fragebogens, für den bereits Antworten übermittelt wurden, werden alle zuvor übermittelten Antworten ungültig und müssen erneut übermittelt werden. + +#### Textfragen bearbeiten + +Nach der Erstellung lassen sich bei Textfragen nur die Reihenfolge, der Optional-Status und die Formulierung der Frage ändern. + +#### Auswahlfragen bearbeiten + +Die Standardanzahl möglicher Antworten auf eine Auswahlfrage beträgt sechs, kann aber nach dem Erstellen des Fragebogens erhöht werden. Klicken Sie dazu in der Ansicht „Alle Fragen“ auf die Frage, klicken Sie auf das **+** rechts neben dem Dropdown-Menü „Auswahlmöglichkeiten“, fügen Sie die neue Antwort hinzu und klicken Sie auf **Absenden**. + +![image](images/q_ss16.png) + +![image](images/q_ss17.png) + +Die neu erstellte Option wird dem Fragebogen nicht automatisch hinzugefügt. Klicken Sie zum Hinzufügen auf das Dropdown-Menü **Auswahlmöglichkeiten** und wählen Sie die neu hinzugefügte Option aus. Daneben erscheint ein Häkchen, das anzeigt, dass sie nun als mögliche Antwort im Fragebogen enthalten ist. + +![image](images/q_ss18.png) + +## Fragebögen bereitstellen + +Sobald eine Fragebogenvorlage erfolgreich erstellt wurde, kann sie bereitgestellt werden, um Antworten anzunehmen. Der Bereitstellungsvorgang unterscheidet sich je nach Fragebogentyp leicht. + +### Bereitstellung eines allgemeinen Fragebogens + +So stellen Sie einen allgemeinen Fragebogen bereit: +1. Wechseln Sie zur Ansicht „Alle Fragebögen“. +2. Klicken Sie auf das **+** rechts in der Tabelle „Allgemeine Fragebögen“. +3. Wählen Sie den bereitzustellenden Fragebogen aus. +4. Legen Sie das Ablaufdatum fest. +5. Klicken Sie auf **Fragebogen hinzufügen**. + +#### Einen allgemeinen Fragebogen teilen + +Nach der Bereitstellung kann ein allgemeiner Fragebogen geteilt werden, indem Sie in der Spalte „Aktionen“ der Tabelle „Allgemeine Fragebögen“ auf **Fragebogen teilen** klicken. Dadurch wird ein Link erzeugt, den Sie an die vorgesehenen Empfänger weitergeben können; zuvor können Sie außerdem prüfen, ob der Fragebogen wie gewünscht aufgebaut ist. + +![image](images/q_ss14.png) + +Beachten Sie Folgendes: +- Antworten auf einen allgemeinen Fragebogen sind erst nach Ablauf des Fragebogens sichtbar. +- Nach der Veröffentlichung des Fragebogens kann das Ablaufdatum nicht mehr geändert werden. +- Standardmäßig läuft ein Fragebogen um Mitternacht ab (ein Fragebogen mit Ablaufdatum 31. Dezember 2026 ist beispielsweise nur bis 23:59:59 an diesem Tag verfügbar). +- Eine individuelle Ablaufzeit kann nicht festgelegt werden. + +Informationen dazu, wie Sie Antworten externer Benutzer zulassen, finden Sie unten unter [Anonyme Antworten aktivieren](#enabling-anonymous-responses). + +### Bereitstellung eines verknüpften Fragebogens + +So stellen Sie einen verknüpften Fragebogen bereit: +1. Wechseln Sie zu dem Engagement, das mit dem Fragebogen verknüpft werden soll. +2. Klicken Sie auf den Abwärtspfeil an der Tabelle **Zusätzliche Funktionen**. +3. Klicken Sie auf das **+** rechts in der Untertabelle „Fragebögen“. +4. Wählen Sie im Dropdown-Menü den zu verknüpfenden Fragebogen aus. +5. Klicken Sie auf **Fragebogen hinzufügen** oder **Fragebogen hinzufügen und beantworten**. + +Der verknüpfte Fragebogen ist nun für alle Benutzer aktiv, die Zugriff auf das Engagement haben. + +#### Einen verknüpften Fragebogen teilen + +Um den verknüpften Fragebogen direkt mit internen DefectDojo-Benutzern zu teilen, klicken Sie auf das Kebab-Menü ⋮ und wählen Sie im Dropdown **Fragebogen teilen**. Es erscheint ein Link, der kopiert und an den vorgesehenen Empfänger weitergeleitet werden kann. + +![image](images/q_ss10.png) + +Wie erwähnt können verknüpfte Fragebögen nur mit DefectDojo-Benutzern geteilt werden. + +## Fragebögen beantworten + +Der Ablauf beim Beantworten unterscheidet sich leicht, je nachdem, ob es sich um einen allgemeinen oder einen verknüpften Fragebogen handelt. + +### Einen allgemeinen Fragebogen beantworten + +Um einen allgemeinen Fragebogen zu beantworten, muss Benutzern ohne Superuser-Status der Link direkt von einem Superuser mitgeteilt werden, wie [hier](#sharing-a-general-questionnaire) beschrieben. + +#### Anonyme Antworten aktivieren + +Standardmäßig sind allgemeine Fragebögen nur für DefectDojo-Benutzer zugänglich. Damit externe Personen DefectDojo-Fragebögen beantworten können, muss die Option **Anonyme Umfrageantworten zulassen** in den Systemeinstellungen eingeschaltet sein; diese finden Sie im Bereich **Konfigurationen** der Seitenleiste. + +![image](images/q_ss4.png) + +![image](images/q_ss5.png) + +Externe Antworten erscheinen als anonym, da mit der Antwort keine DefectDojo-Benutzer-ID verknüpft ist. + +Wenn ein Fragebogen sowohl interne als auch externe Benutzer umfasst, erstellen Sie einen allgemeinen Fragebogen und geben Sie beim Erstellen den Namen des Engagements in der Beschreibung an, damit die Ergebnisse gefiltert werden können. + +![image](images/q_ss8.png) + +![image](images/q_ss9.png) + +### Verknüpfte Fragebögen beantworten + +So beantworten Sie einen verknüpften Fragebogen: +1. Wechseln Sie zur Engagement-Ansicht. +2. Klappen Sie die Tabelle „Zusätzliche Funktionen“ auf. +3. Klappen Sie die Untertabelle „Fragebögen“ auf. +4. Klicken Sie auf das Kebab-Menü ⋮ des verknüpften Fragebogens. +5. Klicken Sie auf **Fragebogen beantworten**. + +![image](images/q_ss15.png) + +Verknüpfte Fragebögen erlauben keine externen bzw. anonymen Antworten, da für den Zugriff auf das Engagement ein DefectDojo-Zugang erforderlich ist. + +## Antworten + +Wie erwähnt erzeugt jede Bereitstellung einer Fragebogenvorlage einen eigenen Antwortcontainer. Wird dieselbe Fragebogenvorlage mit mehreren Engagements verknüpft, entstehen getrennte Antwortsätze, und die Veröffentlichung eines allgemeinen Fragebogens wirkt sich nicht auf die Antwortsätze verknüpfter Fragebögen aus. + +### Antworten auf allgemeine Fragebögen + +Nach Ablauf eines allgemeinen Fragebogens gilt: +- Es können keine weiteren Antworten mehr übermittelt werden. +- Alle bisherigen Antworten werden gespeichert und sichtbar. +- Der Fragebogen wird auf dem DefectDojo-Dashboard als nicht zugewiesener, beantworteter Engagement-Fragebogen aufgeführt. + +Nach Schließen des Antwortzeitraums eines Fragebogens stehen drei Aktionen zur Verfügung: **Antworten anzeigen**, **Engagement erstellen** und **Benutzer zuweisen**. + +#### Antworten auf Fragebögen ansehen + +Mit **Antworten anzeigen** werden alle Antworten des Fragebogens dargestellt. + +#### Aus einem Fragebogen ein Engagement erstellen + +Nach Ablauf kann ein allgemeiner Fragebogen über ein Engagement mit einem Asset verbunden werden, indem Sie die Aktion **Engagement erstellen** wählen. Wählen Sie in der daraufhin angezeigten Dropdown-Liste ein Asset aus und klicken Sie auf **Engagement erstellen**. Anschließend kann ein neues Engagement erstellt und wie andere Engagements in DefectDojo mit Details wie Beschreibung, Version, Status, Tags usw. versehen werden. + +![image](images/q_ss6.png) + +![image](images/q_ss7.png) + +#### Benutzer zuweisen + +Bei der Aktion „Benutzer zuweisen“ wählen Sie im Dropdown der verfügbaren Benutzer einen Benutzer aus. Wählen Sie einen Benutzer aus dem Dropdown-Menü und klicken Sie auf **Fragebogen zuweisen**; dadurch wird dieser Benutzer zum Eigentümer des Fragebogens. + +### Antworten auf verknüpfte Fragebögen + +Verknüpfte Fragebögen bleiben verfügbar, solange das zugehörige Engagement aktiv ist. Die Antworten sind daher jederzeit einsehbar. + +Das Kebab-Menü ⋮ eines verknüpften Fragebogens enthält mehrere Funktionen zur Verwaltung des Fragebogens und der Antworten: +- **Fragebogen beantworten**: Diese Option erscheint, wenn ein Benutzer den verknüpften Fragebogen noch nicht beantwortet hat. Nach der Beantwortung erscheinen „Antworten anzeigen“ und „Antworten bearbeiten“. +- **Antworten anzeigen**: Ermöglicht Benutzern, alle bisherigen Antworten auf den Fragebogen zu sehen. +- **Antworten bearbeiten**: Ermöglicht einzelnen Benutzern, ihre früheren Antworten zu bearbeiten. +- **Benutzer zuweisen**: Weist den Fragebogen einem Benutzer zu. +- **Mit einem anderen Engagement verknüpfen**: Öffnet ein Dropdown-Menü mit anderen Engagements, denen der Fragebogen zugewiesen werden kann. +- **Fragebogen teilen**: Erzeugt einen Link, um den Fragebogen mit internen Benutzern zu teilen. +- **Fragebogen löschen**: Hebt die Verknüpfung des Fragebogens mit dem Engagement auf und löscht alle bisher erfassten Antworten. + +## Fragebögen löschen + +Das Löschen allgemeiner und verknüpfter Fragebögen hat je nach beabsichtigtem Ergebnis unterschiedliche Folgewirkungen. + +### Allgemeine Fragebögen löschen + +Wenn Sie einen allgemeinen Fragebogen aus der Tabelle „Allgemeine Fragebögen“ im Bereich „Alle Fragebögen“ löschen, werden alle Antworten gelöscht, die vor dem Löschen über diese Bereitstellung erfasst wurden. Verknüpfte Fragebögen, die dieselbe Fragebogenvorlage verwenden, werden nicht gelöscht. + +### Verknüpfte Fragebögen löschen + +Beim Löschen eines verknüpften Fragebogens wird die Verknüpfung des Fragebogens mit dem Engagement aufgehoben. Alle Antworten, die vor dem Löschen innerhalb des Engagements erfasst wurden, gehen verloren. Allgemeine Fragebögen, die zuvor mit derselben Fragebogenvorlage bereitgestellt wurden, sind nicht betroffen. + +### Fragebogenvorlagen löschen + +Um eine Fragebogenvorlage vollständig zu löschen, wählen Sie sie in der Tabelle „Fragebögen“ in der Ansicht „Alle Fragebögen“ aus und klicken Sie auf **Fragebogen löschen**. Dadurch werden die Fragebogenvorlage und alle zugehörigen Antworten aus allen Bereitstellungen dauerhaft gelöscht. Dieser Vorgang kann nicht rückgängig gemacht werden. diff --git a/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.es.md b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.es.md new file mode 100644 index 00000000000..2320574cd21 --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.es.md @@ -0,0 +1,274 @@ +--- +title: Cuestionarios +description: Comprender los Cuestionarios en DefectDojo OS +audience: opensource +weight: 2 +--- + +En DefectDojo, un Cuestionario es un conjunto reutilizable de preguntas que recopila información de desarrolladores, equipos y partes interesadas tanto internas como externas. Se pueden utilizar para recopilar información antes de que comience el trabajo, garantizar la alineación entre personas y equipos a medida que avanza el trabajo, y permitir un análisis retrospectivo una vez finalizado el trabajo. + +## Plantillas de Cuestionario + +Una plantilla de Cuestionario define la estructura y el contenido del Cuestionario, incluyendo su nombre, descripción y las Preguntas asociadas. Crear una plantilla de Cuestionario no la hace disponible automáticamente para recibir respuestas. Para recopilar respuestas, una plantilla de Cuestionario debe implementarse como un **Cuestionario General** o como un **Cuestionario Vinculado**. + +### Cuestionarios Generales y Vinculados + +Los Cuestionarios Generales y Vinculados difieren en varios aspectos, incluyendo cómo se distribuyen, quién puede responderlos y dónde se almacenan las respuestas. + +| Cuestionarios Generales | Cuestionarios Vinculados | +|---|---| +| Requieren publicación | No requieren publicación | +| Requieren una fecha de vencimiento | Permanecen activos si el Compromiso sigue activo | +| Permiten respuestas anónimas | No permiten respuestas anónimas | +| Se pueden compartir interna y externamente | Solo se pueden compartir internamente | +| No permiten cambiar las respuestas | Permiten cambiar las respuestas | +| Las respuestas solo son visibles al vencer | Las respuestas son visibles de inmediato | +| Las respuestas son visibles en "Todos los Cuestionarios" | Las respuestas son visibles dentro del Compromiso | +| Se pueden convertir en un Compromiso | Ya están vinculados a un Compromiso | + +#### Ciclo de vida de implementación del Cuestionario + +Las plantillas de Cuestionario siguen ciclos de vida diferentes según el tipo de implementación: + +**Cuestionarios Generales** +Plantilla → Publicado → Aceptar respuestas → Vencer → Conversión opcional a Compromiso + +**Cuestionarios Vinculados** +Plantilla → Vinculado a un Compromiso → Aceptar respuestas → Permanece activo mientras el Compromiso esté activo + +#### Separación de respuestas + +Una misma plantilla de Cuestionario se puede implementar varias veces simultáneamente, tanto como Cuestionario General como Cuestionario Vinculado. Cada implementación crea su propio conjunto independiente de respuestas. + +Si la misma plantilla de Cuestionario se implementa como Cuestionario General y también se vincula a un Compromiso, las respuestas enviadas a través de cada implementación se almacenan de forma independiente y no se combinan. Esto permite reutilizar la misma plantilla de Cuestionario en distintos contextos, manteniendo separados los conjuntos de respuestas. + +## Acceder a Cuestionarios y Preguntas + +Se puede acceder a los Cuestionarios y las Preguntas desde la barra lateral haciendo clic en la opción **Cuestionarios**. El submenú brinda acceso a **Todos los Cuestionarios** y **Todas las Preguntas**. + +![imagen](images/q_ss1.png) + +Cabe destacar que el acceso a las vistas Todos los Cuestionarios y Todas las Preguntas está restringido a Usuarios con estado de Superusuario. Solo los Superusuarios pueden crear plantillas de Cuestionario, crear Preguntas e implementar Cuestionarios. Los Usuarios sin estado de Superusuario aún pueden responder a los Cuestionarios Generales que se compartan con ellos, así como responder a los Cuestionarios Vinculados de los Compromisos a los que tengan acceso, pero no pueden crearlos ni gestionarlos. + +### Cuestionarios + +La vista de Todos los Cuestionarios incluye dos tablas: +- **Cuestionarios** + - Esta sección incluye todas las plantillas de Cuestionario existentes. +- **Cuestionarios Generales** + - Esta sección incluye todos los Cuestionarios Generales que actualmente están abiertos para recibir respuestas. + +Ambas secciones se pueden filtrar por nombre, descripción o estado activo. + +### Preguntas + +La vista de Todas las Preguntas incluye una tabla de Preguntas que actualmente se pueden agregar a un Cuestionario. También se puede filtrar por el estado opcional de cada Pregunta, su contenido o el tipo de pregunta (por ejemplo, pregunta de texto o pregunta de opción múltiple). + +## Gestionar Plantillas de Cuestionario + +### Crear Cuestionarios + +Se pueden crear nuevos Cuestionarios utilizando el botón Crear Cuestionario en la vista Todos los Cuestionarios. + +![imagen](images/q_ss2.png) + +Después de incluir un nombre y una descripción, el Cuestionario se puede crear sin Preguntas (que se pueden agregar más adelante) o se pueden agregar Preguntas de inmediato. + +#### Agregar Preguntas de inmediato a un nuevo Cuestionario + +Si se van a agregar Preguntas de inmediato, seleccione todas las Preguntas correspondientes en el menú desplegable que aparece. También puede crear una nueva Pregunta para agregarla al Cuestionario haciendo clic en el signo + a la derecha del menú desplegable. + +![imagen](images/q_ss12.png) + +Una vez seleccionadas todas las Preguntas correspondientes, haga clic en **Actualizar Preguntas del Cuestionario** para agregar todas las Preguntas seleccionadas al Cuestionario. + +#### Agregar Preguntas a un Cuestionario preexistente + +Para agregar Preguntas a un Cuestionario preexistente, haga clic en el nombre del Cuestionario en la tabla de Cuestionarios, haga clic en **Editar Preguntas**, seleccione las nuevas Preguntas que desee agregar al Cuestionario en el menú desplegable y, a continuación, haga clic en **Actualizar Preguntas del Cuestionario**. + +### Crear Preguntas + +Se pueden crear nuevas Preguntas utilizando el botón **Crear Pregunta** en la vista Todas las Preguntas. + +![imagen](images/q_ss3.png) + +Además, las Preguntas también se pueden crear al decidir qué Preguntas agregar a un Cuestionario, haciendo clic en el signo + a la derecha del menú desplegable. + +#### Tipos de Pregunta + +Al crear una nueva Pregunta, se puede dar formato como pregunta basada en texto o como pregunta de opción múltiple, seleccionando **Texto** o **Opción** en el menú desplegable. + +#### Permitir múltiples respuestas y respuestas opcionales + +El número máximo de respuestas permitidas en una pregunta de opción múltiple es seis. Al hacer clic en la casilla **Multichoice** se permite seleccionar varias respuestas (solo disponible para preguntas de opción múltiple). Las Preguntas también se pueden marcar como **Opcionales** haciendo clic en la casilla correspondiente. + +Consulte la sección [Editar Preguntas](#editing-questions) para saber cómo agregar respuestas adicionales a una pregunta de opción múltiple. + +#### Orden de las Preguntas + +Determine el orden de una Pregunta asignándole un número de orden. Por ejemplo, si una Pregunta tiene el valor 1 en el campo Orden, esa Pregunta aparecerá por encima de una Pregunta con el valor 2 en el campo Orden. + +![imagen](images/q_ss13.png) + +### Editar Preguntas + +Una vez creada una Pregunta, se puede editar accediendo al submenú Todas las Preguntas y haciendo clic en la Pregunta que se desea modificar. Las Preguntas no se pueden eliminar. + +Es importante evitar editar Preguntas que formen parte de Cuestionarios activos. Si se modifica cualquier parte de una Pregunta (por ejemplo, el orden, el estado opcional, la corrección de un error tipográfico, la adición de una posible respuesta, etc.) y esa Pregunta formaba parte de un Cuestionario activo que ya había recibido respuestas, todas las respuestas enviadas previamente quedarán invalidadas y deberán volver a enviarse. + +#### Editar Preguntas de texto + +Después de la creación, los únicos cambios que se pueden realizar en las Preguntas basadas en texto son el orden, el estado opcional y la redacción de la pregunta. + +#### Editar Preguntas de opción múltiple + +Si bien el número predeterminado de posibles respuestas para una pregunta de opción múltiple es seis, esto se puede aumentar después de haber creado el Cuestionario. Para hacerlo, haga clic en la Pregunta en la vista Todas las Preguntas, haga clic en el signo **+** a la derecha del menú desplegable de Opciones, agregue la nueva respuesta y haga clic en **Enviar**. + +![imagen](images/q_ss16.png) + +![imagen](images/q_ss17.png) + +La opción recién creada no se agregará automáticamente al Cuestionario. Para agregarla, haga clic en el menú desplegable **Opciones** y seleccione la opción recién agregada. Aparecerá una marca de verificación junto a ella indicando que ahora está incluida como una posible respuesta en el Cuestionario. + +![imagen](images/q_ss18.png) + +## Implementar Cuestionarios + +Una vez que se ha creado correctamente una plantilla de Cuestionario, se puede implementar para aceptar respuestas. El proceso de implementación varía ligeramente según el tipo de Cuestionario. + +### Implementación de un Cuestionario General + +Para implementar un Cuestionario General: +1. Vaya a la vista Todos los Cuestionarios. +2. Haga clic en el **+** en el lado derecho de la tabla de Cuestionarios Generales. +3. Seleccione el Cuestionario que desea implementar. +4. Establezca la fecha de vencimiento. +5. Haga clic en **Agregar Cuestionario**. + +#### Compartir un Cuestionario General + +Una vez implementado, un Cuestionario General se puede compartir haciendo clic en **Compartir Cuestionario** desde la columna Acciones de la tabla de Cuestionarios Generales. Esto generará un enlace que podrá compartir con los destinatarios deseados, además de permitirle confirmar que el Cuestionario tiene el formato previsto antes de hacerlo. + +![imagen](images/q_ss14.png) + +Tenga en cuenta lo siguiente: +- Las respuestas a un Cuestionario General no se podrán visualizar hasta que el Cuestionario haya vencido. +- No es posible cambiar la fecha de vencimiento una vez que el Cuestionario ha sido publicado. +- La hora predeterminada en que un Cuestionario vencerá es la medianoche (por ejemplo, un Cuestionario con vencimiento el 31 de diciembre de 2026 solo será visible hasta las 23:59:59 de esa fecha). +- No es posible establecer una hora de vencimiento personalizada. + +Consulte [Habilitar Respuestas Anónimas](#enabling-anonymous-responses) a continuación para permitir respuestas de Usuarios externos. + +### Implementación de un Cuestionario Vinculado + +Para implementar un Cuestionario Vinculado: +1. Vaya al Compromiso que se vinculará al Cuestionario. +2. Haga clic en la flecha hacia abajo de la tabla **Funciones Adicionales**. +3. Haga clic en el **+** en el lado derecho de la subtabla de Cuestionarios. +4. Seleccione el Cuestionario que se vinculará en el menú desplegable. +5. Haga clic en **Agregar Cuestionario** o **Agregar Cuestionario y Responder**. + +El Cuestionario Vinculado quedará ahora activo para todos los Usuarios con acceso al Compromiso. + +#### Compartir un Cuestionario Vinculado + +Para compartir el Cuestionario Vinculado directamente con Usuarios internos de DefectDojo, haga clic en el menú de tres puntos (⋮) y seleccione **Compartir Cuestionario** en el menú desplegable. Aparecerá un enlace que se puede copiar y reenviar al destinatario deseado. + +![imagen](images/q_ss10.png) + +Como se mencionó, los Cuestionarios Vinculados solo se pueden compartir con Usuarios de DefectDojo. + +## Responder Cuestionarios + +El flujo de respuesta difiere ligeramente según si el Cuestionario es General o Vinculado. + +### Responder a un Cuestionario General + +Para responder a un Cuestionario General, los usuarios que no sean Superusuarios deben recibir el enlace directamente de un Superusuario, como se describe [aquí](#sharing-a-general-questionnaire). + +#### Habilitar Respuestas Anónimas + +De forma predeterminada, los Cuestionarios Generales solo son accesibles para los Usuarios de DefectDojo. Para permitir que partes externas respondan a los Cuestionarios de DefectDojo, asegúrese de que la opción **Allow Anonymous Survey Responses** esté activada en la Configuración del Sistema, que se encuentra dentro de la sección **Configuraciones** de la barra lateral. + +![imagen](images/q_ss4.png) + +![imagen](images/q_ss5.png) + +Las respuestas externas aparecerán como anónimas porque no hay un ID de usuario de DefectDojo asociado a la respuesta. + +Si el alcance de un Cuestionario incluye tanto Usuarios internos como externos, cree un Cuestionario General y especifique el nombre del Compromiso en la descripción al momento de crearlo, lo que permitirá filtrar los resultados. + +![imagen](images/q_ss8.png) + +![imagen](images/q_ss9.png) + +### Responder a Cuestionarios Vinculados + +Para responder a un Cuestionario Vinculado: +1. Vaya a la vista del Compromiso. +2. Expanda la tabla Funciones Adicionales. +3. Expanda la subtabla de Cuestionarios. +4. Haga clic en el menú de tres puntos (⋮) del Cuestionario Vinculado. +5. Haga clic en **Responder Cuestionario**. + +![imagen](images/q_ss15.png) + +Los Cuestionarios Vinculados no permiten respuestas externas/anónimas, ya que se requiere acceso a DefectDojo para acceder al Compromiso. + +## Respuestas + +Como se mencionó, cada implementación de una plantilla de Cuestionario crea su propio contenedor de respuestas. Vincular la misma plantilla de Cuestionario a varios Compromisos genera conjuntos de respuestas independientes, y publicar un Cuestionario General no afecta los conjuntos de respuestas de los Cuestionarios Vinculados. + +### Respuestas de Cuestionario General + +Una vez que ha vencido un Cuestionario General: +- Ya no será posible enviar respuestas adicionales. +- Todas las respuestas previas se guardarán y se podrán visualizar. +- El Cuestionario aparecerá listado como un Cuestionario de Compromiso Respondido No Asignado en el panel de DefectDojo. + +Hay tres acciones que se pueden realizar cuando se ha cerrado la ventana de respuesta de un Cuestionario: **Ver Respuestas**, **Crear Compromiso** y **Asignar Usuario**. + +#### Ver Respuestas del Cuestionario + +Al seleccionar **Ver Respuestas** se mostrarán todas las respuestas del Cuestionario. + +#### Crear un Compromiso a partir de un Cuestionario + +Al vencer, un Cuestionario General se puede conectar a un Activo mediante un Compromiso seleccionando la acción **Crear Compromiso**. Seleccione un Activo en la lista desplegable que aparece y haga clic en **Crear Compromiso**. Luego se puede crear un nuevo Compromiso y asignarle detalles específicos similares a los de otros Compromisos en DefectDojo, como Descripción, Versión, Estado, Etiquetas, etc. + +![imagen](images/q_ss6.png) + +![imagen](images/q_ss7.png) + +#### Asignar Usuario + +La acción Asignar Usuario solicitará que se seleccione un Usuario del menú desplegable de Usuarios disponibles. Seleccione un Usuario del menú desplegable y haga clic en **Asignar Cuestionario**, lo que lo convertirá en el propietario de ese Cuestionario. + +### Respuestas de Cuestionario Vinculado + +Los Cuestionarios Vinculados permanecen disponibles mientras el Compromiso asociado esté activo. Por lo tanto, las respuestas se pueden visualizar en cualquier momento. + +El menú de tres puntos (⋮) de un Cuestionario Vinculado incluye varias funciones para gestionar el Cuestionario y sus respuestas: +- **Responder Cuestionario**: Esta opción aparecerá si un Usuario aún no ha respondido al Cuestionario Vinculado. Una vez respondido, aparecerán Ver Respuestas y Editar Respuestas. +- **Ver Respuestas**: Permite a los Usuarios ver todas las respuestas del Cuestionario hasta la fecha. +- **Editar Respuestas**: Permite a los Usuarios individuales editar sus respuestas previas. +- **Asignar Usuario**: Asigna el cuestionario a un Usuario. +- **Vincular a un Compromiso diferente**: Abre un menú desplegable de otros Compromisos a los que asignar el Cuestionario. +- **Compartir Cuestionario**: Genera un enlace para compartir el Cuestionario con Usuarios internos. +- **Eliminar Cuestionario**: Desvinculará el Cuestionario del Compromiso y eliminará cualquier respuesta recopilada previamente. + +## Eliminar Cuestionarios + +Eliminar Cuestionarios Generales y Vinculados tiene efectos posteriores distintos según el resultado deseado de la eliminación. + +### Eliminar Cuestionarios Generales + +Eliminar un Cuestionario General desde la tabla de Cuestionarios Generales en la sección Todos los Cuestionarios eliminará todas las respuestas que se hayan recopilado a partir de esa implementación antes de la eliminación. Los Cuestionarios Vinculados que hayan utilizado la misma plantilla de Cuestionario no se eliminarán. + +### Eliminar Cuestionarios Vinculados + +Eliminar un Cuestionario Vinculado desvinculará el Cuestionario del Compromiso. Se perderán todas las respuestas que se hayan recopilado dentro del Compromiso antes de la eliminación. Los Cuestionarios Generales que se hayan implementado previamente utilizando la misma plantilla de Cuestionario no se verán afectados. + +### Eliminar Plantillas de Cuestionario + +Para eliminar completamente una plantilla de Cuestionario, selecciónela en la tabla de Cuestionarios en la vista Todos los Cuestionarios y haga clic en **Eliminar Cuestionario**. Esto eliminará permanentemente la plantilla de Cuestionario y todas las respuestas asociadas de todas las implementaciones. Esta acción no se puede deshacer. diff --git a/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.fr.md b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.fr.md new file mode 100644 index 00000000000..942ed0d4bd8 --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.fr.md @@ -0,0 +1,274 @@ +--- +title: Questionnaires +description: Comprendre les Questionnaires dans OS DefectDojo +audience: opensource +weight: 2 +--- + +Dans DefectDojo, un Questionnaire est un ensemble réutilisable de questions qui permet de recueillir des informations auprès des développeurs, des équipes et des parties prenantes internes et externes. Il peut être utilisé pour recueillir des retours avant le début des travaux, assurer l'alignement entre les personnes et les équipes au fur et à mesure de l'avancement, et permettre une analyse rétrospective une fois le travail terminé. + +## Modèles de Questionnaire + +Un modèle de Questionnaire définit la structure et le contenu du Questionnaire, notamment son nom, sa description et les Questions associées. La création d'un modèle de Questionnaire ne le rend pas automatiquement disponible pour recueillir des réponses. Pour recueillir des réponses, un modèle de Questionnaire doit être déployé soit comme **Questionnaire général**, soit comme **Questionnaire lié**. + +### Questionnaires généraux et liés + +Les Questionnaires généraux et les Questionnaires liés diffèrent à plusieurs égards, notamment leur mode de diffusion, les personnes pouvant y répondre et l'emplacement de stockage des réponses. + +| Questionnaires généraux | Questionnaires liés | +|---|---| +| Nécessitent une publication | Ne nécessitent pas de publication | +| Nécessitent une date d'expiration | Restent actifs tant que l'Engagement est actif | +| Autorisent les réponses anonymes | N'autorisent pas les réponses anonymes | +| Peuvent être partagés en interne et en externe | Ne peuvent être partagés qu'en interne | +| Ne permettent pas de modifier les réponses | Permettent de modifier les réponses | +| Les réponses ne sont visibles qu'à l'expiration | Les réponses sont visibles immédiatement | +| Les réponses sont visibles dans « Tous les Questionnaires » | Les réponses sont visibles au sein de l'Engagement | +| Peuvent être convertis en Engagement | Sont déjà liés à un Engagement | + +#### Cycle de vie du déploiement des Questionnaires + +Les modèles de Questionnaire suivent des cycles de vie différents selon le type de déploiement : + +**Questionnaires généraux** +Modèle → Publié → Réception des réponses → Expiration → Conversion facultative en Engagement + +**Questionnaires liés** +Modèle → Lié à un Engagement → Réception des réponses → Reste actif tant que l'Engagement est actif + +#### Séparation des réponses + +Un même modèle de Questionnaire peut être déployé plusieurs fois simultanément, à la fois comme Questionnaire général et comme Questionnaire lié. Chaque déploiement crée son propre ensemble de réponses, indépendant des autres. + +Si le même modèle de Questionnaire est déployé comme Questionnaire général et également lié à un Engagement, les réponses soumises via chaque déploiement sont stockées indépendamment et ne sont pas combinées. Cela permet de réutiliser le même modèle de Questionnaire dans différents contextes tout en séparant les ensembles de réponses. + +## Accéder aux Questionnaires et aux Questions + +Les Questionnaires et les Questions sont accessibles depuis la barre latérale en cliquant sur l'option **Questionnaires**. Le sous-menu donne accès à **All Questionnaires** et **All Questions**. + +![image](images/q_ss1.png) + +À noter que l'accès aux vues All Questionnaires et All Questions est réservé aux Utilisateurs ayant le statut de Superutilisateur. Seuls les Superutilisateurs peuvent créer des modèles de Questionnaire, créer des Questions et déployer des Questionnaires. Les Utilisateurs sans statut de Superutilisateur peuvent néanmoins répondre aux Questionnaires généraux qui leur sont partagés, ainsi qu'aux Questionnaires liés des Engagements auxquels ils ont accès, mais ils ne peuvent ni les créer ni les gérer. + +### Questionnaires + +La vue All Questionnaires comprend deux tableaux : +- **Questionnaires** + - Cette section regroupe tous les modèles de Questionnaire existants. +- **General Questionnaires** + - Cette section regroupe tous les Questionnaires généraux actuellement ouverts aux réponses. + +Les deux sections peuvent être filtrées par nom, description ou statut actif. + +### Questions + +La vue All Questions comprend un tableau des Questions pouvant actuellement être ajoutées à un Questionnaire. Elle peut également être filtrée par le statut facultatif de chaque Question, son contenu ou son type (par exemple, question texte ou question à choix multiples). + +## Gestion des modèles de Questionnaire + +### Créer des Questionnaires + +De nouveaux Questionnaires peuvent être créés à l'aide du bouton Create Questionnaire dans la vue All Questionnaires. + +![image](images/q_ss2.png) + +Après avoir renseigné un nom et une description, le Questionnaire peut être créé sans Questions (qui pourront être ajoutées ultérieurement) ou avec des Questions ajoutées immédiatement. + +#### Ajouter immédiatement des Questions à un nouveau Questionnaire + +Si des Questions sont ajoutées immédiatement, sélectionnez toutes les Questions concernées dans le menu déroulant qui apparaît. Vous pouvez également créer une nouvelle Question à ajouter au Questionnaire en cliquant sur le signe + à droite du menu déroulant. + +![image](images/q_ss12.png) + +Une fois toutes les Questions concernées sélectionnées, cliquez sur **Update Questionnaire Questions** pour les ajouter au Questionnaire. + +#### Ajouter des Questions à un Questionnaire existant + +Pour ajouter des Questions à un Questionnaire existant, cliquez sur le nom du Questionnaire dans le tableau Questionnaires, cliquez sur **Edit Questions**, sélectionnez les nouvelles Questions à ajouter au Questionnaire dans le menu déroulant, puis cliquez sur **Update Questionnaire Questions**. + +### Créer des Questions + +De nouvelles Questions peuvent être créées à l'aide du bouton **Create Question** dans la vue All Questions. + +![image](images/q_ss3.png) + +Il est également possible de créer des Questions au moment de choisir celles à ajouter à un Questionnaire, en cliquant sur le signe + à droite du menu déroulant. + +#### Types de Question + +Lors de la création d'une nouvelle Question, elle peut être formatée soit comme une question de type texte, soit comme une question à choix multiples, en sélectionnant **Text** ou **Choice** dans le menu déroulant. + +#### Autoriser les réponses multiples et les réponses facultatives + +Le nombre maximal de réponses autorisées dans une question à choix multiples est de six. Cocher la case **Multichoice** permet de sélectionner plusieurs réponses (disponible uniquement pour les questions à choix multiples). Les Questions peuvent également être marquées comme **Optional** en cochant la case correspondante. + +Consultez la section [Modification des Questions](#editing-questions) pour savoir comment ajouter des réponses supplémentaires à une question à choix multiples. + +#### Ordre des Questions + +Déterminez l'ordre d'une Question en lui attribuant un numéro d'ordre. Par exemple, si une Question a la valeur 1 dans le champ Order, elle apparaîtra au-dessus d'une Question ayant la valeur 2 dans ce même champ. + +![image](images/q_ss13.png) + +### Modification des Questions + +Une fois qu'une Question a été créée, elle peut être modifiée en accédant au sous-menu All Questions et en cliquant sur la Question à modifier. Les Questions ne peuvent pas être supprimées. + +Il est important d'éviter de modifier des Questions faisant partie de Questionnaires actifs. Si un élément d'une Question est modifié (par exemple, l'ordre, le statut facultatif, la correction d'une faute de frappe, l'ajout d'une réponse possible, etc.) et que cette Question faisait partie d'un Questionnaire actif ayant déjà reçu des réponses, toutes les réponses précédemment soumises seront invalidées et devront être soumises à nouveau. + +#### Modifier les Questions de type texte + +Une fois créées, les seules modifications possibles pour les Questions de type texte concernent l'ordre, le statut facultatif et le libellé de la question. + +#### Modifier les Questions à choix multiples + +Bien que le nombre par défaut de réponses possibles pour une question à choix multiples soit de six, il peut être augmenté après la création du Questionnaire. Pour cela, cliquez sur la Question dans la vue All Questions, cliquez sur le signe **+** à droite du menu déroulant Choices, ajoutez la nouvelle réponse, puis cliquez sur **Submit**. + +![image](images/q_ss16.png) + +![image](images/q_ss17.png) + +La nouvelle option créée ne sera pas automatiquement ajoutée au Questionnaire. Pour l'ajouter, cliquez sur le menu déroulant **Choices** et sélectionnez l'option nouvellement créée. Une coche apparaîtra à côté d'elle, indiquant qu'elle est désormais incluse comme réponse possible dans le Questionnaire. + +![image](images/q_ss18.png) + +## Déployer des Questionnaires + +Une fois qu'un modèle de Questionnaire a été créé avec succès, il peut être déployé pour recevoir des réponses. Le processus de déploiement varie légèrement selon le type de Questionnaire. + +### Déploiement d'un Questionnaire général + +Pour déployer un Questionnaire général : +1. Accédez à la vue All Questionnaires. +2. Cliquez sur **+** à droite du tableau General Questionnaires. +3. Sélectionnez le Questionnaire à déployer. +4. Définissez la date d'expiration. +5. Cliquez sur **Add Questionnaire**. + +#### Partager un Questionnaire général + +Une fois déployé, un Questionnaire général peut être partagé en cliquant sur **Share Questionnaire** dans la colonne Actions du tableau General Questionnaires. Cela génère un lien que vous pouvez partager avec les destinataires prévus, tout en vous permettant de vérifier au préalable que le Questionnaire est formaté comme prévu. + +![image](images/q_ss14.png) + +Remarques : +- Les réponses à un Questionnaire général ne sont pas visibles tant que le Questionnaire n'a pas expiré. +- Il n'est pas possible de modifier la date d'expiration une fois le Questionnaire publié. +- L'heure par défaut à laquelle un Questionnaire expire est minuit (par exemple, un Questionnaire dont l'expiration est fixée au 31 décembre 2026 ne sera visible que jusqu'à 23h59:59 ce jour-là). +- Il n'est pas possible de définir une heure d'expiration personnalisée. + +Consultez la section [Activer les réponses anonymes](#enabling-anonymous-responses) ci-dessous pour savoir comment autoriser les réponses d'Utilisateurs externes. + +### Déploiement d'un Questionnaire lié + +Pour déployer un Questionnaire lié : +1. Accédez à l'Engagement auquel le Questionnaire doit être lié. +2. Cliquez sur la flèche vers le bas du tableau **Additional Features**. +3. Cliquez sur **+** à droite du sous-tableau Questionnaires. +4. Sélectionnez le Questionnaire à lier dans le menu déroulant. +5. Cliquez sur **Add Questionnaire** ou **Add Questionnaire and Respond**. + +Le Questionnaire lié sera alors actif pour tous les Utilisateurs ayant accès à l'Engagement. + +#### Partager un Questionnaire lié + +Pour partager directement le Questionnaire lié avec des Utilisateurs internes de DefectDojo, cliquez sur le menu kebab ⋮ et sélectionnez **Share Questionnaire** dans le menu déroulant. Un lien apparaît, qui peut être copié et transmis au destinataire prévu. + +![image](images/q_ss10.png) + +Comme indiqué précédemment, les Questionnaires liés ne peuvent être partagés qu'avec des Utilisateurs de DefectDojo. + +## Répondre aux Questionnaires + +Le processus de réponse varie légèrement selon que le Questionnaire est un Questionnaire général ou un Questionnaire lié. + +### Répondre à un Questionnaire général + +Pour répondre à un Questionnaire général, les Utilisateurs qui ne sont pas Superutilisateurs doivent recevoir le lien directement d'un Superutilisateur, comme décrit [ici](#sharing-a-general-questionnaire). + +#### Activer les réponses anonymes + +Par défaut, les Questionnaires généraux ne sont accessibles qu'aux Utilisateurs de DefectDojo. Pour permettre à des tiers externes de répondre aux Questionnaires DefectDojo, assurez-vous que l'option **Allow Anonymous Survey Responses** est activée dans les System Settings, accessibles dans la section **Configurations** de la barre latérale. + +![image](images/q_ss4.png) + +![image](images/q_ss5.png) + +Les réponses externes apparaissent comme anonymes, car aucun identifiant d'utilisateur DefectDojo n'est associé à la réponse. + +Si le périmètre d'un Questionnaire inclut à la fois des Utilisateurs internes et externes, créez un Questionnaire général et indiquez le nom de l'Engagement dans la description lors de la création, ce qui permettra de filtrer les résultats. + +![image](images/q_ss8.png) + +![image](images/q_ss9.png) + +### Répondre aux Questionnaires liés + +Pour répondre à un Questionnaire lié : +1. Accédez à la vue Engagement. +2. Développez le tableau Additional Features. +3. Développez le sous-tableau Questionnaires. +4. Cliquez sur le menu kebab ⋮ du Questionnaire lié. +5. Cliquez sur **Answer Questionnaire**. + +![image](images/q_ss15.png) + +Les Questionnaires liés n'autorisent pas les réponses externes/anonymes, car l'accès à DefectDojo est requis pour accéder à l'Engagement. + +## Réponses + +Comme indiqué précédemment, chaque déploiement d'un modèle de Questionnaire crée son propre conteneur de réponses. Lier le même modèle de Questionnaire à plusieurs Engagements produit des ensembles de réponses distincts, et la publication d'un Questionnaire général n'affecte pas les ensembles de réponses des Questionnaires liés. + +### Réponses aux Questionnaires généraux + +Une fois la date d'expiration d'un Questionnaire général dépassée : +- Il ne sera plus possible de soumettre de nouvelles réponses. +- Toutes les réponses précédentes seront enregistrées et deviendront consultables. +- Le Questionnaire apparaîtra comme un Unassigned Answered Engagement Questionnaire sur le tableau de bord DefectDojo. + +Trois actions sont possibles une fois la fenêtre de réponse d'un Questionnaire fermée : **View Responses**, **Create Engagement** et **Assign User**. + +#### Consulter les réponses au Questionnaire + +Sélectionner **View Responses** affiche toutes les réponses du Questionnaire. + +#### Créer un Engagement à partir d'un Questionnaire + +Après expiration, un Questionnaire général peut être associé à un Actif via un Engagement en sélectionnant l'action **Create Engagement**. Sélectionnez un Actif dans le menu déroulant qui apparaît, puis cliquez sur **Create Engagement**. Un nouvel Engagement peut alors être créé et renseigné avec des détails spécifiques, comme pour tout autre Engagement dans DefectDojo, tels que Description, Version, Status, Tags, etc. + +![image](images/q_ss6.png) + +![image](images/q_ss7.png) + +#### Assign User + +L'action Assign User invite à sélectionner un Utilisateur dans le menu déroulant des Utilisateurs disponibles. Sélectionnez un Utilisateur dans le menu déroulant et cliquez sur **Assign Questionnaire**, ce qui en fera le propriétaire de ce Questionnaire. + +### Réponses aux Questionnaires liés + +Les Questionnaires liés restent disponibles tant que l'Engagement associé est actif. Les réponses sont donc consultables à tout moment. + +Le menu kebab ⋮ d'un Questionnaire lié propose plusieurs fonctions pour gérer le Questionnaire et ses réponses : +- **Answer Questionnaire** : cette option apparaît si un Utilisateur n'a pas encore répondu au Questionnaire lié. Une fois la réponse soumise, View Responses et Edit Responses apparaissent. +- **View responses** : permet aux Utilisateurs de consulter toutes les réponses reçues à ce jour pour le Questionnaire. +- **Edit Responses** : permet à chaque Utilisateur de modifier ses réponses précédentes. +- **Assign User** : attribue le questionnaire à un Utilisateur. +- **Link to a Different Engagement** : ouvre un menu déroulant listant d'autres Engagements auxquels associer le Questionnaire. +- **Share Questionnaire** : génère un lien pour partager le Questionnaire avec des Utilisateurs internes. +- **Delete Questionnaire** : dissocie le Questionnaire de l'Engagement et supprime toutes les réponses précédemment recueillies. + +## Supprimer des Questionnaires + +La suppression des Questionnaires généraux et liés a des effets différents en aval, selon le résultat visé par la suppression. + +### Supprimer des Questionnaires généraux + +Supprimer un Questionnaire général depuis le tableau General Questionnaires dans la section All Questionnaires supprime toutes les réponses collectées lors de ce déploiement avant la suppression. Les Questionnaires liés utilisant le même modèle de Questionnaire ne seront pas supprimés. + +### Supprimer des Questionnaires liés + +Supprimer un Questionnaire lié dissocie le Questionnaire de l'Engagement. Toutes les réponses collectées au sein de l'Engagement avant la suppression seront perdues. Les Questionnaires généraux déployés précédemment à partir du même modèle de Questionnaire ne seront pas affectés. + +### Supprimer des modèles de Questionnaire + +Pour supprimer complètement un modèle de Questionnaire, sélectionnez-le dans le tableau Questionnaires de la vue All Questionnaires, puis cliquez sur **Delete Questionnaire**. Cette action supprime définitivement le modèle de Questionnaire ainsi que toutes les réponses associées à tous ses déploiements. Cette action est irréversible. diff --git a/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.ja.md b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.ja.md new file mode 100644 index 00000000000..a1fc14e0c9c --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.ja.md @@ -0,0 +1,274 @@ +--- +title: アンケート +description: OS DefectDojoにおけるアンケートの理解 +audience: opensource +weight: 2 +--- + +DefectDojoにおいて、アンケートとは、開発者、チーム、社内外のステークホルダーから情報を収集するための再利用可能な質問セットです。作業開始前の意見収集、作業の進行に伴う個人やチーム間の連携の確保、作業完了後の振り返り分析を可能にするために使用できます。 + +## アンケートテンプレート + +アンケートテンプレートは、名前、説明、関連する質問など、アンケートの構造と内容を定義します。アンケートテンプレートを作成しただけでは、自動的に回答を受け付けられるようにはなりません。回答を収集するには、アンケートテンプレートを**一般アンケート**または**リンク済みアンケート**のいずれかとしてデプロイする必要があります。 + +### 一般アンケートとリンク済みアンケート + +一般アンケートとリンク済みアンケートは、配布方法、回答できるユーザー、回答の保存場所など、いくつかの点で異なります。 + +| General Questionnaires | Linked Questionnaires | +|---|---| +| 公開が必要 | 公開は不要 | +| 有効期限の設定が必要 | エンゲージメントがアクティブである限り有効 | +| 匿名回答を許可 | 匿名回答は不可 | +| 社内外で共有可能 | 社内のみ共有可能 | +| 回答の変更は不可 | 回答の変更が可能 | +| 回答は期限切れ後にのみ表示される | 回答は即座に表示される | +| 回答は「すべてのアンケート」に表示される | 回答はエンゲージメント内に表示される | +| エンゲージメントへの変換が可能 | すでにエンゲージメントにリンク済み | + +#### アンケートのデプロイライフサイクル + +アンケートテンプレートは、デプロイの種類によって異なるライフサイクルをたどります。 + +**一般アンケート** +テンプレート → 公開 → 回答受付 → 期限切れ → エンゲージメントへの変換（任意） + +**リンク済みアンケート** +テンプレート → エンゲージメントにリンク → 回答受付 → エンゲージメントがアクティブな間は有効なまま + +#### 回答の分離 + +1つのアンケートテンプレートは、一般アンケートとリンク済みアンケートの両方として、同時に複数回デプロイできます。デプロイごとに、それぞれ独立した回答セットが作成されます。 + +同じアンケートテンプレートが一般アンケートとしてデプロイされ、同時にエンゲージメントにもリンクされている場合、それぞれのデプロイを通じて送信された回答は独立して保存され、結合されることはありません。これにより、同じアンケートテンプレートを異なる文脈で再利用しながら、回答セットを分離しておくことができます。 + +## アンケートと質問へのアクセス + +アンケートと質問には、サイドバーの**アンケート**オプションをクリックしてアクセスできます。サブメニューから**すべてのアンケート**と**すべての質問**にアクセスできます。 + +![image](images/q_ss1.png) + +なお、すべてのアンケートおよびすべての質問のビューへのアクセスは、スーパーユーザー権限を持つユーザーに限定されています。アンケートテンプレートの作成、質問の作成、アンケートのデプロイができるのはスーパーユーザーのみです。スーパーユーザー権限を持たないユーザーも、共有された一般アンケートに回答したり、アクセス権を持つエンゲージメントのリンク済みアンケートに回答したりすることはできますが、それらを作成または管理することはできません。 + +### アンケート + +すべてのアンケートのビューには、2つのテーブルが含まれます。 +- **アンケート** + - このセクションには、既存のすべてのアンケートテンプレートが含まれます。 +- **一般アンケート** + - このセクションには、現在回答を受け付けている一般アンケートがすべて含まれます。 + +どちらのセクションも、名前、説明、またはアクティブ状態でフィルタリングできます。 + +### 質問 + +すべての質問のビューには、現在アンケートに追加できる質問のテーブルが含まれます。各質問の任意ステータス、内容、または質問タイプ（例：テキスト質問や複数選択質問）でフィルタリングすることもできます。 + +## アンケートテンプレートの管理 + +### アンケートの作成 + +新しいアンケートは、すべてのアンケートビューの「アンケートの作成」ボタンを使用して作成できます。 + +![image](images/q_ss2.png) + +名前と説明を入力した後、質問を含めずにアンケートを作成する（後から追加可能）か、すぐに質問を追加することができます。 + +#### 新しいアンケートに質問をすぐに追加する + +質問をすぐに追加する場合は、続いて表示されるドロップダウンメニューから該当するすべての質問を選択します。ドロップダウンメニューの右側にある+記号をクリックすることで、アンケートに追加する新しい質問を作成することもできます。 + +![image](images/q_ss12.png) + +該当するすべての質問を選択したら、**アンケートの質問を更新**をクリックして、選択したすべての質問をアンケートに追加します。 + +#### 既存のアンケートに質問を追加する + +既存のアンケートに質問を追加するには、アンケートテーブルでアンケート名をクリックし、**質問の編集**をクリックして、ドロップダウンメニューからアンケートに追加する新しい質問を選択し、**アンケートの質問を更新**をクリックします。 + +### 質問の作成 + +新しい質問は、すべての質問ビューの**質問の作成**ボタンを使用して作成できます。 + +![image](images/q_ss3.png) + +さらに、アンケートに追加する質問を決める際に、ドロップダウンメニューの右側にある+記号をクリックすることでも質問を作成できます。 + +#### 質問タイプ + +新しい質問を作成する際、ドロップダウンメニューから**テキスト**または**選択肢**のいずれかを選ぶことで、テキスト形式の質問または複数選択形式の質問として設定できます。 + +#### 複数回答と任意回答の許可 + +複数選択の質問で許可される回答の最大数は6つです。**複数選択**チェックボックスをクリックすると、複数の回答を選択できるようになります（複数選択の質問でのみ利用可能）。対応するチェックボックスをクリックすることで、質問を**任意**としてマークすることもできます。 + +複数選択の質問に回答を追加する方法については、[質問の編集](#editing-questions)セクションを参照してください。 + +#### 質問の順序 + +質問には順序番号を付けることで、その順序を決定します。例えば、ある質問の順序フィールドが1で、別の質問が2の場合、順序フィールドが1の質問が2の質問より上に表示されます。 + +![image](images/q_ss13.png) + +### 質問の編集 + +質問が作成されると、すべての質問サブメニューにアクセスし、変更したい質問をクリックすることで編集できます。質問を削除することはできません。 + +アクティブなアンケートの一部となっている質問を編集することは避けるべきです。質問の一部（順序、任意ステータス、誤字の修正、選択肢の追加など）が変更され、その質問がすでに回答が提出されているアクティブなアンケートの一部だった場合、これまでに提出されたすべての回答は無効になり、回答を再提出する必要があります。 + +#### テキスト質問の編集 + +作成後、テキスト形式の質問に対して行える変更は、順序、任意ステータス、質問文の表現のみです。 + +#### 複数選択質問の編集 + +複数選択質問のデフォルトの回答数は6つですが、アンケート作成後にこれを増やすことができます。そのためには、すべての質問ビューで質問をクリックし、選択肢ドロップダウンメニューの右側にある**+**記号をクリックして、新しい回答を追加し、**送信**をクリックします。 + +![image](images/q_ss16.png) + +![image](images/q_ss17.png) + +新しく作成された選択肢は、自動的にはアンケートに追加されません。追加するには、**選択肢**ドロップダウンメニューをクリックし、新しく追加された選択肢を選択します。その隣にチェックマークが表示され、アンケートの回答候補として含まれたことを示します。 + +![image](images/q_ss18.png) + +## アンケートのデプロイ + +アンケートテンプレートの作成が完了すると、回答を受け付けるためにデプロイできます。デプロイのプロセスは、アンケートの種類によって多少異なります。 + +### 一般アンケートのデプロイ + +一般アンケートをデプロイするには、 +1. すべてのアンケートビューに移動します。 +2. 一般アンケートテーブルの右側にある**+**をクリックします。 +3. デプロイする対象のアンケートを選択します。 +4. 有効期限を設定します。 +5. **アンケートの追加**をクリックします。 + +#### 一般アンケートの共有 + +デプロイ後、一般アンケートテーブルのアクション列にある**アンケートの共有**をクリックすることで、一般アンケートを共有できます。これにより、意図した受信者と共有できるリンクが生成されるとともに、共有前にアンケートが意図したとおりの形式になっていることを確認できます。 + +![image](images/q_ss14.png) + +以下の点に注意してください。 +- 一般アンケートへの回答は、アンケートの期限が切れるまで閲覧できません。 +- アンケートが公開された後は、有効期限を変更することはできません。 +- アンケートのデフォルトの期限切れ時刻は真夜中です（例：有効期限が2026年12月31日のアンケートは、その日の11:59:59まで閲覧可能です）。 +- カスタムの期限切れ時刻を設定することはできません。 + +外部ユーザーからの回答を許可する方法については、下記の[匿名回答の有効化](#enabling-anonymous-responses)を参照してください。 + +### リンク済みアンケートのデプロイ + +リンク済みアンケートをデプロイするには、 +1. アンケートをリンクするエンゲージメントに移動します。 +2. **追加機能**テーブルの下矢印をクリックします。 +3. アンケートサブテーブルの右側にある**+**をクリックします。 +4. ドロップダウンメニューからリンクするアンケートを選択します。 +5. **アンケートの追加**または**アンケートの追加と回答**をクリックします。 + +これで、リンク済みアンケートはエンゲージメントにアクセス権を持つすべてのユーザーに対してアクティブになります。 + +#### リンク済みアンケートの共有 + +リンク済みアンケートを社内のDefectDojoユーザーと直接共有するには、⋮ケバブメニューをクリックし、ドロップダウンから**アンケートの共有**を選択します。コピーして意図した受信者に転送できるリンクが表示されます。 + +![image](images/q_ss10.png) + +前述のとおり、リンク済みアンケートはDefectDojoユーザーとのみ共有できます。 + +## アンケートへの回答 + +回答のワークフローは、アンケートが一般アンケートかリンク済みアンケートかによって多少異なります。 + +### 一般アンケートへの回答 + +一般アンケートに回答するには、スーパーユーザー以外のユーザーは、[こちら](#sharing-a-general-questionnaire)で説明されているように、スーパーユーザーから直接リンクを共有してもらう必要があります。 + +#### 匿名回答の有効化 + +デフォルトでは、一般アンケートはDefectDojoユーザーのみがアクセスできます。外部の関係者がDefectDojoのアンケートに回答できるようにするには、サイドバーの**設定**セクションにあるシステム設定で、**匿名アンケート回答を許可**オプションが有効になっていることを確認してください。 + +![image](images/q_ss4.png) + +![image](images/q_ss5.png) + +外部からの回答には関連付けられたDefectDojoユーザーIDが存在しないため、匿名として表示されます。 + +アンケートの対象範囲に社内・社外の両方のユーザーが含まれる場合は、一般アンケートを作成し、作成時に説明にエンゲージメント名を指定してください。これにより結果のフィルタリングが可能になります。 + +![image](images/q_ss8.png) + +![image](images/q_ss9.png) + +### リンク済みアンケートへの回答 + +リンク済みアンケートに回答するには、 +1. エンゲージメントビューに移動します。 +2. 追加機能テーブルを展開します。 +3. アンケートサブテーブルを展開します。 +4. リンク済みアンケートの⋮ケバブメニューをクリックします。 +5. **アンケートに回答**をクリックします。 + +![image](images/q_ss15.png) + +エンゲージメントへのアクセスにはDefectDojoへのアクセスが必要なため、リンク済みアンケートでは外部/匿名の回答は許可されません。 + +## 回答 + +前述のとおり、アンケートテンプレートのデプロイごとに、それぞれ独自の回答コンテナが作成されます。同じアンケートテンプレートを複数のエンゲージメントにリンクすると、それぞれ別々の回答セットになり、一般アンケートを公開してもリンク済みアンケートの回答セットには影響しません。 + +### 一般アンケートの回答 + +一般アンケートの有効期限が過ぎると、 +- それ以上の回答を送信できなくなります。 +- それまでのすべての回答が保存され、閲覧可能になります。 +- そのアンケートはDefectDojoダッシュボード上で「未割り当ての回答済みエンゲージメントアンケート」として表示されます。 + +アンケートの回答受付期間が終了すると、**回答を表示**、**エンゲージメントの作成**、**ユーザーの割り当て**の3つのアクションを実行できます。 + +#### アンケート回答の表示 + +**回答を表示**を選択すると、そのアンケートのすべての回答が表示されます。 + +#### アンケートからのエンゲージメントの作成 + +期限切れになると、**エンゲージメントの作成**アクションを選択することで、一般アンケートをエンゲージメント経由でアセットに接続できます。続いて表示されるドロップダウンリストからアセットを選択し、**エンゲージメントの作成**をクリックします。すると新しいエンゲージメントが作成され、DefectDojoの他のエンゲージメントと同様に、説明、バージョン、ステータス、タグなどの詳細を設定できます。 + +![image](images/q_ss6.png) + +![image](images/q_ss7.png) + +#### ユーザーの割り当て + +ユーザーの割り当てアクションでは、利用可能なユーザーのドロップダウンからユーザーを選択するよう求められます。ドロップダウンメニューからユーザーを選択し、**アンケートの割り当て**をクリックすると、そのユーザーがそのアンケートの所有者になります。 + +### リンク済みアンケートの回答 + +リンク済みアンケートは、関連するエンゲージメントがアクティブである限り利用可能です。そのため、回答はいつでも閲覧できます。 + +リンク済みアンケートの⋮ケバブメニューには、アンケートと回答を管理するためのいくつかの機能が含まれています。 +- **アンケートに回答**：ユーザーがまだリンク済みアンケートに回答していない場合に表示されるオプションです。回答すると、回答を表示と回答を編集が表示されるようになります。 +- **回答を表示**：これまでのアンケートのすべての回答をユーザーが閲覧できるようにします。 +- **回答を編集**：各ユーザーが以前の回答を編集できるようにします。 +- **ユーザーの割り当て**：アンケートをユーザーに割り当てます。 +- **別のエンゲージメントにリンク**：アンケートを割り当てる他のエンゲージメントのドロップダウンメニューを開きます。 +- **アンケートの共有**：社内のユーザーとアンケートを共有するためのリンクを生成します。 +- **アンケートの削除**：エンゲージメントからアンケートのリンクを解除し、それまでに収集された回答を削除します。 + +## アンケートの削除 + +一般アンケートとリンク済みアンケートの削除は、削除の意図した結果によって、その後の影響が異なります。 + +### 一般アンケートの削除 + +すべてのアンケートセクションの一般アンケートテーブルから一般アンケートを削除すると、削除前にそのデプロイで収集されたすべての回答が削除されます。同じアンケートテンプレートを使用しているリンク済みアンケートは削除されません。 + +### リンク済みアンケートの削除 + +リンク済みアンケートを削除すると、エンゲージメントからアンケートのリンクが解除されます。削除前にそのエンゲージメント内で収集されたすべての回答は失われます。同じアンケートテンプレートを使用して以前にデプロイされた一般アンケートには影響しません。 + +### アンケートテンプレートの削除 + +アンケートテンプレートを完全に削除するには、すべてのアンケートビューのアンケートテーブルからそのテンプレートを選択し、**アンケートの削除**をクリックします。これにより、アンケートテンプレートと、すべてのデプロイからの関連するすべての回答が完全に削除されます。この操作は取り消せません。 diff --git a/docs/content/asset_modelling/OS_questionnaires/_index.de.md b/docs/content/asset_modelling/OS_questionnaires/_index.de.md new file mode 100644 index 00000000000..3ed34fda643 --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/_index.de.md @@ -0,0 +1,9 @@ +--- +title: Fragebögen +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +audience: opensource +--- diff --git a/docs/content/asset_modelling/OS_questionnaires/_index.es.md b/docs/content/asset_modelling/OS_questionnaires/_index.es.md new file mode 100644 index 00000000000..938624d11ab --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/_index.es.md @@ -0,0 +1,9 @@ +--- +title: Cuestionarios +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +audience: opensource +--- diff --git a/docs/content/asset_modelling/OS_questionnaires/_index.fr.md b/docs/content/asset_modelling/OS_questionnaires/_index.fr.md new file mode 100644 index 00000000000..83cbaf9abaa --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/_index.fr.md @@ -0,0 +1,9 @@ +--- +title: Questionnaires +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +audience: opensource +--- diff --git a/docs/content/asset_modelling/OS_questionnaires/_index.ja.md b/docs/content/asset_modelling/OS_questionnaires/_index.ja.md new file mode 100644 index 00000000000..2314f29d343 --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/_index.ja.md @@ -0,0 +1,9 @@ +--- +title: アンケート +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +audience: opensource +--- diff --git a/docs/content/asset_modelling/PRO_hierarchy/_index.de.md b/docs/content/asset_modelling/PRO_hierarchy/_index.de.md new file mode 100644 index 00000000000..24e3ccc6fe2 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/_index.de.md @@ -0,0 +1,11 @@ +--- +title: Asset-Hierarchie +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +audience: pro +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/PRO_hierarchy/_index.es.md b/docs/content/asset_modelling/PRO_hierarchy/_index.es.md new file mode 100644 index 00000000000..33bbb121647 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/_index.es.md @@ -0,0 +1,11 @@ +--- +title: Jerarquía de activos +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +audience: pro +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/PRO_hierarchy/_index.fr.md b/docs/content/asset_modelling/PRO_hierarchy/_index.fr.md new file mode 100644 index 00000000000..9fc3ee0f3e1 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/_index.fr.md @@ -0,0 +1,11 @@ +--- +title: Hiérarchie des actifs +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +audience: pro +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/PRO_hierarchy/_index.ja.md b/docs/content/asset_modelling/PRO_hierarchy/_index.ja.md new file mode 100644 index 00000000000..46434218921 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/_index.ja.md @@ -0,0 +1,11 @@ +--- +title: アセット階層 +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +audience: pro +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.de.md b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.de.md new file mode 100644 index 00000000000..a94d1f1c3b5 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.de.md @@ -0,0 +1,149 @@ +--- +title: Asset-Hierarchie +description: DefectDojo Pro – Überarbeitung der Produkthierarchie +audience: pro +weight: 1 +aliases: +- /de/en/working_with_findings/organizing_engagements_tests/pro_assets_organizations +- /de/asset_modelling/pro_hierarchy/assets_organizations +--- + +DefectDojo Pro erweitert die Objektklassen Produkt/Produkttyp, um mehr Flexibilität im Datenmodell zu bieten. + +## Aktivieren der Hierarchie-Funktion + +Die beiden folgenden Teile sind voneinander unabhängig und werden über unterschiedliche Mechanismen gesteuert. + +### Asset-Hierarchie + +**Asset-Hierarchie** ermöglicht übergeordnete/untergeordnete Beziehungen zwischen Assets. Die Hierarchie wird über die Registerkarte **Produkt** in der Navigation angezeigt und verwaltet. + +Asset-Hierarchie ist allgemein verfügbar und für jede Instanz, ob Cloud oder On-Premise, standardmäßig aktiviert. Es muss nichts aktiviert werden, und die Funktion wird auf der Seite „Feature Flags" nicht mehr aufgeführt. + +### Bezeichnungsänderungen (optional) + +**Bezeichnungsänderungen** benennen in der gesamten UI „Produkttyp" in „Organisation" und „Produkt" in „Asset" um. Dies ist ein separater Schritt von der Aktivierung der Hierarchie und kann gleichzeitig oder später durchgeführt werden. + +Bezeichnungsänderungen sind ab Version 3.0 standardmäßig aktiviert. Es gibt zwei Steuerungen, die unterschiedliche Teile der Anwendung abdecken: + +* **Pro-UI** (die Standard-UI): Ein Superuser schaltet „Organization / Asset Relabeling" unter **Settings > Feature Flags** um, sowohl auf Cloud- als auch auf On-Premise-Instanzen. Die neuen Bezeichnungen erscheinen beim nächsten Laden der Seite. Siehe [Feature Flags](/admin/feature_flags/pro__feature_flags/). +* **Klassische UI-Seiten und generierte Berichte**: Deren Bezeichnungen und URLs stammen aus der Deployment-Einstellung `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`, die beim Start von DefectDojo gelesen wird. Setzen Sie sie On-Premise und starten Sie DefectDojo neu. Bei [DefectDojo Pro (Cloud)](/get_started/pro/cloud/) senden Sie eine E-Mail an [support@defectdojo.com](mailto:support@defectdojo.com) mit Ihrer Instanz-URL. + +Beide sind standardmäßig aktiviert, und der Feature-Flags-Wert wurde ursprünglich aus der Deployment-Einstellung übernommen, sodass beide übereinstimmen, sofern Sie nicht eine davon ändern. Halten Sie sie synchron, wenn Sie sowohl die klassische UI als auch die Pro-UI verwenden. + +Beachten Sie, dass Bezeichnungsänderungen rein kosmetisch sind: API-Endpunkte und Feldnamen bleiben unverändert, sodass bestehende Automatisierungen weiterhin funktionieren. + +## Wesentliche Änderungen + +* **Produkttypen** wurden in „Organizations" umbenannt, und **Produkte** wurden in „Assets" umbenannt. Ab Version 3.0 ist diese Umbenennung standardmäßig aktiviert. Siehe [Bezeichnungsänderungen](#label-changes-optional) für die Steuerungen, mit denen sie deaktiviert wird. +* **Assets** können jetzt untereinander übergeordnete/untergeordnete Beziehungen haben, um Organisationskomponenten weiter zu unterteilen. + +### Organisationen + +Wie bei Produkttypen sollten **Organisationen** als übergeordnete Kategorie verstanden werden. Sie können diese verwenden, um die Kernsoftwareanwendungen, Abteilungen oder Geschäftsfunktionen Ihres Unternehmens zu trennen. + +Sie könnten zum Beispiel eine Organisation für mehrere Repository-Gruppierungen anlegen: „Core Application", „Infrastructure", „DevOps", „Analytics", „SDK" könnten jeweils mehrere Code-Repositories enthalten. + +Bedenken Sie, dass es für Berichtszwecke einfacher ist, mehrere Organisationen zu einem einzigen Dokument zusammenzufassen, als eine einzelne Organisation in separate Dokumente zu unterteilen. Wir empfehlen daher, Organisationen auf einer möglichst granularen Ebene einzurichten, wie es für die Berichte Ihres Teams sinnvoll ist. Es besteht zum Beispiel keine Notwendigkeit, eine große Geschäftseinheit als Organisation abzubilden, wenn Sie hauptsächlich über einzelne Abteilungen innerhalb dieser Einheit berichten möchten. + +### Assets + +Assets sollen Unterteilungen Ihrer Organisationen darstellen. Im Gegensatz zu Produkten können Assets jedoch verschachtelt werden und untereinander übergeordnete/untergeordnete Beziehungen haben. + +## Beispiele für die Asset-Verschachtelung + +### Branch-Darstellung auf Asset-Ebene + +Entwicklungs- und Feature-Branches können auf verschiedene Weise dargestellt werden; separate Engagements oder Tests sind bestehende Möglichkeiten, um den Unterschied zwischen Ihren Produktions-, Dev- und anderen Feature-Branches abzubilden. + +Sie können diese auch mithilfe verschachtelter Assets abbilden. Betrachten Sie den folgenden Asset-Baum: + +``` +Core Application [Organization] +└── webapp-frontend + ├── webapp-frontend/prod + └── webapp-frontend/dev + ├── webapp-frontend/dev/feature-a + └── webapp-frontend/dev/feature-b +``` + +In dieser Umgebung könnte jeder Branch (`prod`, `dev`, `feature a`, `feature b`) eigene Engagements und Tests haben, die von den anderen Assets isoliert sind, sodass sie nicht gegeneinander dedupliziert werden. Dieser Aufbau kann auch die Navigation erleichtern, da Asset-Namen direkt dem Pfad in Git entsprechen können. + +### Mono-Repo: Separate Komponenten + +Wenn Sie ein einzelnes Repository für Ihren gesamten Code verwenden, aber unterschiedliche Teams zu Verzeichnissen innerhalb dieses Repositorys beitragen, können Sie Ihre Asset-Verschachtelung so einrichten, dass sie diese Struktur abbildet. + +``` +Core Application [Organization] +├── webapp-frontend [Parent Asset] +│ ├── mobile-ios +│ ├── mobile-android +│ └── mobile-sdk +├── webapp-backend [Parent Asset] +│ ├── database +│ └── api +└── infra [Parent Asset] + ├── docker + ├── kubernetes + └── nginx +``` + +In diesem Diagramm könnte jedes Element unter „Core Application" als separates Asset erfasst werden, mit eigener Geschäftskritikalität (siehe: [Priorität & Risiko](/asset_modelling/pro_hierarchy/priority_sla/#prioritization-engines)), eigenem RBAC sowie zugehörigen Engagements und Tests. Sie könnten weiterhin auf dem übergeordneten Asset testen und Ergebnisse speichern (zum Beispiel `webapp-backend`), aber auch isolierte Tests auf einem bestimmten untergeordneten Asset durchführen (zum Beispiel `database`). + +### Pen-Tests: Isoliertes RBAC + +Wenn Sie Pen-Test-Ergebnisse innerhalb eines einzelnen Assets speichern möchten, aber nicht möchten, dass Tester Asset-Daten einsehen können, können Sie für jede Testgruppe untergeordnete Assets erstellen, in die diese ihre Ergebnisse hochladen. + +``` +Core Application [Organization] +└── webapp-frontend [Parent Asset] + ├── Pen Test Group A + └── Pen Test Group B +``` + +Entscheidend ist, dass ein Benutzer, dem RBAC-Zugriff auf ein einzelnes untergeordnetes Asset gewährt wird (z. B. `Pen Test Group A`), dadurch keine Befunde aus anderen untergeordneten Assets (z. B. `Pen Test Group B`) einsehen kann und auch keine Befunde im übergeordneten Asset (`webapp-frontend`) einsehen kann. + +Das übergeordnete Asset könnte Engagements enthalten, die CI/CD-Ergebnisse, internes Testing, historische Daten oder andere Befunddaten darstellen, die Dritte nicht entdecken können sollen. Das Erstellen eines untergeordneten Assets für bestimmte Testergebnisse ermöglicht es Ihrem internen Team, über diese Ergebnisse in Kombination mit dem Zustand des übergeordneten Assets zu berichten. + +## Assets visualisieren – Hierarchie + +Sie können die Struktur der Assets in DefectDojo visualisieren und Beziehungen über die Option „Asset-Hierarchie" im Menü ändern. + +![image](images/asset_hierarchy.png) + +Beim Öffnen der Asset-Hierarchie wird eine filterbare Tabelle aller Ihrer Assets angezeigt. Die Auswahl eines oder mehrerer Assets aus dieser Tabelle rendert ein Hierarchiediagramm. + +![image](images/asset_hierarchy_diagram.png) + +### Diagrammnavigation + +Mit den Symbolen oben links im Hierarchiediagramm können Sie hinein- und herauszoomen. Durch Klicken und Ziehen in diesem Diagramm können Sie darin scrollen. + +Jedes Asset wird in diesem Diagramm als einzelner Knoten dargestellt, der zu Anzeigezwecken verschoben werden kann. + +Assets werden über beschriftete Pfade miteinander verbunden, die die Art der Beziehung zwischen den einzelnen Knoten darstellen. Derzeit wird nur die Beschriftung `parent` unterstützt. + +### Asset-Knoten erkunden + +Mit jedem Asset-Knoten kann durch Klicken auf die blauen Schaltflächen interagiert werden. Diese Schaltflächen erscheinen nur, wenn ein Asset-Knoten ausgewählt ist (durch Klicken auf den Knoten). + +![image](images/asset_hierarchy_node.png) + +* 👁️ (Augensymbol) führt Sie direkt zur entsprechenden Asset-Ansicht (früher als Produktansicht bekannt). +* ✏️ (Stiftsymbol) öffnet ein modales Fenster mit dem Formular „Asset bearbeiten" (früher als Formular „Produkt bearbeiten" bekannt) +* ➕ (Plussymbol) ermöglicht es Ihnen, diesem Asset ein neues untergeordnetes Asset hinzuzufügen. Das Asset muss im Diagramm nicht aktuell sichtbar sein, muss aber Teil derselben Organisation sein. +* ✥ (Vier-Pfeile-Symbol) ermöglicht es Ihnen, das übergeordnete Asset des aktuell ausgewählten Assets zu ändern. +* 🗑️ (Papierkorbsymbol) ermöglicht es Ihnen, die übergeordnete Beziehung eines Assets zu entfernen. Dieses Symbol erscheint nur, wenn ein Asset bereits ein übergeordnetes Asset hat. + +Wenn Ihr Diagramm ein Asset mit nicht ausgewählten übergeordneten Assets anzeigt, können Sie auf die Schaltfläche „Load More" klicken, um das Diagramm mit dem übergeordneten Asset (sowie dessen untergeordneten Assets) zu füllen. + +![image](images/assets_loadmore.png) + +## Notizen + +* Beachten Sie, dass sich die Deduplizierungsbereiche nicht geändert haben; Assets deduplizieren Befunde nur innerhalb ihrer selbst und berücksichtigen keine Befunde in anderen Assets, unabhängig von übergeordneten/untergeordneten Beziehungen. +* Die RBAC-Bereiche haben sich in diesem System nicht geändert; jedes Asset gilt weiterhin als eigenständiges Objekt für die Zuweisung von Berechtigungen. Es wurde keine neue RBAC-Vererbung geschaffen. + * Wenn einem Benutzer Zugriff auf eine gesamte Organisation gewährt wird, erhält dieser Benutzer weiterhin Zugriff auf alle in dieser Organisation enthaltenen Assets (wie bei Produkttypen). + * Wenn einem Benutzer Zugriff auf ein einzelnes Asset gewährt wird, erhält dieser Benutzer dadurch keinen Zugriff auf zugehörige übergeordnete oder untergeordnete Assets und auch keinen Zugriff auf die Organisation. +* Es gibt keine Begrenzung für die Anzahl der erstellbaren übergeordneten/untergeordneten Beziehungen. Theoretisch könnten Sie die gesamte Verzeichnisstruktur eines Repositorys mit separaten Assets abbilden, wenn Sie dies wünschten. +* Zyklische Beziehungen sind nicht zulässig: Übergeordnete Assets können nicht gleichzeitig untergeordnete Assets ihrer eigenen untergeordneten Assets sein. diff --git a/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.es.md b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.es.md new file mode 100644 index 00000000000..d712da90f17 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.es.md @@ -0,0 +1,149 @@ +--- +title: Jerarquía de activos +description: 'DefectDojo Pro: renovación de la jerarquía de productos' +audience: pro +weight: 1 +aliases: +- /es/en/working_with_findings/organizing_engagements_tests/pro_assets_organizations +- /es/asset_modelling/pro_hierarchy/assets_organizations +--- + +DefectDojo Pro está ampliando las clases de objetos Producto/Tipo de producto para ofrecer mayor flexibilidad en el modelo de datos. + +## Enabling the Hierarchy Feature + +Las dos partes siguientes son independientes y se controlan mediante mecanismos distintos. + +### Asset Hierarchy + +**Jerarquía de activos** habilita relaciones padre/hijo entre Activos. La jerarquía se visualiza y se administra desde la pestaña **Producto** en la navegación. + +Jerarquía de activos está disponible de forma general y activada en todas las instancias, tanto Cloud como On-Premise. No hay nada que habilitar, y ya no aparece en la página de Feature Flags. + +### Label Changes (optional) + +**Cambios de etiquetas** renombra "Product Type" a "Organization" y "Product" a "Asset" en toda la interfaz. Este es un paso independiente de la habilitación de la jerarquía y se puede realizar al mismo tiempo o más adelante. + +Los cambios de etiquetas están activados de forma predeterminada a partir de la versión 3.0. Hay dos controles que abarcan partes distintas de la aplicación: + +* **Interfaz Pro** (la interfaz predeterminada): un superusuario activa "Organization / Asset Relabeling" en **Settings > Feature Flags**, tanto en instancias Cloud como On-Premise. Las nuevas etiquetas aparecen en la siguiente carga de página. Consulte [Feature Flags](/admin/feature_flags/pro__feature_flags/). +* **Páginas de la interfaz clásica e informes generados**: sus etiquetas y URLs provienen del ajuste de despliegue `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`, que se lee cuando DefectDojo se inicia. En instalaciones on-premise, configúrelo y reinicie DefectDojo. En [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), envíe un correo a [support@defectdojo.com](mailto:support@defectdojo.com) con la URL de su instancia. + +Ambos están activados de forma predeterminada, y el valor de Feature Flags se inicializó a partir del ajuste de despliegue, por lo que ambos coinciden a menos que cambie uno de ellos. Manténgalos sincronizados si usa tanto la interfaz clásica como la interfaz Pro. + +Tenga en cuenta que los cambios de etiquetas son solo cosméticos: los endpoints de la API y los nombres de los campos permanecen sin cambios, por lo que la automatización existente seguirá funcionando. + +## Significant Changes + +* **Los Tipos de producto** se han renombrado a "Organizations", y los **Productos** se han renombrado a "Assets". A partir de la versión 3.0, este cambio de nombre está activado de forma predeterminada. Consulte [Cambios de etiquetas](#label-changes-optional) para conocer los controles que lo desactivan. +* Los **Activos** ahora pueden tener relaciones padre/hijo entre sí para subcategorizar aún más los componentes organizacionales. + +### Organizations + +Al igual que con los Tipos de producto, las **Organizaciones** deben entenderse como una categoría de nivel superior. Puede usarlas para separar las aplicaciones de software principales de su empresa, sus departamentos o sus funciones de negocio. + +Por ejemplo, podría crear una Organización para varias agrupaciones de repositorios: "Core Application", "Infrastructure", "DevOps", "Analytics" o "SDK" podrían contener cada una múltiples repositorios de código. + +Tenga en cuenta que, a efectos de generación de informes, es más fácil combinar varias Organizaciones en un solo documento que subdividir una única Organización en documentos separados. Por lo tanto, recomendamos configurar las Organizaciones con el nivel de granularidad que tenga sentido para los informes de su equipo. Por ejemplo, no es necesario representar una gran división de negocio como una Organización si principalmente va a generar informes sobre departamentos individuales dentro de esa división. + +### Assets + +Los Activos están pensados para representar subdivisiones de sus Organizaciones. Sin embargo, a diferencia de los Productos, los Activos pueden anidarse y tener relaciones padre-hijo entre sí. + +## Asset Nesting Examples + +### Asset-Level Branch Representation + +Las ramas de desarrollo y de funcionalidades se pueden representar de varias maneras; Compromisos o Tests separados son formas ya existentes de representar la diferencia entre sus ramas de Producción, Desarrollo y otras ramas de funcionalidades. + +También puede representarlas usando Activos anidados. Considere el siguiente árbol de Activos: + +``` +Core Application [Organization] +└── webapp-frontend + ├── webapp-frontend/prod + └── webapp-frontend/dev + ├── webapp-frontend/dev/feature-a + └── webapp-frontend/dev/feature-b +``` + +En este entorno, cada rama (`prod`, `dev`, `feature a`, `feature b`) podría tener sus propios Compromisos y Tests aislados de los demás Activos, de modo que no se deduplican entre sí. Esta configuración también puede facilitar la navegación, ya que los nombres de los Activos pueden corresponder directamente a la ruta en Git. + +### Mono-Repo: Separate Components + +Si usa un único repositorio para todo su código, pero tiene distintos equipos que contribuyen a directorios dentro de ese repositorio, puede configurar el anidamiento de Activos para representar esa estructura. + +``` +Core Application [Organization] +├── webapp-frontend [Parent Asset] +│ ├── mobile-ios +│ ├── mobile-android +│ └── mobile-sdk +├── webapp-backend [Parent Asset] +│ ├── database +│ └── api +└── infra [Parent Asset] + ├── docker + ├── kubernetes + └── nginx +``` + +En este diagrama, cada elemento bajo "Core Application" podría registrarse como un Activo separado, con criticidad de negocio propia (ver: [Priority & Risk](/asset_modelling/pro_hierarchy/priority_sla/#prioritization-engines)), RBAC y sus correspondientes Compromisos y Tests. Podría seguir realizando pruebas y almacenando resultados en el Activo superior (por ejemplo, `webapp-backend`), pero también podría ejecutar pruebas aisladas en un Activo hijo concreto (por ejemplo, `database`). + +### Pen Tests: Isolated RBAC + +Si desea almacenar los resultados de pruebas de penetración dentro de un único activo, pero no quiere que los testers puedan ver los datos del activo, podría crear activos hijos para que cada grupo de pruebas suba sus resultados. + +``` +Core Application [Organization] +└── webapp-frontend [Parent Asset] + ├── Pen Test Group A + └── Pen Test Group B +``` + +Es fundamental señalar que dar a un usuario acceso RBAC a un único Activo hijo (por ejemplo, `Pen Test Group A`) no le permite ver ningún Hallazgo de otros Activos hijos (por ejemplo, `Pen Test Group B`), ni tampoco le permite ver Hallazgos en el Activo superior (`webapp-frontend`). + +El Activo superior podría contener Compromisos que representen resultados de CI/CD, pruebas internas, datos históricos u otros datos de Hallazgos que no desee que terceros puedan descubrir. Crear un Activo hijo para resultados de Test específicos permite que su equipo interno informe sobre esos resultados en combinación con el estado del Activo superior. + +## Visualizing Assets - Hierarchy + +Puede visualizar la estructura de los Activos en DefectDojo y cambiar las relaciones usando la opción Jerarquía de activos en el menú. + +![image](images/asset_hierarchy.png) + +Al abrir Jerarquía de activos se mostrará una tabla con todos sus Activos, que se puede filtrar. Seleccionar uno o más Activos de esta tabla generará un diagrama de jerarquía. + +![image](images/asset_hierarchy_diagram.png) + +### Diagram navigation + +Los iconos de la parte superior izquierda del diagrama de jerarquía le permiten acercar y alejar el zoom. Hacer clic y arrastrar en este diagrama le permite desplazarse por él. + +Cada Activo se representa como un único nodo en este diagrama, que se puede mover para fines de visualización. + +Los Activos se conectan entre sí mediante rutas etiquetadas, que representan el tipo de relación que tiene cada nodo con los demás. Actualmente, `parent` es la única etiqueta admitida. + +### Exploring Asset nodes + +Se puede interactuar con cada nodo de Activo haciendo clic en los botones azules. Estos botones solo aparecen cuando se selecciona un nodo de Activo (haciendo clic en el nodo). + +![image](images/asset_hierarchy_node.png) + +* 👁️ (icono de ojo) lo llevará directamente a la Vista de activo correspondiente (anteriormente conocida como Vista de producto). +* ✏️ (icono de lápiz) abrirá una ventana modal con el formulario Editar activo (anteriormente conocido como formulario Editar producto) +* ➕ (icono de más) le permitirá agregar un nuevo Activo hijo a este Activo. El Activo no necesita estar actualmente visible en el diagrama, pero debe formar parte de la misma Organización. +* ✥ (icono de cuatro flechas) le permite cambiar el Activo superior del Activo seleccionado actualmente. +* 🗑️ (icono de papelera) le permite eliminar la relación de un Activo con su superior. Este icono solo aparece si un Activo ya tiene un Activo superior. + +Si su diagrama muestra un Activo con Activos superiores no seleccionados, puede hacer clic en el botón Load More para completar el diagrama con el Activo superior (así como con los hijos de ese Activo superior). + +![image](images/assets_loadmore.png) + +## Notes + +* Tenga en cuenta que los ámbitos de deduplicación no han cambiado; los Activos solo deduplican Hallazgos dentro de sí mismos y no consideran los Hallazgos de otros Activos, independientemente de las relaciones padre/hijo. +* Los ámbitos de RBAC no han cambiado dentro de este sistema; cada Activo sigue considerándose un objeto individual a efectos de asignación de permisos. No se ha creado ninguna nueva herencia de RBAC. + * Dar a un usuario acceso a toda una Organización seguirá dándole acceso a todos los Activos contenidos en esa Organización (como ocurría con los Tipos de producto). + * Dar a un usuario acceso a un único Activo no le da acceso a ningún Activo superior o hijo relacionado, ni acceso a la Organización. +* No hay límite en la cantidad de relaciones padre/hijo que se pueden crear. En teoría, podría representar toda la estructura de directorios de un repositorio con Activos separados si así lo deseara. +* No se permiten relaciones cíclicas: los Activos superiores no pueden ser hijos de sus propios Activos hijos. diff --git a/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.fr.md b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.fr.md new file mode 100644 index 00000000000..4c3c513e340 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.fr.md @@ -0,0 +1,149 @@ +--- +title: Hiérarchie des actifs +description: DefectDojo Pro - Refonte de la hiérarchie des produits +audience: pro +weight: 1 +aliases: +- /fr/en/working_with_findings/organizing_engagements_tests/pro_assets_organizations +- /fr/asset_modelling/pro_hierarchy/assets_organizations +--- + +DefectDojo Pro étend les classes d'objets Produit/Type de produit afin d'offrir une plus grande flexibilité dans le modèle de données. + +## Enabling the Hierarchy Feature + +Les deux éléments ci-dessous sont distincts et sont contrôlés par des moyens différents. + +### Asset Hierarchy + +**La Hiérarchie des actifs** permet d'établir des relations parent/enfant entre les Actifs. La hiérarchie se consulte et se gère depuis l'onglet **Produit** de la navigation. + +La Hiérarchie des actifs est disponible en version stable et activée sur toutes les instances, Cloud et On-Premise. Il n'y a rien à activer, et elle n'apparaît plus sur la page Feature Flags. + +### Label Changes (optional) + +**Les changements d'étiquettes** renomment « Product Type » en « Organization » et « Product » en « Asset » dans toute l'UI. Il s'agit d'une étape distincte de l'activation de la hiérarchie, qui peut être effectuée en même temps ou plus tard. + +Les changements d'étiquettes sont activés par défaut depuis la version 3.0. Il existe deux contrôles, couvrant différentes parties de l'application : + +* **UI Pro** (l'UI par défaut) : un superutilisateur active « Organization / Asset Relabeling » dans **Paramètres > Feature Flags**, sur les instances Cloud comme On-Premise. Les nouvelles étiquettes apparaissent au chargement de page suivant. Voir [Feature Flags](/admin/feature_flags/pro__feature_flags/). +* **Pages de l'UI classique et rapports générés** : leurs étiquettes et URL proviennent du paramètre de déploiement `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`, lu au démarrage de DefectDojo. En on-premise, définissez-le puis redémarrez DefectDojo. Sur [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), envoyez un e-mail à [support@defectdojo.com](mailto:support@defectdojo.com) avec l'URL de votre instance. + +Les deux sont activés par défaut, et la valeur de Feature Flags a été initialisée à partir du paramètre de déploiement : les deux concordent donc tant que vous n'en modifiez pas un seul. Gardez-les synchronisés si vous utilisez à la fois l'UI classique et l'UI Pro. + +Notez que les changements d'étiquettes sont purement cosmétiques : les endpoints API et les noms de champs restent inchangés, de sorte que vos automatisations existantes continueront de fonctionner. + +## Significant Changes + +* Les **Types de produit** ont été renommés en « Organizations », et les **Produits** ont été renommés en « Assets ». Depuis la version 3.0, ce changement de nom est activé par défaut. Voir [Label Changes](#label-changes-optional) pour les contrôles permettant de le désactiver. +* Les **Actifs** peuvent désormais avoir des relations parent/enfant entre eux, afin de sous-catégoriser plus finement les composants organisationnels. + +### Organizations + +Comme pour les Types de produit, les **Organisations** doivent être comprises comme une catégorie de premier niveau. Vous pouvez les utiliser pour séparer les applications logicielles cœur de votre entreprise, ses départements ou ses fonctions métier. + +Par exemple, vous pourriez créer une Organisation pour plusieurs regroupements de dépôts : « Core Application », « Infrastructure », « DevOps », « Analytics », « SDK » pourraient chacun contenir plusieurs dépôts de code. + +Gardez à l'esprit que, pour les besoins de reporting, il est plus simple de combiner plusieurs Organisations en un seul document que de subdiviser une Organisation unique en plusieurs documents. Nous recommandons donc de configurer vos Organisations au niveau de granularité le plus adapté aux rapports de votre équipe. Par exemple, il n'est pas nécessaire de représenter une grande division de l'entreprise comme une seule Organisation si vous allez principalement produire des rapports sur les départements individuels de cette division. + +### Assets + +Les Actifs sont destinés à représenter des subdivisions de vos Organisations. Cependant, contrairement aux Produits, les Actifs peuvent être imbriqués et avoir des relations parent-enfant entre eux. + +## Asset Nesting Examples + +### Asset-Level Branch Representation + +Les branches de développement et de fonctionnalités peuvent être représentées de diverses façons ; des Engagements ou des Tests distincts sont des moyens existants pour représenter la différence entre vos branches de Production, de Dev, et vos autres branches de fonctionnalités. + +Vous pouvez également les représenter à l'aide d'Actifs imbriqués. Prenons l'arborescence d'Actifs suivante : + +``` +Core Application [Organization] +└── webapp-frontend + ├── webapp-frontend/prod + └── webapp-frontend/dev + ├── webapp-frontend/dev/feature-a + └── webapp-frontend/dev/feature-b +``` + +Dans cet environnement, chaque branche (`prod`, `dev`, `feature a`, `feature b`) pourrait avoir ses propres Engagements et Tests isolés des autres Actifs, afin qu'ils ne se dédupliquent pas entre eux. Cette configuration peut également faciliter la navigation, les noms d'Actifs pouvant correspondre directement au chemin sur Git. + +### Mono-Repo: Separate Components + +Si vous utilisez un dépôt unique pour tout votre code, mais que différentes équipes contribuent à des répertoires au sein de ce dépôt, vous pouvez configurer votre imbrication d'Actifs pour représenter cette structure. + +``` +Core Application [Organization] +├── webapp-frontend [Parent Asset] +│ ├── mobile-ios +│ ├── mobile-android +│ └── mobile-sdk +├── webapp-backend [Parent Asset] +│ ├── database +│ └── api +└── infra [Parent Asset] + ├── docker + ├── kubernetes + └── nginx +``` + +Dans ce diagramme, chaque élément sous « Core Application » pourrait être enregistré comme un Actif distinct, avec sa propre criticité métier (voir : [Priority & Risk](/asset_modelling/pro_hierarchy/priority_sla/#prioritization-engines)), son propre RBAC, ainsi que ses propres Engagements et Tests. Vous pourriez continuer à tester, et stocker les résultats, sur l'Actif parent (par exemple, `webapp-backend`), mais vous pourriez aussi exécuter des tests isolés sur un Actif enfant particulier (par exemple, `database`). + +### Pen Tests: Isolated RBAC + +Si vous souhaitez stocker les résultats de tests d'intrusion au sein d'un même actif, mais que vous ne voulez pas que les testeurs puissent consulter les données de l'actif, vous pouvez créer des actifs enfants pour que chaque groupe de test y envoie ses résultats. + +``` +Core Application [Organization] +└── webapp-frontend [Parent Asset] + ├── Pen Test Group A + └── Pen Test Group B +``` + +Point essentiel : donner à un utilisateur un accès RBAC à un seul Actif enfant (par exemple `Pen Test Group A`) ne lui permet pas de voir les Constatations des autres Actifs enfants (par exemple `Pen Test Group B`), ni de voir les Constatations dans l'Actif parent (`webapp-frontend`). + +L'Actif parent pourrait contenir des Engagements représentant des résultats CI/CD, des Tests internes, des données historiques, ou d'autres données de Constatations que vous ne voulez pas que des tiers puissent découvrir. Créer un Actif enfant pour des résultats de Test spécifiques permet à votre équipe interne de produire des rapports sur ces résultats en combinaison avec l'état de l'Actif parent. + +## Visualizing Assets - Hierarchy + +Vous pouvez visualiser la structure des Actifs dans DefectDojo, et modifier les relations à l'aide de l'option Hiérarchie des actifs dans le menu. + +![image](images/asset_hierarchy.png) + +L'ouverture de la Hiérarchie des actifs affiche un tableau de tous vos Actifs, qui peut être filtré. Sélectionner un ou plusieurs Actifs dans ce tableau génère un diagramme de hiérarchie. + +![image](images/asset_hierarchy_diagram.png) + +### Diagram navigation + +Les icônes en haut à gauche du diagramme de hiérarchie permettent de zoomer et dézoomer. Cliquer-glisser dans ce diagramme permet de le faire défiler. + +Chaque Actif est représenté par un seul nœud dans ce diagramme, qui peut être déplacé à des fins d'affichage. + +Les Actifs sont reliés entre eux par des chemins étiquetés, qui représentent le type de relation qu'ils entretiennent les uns avec les autres. Actuellement, `parent` est la seule étiquette prise en charge. + +### Exploring Asset nodes + +Chaque nœud d'Actif peut être manipulé en cliquant sur les boutons bleus. Ces boutons n'apparaissent que lorsqu'un nœud d'Actif est sélectionné (en cliquant sur le nœud). + +![image](images/asset_hierarchy_node.png) + +* 👁️ (icône œil) vous amène directement à la Vue Actif correspondante (anciennement appelée Vue Produit). +* ✏️ (icône crayon) ouvre une fenêtre modale avec le formulaire Modifier l'actif (anciennement appelé formulaire Modifier le produit) +* ➕ (icône plus) vous permet d'ajouter un nouvel Actif enfant à cet Actif. L'Actif n'a pas besoin d'être actuellement visible dans le diagramme, mais doit appartenir à la même Organisation. +* ✥ (icône quatre flèches) permet de changer l'Actif parent de l'Actif actuellement sélectionné. +* 🗑️ (icône corbeille) permet de supprimer la relation parent d'un Actif. Cette icône n'apparaît que si un Actif a déjà un Parent. + +Si votre diagramme affiche un Actif dont les Actifs parents ne sont pas sélectionnés, vous pouvez cliquer sur le bouton Load More pour compléter le diagramme avec l'Actif parent (ainsi que les enfants de cet Actif parent). + +![image](images/assets_loadmore.png) + +## Notes + +* Notez que les périmètres de déduplication n'ont pas changé ; les Actifs ne dédupliquent les Constatations qu'en leur sein, et ne prennent pas en compte les Constatations d'autres Actifs, quelles que soient les relations Parent/Enfant. +* Les périmètres RBAC n'ont pas changé dans ce système ; chaque Actif reste considéré comme un objet individuel pour l'attribution des permissions. Aucun nouvel héritage RBAC n'a été créé. + * Donner à un utilisateur l'accès à une Organisation entière lui donne toujours accès à tous les Actifs contenus dans cette Organisation (comme pour les Types de produit). + * Donner à un utilisateur l'accès à un seul Actif ne lui donne pas accès aux Actifs parents ou enfants associés, ni à l'Organisation. +* Il n'y a pas de limite au nombre de relations Parent/Enfant qui peuvent être créées. En théorie, vous pourriez représenter l'intégralité de la structure de répertoires d'un dépôt à l'aide d'Actifs distincts si vous le souhaitiez. +* Les relations cycliques ne sont pas autorisées : un Actif parent ne peut pas être l'enfant de l'un de ses Actifs enfants. diff --git a/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.ja.md b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.ja.md new file mode 100644 index 00000000000..619c8ce4019 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.ja.md @@ -0,0 +1,149 @@ +--- +title: アセット階層 +description: DefectDojo Pro - 製品階層の刷新 +audience: pro +weight: 1 +aliases: +- /ja/en/working_with_findings/organizing_engagements_tests/pro_assets_organizations +- /ja/asset_modelling/pro_hierarchy/assets_organizations +--- + +DefectDojo Proは、データモデルの柔軟性を高めるために、製品/製品タイプのオブジェクトクラスを拡張しています。 + +## Enabling the Hierarchy Feature + +以下の2つの要素は別個のものであり、それぞれ異なる方法で制御されます。 + +### Asset Hierarchy + +**アセット階層**は、アセット間の親子関係を可能にします。この階層は、ナビゲーションの**製品**タブから表示および管理できます。 + +アセット階層は一般提供されており、クラウド版・オンプレミス版を問わずすべてのインスタンスで有効になっています。特に有効化する操作は不要で、Feature Flagsページにも表示されなくなりました。 + +### Label Changes (optional) + +**ラベル変更**は、UI全体で"Product Type"を"Organization"に、"Product"を"Asset"に名称変更します。これは階層機能の有効化とは別の手順であり、同時に行うことも、後から行うこともできます。 + +ラベル変更は、3.0以降デフォルトで有効になっています。アプリケーションの異なる部分をカバーする、2つの制御があります: + +* **Pro UI**(デフォルトのUI): スーパーユーザーが、クラウド版・オンプレミス版の両方のインスタンスで**Settings > Feature Flags**の"Organization / Asset Relabeling"を切り替えます。新しいラベルは次回のページ読み込み時に表示されます。[Feature Flags](/admin/feature_flags/pro__feature_flags/)を参照してください。 +* **クラシックUIのページと生成されるレポート**: これらのラベルとURLは、DefectDojoの起動時に読み込まれる`DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`デプロイメント設定によって決まります。オンプレミスの場合は、この設定を行いDefectDojoを再起動してください。[DefectDojo Pro (Cloud)](/get_started/pro/cloud/)の場合は、インスタンスのURLを添えて[support@defectdojo.com](mailto:support@defectdojo.com)までメールでお問い合わせください。 + +どちらもデフォルトで有効になっており、Feature Flagsの値はデプロイメント設定から初期値が設定されているため、どちらか一方を変更しない限り両者は一致します。Pro UIに加えてクラシックUIも使用している場合は、両者を同期させた状態に保ってください。 + +ラベル変更は見た目のみの変更である点に注意してください。APIエンドポイントとフィールド名は変更されないため、既存の自動化処理はそのまま動作し続けます。 + +## Significant Changes + +* **製品タイプ**は"Organizations"に、**製品**は"Assets"に名称変更されました。3.0以降、この名称変更はデフォルトで有効です。これを無効にする方法については[Label Changes](#label-changes-optional)を参照してください。 +* **アセット**は、Organizationのコンポーネントをさらに細かく分類するために、互いに親子関係を持てるようになりました。 + +### Organizations + +製品タイプと同様に、**Organizations**はトップレベルのカテゴリーとして理解してください。これを使用して、自社のコアとなるソフトウェアアプリケーション、部門、または事業機能を分割できます。 + +例えば、複数のリポジトリのグループ化のためにOrganizationを作成できます。"Core Application"、"Infrastructure"、"DevOps"、"Analytics"、"SDK"はいずれも複数のコードリポジトリを含むことができます。 + +レポート作成の観点では、1つのOrganizationを複数の文書に分割するよりも、複数のOrganizationを1つの文書にまとめる方が容易であることに留意してください。そのため、チームのレポートに適した粒度で、できるだけ細かい単位でOrganizationを設定することを推奨します。例えば、ある事業部門内の個々の部署ごとにレポートを作成する予定であれば、その事業部門全体を1つのOrganizationとして表す必要はありません。 + +### Assets + +AssetはOrganizationのサブディビジョンを表すためのものです。ただし、Productとは異なり、Assetは入れ子構造にでき、互いに親子関係を持つことができます。 + +## Asset Nesting Examples + +### Asset-Level Branch Representation + +開発ブランチやフィーチャーブランチは、さまざまな方法で表現できます。個別のエンゲージメントやテストを使う方法は、Production、Dev、その他のフィーチャーブランチの違いを表現する既存の手段です。 + +これらは、入れ子になったAssetを使って表現することもできます。次のAssetツリーを考えてみましょう: + +``` +Core Application [Organization] +└── webapp-frontend + ├── webapp-frontend/prod + └── webapp-frontend/dev + ├── webapp-frontend/dev/feature-a + └── webapp-frontend/dev/feature-b +``` + +この環境では、各ブランチ(`prod`、`dev`、`feature a`、`feature b`)は、他のAssetから分離された独自のエンゲージメントとテストを持つことができ、互いに重複排除されることがありません。また、Assetの名前をGit上のパスに直接対応させることができるため、ナビゲーションも容易になります。 + +### Mono-Repo: Separate Components + +すべてのコードに単一のリポジトリを使用しているものの、そのリポジトリ内の各ディレクトリに異なるチームが貢献している場合、その構造を表現するためにAssetの入れ子構造を設定できます。 + +``` +Core Application [Organization] +├── webapp-frontend [Parent Asset] +│ ├── mobile-ios +│ ├── mobile-android +│ └── mobile-sdk +├── webapp-backend [Parent Asset] +│ ├── database +│ └── api +└── infra [Parent Asset] + ├── docker + ├── kubernetes + └── nginx +``` + +この図では、"Core Application"配下のすべての要素を、独自のビジネス重要度(参照: [Priority & Risk](/asset_modelling/pro_hierarchy/priority_sla/#prioritization-engines))、RBAC、および対応するエンゲージメントとテストを持つ個別のAssetとして記録できます。親のAsset(例: `webapp-backend`)に対して引き続きテストを実施し、結果を保存することもできますが、特定の子Asset(例: `database`)に対して独立したテストを実行することもできます。 + +### Pen Tests: Isolated RBAC + +単一のアセット内にペンテストの結果を保存したいものの、テスターにアセットのデータを閲覧させたくない場合は、各テストグループが結果をアップロードするための子アセットを作成できます。 + +``` +Core Application [Organization] +└── webapp-frontend [Parent Asset] + ├── Pen Test Group A + └── Pen Test Group B +``` + +重要な点として、ユーザーに単一の子Asset(例: `Pen Test Group A`)へのRBACアクセス権を付与しても、他の子Asset(例: `Pen Test Group B`)の検出事項を閲覧することはできず、親Asset(`webapp-frontend`)の検出事項を閲覧することもできません。 + +親Assetには、CI/CDの結果、内部テスト、履歴データ、その他の第三者に知られたくない検出事項データを表すエンゲージメントを含めることができます。特定のテスト結果用に子Assetを作成することで、社内チームは親Assetの状態と組み合わせてそれらの結果をレポートできます。 + +## Visualizing Assets - Hierarchy + +DefectDojoでは、メニューのAsset Hierarchyオプションを使用して、Assetの構造を可視化したり、関係性を変更したりできます。 + +![image](images/asset_hierarchy.png) + +Asset Hierarchyを開くと、フィルタリング可能なすべてのAssetのテーブルが表示されます。このテーブルから1つ以上のAssetを選択すると、階層図がレンダリングされます。 + +![image](images/asset_hierarchy_diagram.png) + +### Diagram navigation + +階層図の左上にあるアイコンで、ズームイン・ズームアウトができます。この図をクリックしてドラッグすると、図内をスクロールできます。 + +各Assetはこの図内で1つのノードとしてレンダリングされ、表示のために自由に移動させることができます。 + +Asset同士は、ノード間の関係の種類を表すラベル付きのパスで接続されます。現在サポートされているラベルは`parent`のみです。 + +### Exploring Asset nodes + +各Assetノードは、青いボタンをクリックすることで操作できます。これらのボタンは、ノードをクリックしてAssetノードが選択されている場合にのみ表示されます。 + +![image](images/asset_hierarchy_node.png) + +* 👁️ (eyeball icon) は、対応するAsset View(以前はProduct Viewと呼ばれていました)に直接移動します。 +* ✏️ (pencil icon) は、Edit Assetフォーム(以前はEdit Productフォームと呼ばれていました)を含むモーダルを開きます。 +* ➕ (plus icon) は、このAssetに新しい子Assetを追加できるようにします。追加先のAssetは現在図に表示されている必要はありませんが、同じOrganizationに属している必要があります。 +* ✥ (four-arrows icon) は、現在選択されているAssetの親Assetを変更できるようにします。 +* 🗑️ (trash can icon) は、Assetの親関係を削除できるようにします。このアイコンは、Assetにすでに親が設定されている場合にのみ表示されます。 + +図に、未選択の親Assetを持つAssetが表示されている場合は、Load Moreボタンをクリックすることで、その親Asset(および親Assetの子)を図に追加できます。 + +![image](images/assets_loadmore.png) + +## Notes + +* 重複排除の範囲は変更されていない点に注意してください。Assetは自身の内部でのみ検出事項を重複排除し、Parent/Child関係の有無にかかわらず、他のAssetの検出事項は考慮しません。 +* RBACの範囲はこのシステムにおいて変更されていません。権限の割り当てにおいて、各Assetは引き続き個別のオブジェクトとして扱われます。新しいRBACの継承は作成されていません。 + * ユーザーにOrganization全体へのアクセス権を付与すると、そのOrganizationに含まれるすべてのAssetへのアクセス権も引き続き付与されます(製品タイプの場合と同様です)。 + * ユーザーに単一のAssetへのアクセス権を付与しても、関連する親または子のAssetへのアクセス権や、Organizationへのアクセス権は付与されません。 +* 作成できるParent/Child関係の数に制限はありません。理論上は、リポジトリのディレクトリ構造全体を、望むのであれば個別のAssetとして表現することも可能です。 +* 循環関係は許可されていません。親Assetは、自身の子Assetの子になることはできません。 diff --git a/docs/content/asset_modelling/PRO_hierarchy/priority_sla.de.md b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.de.md new file mode 100644 index 00000000000..33d264adbc9 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.de.md @@ -0,0 +1,268 @@ +--- +title: Priority, Risk und SLAs zuweisen +description: Wie DefectDojo Ihre Befunde einstuft +weight: 1 +audience: pro +aliases: +- /de/en/working_with_findings/finding_priority +- /de/en/working_with_findings/priority_adjustments +--- + +![image](images/pro_finding_priority.png) + +Effektives risikobasiertes Schwachstellenmanagement erfordert einen Ansatz, der sowohl den geschäftlichen Kontext als auch die technische Ausnutzbarkeit berücksichtigt. Mit der Priority- und Risk-Funktion von DefectDojo Pro können Benutzer Befunde automatisch in einen aussagekräftigen Kontext einordnen, sodass Schwachstellen mit hoher Auswirkung zuerst behandelt werden können. + +**Priority** ist ein berechneter numerischer Rang, der auf alle Befunde in Ihrer DefectDojo-Instanz angewendet wird. Er ermöglicht es Ihnen, Schwachstellen schnell im Kontext zu verstehen, besonders in großen Organisationen, die die Sicherheitsanforderungen für viele Befunde und/oder Produkte überwachen. + +**Risk** ist ein vierstufiges Bewertungssystem, das die Ausnutzbarkeit eines Befunds stärker berücksichtigt. Es ist als weniger granulare, eher „führungsebenengerechte" Version von Priority gedacht. + +![image](images/pro_risk_example.png) + +Priority- und Risk-Werte können zusammen mit anderen Filtern verwendet werden, um Befunde in jedem Kontext zu vergleichen, zum Beispiel: + +* innerhalb eines einzelnen Produkts, Engagements oder Tests +* global über alle DefectDojo-Produkte hinweg +* zwischen einigen bestimmten Produkten + +Die Anwendung von Finding Priority und Risk hilft Ihrem Team, auf die relevantesten Schwachstellen in Ihrer Organisation zu reagieren, und bietet außerdem einen Rahmen zur Unterstützung der Einhaltung gesetzlicher Standards. + + +Erfahren Sie mehr über Priority und Risk in den Office Hours von DefectDojo, Inc. vom Mai 2025: + + + +## Wie Priority & Risk berechnet werden +Der Wertebereich von Priority reicht von 0 bis 1150. Je höher die Zahl, desto dringender muss der +Befund triagiert oder behoben werden. + +Ähnlich wie beim Schweregrad wird Risk von Niedrig -> Mittel -> Maßnahme erforderlich -> Dringend bewertet. **Risk** berücksichtigt Priority-Felder und kann sich daher vom durch ein Tool gemeldeten Schweregrad unterscheiden. + +![image](images/priority-overview.png) + +## Priority-Felder: Produktebene + +Jedes Produkt in DefectDojo verfügt über Metadaten, die die geschäftliche Kritikalität und +Risikofaktoren erfassen. Diese Metadaten werden verwendet, um Priority und Risk für die +zugehörigen Befunde zu berechnen. + +Alle diese Metadatenfelder können im Formular **Edit Product** für ein bestimmtes Produkt festgelegt werden. + +![image](images/priority_edit_product.png) + +* **Criticality** kann auf einen der Werte Keine, Sehr niedrig, Niedrig, Mittel, Hoch oder Sehr +Hoch gesetzt werden. Criticality ist ein subjektives Feld; berücksichtigen Sie bei der Vergabe +daher, wie das Produkt im Vergleich zu anderen Produkten Ihrer Organisation einzuordnen ist. +* **User Records** ist eine numerische Schätzung der Benutzerdatensätze in einer Datenbank (oder +einem System, das auf diese Datenbank zugreifen kann). +* **Revenue** ist eine numerische Schätzung des Jahresumsatzes für das Produkt. Zur Berechnung von Priority ermittelt DefectDojo einen Prozentsatz, indem der Umsatz dieses Produkts mit der Summe aller Produkte innerhalb des Produkttyps verglichen wird. + +Es ist in DefectDojo nicht möglich, eine Währung festzulegen. Stellen Sie daher sicher, dass alle Ihre Revenue- +Schätzungen dieselbe Währungseinheit verwenden. („50000" könnte 50.000 US-Dollar +oder ¥50.000 japanische Yen bedeuten - die Währungseinheit spielt keine Rolle, solange +der Umsatz für alle Ihre Produkte in derselben Währung berechnet wird). +* **External Audience** ist ein Wahr/Falsch-Wert - setzen Sie diesen auf Wahr (True), wenn auf +dieses Produkt von einem externen Publikum zugegriffen werden kann. Zum Beispiel Kunden, Benutzer +oder jeder außerhalb Ihrer Organisation. +* **Internet Accessible** ist ein Wahr/Falsch-Wert. Wenn dieses Produkt eine Verbindung zum offenen +Internet herstellen kann, sollten Sie diesen Wert auf Wahr (True) setzen. + +Priority ist eine „relative" Berechnung, die dazu dient, verschiedene Produkte innerhalb +Ihrer DefectDojo-Instanz zu vergleichen. Letztlich liegt es an Ihrer Organisation zu entscheiden, +wie diese Filter gesetzt werden. Diese Werte sollten so genau wie möglich sein, aber das +primäre Ziel besteht darin, Ihre wichtigsten Produkte hervorzuheben, damit Sie Schwachstellen +gemäß den Richtlinien Ihrer Organisation priorisieren können, sodass diese Felder nicht +unbedingt perfekt gesetzt sein müssen. + +## Priority-Felder: Befund-Ebene + +Befunde innerhalb eines Produkts können über zusätzliche Metadaten verfügen, die die Priority- und Risk-Stufe des Befunds weiter anpassen: + +* Ob der Befund einen **EPSS Score** aufweist oder nicht - dieser wird Befunden automatisch hinzugefügt und für Pro-Benutzer aktuell gehalten. Der **EPSS Score** ist das Feld, das in den Priority Score einfließt — **EPSS Percentile** wird am Befund zu Referenzzwecken erfasst, fließt aber nicht direkt in die Berechnung ein. +* Wie viele Endpunkte im Produkt von diesem Befund betroffen sind +* Ob ein Befund sich In Prüfung befindet +* Ob sich der Befund in der KEV-Datenbank (Known Exploited Vulnerabilities) befindet, die von DefectDojo regelmäßig überprüft wird +* Der vom Tool gemeldete Schweregrad eines Befunds (Info, Niedrig, Mittel, Hoch, Kritisch) + +#### EPSS Score vs. EPSS Percentile + +Zwei Befunde, die bei den sichtbaren Faktoren (Severity, Business Criticality, Internet Accessible, Exploit Available) identisch aussehen, können dennoch unterschiedliche Priority Scores erhalten, wenn sich ihre **EPSS Scores** unterscheiden. Das ist zu erwarten: Der EPSS Score ist ein kontextabhängiger Eingabewert für die Berechnung. + +EPSS Percentile wird am Befund zur Einordnung angezeigt, fließt aber nicht in die Berechnung des Priority Score ein. Wenn Sie zwei Befunde vergleichen möchten, um eine Abweichung im Priority Score zu verstehen, betrachten Sie die EPSS-Score-Werte, nicht die Percentile-Werte. + +Das genaue Gewicht, das EPSS Score (und die anderen Faktoren) in die Berechnung des Priority Score einbringt, wird absichtlich nicht veröffentlicht. Wenn Sie beeinflussen möchten, wie stark sich EPSS Score in Ihrer Umgebung auf die Bewertung auswirkt, passen Sie den Regler **Exploitability** in Ihrer [Prioritization Engine](#prioritization-engines) an. + + +## Finding-Risk-Berechnung + +![image](images/risk_table.png) + +Die Risk-Spalte in einer Befundtabelle ist eine weitere Möglichkeit, Befunde schnell zu priorisieren. Risk wird anhand der Priority-Stufe eines Befunds berechnet, berücksichtigt aber zusätzlich stärker dessen Ausnutzbarkeit. Es ist als weniger granulare, eher „führungsebenengerechte" Version von Priority gedacht. + +Die vier zuweisbaren Risk-Stufen sind: + +![image](images/pro_risk_levels.png) + +Die EPSS-Werte bzw. die Ausnutzbarkeit eines Befunds werden in der Risk-Berechnung wesentlich stärker gewichtet. Dadurch kann ein Befund gleichzeitig eine hohe Priority und einen niedrigen Risk-Wert aufweisen. + +Die Risk-Berechnung selbst kann derzeit nicht direkt angepasst werden. Ist jedoch [Threat Intelligence](/asset_modelling/pro_hierarchy/threat_intelligence/) aktiviert, können Sie mit dem **Actively-Exploited Risk Floor** das Ergebnis für den wichtigsten Fall steuern: Ein Befund, der nachweislich aktiv ausgenutzt wird, wird mindestens auf eine von Ihnen gewählte Risk-Stufe angehoben, statt aufgrund eines niedrigen Basis-Schweregrads in einer niedrigen Stufe zu verbleiben. Standardmäßig ist er auf **Maßnahme erforderlich** gesetzt, und jede Prioritization Engine kann ihn anheben, absenken oder zurücksetzen, um die Untergrenze zu deaktivieren. Siehe [Actively-Exploited Risk Floor](/asset_modelling/pro_hierarchy/threat_intelligence/#the-actively-exploited-risk-floor). + +## Priority Insights Dashboard + +Benutzer können sich mit dem Priority Insights Dashboard einen Überblick auf Führungsebene +über Priority und Risk in ihrer Umgebung verschaffen (Metrics > Priority Insights in der Seitenleiste) + +![image](images/priority_dashboard.png) + +Dieses Dashboard kann gefiltert werden, um bestimmte Produkte oder Zeiträume einzuschließen. Wie +andere Pro-Dashboards kann auch dieses Dashboard aus DefectDojo als PDF exportiert werden, um +schnell einen Bericht zu erstellen. + +## Priority & Risk für die Einhaltung gesetzlicher Vorgaben festlegen + +Dies ist eine nicht abschließende Liste gesetzlicher Standards, die spezifisch Methoden zur +Priorisierung von Schwachstellen vorschreiben: + +* Die Einhaltung von [SOX (Sarbanes-Oxley Act](https://www.sarbanes-oxley-act.com/)) erfordert eine umsatzbasierte Priorisierung für +Systeme, die Finanzdaten betreffen. In DefectDojo kann der Umsatz eines Systems auf Produktebene +eingegeben werden. +* Die Einhaltung von [PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/) erfordert eine Priorisierung anhand von Risikobewertungen und der +Kritikalität für Umgebungen mit Karteninhaberdaten. Business Criticality und External Audience können +auf Produktebene festgelegt werden, während der EPSS-Sync von DefectDojo auf Befundebene den +risikobasierten Ansatz von PCI unterstützt. +* [NIST SP 800-40](https://csrc.nist.gov/pubs/sp/800/40/r4/final) ist ein Leitfaden zur vorbeugenden Wartung, der ausdrücklich eine +Priorisierung von Schwachstellen anhand von geschäftlichen Auswirkungen, Produktkritikalität und +Internetzugänglichkeit fordert. All dies kann auf Produktebene in DefectDojo festgelegt werden. +* Die Einhaltung von Control A.12.6.1 der [ISO 27001/27002](https://www.iso.org/standard/27001) erfordert das Management technischer +Schwachstellen mit einer Priorisierung basierend auf der Risikobewertung. +* [GDPR Article 32](https://gdpr-info.eu/art-32-gdpr/) verlangt risikobasierte Sicherheitsmaßnahmen - User Records und External +Audience auf Produktebene können dabei helfen, Systeme in Ihrer Organisation zu priorisieren, +die personenbezogene Daten verarbeiten. +* Die Einhaltung von [FISMA/FedRAMP](https://help.fedramp.gov/hc/en-us) erfordert eine kontinuierliche Überwachung und risikobasierte Behebung von Schwachstellen. + +Die Priority- und Risk-Berechnungen von DefectDojo Pro können angepasst werden, sodass Sie DefectDojo Pro auf Ihre internen Standards für Finding Priority und Risk zuschneiden können. + +## Prioritization Engines + +Ähnlich wie SLA-Konfigurationen ermöglichen Ihnen Prioritization Engines, die Regeln festzulegen, nach denen Priority und Risk berechnet werden. + +![image](images/priority_default.png) + +DefectDojo wird mit einer integrierten Prioritization Engine ausgeliefert, die auf alle Produkte angewendet wird. Sie können diese Prioritization Engine jedoch bearbeiten, um die Gewichtung der **Befund**- und **Produkt**-Multiplikatoren zu ändern, wodurch angepasst wird, wie Priority und Risk für Befunde zugewiesen werden. + +### Befund-Multiplikatoren + +Acht kontextbezogene Faktoren beeinflussen den Priority Score eines Befunds. Drei davon sind befundspezifisch, die anderen fünf werden anhand des Produkts zugewiesen, das den Befund enthält. + +Sie können Ihre Prioritization Engine anpassen, indem Sie festlegen, wie diese Faktoren in die endgültige Berechnung einfließen. + +![image](images/priority_sliders.png) + +Wählen Sie einen Faktor durch Klicken auf die Schaltfläche aus; über den Regler steuern Sie, mit welchem Prozentsatz dieser Faktor angewendet wird. Während Sie den Regler verschieben, sehen Sie, wie sich die Risk-Schwellenwerte entsprechend ändern. + +#### Multiplikatoren auf Befundebene + +* **Schweregrad** - der Schweregrad eines Befunds +* **Exploitability** - der KEV- und/oder EPSS-Wert eines Befunds +* **Endpunkte** - die Anzahl der einem Befund zugeordneten Endpunkte + +#### Multiplikatoren auf Produktebene + +* **Business Criticality** - die Business Criticality des zugehörigen Produkts (Keine, Sehr niedrig, Niedrig, Mittel, Hoch oder Sehr +Hoch) +* **User Records** - die Anzahl der User Records des zugehörigen Produkts +* **Revenue** - der Umsatz des zugehörigen Produkts, relativ zum Gesamtumsatz des Produkttyps +* **External Audience** - ob das zugehörige Produkt ein externes Publikum hat oder nicht +* **Internet Accessible** - ob das zugehörige Produkt aus dem Internet erreichbar ist oder nicht + +### Risk-Schwellenwerte + +Basierend auf der Abstimmung der Priority Engine empfiehlt DefectDojo automatisch Risk-Schwellenwerte. Diese Schwellenwerte können jedoch ebenfalls angepasst und auf beliebige, von Ihnen als geeignet erachtete Werte gesetzt werden. + +![image](images/risk_threshold.png) + +## Neue Prioritization Engines erstellen + +Sie können mehrere Prioritization Engines verwenden, die jeweils unterschiedlichen Produkten zugewiesen werden können. + +![image](images/priority_engine_new.png) + +Das Erstellen einer neuen Prioritization Engine öffnet das Prioritization-Engine-Formular. Sobald dieses Formular abgeschickt wird, wird eine neue Prioritization Engine zur Tabelle hinzugefügt. + +## Prioritization Engines Produkten zuweisen + +Jedem Produkt kann über das Formular **Edit Product** für dieses Produkt eine aktuell verwendete Prioritization Engine zugeordnet werden. + +![image](images/priority_chooseengine.png) + +Beachten Sie: Wenn die Prioritization Engine eines Produkts geändert oder eine Prioritization Engine aktualisiert wird, ist die Prioritization Engine des Produkts bzw. die Prioritization Engine selbst bis zum Abschluss der Priorisierungsberechnung „Locked" (gesperrt). + +Jedes Produkt in DefectDojo kann über eine eigene Service-Level-Agreement-Konfiguration (SLA) verfügen, die angibt, wie viele Tage Ihrer Organisation zur Behebung oder anderweitigen Bearbeitung eines Befunds zur Verfügung stehen. + +Die SLA kann entweder auf Basis des **[Schweregrads des Befunds](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** oder des **[Finding Risk](/asset_modelling/pro_hierarchy/priority_sla/)** (in DefectDojo Pro) festgelegt werden. + +![image](images/sla_multiple.png) + +SLAs wenden auf einen Befund einen Tage-Countdown an, der auf dem Tag basiert, an dem der Befund in DefectDojo erstellt wurde. Wird ein Befund nicht innerhalb des Countdowns geschlossen (Closed), gilt der Befund als SLA-Verstoß. + +## Arbeiten mit SLAs + +Sie können SLAs nutzen, um die Behebungsrichtlinien Ihrer Organisation abzubilden. Sie können sie außerdem verwenden, um die am längsten aktiven, kritischsten Befunde in Ihrer DefectDojo-Instanz zu priorisieren. + +* Sie können Befundtabellen nach SLA-Tagen sortieren oder filtern. +* SLA-Verstöße können so konfiguriert werden, dass sie [Notifications](/admin/notifications/about_notifications/) an DefectDojo-Benutzer auslösen, die dem zugehörigen Produkt zugewiesen sind. +* In **DefectDojo Pro** wird die SLA-Performance außerdem auf den Metrics-Dashboards [Executive Insights and Remediation](/metrics_reports/pro_metrics/pro__overview/) erfasst. +* Die SLA-Einhaltung kann in **DefectDojo Pro** auch auf einem benutzerdefinierten [Dashboard](/metrics_reports/dashboards/custom-dashboards/) angezeigt werden — zum Beispiel mit einem SLA-Burndown- oder einem gefilterten Count-Widget. + +### Status „Innerhalb der SLA behoben" + +Wird ein Befund erfolgreich vor Ablauf der SLA-Frist behoben (Mitigated), erhält der Befund in der Spalte Mitigated Within SLA ein grünes ✅ Häkchen. + +![image](images/sla_mitigated_within.png) + +Wurde ein Befund behoben (Mitigated), jedoch erst nachdem die SLA verletzt wurde, erhält der Befund in der Spalte Mitigated Within SLA ein rotes ❌ X. + +### SLA-Verstöße + +Wenn die SLA für einen bestimmten Befund verletzt wird (der Befund wird nicht innerhalb der SLA-Frist geschlossen), wechselt das grüne ✅ Häkchen zu einem roten ❌ X. Die SLA wird weiterhin mit einer negativen Zahl verfolgt, die angibt, um wie viele Tage die SLA überschritten wurde. + +![image](images/sla_breached.png) + +## SLA-Konfigurationen verwalten (Pro) + +In DefectDojo Pro werden eine oder mehrere SLA-Konfigurationen unter **Configuration > Service Level Agreements** in der Seitenleiste verwaltet. Sie können ein **New Service Level Agreement** erstellen oder über die Seite **All Service Level Agreements** mit bestehenden SLA-Konfigurationen arbeiten. + +![image](images/pro_sla_risk.png) + +SLA-Konfigurationen können nur von Superusern oder von einem Benutzer mit der entsprechenden [Configuration Permission](/admin/user_management/user_permission_chart/#configuration-permission-chart) bearbeitet werden. + +### SLA konfigurieren + +SLA-Konfigurationen enthalten die Anzahl der Tage, die jedem **Schweregrad**- oder **Risk**-Wert in DefectDojo zugewiesen sind. + +![image](images/pro_new_sla.png) + +Jedes Service Level Agreement kann über einen eindeutigen Namen sowie eine optionale Beschreibung verfügen. + +**Restart SLA on Finding Reactivation**: Ist diese Option aktiviert, beginnt die SLA von Neuem, wenn ein Befund wieder geöffnet (Reopened) wird. Andernfalls basiert die SLA auf dem Erstellungszeitpunkt des Befunds. + +Beim Bearbeiten einer SLA können Sie wählen, ob diese SLA **Schweregrad** oder **Risk** als Maßstab für die Zuweisung von Days To Remediate verwendet. Dies geschieht durch Auswahl der entsprechenden Option im Abschnitt **Service Level configuration Type** des Formulars. + +Von hier aus können Sie die Anzahl der zulässigen Tage für jede **Schweregrad**- oder **Risk**-Stufe festlegen. Sie können SLAs auch selektiv erzwingen; indem Sie **Enforce ___ Finding Days** deaktivieren, können Sie die SLA-Berechnung für diese Schweregrad- oder Risk-Stufen ignorieren. + +## Eine SLA-Konfiguration auf ein Produkt anwenden (Pro) + +Neu erstellte Produkte in DefectDojo wenden immer die **Default SLA Configuration** an, deren Werte Sie bei Bedarf anpassen können. + +Wenn Sie über SLA-Konfigurationen verfügen, können Sie im Formular **Edit Product** auswählen, welche davon auf Ihr Produkt angewendet wird. + +![image](images/pro_sla_product.png) + +### SLA-Neuberechnung + +Sobald für ein Produkt eine neue SLA ausgewählt wurde, müssen die SLAs aller zugehörigen Befunde von DefectDojo neu berechnet werden. Während dieser Vorgang läuft, kann die SLA eines Produkts nicht geändert werden. + +## Hinweise zu SLAs + +* SLAs können optional neu gestartet werden, sobald ein Befund mit dem Status [Risiko akzeptiert](/triage_findings/findings_workflows/pro__risk_acceptance/) reaktiviert wird. Dies wird beim Erstellen der Risikoakzeptanz über das Feld **Restart SLA Expired** festgelegt. +* Das erneute Importieren eines Befunds startet die SLA nicht neu - SLAs werden immer ab dem Zeitpunkt berechnet, an dem ein Befund erstmals erkannt wurde, sofern nicht **Restart SLA on Finding Reactivation** aktiviert ist. +* Der Ablauf einer Risikoakzeptanz oder die Reaktivierung eines geschlossenen (Closed) Befunds sind die einzigen Möglichkeiten, eine SLA für einen bereits erstellten Befund zurückzusetzen oder neu zu berechnen (ohne die SLA-Konfiguration des Produkts zu ändern). diff --git a/docs/content/asset_modelling/PRO_hierarchy/priority_sla.es.md b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.es.md new file mode 100644 index 00000000000..fbc87f0f963 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.es.md @@ -0,0 +1,236 @@ +--- +title: Asignar Prioridad, Riesgo y SLA +description: Cómo DefectDojo clasifica sus Hallazgos +weight: 1 +audience: pro +aliases: +- /es/en/working_with_findings/finding_priority +- /es/en/working_with_findings/priority_adjustments +--- + +![image](images/pro_finding_priority.png) + +Una gestión eficaz de vulnerabilidades basada en riesgo requiere un enfoque que tenga en cuenta tanto el contexto de negocio como la explotabilidad técnica. Con la función de Prioridad y Riesgo de DefectDojo Pro, los usuarios pueden clasificar automáticamente los Hallazgos en un contexto significativo, garantizando que las vulnerabilidades de mayor impacto puedan abordarse primero. + +**Prioridad** es una clasificación numérica calculada que se aplica a todos los Hallazgos de su instancia de DefectDojo. Le permite comprender rápidamente las vulnerabilidades en contexto, especialmente en organizaciones grandes que supervisan las necesidades de seguridad de muchos Hallazgos y/o Productos. + +**Riesgo** es un sistema de clasificación de 4 niveles que tiene en cuenta en mayor medida la explotabilidad de un Hallazgo. Está pensado como una versión menos granular y más 'de nivel ejecutivo' de la Prioridad. + +![image](images/pro_risk_example.png) + +Los valores de Prioridad y Riesgo pueden usarse junto con otros filtros para comparar Hallazgos en cualquier contexto, como por ejemplo: + +* dentro de un único Producto, Compromiso o Test +* de forma global en todos los Productos de DefectDojo +* entre varios Productos específicos + +Aplicar la Prioridad y el Riesgo de los Hallazgos ayuda a su equipo a responder a las vulnerabilidades más relevantes de su organización, además de ofrecer un marco de trabajo que facilita el cumplimiento de normativas regulatorias. + + +Obtenga más información sobre Prioridad y Riesgo con las Office Hours de DefectDojo, Inc. de mayo de 2025: + + + +## Cómo se calculan la Prioridad y el Riesgo +El rango de valores de Prioridad va de 0 a 1150. Cuanto más alto es el número, mayor es la urgencia de triar o remediar el Hallazgo. + +De forma similar a la Severidad, el Riesgo se puntúa de Baja -> Media -> Requiere acción -> Urgente. **Riesgo** tiene en cuenta los campos de Prioridad y, como resultado, puede diferir de la Severidad reportada por una herramienta. + +![image](images/priority-overview.png) + +## Campos de Prioridad: nivel de Producto + +Cada Producto en DefectDojo tiene metadatos que registran la criticidad de negocio y los factores de riesgo. Estos metadatos se utilizan para ayudar a calcular la Prioridad y el Riesgo de los Hallazgos asociados. + +Todos estos campos de metadatos pueden establecerse en el formulario **Editar Producto** de un Producto determinado. + +![image](images/priority_edit_product.png) + +* **Criticidad** puede establecerse en cualquier valor entre Ninguna, Muy baja, Baja, Media, Alta o Muy alta. La Criticidad es un campo subjetivo, así que al asignarlo, tenga en cuenta cómo se compara el Producto con otros Productos de su organización. +* **Registros de usuarios** es una estimación numérica de los registros de usuarios en una base de datos (o en un sistema que pueda acceder a dicha base de datos). +* **Ingresos** es una estimación numérica de los ingresos anuales del Producto. Para calcular la Prioridad, DefectDojo calculará un porcentaje comparando los ingresos de este Producto con la suma de los ingresos de todos los Productos dentro del Tipo de Producto. + +No es posible establecer un tipo de moneda en DefectDojo, así que asegúrese de que todas sus estimaciones de Ingresos usen la misma denominación de moneda. ("50000" podría significar 50.000 dólares estadounidenses o ¥50.000 yenes japoneses - la denominación no importa siempre que todos sus Productos calculen los ingresos en la misma moneda). +* **Audiencia externa** es un valor verdadero/falso - establézcalo en Verdadero si este Producto puede ser accedido por una audiencia externa. Por ejemplo, clientes, usuarios o cualquier persona fuera de su organización. +* **Accesible por Internet** es un valor verdadero/falso. Si este Producto puede conectarse a Internet abierto, debería establecer este valor en Verdadero. + +La Prioridad es un cálculo 'relativo', pensado para comparar diferentes Productos dentro de su instancia de DefectDojo. En última instancia, depende de su organización decidir cómo se configuran estos filtros. Estos valores deben ser lo más precisos posible, pero el objetivo principal es resaltar sus Productos clave para que pueda priorizar las vulnerabilidades según las políticas de su organización, por lo que no es estrictamente necesario que estos campos se configuren de forma perfecta. + +## Campos de Prioridad: nivel de Hallazgo + +Los Hallazgos dentro de un Producto pueden tener metadatos adicionales que ajusten aún más el nivel de Prioridad y Riesgo del Hallazgo: + +* Si el Hallazgo tiene o no una **Puntuación EPSS**, esta se añade automáticamente a los Hallazgos y se mantiene actualizada para los usuarios de Pro. La **Puntuación EPSS** es el campo que contribuye a la Puntuación de Prioridad — el **Percentil EPSS** se registra en el Hallazgo como referencia, pero no alimenta directamente el cálculo. +* Cuántos Endpoints del Producto se ven afectados por este Hallazgo +* Si el Hallazgo está o no En revisión +* Si el Hallazgo está en la base de datos KEV (Known Exploited Vulnerabilities), que DefectDojo comprueba periódicamente +* La Severidad reportada por la herramienta para un Hallazgo (Informativa, Baja, Media, Alta, Crítica) + +#### Puntuación EPSS frente a Percentil EPSS + +Dos Hallazgos que parecen idénticos en los factores visibles (Severidad, Criticidad de negocio, Accesible por Internet, Exploit disponible) pueden acabar con Puntuaciones de Prioridad distintas si sus **Puntuaciones EPSS** difieren. Esto es lo esperado: la Puntuación EPSS es una entrada contextual del cálculo. + +El Percentil EPSS se muestra en el Hallazgo como contexto, pero no se utiliza en el cálculo de la Puntuación de Prioridad. Si necesita comparar dos Hallazgos para entender una diferencia en la Puntuación de Prioridad, fíjese en los valores de Puntuación EPSS, no en los valores de Percentil. + +El peso exacto que tiene la Puntuación EPSS (y los demás factores) en el cálculo de la Puntuación de Prioridad no se publica de forma intencionada. Si necesita influir en cuánto afecta la Puntuación EPSS a la puntuación en su entorno, ajuste el control deslizante de **Explotabilidad** en su [Motor de Priorización](#prioritization-engines). + + +## Cálculo del Riesgo de un Hallazgo + +![image](images/risk_table.png) + +La columna Riesgo en una tabla de Hallazgos es otra forma rápida de priorizar Hallazgos. El Riesgo se calcula a partir del nivel de Prioridad de un Hallazgo, pero además tiene en cuenta en mayor medida la explotabilidad del Hallazgo. Está pensado como una versión menos granular y más 'de nivel ejecutivo' de la Prioridad. + +Los cuatro niveles de Riesgo asignables son: + +![image](images/pro_risk_levels.png) + +El EPSS / la explotabilidad de un Hallazgo tiene mucho más peso en el cálculo del Riesgo. Como resultado, un Hallazgo puede tener a la vez una Prioridad alta y un valor de Riesgo bajo. + +El cálculo del Riesgo en sí mismo no puede ajustarse directamente por el momento. Sin embargo, si la función de [Inteligencia de amenazas](/asset_modelling/pro_hierarchy/threat_intelligence/) está habilitada, el **Piso de Riesgo por Explotación Activa** sí le permite controlar el resultado en el caso que más importa: un Hallazgo confirmado como explotado activamente se eleva como mínimo a la banda de Riesgo que usted elija, en lugar de quedar en una banda baja porque su severidad base es Baja. Viene configurado en **Requiere acción** de forma predeterminada, y cada Motor de Priorización puede subirlo, bajarlo o desactivarlo por completo. Consulte [el Piso de Riesgo por Explotación Activa](/asset_modelling/pro_hierarchy/threat_intelligence/#the-actively-exploited-risk-floor). + +## Panel de Información de Prioridad + +Los usuarios pueden obtener una vista de nivel ejecutivo de la Prioridad y el Riesgo en su entorno usando el Panel de Información de Prioridad (Métricas > Información de Prioridad en la barra lateral) + +![image](images/priority_dashboard.png) + +Este panel puede filtrarse para incluir Productos o rangos de fechas específicos. Al igual que otros paneles de Pro, este panel puede exportarse desde DefectDojo como PDF para generar un informe rápidamente. + +## Configurar Prioridad y Riesgo para el cumplimiento normativo + +Esta es una lista no exhaustiva de normativas que requieren específicamente métodos de priorización de vulnerabilidades: + +* El cumplimiento de [SOX (Sarbanes-Oxley Act](https://www.sarbanes-oxley-act.com/)) exige una priorización basada en ingresos para los sistemas que afectan a los datos financieros. En DefectDojo, los ingresos de un sistema pueden introducirse a nivel de Producto. +* El cumplimiento de [PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/) exige una priorización basada en clasificaciones de riesgo y en la criticidad para los entornos de datos de titulares de tarjetas. La Criticidad de negocio y la Audiencia externa pueden establecerse a nivel de Producto, mientras que la sincronización EPSS a nivel de Hallazgo de DefectDojo respalda el enfoque basado en riesgo de PCI. +* [NIST SP 800-40](https://csrc.nist.gov/pubs/sp/800/40/r4/final) es una guía de mantenimiento preventivo que exige específicamente la priorización de vulnerabilidades en función del impacto de negocio, la criticidad del producto y los factores de accesibilidad por Internet. Todos estos pueden configurarse a nivel de Producto en DefectDojo. +* El cumplimiento del control A.12.6.1 de [ISO 27001/27002](https://www.iso.org/standard/27001) exige la gestión de vulnerabilidades técnicas con una Prioridad basada en la evaluación de riesgos. +* El [Artículo 32 del RGPD](https://gdpr-info.eu/art-32-gdpr/) exige medidas de seguridad basadas en riesgo - los indicadores de registros de usuarios y audiencia externa a nivel de Producto pueden ayudar a priorizar los sistemas de su organización que procesan datos personales. +* El cumplimiento de [FISMA/FedRAMP](https://help.fedramp.gov/hc/en-us) exige monitorización continua y remediación de vulnerabilidades basada en riesgo. + +Los cálculos de Prioridad y Riesgo de DefectDojo Pro pueden ajustarse, lo que le permite adaptar DefectDojo Pro para que coincida con los estándares internos de su organización en materia de Prioridad y Riesgo de Hallazgos. + +## Motores de Priorización + +De forma similar a las configuraciones de SLA, los Motores de Priorización le permiten establecer las reglas que rigen cómo se calculan la Prioridad y el Riesgo. + +![image](images/priority_default.png) + +DefectDojo incluye un Motor de Priorización integrado, que se aplica a todos los Productos. Sin embargo, puede editar este Motor de Priorización para cambiar la ponderación de los multiplicadores de **Hallazgo** y de **Producto**, lo que ajustará cómo se asignan la Prioridad y el Riesgo de los Hallazgos. + +### Multiplicadores de Hallazgo + +Ocho factores contextuales influyen en la Puntuación de Prioridad de un Hallazgo. Tres de ellos son específicos del Hallazgo, y los otros cinco se asignan según el Producto que contiene el Hallazgo. + +Puede ajustar su Motor de Priorización modificando cómo se aplican estos factores al cálculo final. + +![image](images/priority_sliders.png) + +Seleccione un factor haciendo clic en el botón, y este control deslizante le permite controlar el porcentaje con el que se aplica un factor concreto. A medida que ajusta el control deslizante, verá cómo cambian los umbrales de Riesgo como resultado. + +#### Multiplicadores a nivel de Hallazgo + +* **Severidad** - el nivel de Severidad de un Hallazgo +* **Explotabilidad** - la puntuación KEV y/o EPSS de un Hallazgo +* **Endpoints** - la cantidad de Endpoints asociados a un Hallazgo + +#### Multiplicadores a nivel de Producto + +* **Criticidad de negocio** - la Criticidad de negocio del Producto relacionado (Ninguna, Muy baja, Baja, Media, Alta o Muy alta) +* **Registros de usuarios** - el recuento de Registros de usuarios del Producto relacionado +* **Ingresos** - los ingresos del Producto relacionado, en relación con los ingresos totales del Tipo de Producto +* **Audiencia externa** - si el Producto relacionado tiene o no una audiencia externa +* **Accesible por Internet** - si el Producto relacionado es o no accesible por Internet + +### Umbrales de Riesgo + +Según el ajuste del Motor de Prioridad, DefectDojo recomendará automáticamente Umbrales de Riesgo. Sin embargo, estos umbrales también pueden ajustarse y establecerse en los valores que considere apropiados. + +![image](images/risk_threshold.png) + +## Crear nuevos Motores de Priorización + +Puede utilizar varios Motores de Priorización, cada uno de los cuales puede asignarse a Productos distintos. + +![image](images/priority_engine_new.png) + +Al crear un nuevo Motor de Priorización se abrirá el formulario del Motor de Priorización. Una vez enviado este formulario, se añadirá un nuevo Motor de Priorización a la tabla. + +## Asignar Motores de Priorización a Productos + +Cada Producto puede tener un Motor de Priorización en uso actualmente a través del formulario **Editar Producto** de un Producto determinado. + +![image](images/priority_chooseengine.png) + +Tenga en cuenta que cuando se cambia el Motor de Priorización de un Producto, o se actualiza un Motor de Priorización, el Motor de Priorización del Producto o el propio Motor de Priorización quedará "Bloqueado" hasta que se complete el cálculo de priorización. + +Cada Producto en DefectDojo puede tener su propia configuración de Acuerdo de Nivel de Servicio (SLA), que representa los días de los que dispone su organización para remediar o gestionar de otro modo un Hallazgo. + +El SLA puede establecerse en función de la **[Severidad del Hallazgo](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** o del **[Riesgo del Hallazgo](/asset_modelling/pro_hierarchy/priority_sla/)** (en DefectDojo Pro). + +![image](images/sla_multiple.png) + +Los SLA aplican una cuenta regresiva de días a un Hallazgo a partir del día en que el Hallazgo se creó en DefectDojo. Si un Hallazgo no se Cierra antes de que termine la cuenta regresiva, el Hallazgo se etiquetará como en incumplimiento de SLA. + +## Trabajar con SLA + +Puede usar los SLA como una forma de representar las políticas de remediación de su organización. También puede usarlos como una forma de priorizar los Hallazgos más críticos y con más tiempo activo en su instancia de DefectDojo. + +* Puede ordenar o filtrar las tablas de Hallazgos por días de SLA. +* Las infracciones de SLA pueden configurarse para activar [Notificaciones](/admin/notifications/about_notifications/) a los usuarios de DefectDojo asignados al Producto relacionado. +* En **DefectDojo Pro**, el rendimiento del SLA también se registra en los Paneles de Métricas de [Información Ejecutiva y Remediación](/metrics_reports/pro_metrics/pro__overview/). +* El cumplimiento del SLA también puede mostrarse en un [panel](/metrics_reports/dashboards/custom-dashboards/) personalizado en **DefectDojo Pro** — por ejemplo con un widget de Consumo de SLA (SLA Burndown) o un widget de Conteo filtrado. + +### Estado Mitigado dentro del SLA + +Si un Hallazgo se Mitiga correctamente antes de la fecha límite del SLA, el Hallazgo mostrará una marca de verificación verde ✅ en la columna Mitigado dentro del SLA. + +![image](images/sla_mitigated_within.png) + +Si un Hallazgo se Mitigó, pero no antes de que se incumpliera el SLA, el Hallazgo mostrará una X roja ❌ en la columna Mitigado dentro del SLA. + +### Incumplimiento de SLA + +Cuando se incumple el SLA de un Hallazgo determinado (el Hallazgo no se Cierra dentro del plazo del SLA) la marca de verificación verde ✅ cambiará a una X roja ❌. El SLA seguirá registrándose con un número negativo, para representar cuántos días lleva incumplido el SLA. + +![image](images/sla_breached.png) + +## Gestionar configuraciones de SLA (Pro) + +En DefectDojo Pro, una o más configuraciones de SLA se gestionan en la sección **Configuración > Acuerdos de Nivel de Servicio** de la barra lateral. Puede crear un **Nuevo Acuerdo de Nivel de Servicio** o trabajar con configuraciones de SLA existentes desde la página **Todos los Acuerdos de Nivel de Servicio**. + +![image](images/pro_sla_risk.png) + +Las configuraciones de SLA solo pueden editarlas los Superusuarios o un usuario con el [Permiso de Configuración](/admin/user_management/user_permission_chart/#configuration-permission-chart) correspondiente. + +### Configurar el SLA + +Las configuraciones de SLA contienen los días asignados a cada valor de **Severidad** o **Riesgo** de DefectDojo. + +![image](images/pro_new_sla.png) + +Cada Acuerdo de Nivel de Servicio puede tener un nombre único, junto con una descripción opcional. + +**Reiniciar SLA al reactivar un Hallazgo**: si se habilita, esta opción reiniciará el SLA cuando se Reabra un Hallazgo. De lo contrario, el SLA se basará en la fecha de creación del Hallazgo. + +Al editar un SLA, puede elegir si ese SLA usará la **Severidad** o el **Riesgo** como referencia para asignar los Días para remediar. Esto se hace seleccionando la opción correspondiente en la sección **Tipo de configuración de Nivel de Servicio** del formulario. + +A partir de ahí, puede establecer el número de días permitidos para cada nivel de **Severidad** o **Riesgo**. También puede aplicar los SLA de forma selectiva; al desmarcar **Aplicar días de Hallazgo ___** puede ignorar el cálculo de SLA para esos niveles de Severidad o Riesgo. + +## Aplicar una configuración de SLA a un Producto (Pro) + +Los Productos recién creados en DefectDojo siempre aplicarán la **Configuración de SLA predeterminada**, que puede establecerse con valores distintos si lo desea. + +Si dispone de configuraciones de SLA, puede elegir cuál de ellas se aplica a su Producto desde el formulario **Editar Producto**. + +![image](images/pro_sla_product.png) + +### Recálculo del SLA + +Una vez seleccionado un nuevo SLA para un Producto, DefectDojo deberá recalcular los SLA de todos los Hallazgos asociados. Mientras se ejecuta este proceso, no se puede cambiar el SLA de un Producto. + +## Notas sobre los SLA + +* Los SLA pueden reiniciarse opcionalmente cuando se reactiva un Hallazgo con [Riesgo aceptado](/triage_findings/findings_workflows/pro__risk_acceptance/). Esto se configura al crear la Aceptación de riesgo, estableciendo el campo **Reiniciar SLA al expirar**. +* Reimportar un Hallazgo no reinicia el SLA - los SLA siempre se calculan desde el momento en que se detectó por primera vez un Hallazgo, a menos que esté habilitado **Reiniciar SLA al reactivar un Hallazgo**. +* La expiración de la Aceptación de riesgo o la reactivación de un Hallazgo Cerrado son las únicas formas de reiniciar o recalcular el SLA de un Hallazgo una vez creado (sin cambiar la configuración de SLA del Producto). diff --git a/docs/content/asset_modelling/PRO_hierarchy/priority_sla.fr.md b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.fr.md new file mode 100644 index 00000000000..c705ebda8d5 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.fr.md @@ -0,0 +1,237 @@ +--- +title: Attribuer la priorité, le risque et les SLA +description: Comment DefectDojo classe vos constatations +weight: 1 +audience: pro +aliases: +- /fr/en/working_with_findings/finding_priority +- /fr/en/working_with_findings/priority_adjustments +--- + +![image](images/pro_finding_priority.png) + +Une gestion efficace des vulnérabilités basée sur le risque nécessite une approche qui prend en compte à la fois le contexte métier et l'exploitabilité technique. Grâce à la fonctionnalité Priorité et Risque de DefectDojo Pro, les utilisateurs peuvent trier automatiquement les Constatations selon un contexte pertinent, garantissant que les vulnérabilités à fort impact puissent être traitées en priorité. + +**Priorité** est un rang numérique calculé, appliqué à toutes les Constatations de votre instance DefectDojo. Il vous permet de comprendre rapidement les vulnérabilités dans leur contexte, en particulier au sein de grandes organisations qui supervisent les besoins de sécurité pour de nombreuses Constatations et/ou Produits. + +**Risque** est un système de classement à 4 niveaux qui prend davantage en compte l'exploitabilité d'une Constatation. Il s'agit d'une version moins granulaire, plus « au niveau exécutif », de la Priorité. + +![image](images/pro_risk_example.png) + +Les valeurs de Priorité et de Risque peuvent être utilisées avec d'autres filtres pour comparer les Constatations dans n'importe quel contexte, par exemple : + +* au sein d'un seul Produit, Engagement ou Test +* globalement dans tous les Produits DefectDojo +* entre quelques Produits spécifiques + +L'application de la Priorité et du Risque des Constatations aide votre équipe à répondre aux vulnérabilités les plus pertinentes de votre organisation, et fournit également un cadre pour faciliter la conformité aux normes réglementaires. + + +Pour en savoir plus sur la Priorité et le Risque avec DefectDojo, Inc., consultez les Office Hours de mai 2025 : + + + +## Comment la Priorité et le Risque sont calculés +La plage des valeurs de Priorité va de 0 à 1150. Plus le nombre est élevé, plus la Constatation nécessite un triage ou une remédiation urgente. + +Comme pour la Sévérité, le Risque est noté de Faible -> Moyenne -> Nécessite une action -> Urgent. Le **Risque** prend en compte les champs de Priorité et peut donc différer de la Sévérité rapportée par un outil. + +![image](images/priority-overview.png) + +## Champs de Priorité : niveau Produit + +Chaque Produit dans DefectDojo possède des métadonnées qui suivent la criticité métier et les facteurs de risque. Ces métadonnées sont utilisées pour aider à calculer la Priorité et le Risque des Constatations associées. + +Tous ces champs de métadonnées peuvent être définis dans le formulaire **Modifier le Produit** pour un Produit donné. + +![image](images/priority_edit_product.png) + +* **Criticité** peut être définie sur l'une des valeurs suivantes : Aucune, Très faible, Faible, Moyenne, Élevée ou Très élevée. La Criticité est un champ subjectif ; lors de son attribution, tenez donc compte de la comparaison du Produit avec les autres Produits de votre organisation. +* **Enregistrements utilisateurs** est une estimation numérique du nombre d'enregistrements utilisateurs dans une base de données (ou un système pouvant accéder à cette base de données). +* **Revenu** est une estimation numérique du chiffre d'affaires annuel du Produit. Pour calculer la Priorité, DefectDojo calculera un pourcentage en comparant le revenu de ce Produit à la somme des revenus de tous les Produits du même Type de Produit. + +Il n'est pas possible de définir un type de devise dans DefectDojo, assurez-vous donc que toutes vos estimations de Revenu utilisent la même devise. (« 50000 » peut désigner 50 000 dollars américains ou 50 000 yens japonais - la devise n'a pas d'importance tant que tous vos Produits calculent leur revenu dans la même devise). +* **Audience externe** est une valeur vrai/faux - définissez-la sur Vrai si ce Produit peut être consulté par une audience externe. Par exemple, des clients, des utilisateurs ou toute personne extérieure à votre organisation. +* **Accessible depuis Internet** est une valeur vrai/faux. Si ce Produit peut se connecter à Internet, vous devez définir cette valeur sur Vrai. + +La Priorité est un calcul « relatif », destiné à comparer différents Produits au sein de votre instance DefectDojo. C'est en fin de compte à votre organisation de décider comment ces filtres sont définis. Ces valeurs doivent être aussi précises que possible, mais l'objectif principal est de mettre en évidence vos Produits clés afin de pouvoir prioriser les vulnérabilités selon les politiques de votre organisation, si bien que ces champs n'ont donc pas nécessairement besoin d'être définis parfaitement. + +## Champs de Priorité : niveau Constatation + +Les Constatations d'un Produit peuvent avoir des métadonnées supplémentaires qui peuvent encore ajuster le niveau de Priorité et de Risque de la Constatation : + +* Si la Constatation possède un **Score EPSS** ; celui-ci est ajouté automatiquement aux Constatations et tenu à jour pour les utilisateurs Pro. Le **Score EPSS** est le champ qui contribue au Score de Priorité — le **Percentile EPSS** est suivi sur la Constatation à titre indicatif mais n'alimente pas directement le calcul. +* Le nombre de Points de terminaison du Produit concernés par cette Constatation +* Si la Constatation est en cours de révision (Under Review) +* Si la Constatation figure dans la base KEV (Known Exploited Vulnerabilities), vérifiée régulièrement par DefectDojo +* La Sévérité rapportée par l'outil pour une Constatation (Info, Faible, Moyenne, Élevée, Critique) + +#### Score EPSS et Percentile EPSS + +Deux Constatations qui semblent identiques sur les facteurs visibles (Sévérité, Criticité métier, Accessible depuis Internet, Exploit disponible) peuvent malgré tout obtenir des Scores de Priorité différents si leurs **Scores EPSS** diffèrent. C'est normal : le Score EPSS est une donnée contextuelle du calcul. + +Le Percentile EPSS est affiché sur la Constatation à titre indicatif, mais il n'est pas utilisé dans le calcul du Score de Priorité. Si vous devez comparer deux Constatations pour comprendre un écart de Score de Priorité, examinez les valeurs de Score EPSS, et non les valeurs de Percentile. + +Le poids exact du Score EPSS (et des autres facteurs) dans le calcul du Score de Priorité n'est volontairement pas publié. Si vous devez influencer le poids du Score EPSS dans le calcul de votre environnement, ajustez le curseur **Exploitabilité** dans votre [Moteur de priorisation](#prioritization-engines). + + +## Calcul du Risque d'une Constatation + +![image](images/risk_table.png) + +La colonne Risque d'un tableau de Constatations est un autre moyen de prioriser rapidement les Constatations. Le Risque est calculé à partir du niveau de Priorité d'une Constatation, mais prend également davantage en compte son exploitabilité. Il s'agit d'une version moins granulaire, plus « au niveau exécutif », de la Priorité. + +Les quatre niveaux de Risque attribuables sont : + +![image](images/pro_risk_levels.png) + +L'EPSS / l'exploitabilité d'une Constatation est beaucoup plus mise en avant dans le calcul du Risque. Par conséquent, une Constatation peut avoir à la fois une priorité élevée et une valeur de risque faible. + +Le calcul du Risque lui-même ne peut actuellement pas être ajusté directement. Cependant, si le [Renseignement sur les menaces](/asset_modelling/pro_hierarchy/threat_intelligence/) est activé, le **plancher de Risque pour exploitation active** vous permet de contrôler le résultat pour le cas qui compte le plus : une Constatation confirmée comme étant exploitée en conditions réelles est relevée à au moins la bande de Risque que vous choisissez, plutôt que d'être laissée dans une bande faible en raison de sa sévérité de base Faible. Elle est livrée configurée sur **Nécessite une action**, et chaque Moteur de priorisation peut la relever, l'abaisser ou la désactiver pour couper ce plancher. Voir [le plancher de Risque pour exploitation active](/asset_modelling/pro_hierarchy/threat_intelligence/#the-actively-exploited-risk-floor). + +## Tableau de bord Priority Insights + +Les utilisateurs peuvent avoir une vue de niveau exécutif de la Priorité et du Risque dans leur environnement grâce au Tableau de bord Priority Insights (Métriques > Priority Insights dans la barre latérale) + +![image](images/priority_dashboard.png) + +Ce tableau de bord peut être filtré pour inclure des Produits ou des plages de dates spécifiques. Comme pour les autres tableaux de bord Pro, ce tableau de bord peut être exporté depuis DefectDojo au format PDF pour produire rapidement un rapport. + +## Définir la Priorité et le Risque pour la conformité réglementaire + +Voici une liste non exhaustive de normes réglementaires exigeant spécifiquement des méthodes de priorisation des vulnérabilités : + +* La conformité [SOX (Sarbanes-Oxley Act](https://www.sarbanes-oxley-act.com/)) exige une priorisation basée sur le revenu pour les systèmes impactant les données financières. Dans DefectDojo, le revenu d'un système peut être saisi au niveau du Produit. +* La conformité [PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/) exige une priorisation basée sur les évaluations de risque et la criticité pour les environnements de données des titulaires de cartes. La Criticité métier et l'Audience externe peuvent être définies au niveau du Produit, tandis que la synchronisation EPSS au niveau des Constatations de DefectDojo prend en charge l'approche basée sur le risque de PCI. +* [NIST SP 800-40](https://csrc.nist.gov/pubs/sp/800/40/r4/final) est un guide de maintenance préventive qui préconise spécifiquement une priorisation des vulnérabilités basée sur l'impact métier, la criticité du produit et l'accessibilité depuis Internet. Tous ces facteurs peuvent être définis au niveau du Produit dans DefectDojo. +* La conformité au contrôle A.12.6.1 de l'[ISO 27001/27002](https://www.iso.org/standard/27001) exige la gestion des vulnérabilités techniques avec une Priorité basée sur l'évaluation du risque. +* L'[article 32 du RGPD](https://gdpr-info.eu/art-32-gdpr/) exige des mesures de sécurité basées sur le risque - les enregistrements utilisateurs et les indicateurs d'audience externe au niveau du Produit peuvent aider à prioriser les systèmes de votre organisation qui traitent des données personnelles. +* La conformité [FISMA/FedRAMP](https://help.fedramp.gov/hc/en-us) exige une surveillance continue et une remédiation des vulnérabilités basée sur le risque. + +Les calculs de Priorité et de Risque de DefectDojo Pro peuvent être ajustés, ce qui vous permet d'adapter DefectDojo Pro à vos normes internes de Priorité et de Risque des Constatations. + +## Moteurs de priorisation + +À l'instar des configurations SLA, les Moteurs de priorisation vous permettent de définir les règles régissant le calcul de la Priorité et du Risque. + +![image](images/priority_default.png) + +DefectDojo est livré avec un Moteur de priorisation intégré, appliqué à tous les Produits. Vous pouvez toutefois modifier ce Moteur de priorisation pour changer la pondération des multiplicateurs **Constatation** et **Produit**, ce qui ajustera la façon dont la Priorité et le Risque des Constatations sont attribués. + +### Multiplicateurs de Constatation + +Huit facteurs contextuels influencent le Score de Priorité d'une Constatation. Trois d'entre eux sont propres à la Constatation, et les cinq autres sont attribués en fonction du Produit qui contient la Constatation. + +Vous pouvez ajuster votre Moteur de priorisation en modifiant la façon dont ces facteurs sont appliqués au calcul final. + +![image](images/priority_sliders.png) + +Sélectionnez un facteur en cliquant sur le bouton, puis ce curseur vous permet de contrôler le pourcentage d'application d'un facteur donné. Au fur et à mesure que vous ajustez le curseur, vous verrez les seuils de Risque changer en conséquence. + +#### Multiplicateurs au niveau Constatation + +* **Sévérité** - le niveau de Sévérité d'une Constatation +* **Exploitabilité** - le score KEV et/ou EPSS d'une Constatation +* **Points de terminaison** - le nombre de Points de terminaison associés à une Constatation + +#### Multiplicateurs au niveau Produit + +* **Criticité métier** - la Criticité métier du Produit associé (Aucune, Très faible, Faible, Moyenne, Élevée ou Très +élevée) +* **Enregistrements utilisateurs** - le nombre d'Enregistrements utilisateurs du Produit associé +* **Revenu** - le revenu du Produit associé, relatif au revenu total du Type de Produit +* **Audience externe** - si le Produit associé possède ou non une audience externe +* **Accessible depuis Internet** - si le Produit associé est accessible depuis Internet ou non + +### Seuils de Risque + +En fonction du réglage du Moteur de priorisation, DefectDojo recommandera automatiquement des Seuils de Risque. Ces seuils peuvent toutefois également être ajustés et définis selon les valeurs que vous jugez appropriées. + +![image](images/risk_threshold.png) + +## Créer de nouveaux Moteurs de priorisation + +Vous pouvez utiliser plusieurs Moteurs de priorisation, chacun pouvant être attribué à différents Produits. + +![image](images/priority_engine_new.png) + +La création d'un nouveau Moteur de priorisation ouvrira le formulaire du Moteur de priorisation. Une fois ce formulaire soumis, un nouveau Moteur de priorisation sera ajouté au tableau. + +## Attribuer des Moteurs de priorisation aux Produits + +Chaque Produit peut avoir un Moteur de priorisation actuellement utilisé, via le formulaire **Modifier le Produit** pour un Produit donné. + +![image](images/priority_chooseengine.png) + +Notez que lorsque le Moteur de priorisation d'un Produit est modifié, ou qu'un Moteur de priorisation est mis à jour, le Moteur de priorisation du Produit ou le Moteur de priorisation lui-même sera « Verrouillé » jusqu'à ce que le calcul de priorisation soit terminé. + +Chaque Produit de DefectDojo peut avoir sa propre configuration d'Accord de niveau de service (SLA), qui représente le nombre de jours dont dispose votre organisation pour remédier ou autrement gérer une Constatation. + +Le SLA peut être défini en fonction de la **[Sévérité de la Constatation](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** ou du **[Risque de la Constatation](/asset_modelling/pro_hierarchy/priority_sla/)** (dans DefectDojo Pro). + +![image](images/sla_multiple.png) + +Les SLA appliquent un compte à rebours de jours à une Constatation, à partir du jour où la Constatation a été créée dans DefectDojo. Si une Constatation n'est pas Fermée avant la fin du compte à rebours, la Constatation sera étiquetée comme étant en violation du SLA. + +## Travailler avec les SLA + +Vous pouvez utiliser les SLA pour représenter les politiques de remédiation de votre organisation. Vous pouvez également les utiliser pour prioriser les Constatations les plus critiques et actives depuis le plus longtemps dans votre instance DefectDojo. + +* Vous pouvez trier ou filtrer les tableaux de Constatations par jours de SLA. +* Les violations de SLA peuvent être configurées pour déclencher des [Notifications](/admin/notifications/about_notifications/) aux utilisateurs DefectDojo affectés au Produit concerné. +* Dans **DefectDojo Pro**, la performance du SLA est également suivie sur les Tableaux de bord Métriques [Informations exécutives et remédiation](/metrics_reports/pro_metrics/pro__overview/). +* La conformité au SLA peut également être affichée sur un [tableau de bord](/metrics_reports/dashboards/custom-dashboards/) personnalisé dans **DefectDojo Pro** — par exemple avec un widget SLA Burndown ou un widget de Comptage filtré. + +### Statut Atténué dans les délais du SLA + +Si une Constatation est Atténuée avec succès avant l'échéance du SLA, la Constatation affichera une coche verte ✅ dans la colonne Atténué dans les délais du SLA. + +![image](images/sla_mitigated_within.png) + +Si une Constatation a été Atténuée, mais pas avant que le SLA ne soit violé, la Constatation affichera un X rouge ❌ dans la colonne Atténué dans les délais du SLA. + +### Violation des SLA + +Lorsqu'un SLA pour une Constatation donnée est violé (la Constatation n'est pas Fermée dans les délais du SLA) la coche verte ✅ se transformera en X rouge ❌. Le SLA continuera d'être suivi avec un nombre négatif, représentant le nombre de jours de dépassement du SLA. + +![image](images/sla_breached.png) + +## Gérer les configurations SLA (Pro) + +Dans DefectDojo Pro, une ou plusieurs configurations SLA sont gérées dans la section **Configuration > Accords de niveau de service** de la barre latérale. Vous pouvez créer un **Nouvel Accord de niveau de service** ou gérer les configurations SLA existantes depuis la page **Tous les Accords de niveau de service**. + +![image](images/pro_sla_risk.png) + +Les configurations SLA ne peuvent être modifiées que par les Superutilisateurs ou par un utilisateur disposant de la [Permission de Configuration](/admin/user_management/user_permission_chart/#configuration-permission-chart) correspondante. + +### Configurer le SLA + +Les configurations SLA contiennent le nombre de jours attribué à chaque valeur de **Sévérité** ou de **Risque** dans DefectDojo. + +![image](images/pro_new_sla.png) + +Chaque Accord de niveau de service peut avoir un nom unique, ainsi qu'une description facultative. + +**Redémarrer le SLA lors de la réactivation d'une Constatation** : si cette option est activée, elle relancera le SLA à zéro lorsqu'une Constatation est Rouverte. Sinon, le SLA sera basé sur la date de création de la Constatation. + +Lors de la modification d'un SLA, vous pouvez choisir si ce SLA utilisera la **Sévérité** ou le **Risque** comme référence pour attribuer le nombre de jours pour remédier. Cela se fait en sélectionnant l'option correspondante dans la section **Type de configuration du niveau de service** du formulaire. + +À partir de là, vous pouvez définir le nombre de jours autorisés pour chaque niveau de **Sévérité** ou de **Risque**. Vous pouvez également appliquer les SLA de manière sélective ; en décochant **Appliquer les jours de Constatation ___**, vous pouvez ignorer le calcul du SLA pour ces niveaux de Sévérité ou de Risque. + +## Appliquer une configuration SLA à un Produit (Pro) + +Les Produits nouvellement créés dans DefectDojo appliqueront toujours la **Configuration SLA par défaut**, qui peut être définie avec des valeurs différentes si vous le souhaitez. + +Si vous disposez de configurations SLA, vous pouvez choisir laquelle appliquer à votre Produit depuis le formulaire **Modifier le Produit**. + +![image](images/pro_sla_product.png) + +### Recalcul du SLA + +Une fois qu'un nouveau SLA a été sélectionné pour un Produit, le SLA de toutes les Constatations associées devra être recalculé par DefectDojo. Pendant l'exécution de ce processus, le SLA d'un Produit ne peut pas être modifié. + +## Remarques sur les SLA + +* Les SLA peuvent être facultativement redémarrés une fois qu'une Constatation en [Risque accepté](/triage_findings/findings_workflows/pro__risk_acceptance/) est réactivée. Cela se configure lors de la création de l'Acceptation du risque en activant le champ **Redémarrer si le SLA a expiré**. +* La réimportation d'une Constatation ne redémarre pas le SLA - les SLA sont toujours calculés à partir de la première détection d'une Constatation, sauf si **Redémarrer le SLA lors de la réactivation d'une Constatation** est activé. +* L'expiration de l'Acceptation du risque ou la réactivation d'une Constatation Fermée sont les seuls moyens de réinitialiser ou de recalculer un SLA pour une Constatation une fois celle-ci créée (sans modifier la configuration SLA du Produit). diff --git a/docs/content/asset_modelling/PRO_hierarchy/priority_sla.ja.md b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.ja.md new file mode 100644 index 00000000000..00ccf315b84 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.ja.md @@ -0,0 +1,236 @@ +--- +title: PriorityとRiskおよびSLAの割り当て +description: DefectDojoが検出事項をどのようにランク付けするか +weight: 1 +audience: pro +aliases: +- /ja/en/working_with_findings/finding_priority +- /ja/en/working_with_findings/priority_adjustments +--- + +![image](images/pro_finding_priority.png) + +効果的なリスクベースの脆弱性管理には、ビジネスコンテキストと技術的な悪用可能性の両方を考慮したアプローチが必要です。DefectDojo ProのPriorityおよびRisk機能を使用すると、ユーザーは検出事項を意味のあるコンテキストへ自動的に分類し、影響度の高い脆弱性を優先的に対応できるようになります。 + +**Priority**は、DefectDojoインスタンス内のすべての検出事項に適用される、算出された数値ランクです。特に多数の検出事項や製品のセキュリティニーズを統括する大規模な組織において、脆弱性をコンテキストの中で素早く把握できるようにします。 + +**Risk**は、検出事項の悪用可能性をより重視した4段階のランク付けシステムです。これはPriorityよりも粒度が低く、より「経営層向け」のバージョンとして位置付けられています。 + +![image](images/pro_risk_example.png) + +PriorityとRiskの値は、他のフィルタと組み合わせて、あらゆるコンテキストで検出事項を比較するために使用できます。例えば以下のような単位です。 + +* 単一の製品、エンゲージメント、またはテスト内 +* DefectDojoの全製品にわたるグローバルな比較 +* 特定の少数の製品間での比較 + +検出事項のPriorityとRiskを適用することで、チームは組織内で最も重要な脆弱性に対応しやすくなり、また規制標準への準拠を支援するフレームワークにもなります。 + + +PriorityとRiskについて詳しくは、DefectDojo, Inc.の2025年5月のOffice Hoursをご覧ください。 + + + +## PriorityとRiskの計算方法 +Priorityの値の範囲は0から1150です。数値が高いほど、その検出事項のトリアージまたは修復の緊急度が高いことを意味します。 + +深刻度と同様に、Riskは低 -> 中 -> 要対応 -> 緊急の順にスコア化されます。**Risk**はPriorityのフィールドを考慮するため、結果としてツールが報告した深刻度とは異なる場合があります。 + +![image](images/priority-overview.png) + +## Priorityフィールド:製品レベル + +DefectDojoの各製品には、ビジネス上の重要度やリスク要因を追跡するメタデータがあります。このメタデータは、関連する検出事項のPriorityとRiskを計算する際に使用されます。 + +これらのメタデータフィールドはすべて、対象の製品の**製品を編集**フォームで設定できます。 + +![image](images/priority_edit_product.png) + +* **Criticality(重要度)**には、なし、非常に低い、低い、中程度、高い、非常に高いのいずれかの値を設定できます。Criticalityは主観的なフィールドであるため、この値を設定する際は、組織内の他の製品と比較してどうかを考慮してください。 +* **User Records(ユーザーレコード)**は、データベース(またはそのデータベースにアクセスできるシステム)内のユーザーレコード数を数値で見積もったものです。 +* **Revenue(収益)**は、その製品の年間収益を数値で見積もったものです。Priorityを計算するために、DefectDojoはこの製品の収益を、同じ製品タイプ内のすべての製品の合計収益と比較してパーセンテージを算出します。 + +DefectDojoでは通貨タイプを設定できないため、Revenueの見積もりはすべて同じ通貨単位で統一してください。(「50000」は50,000米ドルを意味する場合もあれば、50,000円を意味する場合もあります。すべての製品の収益が同じ通貨で計算されている限り、単位が何であるかは問題になりません。) +* **External Audience(外部利用者)**はtrue/falseの値です。この製品が顧客、ユーザー、または組織外の誰かなど、外部の利用者からアクセスされる場合はTrueに設定してください。 +* **Internet Accessible(インターネットからアクセス可能)**はtrue/falseの値です。この製品がオープンなインターネットに接続できる場合は、この値をTrueに設定してください。 + +Priorityは「相対的な」計算であり、DefectDojoインスタンス内の異なる製品同士を比較することを目的としています。これらのフィルタをどのように設定するかは、最終的に組織の判断に委ねられます。これらの値はできるだけ正確であることが望ましいですが、主な目的は重要な製品を浮かび上がらせ、組織のポリシーに沿って脆弱性に優先順位を付けられるようにすることなので、これらのフィールドを完璧に設定する必要は必ずしもありません。 + +## Priorityフィールド:検出事項レベル + +製品内の検出事項には、その検出事項のPriorityおよびRiskレベルをさらに調整できる追加のメタデータを持たせることができます。 + +* 検出事項が**EPSSスコア**を持っているかどうか。これはPro利用者向けに検出事項へ自動的に追加され、常に最新の状態に保たれます。Priorityスコアに寄与するフィールドは**EPSSスコア**であり、**EPSSパーセンタイル**は参考として検出事項上に記録されますが、計算に直接反映されるわけではありません。 +* その検出事項の影響を受けるエンドポイントが製品内にいくつあるか +* 検出事項がUnder Review(レビュー中)かどうか +* 検出事項がKEV(Known Exploited Vulnerabilities)データベースに含まれているかどうか。これはDefectDojoが定期的にチェックしています +* ツールが報告した検出事項の深刻度(情報、低、中、高、重大) + +#### EPSSスコア対EPSSパーセンタイル + +可視化される要素(深刻度、Business Criticality、Internet Accessible、Exploit Available)がすべて同じに見える2つの検出事項でも、**EPSSスコア**が異なれば、Priorityスコアが異なる結果になることがあります。これは想定された挙動です。EPSSスコアは計算のコンテキスト入力の1つだからです。 + +EPSSパーセンタイルは参考情報として検出事項に表示されますが、Priorityスコアの計算には使用されません。2つの検出事項を比較してPriorityスコアの差を理解したい場合は、パーセンタイルの値ではなく、EPSSスコアの値を確認してください。 + +EPSSスコア(および他の要因)がPriorityスコアの計算においてどれだけの比重を占めるかについての正確な数値は、意図的に公開されていません。環境内でEPSSスコアがスコアリングに与える影響の大きさを調整したい場合は、[Prioritization Engine](#prioritization-engines)内の**Exploitability**スライダーで調整してください。 + + +## 検出事項のRisk計算 + +![image](images/risk_table.png) + +検出事項テーブルのRisk列は、検出事項に素早く優先順位を付けるためのもう1つの方法です。Riskは検出事項のPriorityレベルを使用して計算されますが、検出事項の悪用可能性をより重視して算出されます。これはPriorityよりも粒度が低く、より「経営層向け」のバージョンとして位置付けられています。 + +割り当て可能な4つのRiskレベルは以下の通りです。 + +![image](images/pro_risk_levels.png) + +Risk計算では、検出事項のEPSS/悪用可能性がはるかに強く重視されます。その結果、検出事項がPriorityは高いのにRiskは低いという状態になることもあります。 + +Risk計算そのものは、現時点では直接調整することはできません。ただし、[Threat Intelligence](/asset_modelling/pro_hierarchy/threat_intelligence/)が有効になっている場合、**Actively-Exploited Risk Floor**によって、最も重要なケースの結果を制御できます。実際に悪用が確認された検出事項は、基本の深刻度がLowであることを理由に低いバンドに留め置かれるのではなく、選択したRiskバンド以上に引き上げられます。デフォルトでは**Needs Action(要対応)**に設定されており、各Prioritization Engineでこれを引き上げたり、引き下げたり、またはクリアしてこのフロアを無効にしたりすることができます。詳細は[Actively-Exploited Risk Floor](/asset_modelling/pro_hierarchy/threat_intelligence/#the-actively-exploited-risk-floor)を参照してください。 + +## Priority Insightsダッシュボード + +ユーザーは、Priority Insightsダッシュボード(サイドバーのMetrics > Priority Insights)を使用して、環境内のPriorityとRiskを経営層向けの視点で把握できます。 + +![image](images/priority_dashboard.png) + +このダッシュボードは、特定の製品や日付範囲でフィルタすることができます。他のProダッシュボードと同様に、このダッシュボードもDefectDojoからPDFとしてエクスポートし、レポートとしてすぐに作成することができます。 + +## 規制コンプライアンスのためのPriorityとRiskの設定 + +以下は、脆弱性の優先順位付け方法を特に要求している規制標準の一部(すべてを網羅したものではありません)です。 + +* [SOX(Sarbanes-Oxley Act)](https://www.sarbanes-oxley-act.com/)への準拠には、財務データに影響を与えるシステムについて収益ベースの優先順位付けが求められます。DefectDojoでは、システムの収益を製品レベルで入力できます。 +* [PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/)への準拠には、リスク評価とカード会員データ環境に対する重要度に基づく優先順位付けが求められます。Business CriticalityとExternal Audienceは製品レベルで設定でき、また検出事項レベルのDefectDojoのEPSS同期がPCIのリスクベースのアプローチをサポートします。 +* [NIST SP 800-40](https://csrc.nist.gov/pubs/sp/800/40/r4/final)は予防保守のガイドであり、ビジネスへの影響、製品の重要度、インターネットからのアクセス可能性の要因に基づく脆弱性の優先順位付けを特に求めています。これらはすべてDefectDojoの製品レベルで設定できます。 +* [ISO 27001/27002](https://www.iso.org/standard/27001)の管理策A.12.6.1への準拠には、リスク評価に基づくPriorityによる技術的脆弱性の管理が求められます。 +* [GDPR第32条](https://gdpr-info.eu/art-32-gdpr/)はリスクベースのセキュリティ対策を求めています。製品レベルのユーザーレコードとExternal Audienceフラグは、個人データを処理する組織内のシステムに優先順位を付ける際に役立ちます。 +* [FISMA/FedRAMP](https://help.fedramp.gov/hc/en-us)への準拠には、継続的な監視とリスクベースの脆弱性修復が求められます。 + +DefectDojo ProのPriorityおよびRiskの計算は調整可能であり、検出事項のPriorityとRiskに関する組織内の基準に合わせてDefectDojo Proをカスタマイズできます。 + +## Prioritization Engine + +SLA構成と同様に、Prioritization Engineを使用すると、PriorityとRiskの計算方法を管理するルールを設定できます。 + +![image](images/priority_default.png) + +DefectDojoにはすべての製品に適用される組み込みのPrioritization Engineが用意されています。ただし、このPrioritization Engineを編集して**Finding(検出事項)**と**Product(製品)**の乗数の重み付けを変更することで、検出事項のPriorityとRiskの割り当て方を調整できます。 + +### 検出事項の乗数 + +検出事項のPriorityスコアには8つのコンテキスト要因が影響します。このうち3つは検出事項固有のものであり、残りの5つは検出事項が属する製品に基づいて割り当てられます。 + +これらの要因が最終的な計算にどのように反映されるかを調整することで、Prioritization Engineをチューニングできます。 + +![image](images/priority_sliders.png) + +ボタンをクリックして要因を選択し、スライダーを調整することで、特定の要因が適用される割合を制御できます。スライダーを調整すると、それに応じてRiskのしきい値が変化する様子を確認できます。 + +#### 検出事項レベルの乗数 + +* **Severity(深刻度)** - 検出事項の深刻度レベル +* **Exploitability(悪用可能性)** - 検出事項のKEVおよび/またはEPSSスコア +* **Endpoints(エンドポイント)** - 検出事項に関連付けられたエンドポイントの数 + +#### 製品レベルの乗数 + +* **Business Criticality(ビジネス重要度)** - 関連する製品のBusiness Criticality(なし、非常に低い、低い、中程度、高い、非常に高い) +* **User Records(ユーザーレコード)** - 関連する製品のUser Records数 +* **Revenue(収益)** - 関連する製品の収益。製品タイプ全体の収益合計に対する相対値 +* **External Audience(外部利用者)** - 関連する製品に外部利用者がいるかどうか +* **Internet Accessible(インターネットからアクセス可能)** - 関連する製品がインターネットからアクセス可能かどうか + +### Riskのしきい値 + +Priority Engineのチューニング内容に基づき、DefectDojoはRiskのしきい値を自動的に推奨します。ただし、このしきい値も調整可能であり、適切と判断する任意の値に設定できます。 + +![image](images/risk_threshold.png) + +## 新しいPrioritization Engineの作成 + +複数のPrioritization Engineを使用し、それぞれを異なる製品に割り当てることができます。 + +![image](images/priority_engine_new.png) + +新しいPrioritization Engineを作成すると、Prioritization Engineフォームが開きます。このフォームを送信すると、新しいPrioritization Engineがテーブルに追加されます。 + +## 製品へのPrioritization Engineの割り当て + +各製品には、対象の製品の**製品を編集**フォームから、現在使用中のPrioritization Engineを設定できます。 + +![image](images/priority_chooseengine.png) + +製品のPrioritization Engineが変更された場合、またはPrioritization Engine自体が更新された場合、優先順位付けの計算が完了するまで、その製品のPrioritization EngineまたはPrioritization Engine自体が「ロック」される点に注意してください。 + +DefectDojoの各製品は、組織が検出事項を修復またはその他の方法で対応するために要する日数を表す、独自のService Level Agreement(SLA)構成を持つことができます。 + +SLAは、**[検出事項の深刻度](/asset_modelling/os_hierarchy/product_hierarchy/#findings)**または(DefectDojo Proでは)**[検出事項のRisk](/asset_modelling/pro_hierarchy/priority_sla/)**のいずれかに基づいて設定できます。 + +![image](images/sla_multiple.png) + +SLAは、検出事項がDefectDojo上で作成された日を起点として日数のカウントダウンを検出事項に適用します。カウントダウン期間内に検出事項がClosed(クローズ)にならない場合、その検出事項はSLA違反としてラベル付けされます。 + +## SLAの活用 + +SLAは組織の修復ポリシーを表す手段として利用できます。また、DefectDojoインスタンス内で最も長くアクティブな状態にある、最も重大な検出事項に優先順位を付ける手段としても利用できます。 + +* 検出事項テーブルをSLAの日数でソートまたはフィルタできます。 +* SLA違反が発生した際に、関連する製品に割り当てられたDefectDojoユーザーへ[通知](/admin/notifications/about_notifications/)をトリガーするよう設定できます。 +* **DefectDojo Pro**では、SLAのパフォーマンスも[Executive InsightsおよびRemediation](/metrics_reports/pro_metrics/pro__overview/)のMetricsダッシュボードで追跡されます。 +* **DefectDojo Pro**では、SLAコンプライアンスをカスタム[ダッシュボード](/metrics_reports/dashboards/custom-dashboards/)上に表示することもできます。例えば、SLA BurndownウィジェットやフィルタされたCountウィジェットなどです。 + +### Mitigated Within SLAステータス + +検出事項がSLAの期限内に正常にMitigated(緩和済み)になった場合、その検出事項のMitigated Within SLA列に✅の緑のチェックマークが記録されます。 + +![image](images/sla_mitigated_within.png) + +検出事項がMitigatedになったものの、それがSLA違反の前でなかった場合、その検出事項のMitigated Within SLA列に❌の赤いXが記録されます。 + +### SLA違反 + +特定の検出事項に対するSLAが違反された場合(SLAの期間内に検出事項がClosedにならなかった場合)、✅の緑のチェックが❌の赤いXに切り替わります。SLAはその後もマイナスの数値で追跡が続けられ、SLAが何日違反されているかを表します。 + +![image](images/sla_breached.png) + +## SLA構成の管理(Pro) + +DefectDojo Proでは、1つ以上のSLA構成がサイドバーの**Configuration > Service Level Agreements**部分で管理されます。**All Service Level Agreements**ページから、**New Service Level Agreement**を作成したり、既存のSLA構成を編集したりできます。 + +![image](images/pro_sla_risk.png) + +SLA構成は、Superuser、またはそれに相当する[Configuration Permission](/admin/user_management/user_permission_chart/#configuration-permission-chart)を持つユーザーのみが編集できます。 + +### SLAの構成 + +SLA構成には、DefectDojoの各**Severity(深刻度)**または**Risk**値に割り当てられた日数が含まれます。 + +![image](images/pro_new_sla.png) + +各Service Level Agreementには、一意の名前と、任意の説明を設定できます。 + +**Restart SLA on Finding Reactivation**:このオプションを有効にすると、検出事項がReopened(再オープン)された際にSLAが最初からやり直されます。無効の場合、SLAは検出事項が作成された時点を基準にします。 + +SLAを編集する際、Days To Remediate(修復までの日数)を割り当てる基準として、そのSLAが**Severity(深刻度)**と**Risk**のどちらを使用するかを選択できます。これはフォームの**Service Level configuration Type**セクションから該当のオプションを選択することで設定します。 + +ここから、**Severity**または**Risk**の各レベルに許容される日数を設定できます。また、**Enforce ___ Finding Days**のチェックを外すことで、特定の深刻度またはRiskレベルについてSLA計算を選択的に除外することもできます。 + +## 製品へのSLA構成の適用(Pro) + +DefectDojoで新しく作成された製品には、常に**Default SLA Configuration(デフォルトSLA構成)**が適用されます。これは必要に応じて別の値に設定できます。 + +SLA構成が複数ある場合、**製品を編集**フォームから、どのSLA構成を製品に適用するかを選択できます。 + +![image](images/pro_sla_product.png) + +### SLAの再計算 + +製品に新しいSLAが選択されると、関連するすべての検出事項のSLAはDefectDojoによって再計算される必要があります。この処理が実行されている間、その製品のSLAを変更することはできません。 + +## SLAに関する注意事項 + +* [Risk Accepted(リスク受容済み)](/triage_findings/findings_workflows/pro__risk_acceptance/)の検出事項が再アクティブ化された際、SLAを任意で再開させることができます。これはRisk Acceptanceを作成する際に**Restart SLA Expired**フィールドを設定することで指定します。 +* 検出事項をReimport(再インポート)してもSLAは再開されません。**Restart SLA on Finding Reactivation**が有効になっていない限り、SLAは常に検出事項が最初に検出された時点から計算されます。 +* Risk Acceptanceの期限切れ、またはClosedになった検出事項の再アクティブ化のみが、(製品のSLA構成を変更せずに)検出事項のSLAをリセットまたは再計算する方法です。 diff --git a/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.de.md b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.de.md new file mode 100644 index 00000000000..63977582890 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.de.md @@ -0,0 +1,32 @@ +--- +title: Product Health Grade +description: Wie DefectDojo eine Product Health Grade berechnet +aliases: +- /de/en/working_with_findings/organizing_engagements_tests/product_health_grade +--- + +DefectDojo kann für Ihre Produkte eine Note basierend auf der Anzahl der darin enthaltenen Befunde berechnen. Die Noten reichen von A \- F. + +Beachten Sie, dass nur Aktive \& Verifizierte Befunde zu einer Product Grade beitragen \- nicht verifizierte Befunde haben keinen Einfluss. + +## Berechnung der Product Grade + +Jede Product Grade beginnt bei 100 (ohne Befunde). + +Die Berechnung der Grade beginnt damit, den höchsten **Schweregrad** eines Befunds in einem Produkt zu betrachten und die Product Health auf ein Grundniveau zu reduzieren. + +| **Höchster Schweregrad eines Befunds** | **Maximale Grade** | +| --- | --- | +| **Kritisch** | **40** | +| **Hoch** | **60** | +| **Mittel** | **80** | +| **Niedrig** | **95** | + +Für jeden weiteren Befund werden anschließend zusätzliche Punkte von der Grade abgezogen: + +| **Schweregrad eines weiteren Befunds** | **Grade reduziert um** | +| --- | --- | +| **Kritisch** | **5** | +| **Hoch** | **3** | +| **Mittel** | **2** | +| **Niedrig** | **1** | diff --git a/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.es.md b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.es.md new file mode 100644 index 00000000000..273016c2d2f --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.es.md @@ -0,0 +1,32 @@ +--- +title: Calificación de Salud del Producto +description: Cómo calcula DefectDojo la Calificación de Salud de un Producto +aliases: +- /es/en/working_with_findings/organizing_engagements_tests/product_health_grade +--- + +DefectDojo puede calcular una calificación para sus Productos en función de la cantidad de Hallazgos que contienen. Las calificaciones se clasifican de A \- F. + +Tenga en cuenta que solo los Hallazgos Activos \& Verificados contribuyen a la Calificación de un Producto \- los Hallazgos no verificados no tendrán impacto. + +## Cálculo de la Calificación del Producto + +Toda Calificación de Producto comienza en 100 (sin Hallazgos). + +El cálculo de la calificación comienza observando el nivel de **Severidad** más alto de un Hallazgo en un Producto, y reduciendo la Salud del Producto a un nivel base. + +| **Nivel de Severidad más alto de un Hallazgo** | **Calificación máxima** | +| --- | --- | +| **Crítica** | **40** | +| **Alta** | **60** | +| **Media** | **80** | +| **Baja** | **95** | + +A continuación se deducen puntos adicionales de la Calificación por cada Hallazgo adicional: + +| **Nivel de Severidad de un Hallazgo adicional** | **Reducción de la Calificación** | +| --- | --- | +| **Crítica** | **5** | +| **Alta** | **3** | +| **Media** | **2** | +| **Baja** | **1** | diff --git a/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.fr.md b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.fr.md new file mode 100644 index 00000000000..cc1450a35e6 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.fr.md @@ -0,0 +1,32 @@ +--- +title: Note de santé du Produit +description: Comment DefectDojo calcule la Note de santé d'un Produit +aliases: +- /fr/en/working_with_findings/organizing_engagements_tests/product_health_grade +--- + +DefectDojo peut calculer une note pour vos Produits en fonction du nombre de Constatations qu'ils contiennent. Les notes sont classées de A \- F. + +Notez que seules les Constatations Actives \& Vérifiées contribuent à la Note d'un Produit \- les Constatations non vérifiées n'ont aucun impact. + +## Calcul de la Note du Produit + +Chaque Note de Produit commence à 100 (sans Constatations). + +Le calcul de la note commence par l'examen du niveau de **Sévérité** le plus élevé d'une Constatation dans un Produit, et réduit la Santé du Produit à un niveau de base. + +| **Niveau de Sévérité le plus élevé d'une Constatation** | **Note maximale** | +| --- | --- | +| **Critique** | **40** | +| **Élevée** | **60** | +| **Moyenne** | **80** | +| **Faible** | **95** | + +Des points supplémentaires sont ensuite déduits de la Note pour chaque Constatation additionnelle : + +| **Niveau de Sévérité d'une Constatation additionnelle** | **Réduction de la Note** | +| --- | --- | +| **Critique** | **5** | +| **Élevée** | **3** | +| **Moyenne** | **2** | +| **Faible** | **1** | diff --git a/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.ja.md b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.ja.md new file mode 100644 index 00000000000..120b5a0a8bc --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.ja.md @@ -0,0 +1,32 @@ +--- +title: 製品ヘルスグレード +description: DefectDojoが製品ヘルスグレードを算出する方法 +aliases: +- /ja/en/working_with_findings/organizing_engagements_tests/product_health_grade +--- + +DefectDojoは、含まれる検出事項の件数に基づいて製品にグレードを算出することができます。グレードはA〜Fでランク付けされます。 + +Product Gradeに影響するのは**アクティブ**かつ**検証済み**の検出事項のみである点に注意してください。未検証の検出事項は影響を与えません。 + +## Product Gradeの計算 + +すべてのProduct Gradeは(検出事項がない状態で)100から始まります。 + +グレードの計算では、まず製品内の検出事項の中で最も高い**深刻度**レベルを確認し、Product Healthをその基準レベルまで引き下げます。 + +| **検出事項の最も高い深刻度レベル** | **最大グレード** | +| --- | --- | +| **重大** | **40** | +| **高** | **60** | +| **中** | **80** | +| **低** | **95** | + +その後、追加の検出事項ごとにグレードからさらにポイントが差し引かれます。 + +| **追加の検出事項の深刻度レベル** | **グレードの減少量** | +| --- | --- | +| **重大** | **5** | +| **高** | **3** | +| **中** | **2** | +| **低** | **1** | diff --git a/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.de.md b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.de.md new file mode 100644 index 00000000000..3bd5db54f45 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.de.md @@ -0,0 +1,78 @@ +--- +title: Threat Intelligence +description: Exploit- und Bedrohungsnachweise als vollwertiger Eingabewert für Priorität + und Risiko +weight: 2 +audience: pro +--- + +DefectDojo Pro reichert Ihre Befunde mit **dedizierter Threat Intelligence** an – Exploit-Verfügbarkeit, bekannte Ausnutzung und Aktivitäten von Bedrohungsakteuren – und bezieht dies in Priorität und Risiko ein. Dies geht weit über EPSS und das CISA-KEV-Flag hinaus. + +## Was Sie erhalten + +Jeder Befund mit einer CVE wird nächtlich mit einem kuratierten Intelligence-Feed abgeglichen, der aus CISA KEV, Metasploit, Exploit-DB, Nuclei-Templates und der Verfolgung öffentlicher Proof-of-Concepts aufgebaut ist. Liegen Exploit-Nachweise vor, zeigt der Befund eine **Threat-Intelligence**-Karte: + +* ein **Exploit-Reifegrad**-Badge – *Keiner → PoC → Weaponized → Aktiv ausgenutzt* +* ein **Threat Score** (0–100) +* **Nachweis-Chips, die auf den jeweiligen Beleg verlinken** – der KEV-Eintrag (mit Aufnahmedatum), Einsatz in Ransomware, ein Metasploit-Modul, ein Exploit-DB-Eintrag, ein Nuclei-Template sowie öffentliche Proof-of-Concept-Repositories +* eine leicht verständliche Zeile, die erklärt, **warum** die Priorität des Befunds gestiegen ist + +Über die Karte hinaus ist diese Intelligence in der gesamten Anwendung nutzbar: + +* eine **Spalte „Exploit-Reifegrad"** in der Befundliste – sortier- und filterbar (zum Beispiel „Nur Weaponized oder Aktiv") +* eine Kachel **„Dringend & aktiv ausgenutzt"** im Priority-Layout-Dashboard, die aktive Befunde mit Risiko „Dringend" zählt, die in freier Wildbahn ausgenutzt werden – ein Klick öffnet die entsprechend gefilterte Befundliste +* ein **Benachrichtigungsereignis** (`threat_intel_alert`), wenn die CVE eines bestehenden Befunds neue Exploit-Nachweise erhält, etwa durch Aufnahme in CISA KEV oder ein neues Metasploit-Modul. Nur Höherstufungen – wenn Nachweise stillschweigend veralten, erfolgt keine Benachrichtigung. + +## Wie sich dies auf die Bewertung auswirkt + +Die Priority-Engine kombinierte bisher bereits Schweregrad, Geschäftskontext und einen „externen Score", der aus EPSS + KEV gebildet wird. Threat Intelligence verallgemeinert diesen externen Score: Jede Art von Exploit-Nachweis wirkt als Untergrenze auf der EPSS-Skala. + +| Evidence | Priority floor (EPSS-equivalent) | +|---|---| +| Active exploitation + ransomware/named actor | 45% | +| In CISA KEV **and** used in ransomware | 30% | +| In KEV or exploited in the wild | 20% | +| Weaponized public exploit (Metasploit / Exploit-DB) | 15% | +| Nuclei detection template exists | 12% | +| Public proof-of-concept only | 8% | +| No exploit evidence | no change | + +Der externe Score eines Befunds ist der **höhere** Wert aus seinem EPSS-abgeleiteten Wert und der höchsten der oben genannten Untergrenzen – Threat Intelligence kann einen Score also nur *anheben*, niemals senken, und ein Befund, dessen EPSS-Wert die Untergrenze bereits übersteigt, bleibt unverändert. Der vertraute, produkttypbezogene **Skalierungsfaktor für den externen Score** in Ihren Prioritization-Engine-Einstellungen skaliert diesen Beitrag genau wie bisher bei EPSS/KEV. + +### Die Risikountergrenze für aktiv ausgenutzte Schwachstellen + +Die obige Tabelle erhöht die **Priorität**, jedoch proportional zum Basis-Schweregrad eines Befunds. Das hat eine Konsequenz, die man klar benennen sollte: Ein Befund mit Schweregrad Niedrig, dessen CVE in freier Wildbahn ausgenutzt wird, erhält nur einen kleinen absoluten Anstieg und könnte dennoch in einer niedrigen **Risiko**-Kategorie verbleiben. Die meisten Teams halten das für falsch – „aktiv ausgenutzt" sollte niemals unter Niedrig einsortiert werden. + +Deshalb gibt es eine zweite, kategorische Regel. Meldet Threat Intelligence eine **aktive Ausnutzung in freier Wildbahn**, wird die Priorität des Befunds mindestens auf das Niveau einer konfigurierten Risiko-Kategorie angehoben – unabhängig davon, was die gewichtete Berechnung allein ergeben hätte. Standardmäßig ist dies auf **Handlungsbedarf** gesetzt; jeder Produkttyp kann diese Untergrenze in den Prioritization-Engine-Einstellungen unter *Risikountergrenze für aktiv ausgenutzte Schwachstellen* auf Dringend anheben, absenken oder deaktivieren. + +Die Untergrenze wirkt ausschließlich nach oben – sie stuft einen Befund nie herab, und ein Befund, der von sich aus bereits höher bewertet ist, bleibt unangetastet. Da sie auf die Priorität wirkt, ergeben sich Risiko-Kategorie und Risiko-Score automatisch daraus, sodass jede Liste, jeder Filter, jedes Diagramm und jede SLA-Berechnung dieselbe konsistente Zahl sieht. + +## Befunde ohne CVE + +Threat Intelligence wird über die CVE abgeglichen. Viele Befunde – die meisten SAST-Ergebnisse, Secrets, Fehlkonfigurationen, benutzerdefinierte Regeln – haben keine CVE, und für sie existiert nirgendwo eine Threat Intelligence auf Ebene der einzelnen Schwachstelleninstanz (das gilt für jeden Anbieter, nicht nur für DefectDojo). Diese Befunde: + +* behalten ihre **exakte** aktuelle Priorität und ihr Risiko – die Funktion senkt niemals einen Score +* werden weiterhin anhand aller übrigen Engine-Eingaben priorisiert (Schweregrad, Geschäftskritikalität, Exposition und so weiter) +* zeigen auf der Karte „Keine Threat Intelligence verfügbar – dieser Befund hat keine CVE, gegen die abgeglichen werden kann" an, im Unterschied zu einem CVE-Befund, für den bislang schlicht kein bekannter Exploit vorliegt + +Eine ehrliche Konsequenz daraus: In einer gemischten Warteschlange sinken Befunde ohne CVE im *relativen* Rang, sobald Befunde mit CVE Exploit-Nachweise erhalten – auch wenn sich ihr eigener Score nicht ändert. + +## Vertrauenswürdigkeit und Stabilität der Bewertung + +* **Signierte Intelligence.** Jedes nächtliche Bundle wird von DefectDojo kryptografisch signiert; Ihre Instanz lehnt manipulierte oder unsignierte Daten ab. Air-Gapped-Instanzen importieren dasselbe signierte Bundle mit einem Offline-Verifizierungsschritt. +* **Kein Score-Flackern.** Höherstufungen durch neue Nachweise gelten ab der Nacht, in der sie erscheinen. Fällt ein Nachweis bei einer Quelle *weg*, bleiben die Scores für ein Stabilitätsfenster (standardmäßig 14 Tage) unverändert – ein kurzzeitiger Ausfall eines Feeds bringt Ihre Warteschlange nie ins Wanken, und echte Rückstufungen setzen sich nach diesem Fenster ruhig durch. +* **Air-Gapped-Unterstützung.** Das tägliche Bundle (einschließlich EPSS-Daten) kann übertragen und offline importiert werden, sodass isolierte Instanzen dieselbe Anreicherung erhalten. + +## Self-Hosted-Bereitstellungen + +DefectDojo-Cloud-Instanzen benötigen keine Konfiguration. Bei Self-Hosted-Instanzen stehen drei Optionen zur Verfügung: + +* **Verbunden (Standard).** Die Instanz ruft das signierte Bundle nächtlich per HTTPS von `intel.defectdojo.com` ab. Dieses Ziel wird von keiner anderen DefectDojo-Funktion verwendet und muss daher meist explizit freigegeben werden: Öffnen Sie ausgehenden Verkehr auf Port 443 zu diesem Host, und fügen Sie ihn unter Kubernetes Ihrer Egress-Netzwerkrichtlinie hinzu. Beachten Sie, dass der Abruf auf dem **Celery-Worker** erfolgt, nicht auf dem Web-Pod – Proxy-Einstellungen müssen also auch diese Arbeitslast erreichen. +* **Interner Mirror.** Verweisen Sie mit `DD_THREAT_INTEL_BUNDLE_URL` (sowie den zugehörigen Digest- und Signatur-URLs) auf einen Speicherort in Ihrem Netzwerk, den Sie selbst synchronisieren. Die Signaturprüfung gilt weiterhin, sodass ein Mirror die Daten nicht verändern kann. +* **Air-Gapped.** Übertragen Sie das Bundle und seine Signatur manuell und importieren Sie sie mit `manage.py load_threat_intel_bundle --file `. Die Signatur wird beim Import verifiziert. + +Kann die Instanz den Feed nicht erreichen, schlägt die Funktion sicher fehl (fail closed): Der Lauf wird als fehlgeschlagen protokolliert, und Ihre bestehenden Scores und Nachweise bleiben exakt unverändert. Nichts verschlechtert sich außer der Aktualität der Intelligence. + +## Aktivierung + +Die Funktion ist standardmäßig deaktiviert. Administratoren können sie direkt aktivieren oder zunächst im **Shadow-Modus** ausführen – dabei werden die potenziellen Scores berechnet, ohne live etwas zu ändern, und ein Drift-Bericht zeigt genau, welche Befunde sich verschieben würden – bevor sie eingeschaltet wird. Wenden Sie sich an den Support, oder lesen Sie das Betriebs-Runbook für die empfohlene Einführung auf großen Instanzen. diff --git a/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.es.md b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.es.md new file mode 100644 index 00000000000..ca042436661 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.es.md @@ -0,0 +1,133 @@ +--- +title: Inteligencia de amenazas +description: Evidencia de exploits y amenazas como entrada de primera clase para la + Prioridad y el Riesgo +weight: 2 +audience: pro +--- + +DefectDojo Pro enriquece sus hallazgos con **inteligencia de amenazas dedicada** — disponibilidad de exploits, explotación conocida y actividad de actores de amenazas — y la incorpora al cálculo de la Prioridad y el Riesgo. Esto va mucho más allá de EPSS y del indicador KEV de CISA. + +## Qué obtiene + +Cada hallazgo con un CVE se compara, cada noche, con un feed de inteligencia curado, construido a partir de CISA KEV, Metasploit, Exploit-DB, plantillas de Nuclei y el seguimiento de pruebas de concepto públicas. Cuando existe evidencia de exploit, el hallazgo muestra una tarjeta de **Inteligencia de amenazas**: + +* una insignia de **madurez del exploit** — *Ninguna → PoC → Armado → Activo en el mundo real* +* una **puntuación de amenaza** (0–100) +* **chips de evidencia que enlazan con la fuente** — la entrada en KEV (con su fecha de inclusión), + uso en ransomware, un módulo de Metasploit, una entrada en Exploit-DB, una plantilla de Nuclei y + repositorios públicos de prueba de concepto +* una línea en lenguaje sencillo que explica **por qué** aumentó la prioridad del hallazgo + +Más allá de la tarjeta, esta inteligencia es una superficie funcional en toda la aplicación: + +* una **columna de Madurez del Exploit** en la lista de hallazgos — ordenable y filtrable + (por ejemplo, "solo Armado o Activo") +* un widget de **"Urgente y explotado activamente"** en el panel de Diseño de Prioridad, que cuenta los + hallazgos activos de riesgo Urgente con explotación en el mundo real — al hacer clic se abre la lista + de hallazgos filtrada exacta +* un **evento de notificación** (`threat_intel_alert`) cuando el CVE de un hallazgo existente obtiene + nueva evidencia de exploit, como su inclusión en CISA KEV o la aparición de un módulo de Metasploit. + Solo se notifican mejoras — que la evidencia caduque silenciosamente nunca genera una notificación. + +## Cómo cambia la puntuación + +El motor de Prioridad ya combinaba la severidad, el contexto de negocio y una "puntuación externa" +construida a partir de EPSS + KEV. La inteligencia de amenazas generaliza esa puntuación externa: cada +tipo de evidencia de exploit actúa como un piso en la escala de EPSS. + +| Evidencia | Piso de Prioridad (equivalente a EPSS) | +|---|---| +| Explotación activa + ransomware/actor identificado | 45% | +| En CISA KEV **y** usado en ransomware | 30% | +| En KEV o explotado en el mundo real | 20% | +| Exploit público armado (Metasploit / Exploit-DB) | 15% | +| Existe una plantilla de detección de Nuclei | 12% | +| Solo prueba de concepto pública | 8% | +| Sin evidencia de exploit | sin cambios | + +La puntuación externa del hallazgo es la **mayor** entre su valor derivado de EPSS y el piso de evidencia +más alto de la tabla anterior — por lo tanto, la inteligencia solo *aumenta* una puntuación, nunca la +reduce, y un hallazgo cuyo EPSS ya supere el piso no se ve afectado. El conocido **escalar de puntuación +externa** por tipo de producto, en la configuración de su Motor de Priorización, escala esta contribución +exactamente igual que siempre escaló EPSS/KEV. + +### El piso de Riesgo por explotación activa + +La tabla anterior aumenta la **Prioridad**, pero de forma proporcional a la severidad base del hallazgo. Esto +tiene una consecuencia que vale la pena señalar con claridad: un hallazgo de severidad Baja que contiene un +CVE que se está explotando en el mundo real solo recibe un pequeño aumento absoluto, y podría seguir +situándose en una banda de **Riesgo** baja. La mayoría de los equipos considera que esto es incorrecto — +"explotado activamente" nunca debería quedar clasificado como Baja. + +Por eso existe una segunda regla, de tipo categórico. Cuando la inteligencia de amenazas reporta +**explotación activa en el mundo real**, la Prioridad del hallazgo se eleva como mínimo al nivel de una +banda de Riesgo configurada, sin importar lo que produjera por sí solo el cálculo ponderado. Viene +configurada de forma predeterminada en **Requiere acción**; cada tipo de producto puede subirla a +Urgente, bajarla o desactivarla por completo, en la configuración del Motor de Priorización bajo *Piso de +Riesgo por Explotación Activa*. + +El piso solo puede elevar — nunca hace bajar a un hallazgo, y un hallazgo que ya puntúa más alto por sí +mismo no se ve afectado. Como se aplica a la Prioridad, la banda de Riesgo y la puntuación de Riesgo se +derivan de ella automáticamente, de modo que cada lista, filtro, gráfico y cálculo de SLA ve el mismo +número coherente. + +## Hallazgos sin CVE + +La inteligencia de amenazas se relaciona mediante el CVE. Muchos hallazgos — la mayoría de los resultados +de SAST, secretos, configuraciones incorrectas, reglas personalizadas — no tienen CVE, y no existe +inteligencia de amenazas a nivel de instancia de vulnerabilidad para ellos en ninguna parte (esto es así +para todos los proveedores, no solo para DefectDojo). Esos hallazgos: + +* conservan su Prioridad y Riesgo actuales de forma **exacta** — la función nunca reduce una puntuación +* siguen priorizándose mediante todas las demás entradas del motor (severidad, criticidad de negocio, + exposición, etc.) +* muestran en la tarjeta "No hay inteligencia de amenazas disponible — este hallazgo no tiene un CVE con + el que compararlo", distinto del caso de un hallazgo con CVE que simplemente aún no tiene ningún + exploit conocido + +Una consecuencia honesta de esto: en una cola mixta, a medida que los hallazgos con CVE ganan evidencia +de exploit, los hallazgos sin CVE bajan en la clasificación *relativa*, aunque su puntuación no cambie. + +## Confianza y estabilidad de la puntuación + +* **Inteligencia firmada.** Cada paquete nocturno está firmado criptográficamente por DefectDojo; su + instancia rechaza los datos manipulados o sin firmar. Las instancias aisladas (air-gapped) importan el + mismo paquete firmado con un paso de verificación fuera de línea. +* **Sin fluctuaciones de puntuación.** Las mejoras de evidencia se aplican la misma noche en que + aparecen. Si una fuente *deja de reportar* una evidencia, las puntuaciones se mantienen estables + durante una ventana de estabilidad (14 días de forma predeterminada) — un fallo puntual del feed nunca + hace rebotar su cola, y las desescaladas genuinas se asientan de forma silenciosa una vez transcurrida + la ventana. +* **Compatibilidad con entornos aislados.** El paquete diario (incluidos los datos de EPSS) puede + transferirse e importarse fuera de línea, de modo que las instancias aisladas obtienen el mismo + enriquecimiento. + +## Implementaciones autoalojadas + +Las instancias de DefectDojo Cloud no necesitan ninguna configuración. Las instancias autoalojadas +tienen tres opciones: + +* **Conectado (predeterminado).** La instancia descarga el paquete firmado cada noche desde + `intel.defectdojo.com` mediante HTTPS. Este es un destino que ninguna otra función de DefectDojo + utiliza, por lo que normalmente hay que permitirlo de forma explícita: abra el puerto 443 saliente + hacia ese host y, en Kubernetes, añádalo a su política de red de salida. Tenga en cuenta que la + descarga se ejecuta en el **worker de Celery**, no en el pod web, así que la configuración del proxy + también debe alcanzar a ese componente. +* **Réplica interna.** Apunte `DD_THREAT_INTEL_BUNDLE_URL` (y las URL correspondientes de digest y + firma) a una ubicación dentro de su red que usted mismo sincronice. La verificación de firma se sigue + aplicando, por lo que una réplica no puede alterar los datos. +* **Aislado (air-gapped).** Transfiera el paquete y su firma manualmente e impórtelos con + `manage.py load_threat_intel_bundle --file `. La firma se verifica durante la importación. + +Si la instancia no puede acceder al feed, la función falla de forma segura: la ejecución se registra +como fallida y sus puntuaciones y evidencias existentes se dejan exactamente como estaban. Nada se +degrada salvo la actualidad de la inteligencia. + +## Activarla + +La función viene desactivada de forma predeterminada. Los administradores pueden activarla +directamente, o ejecutarla primero en **modo sombra** — que calcula las puntuaciones hipotéticas sin +cambiar nada en el entorno activo y genera un informe de desviación que muestra exactamente qué +hallazgos se moverían — antes de activarla. Contacte con soporte o consulte el runbook de operaciones +para conocer la implementación recomendada en instancias grandes. diff --git a/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.fr.md b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.fr.md new file mode 100644 index 00000000000..7df656d4db3 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.fr.md @@ -0,0 +1,132 @@ +--- +title: Renseignement sur les menaces +description: Les preuves d'exploit et de menace comme donnée de premier plan pour + la Priorité et le Risque +weight: 2 +audience: pro +--- + +DefectDojo Pro enrichit vos constatations avec un **renseignement sur les menaces dédié** — disponibilité d'exploit, +exploitation connue et activité d'acteurs de la menace — et l'intègre dans la Priorité +et le Risque. Cela va bien au-delà de l'EPSS et de l'indicateur CISA KEV. + +## Ce que vous obtenez + +Chaque constatation associée à un CVE est confrontée, chaque nuit, à un flux de renseignement organisé, constitué +à partir de CISA KEV, Metasploit, Exploit-DB, des modèles Nuclei et du suivi public des preuves de +concept. Lorsqu'il existe une preuve d'exploit, la constatation affiche une carte **Renseignement sur les menaces** : + +* un badge de **maturité d'exploit** — *Aucune → PoC → Armé → Actif en conditions réelles* +* un **score de menace** (0–100) +* des **puces de preuve renvoyant à la source** — l'entrée KEV (avec sa date d'inscription), + l'utilisation dans un ransomware, un module Metasploit, une entrée Exploit-DB, un modèle Nuclei, et des + dépôts publics de preuves de concept +* une ligne en langage clair expliquant **pourquoi** la priorité de la constatation a augmenté + +Au-delà de la carte, ce renseignement est exploité dans toute l'application : + +* une **colonne Maturité d'exploit** sur la liste des constatations — triable et filtrable + (par exemple, « Armé ou Actif uniquement ») +* une tuile **« Urgent et activement exploité »** sur le tableau de bord Priority Layout, comptant + les constatations à risque Urgent activement exploitées en conditions réelles — cliquer dessus ouvre + la liste des constatations filtrée exactement en conséquence +* un **événement de notification** (`threat_intel_alert`) lorsque le CVE d'une constatation existante gagne une nouvelle + preuve d'exploit, par exemple en entrant dans CISA KEV ou en obtenant un module Metasploit. Seules les montées + en niveau notifient — une preuve qui s'estompe discrètement ne déclenche jamais de notification. + +## Comment cela modifie le calcul du score + +Le moteur de Priorité combinait déjà la sévérité, le contexte métier et un « score externe » +construit à partir de l'EPSS + KEV. Le renseignement sur les menaces généralise ce score externe : chaque type de +preuve d'exploit agit comme un plancher sur l'échelle EPSS. + +| Preuve | Plancher de Priorité (équivalent EPSS) | +|---|---| +| Exploitation active + ransomware/acteur nommé | 45% | +| Dans CISA KEV **et** utilisé dans un ransomware | 30% | +| Dans KEV ou exploité en conditions réelles | 20% | +| Exploit public armé (Metasploit / Exploit-DB) | 15% | +| Un modèle de détection Nuclei existe | 12% | +| Preuve de concept publique uniquement | 8% | +| Aucune preuve d'exploit | aucun changement | + +Le score externe de la constatation correspond à la valeur **la plus élevée** entre sa valeur dérivée de l'EPSS et le plus +haut plancher de preuve ci-dessus — le renseignement ne fait donc jamais qu'*augmenter* un score, jamais le +baisser, et une constatation dont l'EPSS dépasse déjà le plancher n'est pas affectée. Le **facteur d'échelle du score externe** +habituel, par type de produit, dans les paramètres de votre Moteur de priorisation, met à l'échelle cette contribution +exactement comme il l'a toujours fait pour l'EPSS/KEV. + +### Le plancher de Risque pour exploitation active + +Le tableau ci-dessus augmente la **Priorité**, mais proportionnellement à la sévérité de base d'une constatation. Cela +a une conséquence qu'il vaut la peine de préciser clairement : une constatation de sévérité Faible portant un CVE qui est +exploité en conditions réelles ne reçoit qu'une petite hausse absolue, et pourrait donc rester dans une bande +**Risque** faible. La plupart des équipes considèrent que c'est incorrect — une « exploitation active » ne devrait jamais être classée +en Faible. + +Il existe donc une seconde règle, catégorique celle-ci. Lorsque le renseignement sur les menaces signale une +**exploitation active en conditions réelles**, la Priorité de la constatation est relevée au moins au niveau +d'une bande de Risque configurée, indépendamment du résultat du calcul pondéré seul. Elle est livrée +configurée sur **Nécessite une action** ; chaque type de produit peut la relever jusqu'à Urgent, l'abaisser, ou la désactiver +pour couper ce plancher, dans les paramètres du Moteur de priorisation, sous *Plancher de Risque pour exploitation +active*. + +Ce plancher ne fait qu'augmenter — il ne fait jamais redescendre une constatation, et une constatation qui +obtient déjà un score plus élevé par elle-même n'est pas touchée. Comme il s'applique à la Priorité, la bande de +Risque et le score de Risque en découlent automatiquement, de sorte que chaque liste, filtre, graphique et calcul de SLA +voit le même nombre cohérent. + +## Constatations sans CVE + +Le renseignement sur les menaces est mis en correspondance par CVE. De nombreuses constatations — la plupart des résultats SAST, secrets, +mauvaises configurations, règles personnalisées — n'ont pas de CVE, et aucun renseignement sur les menaces au niveau +d'une instance de vulnérabilité n'existe pour elles, nulle part (cela vaut pour tous les éditeurs, pas seulement DefectDojo). +Ces constatations : + +* conservent **exactement** leur Priorité et leur Risque actuels — la fonctionnalité ne baisse jamais un score +* restent priorisées par toutes les autres données d'entrée du moteur (sévérité, criticité métier, + exposition, etc.) +* affichent « Aucun renseignement sur les menaces disponible — cette constatation n'a pas de CVE à faire correspondre » sur + la carte, ce qui la distingue d'une constatation avec CVE qui n'a simplement pas encore d'exploit connu + +Une conséquence honnête : dans une file mixte, à mesure que les constatations porteuses d'un CVE gagnent des preuves d'exploit, +les constatations sans CVE reculent en rang *relatif*, même si leur score reste inchangé. + +## Confiance et stabilité des scores + +* **Renseignement signé.** Chaque lot nocturne est signé cryptographiquement par DefectDojo ; + votre instance refuse les données altérées ou non signées. Les instances air-gap importent le même + lot signé avec une étape de vérification hors ligne. +* **Pas d'oscillation de score.** Les montées en niveau de preuve s'appliquent la nuit où elles apparaissent. Si une source + *perd* une preuve, les scores restent stables pendant une fenêtre de stabilité (14 jours par défaut) — un + incident de flux ne fait jamais rebondir votre file, et les véritables désescalades s'installent discrètement une fois + la fenêtre passée. +* **Prise en charge air-gap.** Le lot quotidien (y compris les données EPSS) peut être transféré et + importé hors ligne, afin que les instances isolées bénéficient du même enrichissement. + +## Déploiements auto-hébergés + +Les instances DefectDojo Cloud ne nécessitent aucune configuration. Les instances auto-hébergées disposent de trois options : + +* **Connecté (par défaut).** L'instance récupère le lot signé chaque nuit depuis + `intel.defectdojo.com` via HTTPS. Il s'agit d'une destination qu'aucune autre fonctionnalité de DefectDojo + n'utilise ; il faut donc généralement l'autoriser explicitement : ouvrez le port 443 sortant vers cet hôte, et sur + Kubernetes, ajoutez-le à votre politique réseau de sortie (egress). Notez que la récupération s'exécute sur le **worker + Celery**, et non sur le pod web ; les paramètres de proxy doivent donc aussi atteindre cette charge de travail. +* **Miroir interne.** Pointez `DD_THREAT_INTEL_BUNDLE_URL` (ainsi que les URL de digest et de + signature correspondantes) vers un emplacement de votre réseau que vous synchronisez vous-même. La vérification de signature + s'applique toujours, donc un miroir ne peut pas altérer les données. +* **Air-gap.** Transférez le lot et sa signature à la main, puis importez-les avec + `manage.py load_threat_intel_bundle --file `. La signature est vérifiée à l'importation. + +Si l'instance ne peut pas atteindre le flux, la fonctionnalité échoue de façon sécurisée (fail closed) : l'exécution est enregistrée comme +échouée et vos scores et preuves existants restent exactement tels quels. Rien ne se dégrade +sinon la fraîcheur du renseignement. + +## Activation + +La fonctionnalité est désactivée par défaut à la livraison. Les administrateurs peuvent l'activer directement, ou d'abord l'exécuter +en **mode observation (shadow mode)** — qui calcule les scores potentiels sans rien modifier en production et +produit un rapport d'écart montrant exactement quelles constatations bougeraient — avant de l'activer réellement. +Contactez le support ou consultez le runbook d'exploitation pour connaître le déploiement recommandé sur les grandes +instances. diff --git a/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.ja.md b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.ja.md new file mode 100644 index 00000000000..2c19823bfff --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.ja.md @@ -0,0 +1,77 @@ +--- +title: 脅威インテリジェンス +description: エクスプロイトおよび脅威の証跡をPriorityとRiskの主要な入力情報として扱う +weight: 2 +audience: pro +--- + +DefectDojo Proは、悪用可能性、既知の悪用事例、脅威アクターの活動といった**専用の脅威インテリジェンス**で検出事項をエンリッチし、それをPriorityとRiskに反映します。これはEPSSやCISA KEVフラグをはるかに超える情報です。 + +## 得られるもの + +CVEを持つすべての検出事項は、毎晩、CISA KEV、Metasploit、Exploit-DB、Nucleiテンプレート、および一般公開されているPoC(概念実証)の追跡情報から構築された厳選済みのインテリジェンスフィードと照合されます。悪用の証跡がある場合、その検出事項には**Threat Intelligence**カードが表示されます。 + +* **悪用成熟度(exploit-maturity)**バッジ — *なし → PoC → 武器化済み → 実際に悪用中* +* **脅威スコア**(0〜100) +* **証跡へのリンクとなるエビデンスチップ** — KEVエントリ(掲載日を含む)、ランサムウェアでの使用、Metasploitモジュール、Exploit-DBエントリ、Nucleiテンプレート、一般公開されているPoCリポジトリ +* その検出事項のpriorityが上昇した**理由**を説明する平易な一文 + +カードだけでなく、このインテリジェンスはアプリ全体で利用できる情報にもなっています。 + +* 検出事項一覧の**Exploit Maturity列** — ソートおよびフィルタが可能(例:「WeaponizedまたはActiveのみ」) +* Priority Layoutダッシュボード上の**「Urgent & Actively Exploited」**タイル — 実際に悪用が確認されているアクティブなUrgentリスクの検出事項数をカウントし、クリックすると該当のフィルタ済み検出事項一覧が開きます +* 既存の検出事項のCVEが、CISA KEVへの掲載やMetasploitモジュールの追加といった新たな悪用証跡を得たときに発生する**通知イベント**(`threat_intel_alert`)。これはアップグレード時のみで、証跡が静かに古くなって失効しても通知は発生しません。 + +## スコアリングへの影響 + +Priorityエンジンは、これまでも深刻度、ビジネスコンテキスト、そしてEPSS + KEVから構築される「外部スコア」を組み合わせて計算していました。脅威インテリジェンスはこの外部スコアを一般化し、各種の悪用証跡がEPSSスケール上のフロア(下限)として機能するようにします。 + +| 証跡 | Priorityフロア(EPSS換算) | +|---|---| +| 実際の悪用 + ランサムウェア/特定の攻撃者 | 45% | +| CISA KEVに掲載**かつ**ランサムウェアで使用 | 30% | +| KEVに掲載、または実際に悪用されている | 20% | +| 武器化された公開エクスプロイト(Metasploit / Exploit-DB) | 15% | +| Nuclei検出テンプレートが存在する | 12% | +| 公開PoCのみ | 8% | +| 悪用証跡なし | 変更なし | + +検出事項の外部スコアは、EPSS由来の値と上記の証跡フロアの**大きい方**が採用されます。そのため、インテリジェンスはスコアを*引き上げる*ことはあっても、決して引き下げることはなく、すでにEPSSがフロアを超えている検出事項には影響しません。Prioritization Engineの設定にあるおなじみの製品タイプ別**external-scoreスカラー**は、EPSS/KEVに対して常にそうしてきたのと同じ方法で、この寄与分にも適用されます。 + +### Actively-Exploited Risk Floor(実際に悪用されている場合のRiskフロア) + +上記の表は**Priority**を引き上げますが、それは検出事項の基本深刻度に比例した形です。ここには明言しておく価値のある帰結があります。実際に悪用されているCVEを含むLow深刻度の検出事項は、絶対値としてはわずかな上昇しか受けず、それでも低い**Risk**バンドに留まる可能性があるということです。多くのチームはこれを誤りだと考えます。「実際に悪用されている」ものがLowに分類されるべきではないからです。 + +そこで、2つ目のカテゴリカルなルールが存在します。脅威インテリジェンスが**実際の悪用(in the wild)**を報告した場合、重み付け計算だけで算出された結果にかかわらず、その検出事項のPriorityは設定されたRiskバンドの水準以上に引き上げられます。デフォルトでは**Needs Action(要対応)**に設定されており、各製品タイプはPrioritization Engineの設定内にある*Actively-Exploited Risk Floor*で、これをUrgentまで引き上げたり、引き下げたり、クリアしてフロアを無効にしたりできます。 + +このフロアは常に引き上げる方向にのみ作用します。検出事項を引き下げることは決してなく、すでに単独でより高いスコアを持つ検出事項には影響しません。これはPriorityに適用されるため、RiskバンドとRiskスコアも自動的にそれに追従し、すべての一覧、フィルタ、チャート、SLA計算が同じ一貫した数値を参照することになります。 + +## CVEを持たない検出事項 + +脅威インテリジェンスはCVEによって照合されます。多くの検出事項 — ほとんどのSAST結果、シークレット、設定ミス、カスタムルール — にはCVEがなく、脆弱性インスタンス単位の脅威インテリジェンスもどこにも存在しません(これはDefectDojoに限らず、あらゆるベンダーに共通する事実です)。これらの検出事項は次のようになります。 + +* 現在のPriorityとRiskが**そのまま**維持されます — この機能がスコアを引き下げることはありません +* 他のすべてのエンジン入力(深刻度、ビジネス重要度、露出度など)によって引き続き優先順位が付けられます +* カード上に「No threat intelligence available — this finding has no CVE to match against(この検出事項には照合対象のCVEがないため、脅威インテリジェンスはありません)」と表示されます。これは、CVEはあるが単に既知の悪用がまだないだけの検出事項とは区別されます + +正直に言うべき1つの帰結があります。混在するキューの中で、CVEを持つ検出事項が悪用証跡を獲得していくにつれ、CVEを持たない検出事項はスコア自体は変わらなくても*相対的な*順位が下がっていきます。 + +## 信頼性とスコアの安定性 + +* **署名付きインテリジェンス。** 毎晩配信されるバンドルはすべてDefectDojoによって暗号署名されており、インスタンスは改ざんされたデータや未署名のデータを拒否します。エアギャップ環境のインスタンスも、オフライン検証手順を経て同じ署名付きバンドルをインポートします。 +* **スコアのばたつきなし。** 証跡のアップグレードは、それが現れた夜に適用されます。ある情報源から証跡が*失われた*場合でも、スコアは安定期間(デフォルトで14日間)は変化せず維持されます。フィードの一時的な不具合でキューが揺れ動くことはなく、本物の格下げは期間終了後に静かに反映されます。 +* **エアギャップサポート。** 日次バンドル(EPSSデータを含む)は転送してオフラインでインポートできるため、隔離されたインスタンスでも同じエンリッチメントを得られます。 + +## セルフホスト環境での展開 + +DefectDojo Cloudインスタンスでは設定は不要です。セルフホストのインスタンスには3つの選択肢があります。 + +* **接続あり(デフォルト)。** インスタンスは毎晩、HTTPS経由で`intel.defectdojo.com`から署名付きバンドルを取得します。これは他のDefectDojo機能が使用しない宛先であるため、通常は明示的に許可する必要があります。このホストへのアウトバウンド443番ポートを開放し、Kubernetesの場合はegressネットワークポリシーにも追加してください。この取得処理はwebポッドではなく**Celeryワーカー**上で実行される点に注意してください。そのため、プロキシ設定もそのワークロードに到達させる必要があります。 +* **内部ミラー。** `DD_THREAT_INTEL_BUNDLE_URL`(および対応するダイジェストと署名のURL)を、自分で同期を行うネットワーク内の場所に向けて設定します。署名検証は引き続き適用されるため、ミラーがデータを改ざんすることはできません。 +* **エアギャップ。** バンドルとその署名を手動で転送し、`manage.py load_threat_intel_bundle --file `でインポートします。署名はインポート時に検証されます。 + +インスタンスがフィードに到達できない場合、この機能はフェイルクローズします。つまり実行は失敗として記録され、既存のスコアと証跡はそのままの状態で保持されます。劣化するのはインテリジェンスの鮮度のみです。 + +## 有効化する + +この機能はデフォルトでは無効になっています。管理者はこれを直接有効化することも、まず**シャドーモード**で実行することもできます。シャドーモードでは、実際には何も変更せずに想定されるスコアを計算し、どの検出事項がどのように変動するかを示すドリフトレポートを生成します。大規模インスタンスでの推奨展開方法については、サポートにお問い合わせいただくか、運用ランブックをご参照ください。 diff --git a/docs/content/asset_modelling/PRO_surveys/PRO__surveys.de.md b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.de.md new file mode 100644 index 00000000000..3afab7b9e63 --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.de.md @@ -0,0 +1,147 @@ +--- +title: Umfragen +description: Umfragen in DefectDojo Pro verstehen +audience: pro +weight: 2 +--- + +In DefectDojo ist eine Umfragevorlage ein wiederverwendbarer Satz von Fragen, der dazu dient, Informationen von Entwicklern, Teams sowie internen und externen Stakeholdern zu sammeln. Sie können verwendet werden, um Input einzuholen, bevor die Arbeit beginnt, die Abstimmung zwischen Einzelpersonen und Teams während des Arbeitsfortschritts sicherzustellen und eine retrospektive Analyse nach Abschluss der Arbeit zu ermöglichen. + +In DefectDojo besteht ein Umfragesystem aus drei Komponenten: +- **Umfragevorlagen**, die die Fragen gruppieren und ordnen. +- **Umfrage-Bereitstellungen**, das sind aktive Instanzen, die Antworten sammeln. +- **Antworten**, die von Benutzern übermittelten Antworten. + +Das Erstellen einer Umfragevorlage macht sie nicht automatisch für Antworten verfügbar. Um Antworten zu sammeln, muss eine Umfragevorlage bereitgestellt werden. + +## Berechtigungen + +Der Bereich Umfragen in der Seitenleiste ist nur für Benutzer mit Superuser-Status sichtbar, und nur Superuser können Umfragevorlagen erstellen, Fragen erstellen und Umfragen bereitstellen. + +Benutzer ohne Superuser-Status können weiterhin auf Umfragen antworten, die mit ihnen geteilt wurden, aber sie können diese oder die zugehörigen Fragen weder erstellen noch verwalten. + +## Zugriff auf Umfragen und Fragen + +Benutzer mit Superuser-Status können über die Seitenleiste durch Klicken auf die Option **Umfragen** auf Umfragen und Fragen zugreifen. Das Untermenü bietet Zugriff auf **Alle Umfragen** und **Alle Fragen** sowie die Möglichkeit, neue Umfragen und Fragen zu erstellen. + +![image](images/pq_ss1.png) + +### Zugriff auf Umfragen + +Die Ansicht für Alle Umfragen enthält eine Tabelle mit allen Umfragevorlagen, einschließlich ihrer ID, ihres Namens, ihrer Beschreibung und ihres Aktivitätsstatus. Die Tabelle kann mithilfe von Stichwörtern gefiltert und durch Klicken auf die Kopfzeile jeder Spalte neu sortiert werden. + +### Zugriff auf Fragen + +Die Ansicht Alle Fragen enthält eine Tabelle mit Fragen, die einer Umfrage hinzugefügt werden können. Die Tabelle kann mithilfe von Stichwörtern gefiltert und durch Klicken auf die Kopfzeile jeder Spalte neu sortiert werden. + +## Verwalten von Umfragevorlagen + +### Umfragevorlagen erstellen + +Umfragevorlagen können entweder durch Klicken auf **Neue Umfrage** in der Seitenleiste oder durch Klicken auf die Schaltfläche **Neue Umfrage** oben in der Ansicht Alle Umfragen erstellt werden. + +![image](images/pq_ss2.png) + +Der Umfragevorlage müssen ein Name und eine Beschreibung gegeben werden, und es muss mindestens eine Frage aus dem Dropdown-Menü ausgewählt werden, bevor sie erstellt werden kann. + +#### Fragen zu einer bereits bestehenden Umfragevorlage hinzufügen + +Um Fragen zu einer bereits bestehenden Umfragevorlage hinzuzufügen, klicken Sie auf das Kebab-Symbol ⋮ links neben der gewünschten Umfrage, klicken Sie auf **Umfrage bearbeiten**, wählen Sie im Dropdown-Menü die neuen Fragen aus, die der Umfrage hinzugefügt werden sollen, und klicken Sie dann auf **Absenden**. + +Als bewährte Praxis wird dringend empfohlen, Fragen einer Umfragevorlage nicht zu ändern oder hinzuzufügen, solange diese über aktive Bereitstellungen verfügt. Das Hinzufügen neuer Fragen wirkt sich nicht auf bestehende Antworten aus, aber diese Antworten wurden übermittelt, ohne die neu hinzugefügten Fragen zu beantworten, was zu unvollständigen Daten führen kann. + +### Fragen erstellen + +Ähnlich wie bei Umfragevorlagen können Fragen entweder durch Klicken auf **Neue Frage** in der Seitenleiste oder durch Klicken auf die Schaltfläche **Neue Frage** oben in der Ansicht Alle Fragen erstellt werden. + +#### Fragetypen + +Beim Erstellen einer neuen Frage kann diese entweder als textbasierte Frage oder als Multiple-Choice-Frage formatiert werden, indem oben in der Ansicht Neue Frage **Textfrage** oder **Auswahlfrage** ausgewählt wird. + +![image](images/pq_ss3.png) + +#### Reihenfolge der Fragen + +Die Reihenfolge einer Frage wird durch die Vergabe einer Ordnungsnummer festgelegt. Hat eine Frage beispielsweise die 1 im Feld Reihenfolge, erscheint sie oberhalb einer Frage mit der 2 im Feld Reihenfolge. + +#### Optionale Antworten + +Sowohl textbasierte Fragen als auch Multiple-Choice-Fragen können durch Klicken auf das entsprechende Kontrollkästchen als **Optional** gekennzeichnet werden. + +#### Mehrfachantworten zulassen + +Einer Multiple-Choice-Frage kann eine unbegrenzte Anzahl möglicher Antworten hinzugefügt werden. Durch Klicken auf das Kontrollkästchen **Mehrfachauswahl zulassen** können mehrere Antworten ausgewählt werden (nur für Multiple-Choice-Fragen verfügbar). + +### Fragen bearbeiten + +Um eine Frage zu ändern, navigieren Sie zur Ansicht Alle Fragen, klicken Sie auf das Kebab-Symbol ⋮ links neben der zu ändernden Frage, klicken Sie auf Frage bearbeiten, nehmen Sie die gewünschte Änderung vor und schließen Sie die Änderung durch Klicken auf Absenden ab. Fragen können nicht gelöscht werden. + +![image](images/pq_ss4.png) + +Es ist wichtig, das Bearbeiten von Fragen, die Teil aktiver Umfragen sind, sowie das Hinzufügen von Fragen zu aktiven Umfragen zu vermeiden. Dies wirkt sich nicht auf zuvor gesammelte Antworten aus, kann jedoch zu unvollständigen oder unzuverlässigen Daten führen. + +## Umfragen bereitstellen + +Sobald eine Umfragevorlage erfolgreich erstellt wurde, erzeugt das Bereitstellen einer Umfrage eine aktive Instanz, die Antworten entgegennimmt. + +Um eine Umfrage bereitzustellen, navigieren Sie zur Ansicht Alle Umfragen, klicken Sie auf das Kebab-Symbol ⋮ links neben der bereitzustellenden Umfrage, klicken Sie auf **Umfrage öffnen**, legen Sie das Ablaufdatum fest und klicken Sie auf Absenden. + +Wenn Sie dieselbe Umfrage erneut bereitstellen möchten, gehen Sie genauso vor. Alle Bereitstellungen erscheinen in der Tabelle Offene Umfrage-Instanzen in der Ansicht der Umfrage und können anhand ihrer ID, ihres Erstellungszeitpunkts und ihres Ablaufdatums unterschieden werden. + +![image](images/pq_ss10.png) + +Eine Umfrage schließt am gewählten Datum zur selben Uhrzeit, zu der sie bereitgestellt wurde. Wenn Sie beispielsweise eine Umfrage am 1. Februar 2026 um 8:00 Uhr bereitstellen und ihren Abschluss auf den 1. März 2026 festlegen, schließt die Umfrage am Morgen des 1. März 2026 um 8:00 Uhr. + +Sobald eine Umfrage geöffnet wurde, können ihr Ablaufdatum und ihre Uhrzeit nicht mehr geändert werden. Wird ein anderer Zeitrahmen benötigt, muss eine neue Bereitstellung erstellt werden. + +Sobald ein Ablaufdatum verstrichen ist, können für diese Bereitstellung der Umfrage keine Antworten mehr übermittelt werden, die Bereitstellung erscheint jedoch weiterhin in der Tabelle Offene Umfrage-Instanzen in der Ansicht der Umfrage. + +#### Eine Umfrage teilen + +Sobald eine Umfrage bereitgestellt wurde, kann sie mit anderen Benutzern geteilt werden, indem Sie auf das Symbol ↗ links neben der Umfrage in der Tabelle Offene Umfrage-Instanzen in der Ansicht der Umfragevorlage klicken. Dadurch wird ein für diese Bereitstellung eindeutiger Link angezeigt, der kopiert und an die vorgesehenen Empfänger weitergegeben werden kann. + +![image](images/pq_ss5.png) + +![image](images/pq_ss9.png) + +#### Eine Umfrage schließen + +Um eine Umfrage zu schließen, klicken Sie auf das rote **X** links neben der Umfrage in der Tabelle Offene Umfrage-Instanzen in der Ansicht der Umfragevorlage. + +![image](images/pq_ss13.png) + +Wie im späteren Abschnitt Antworten erwähnt, wird dadurch lediglich verhindert, dass weitere Antworten übermittelt werden. Zuvor übermittelte Antworten bleiben in der Tabelle Antworten unten in der Ansicht der Umfragevorlage sichtbar. + +## Auf Umfragen antworten + +Um auf eine Umfrage zu antworten, muss Nicht-Superusern der Link gemäß den Anweisungen im obigen Abschnitt [Eine Umfrage teilen](#sharing-a-survey) direkt zur Verfügung gestellt werden. Superuser können ebenfalls über denselben Link antworten. + +#### Anonyme Antworten aktivieren + +Standardmäßig sind Umfragen nur für DefectDojo-Benutzer zugänglich. Damit externe Parteien auf DefectDojo-Umfragen antworten können, stellen Sie sicher, dass die Option **Anonyme Umfrageantworten aktivieren** in den **Systemeinstellungen** aktiviert wurde. Diese finden Sie in der Seitenleiste unter **Einstellungen > System** (im Untermenü **Pro-Einstellungen** bei Instanzen, die noch das vorherige Menülayout verwenden). + +![image](images/pq_ss6.png) + +Externe Antworten erscheinen als anonym, da der Antwort keine DefectDojo-Benutzer-ID zugeordnet ist. + +Wenn der Geltungsbereich einer Umfrage sowohl interne als auch externe Benutzer umfasst, geben Sie bei der Erstellung den Namen des Engagements in der Beschreibung an, damit die Ergebnisse gefiltert werden können. + +![image](images/pq_ss7.png) + +![image](images/pq_ss8.png) + +## Antworten verwalten + +Eine einzelne Umfragevorlage kann mehrfach gleichzeitig bereitgestellt werden. Alle Antworten auf mehrere Bereitstellungen derselben Umfragevorlage werden gemeinsam in der Tabelle Antworten unten in der Ansicht dieser Umfrage angezeigt. + +![image](images/pq_ss11.png) + +Auch nachdem eine Umfrage-Bereitstellung abgelaufen ist oder geschlossen wurde, bleiben ihre Antworten in der Tabelle Antworten unten in der Ansicht der Umfrage sichtbar, sofern die Umfragevorlage selbst nicht gelöscht wurde. Diese Antworten sind dauerhaft und können nicht entfernt werden. + +Wie in der folgenden Abbildung gezeigt, gibt es derzeit keine offenen Umfrage-Bereitstellungen, dennoch sind Antworten aus früheren Bereitstellungen weiterhin in der Tabelle Antworten vorhanden. + +![image](images/pq_ss12.png) + +### Umfragevorlagen löschen + +Um eine Umfragevorlage zu löschen, navigieren Sie zur Ansicht Alle Umfragen, klicken Sie auf das Kebab-Symbol ⋮ links neben der gewählten Umfrage und klicken Sie auf **Umfrage löschen**. Dadurch werden die Umfragevorlage sowie alle zugehörigen Bereitstellungen und Antworten dauerhaft gelöscht. Diese Aktion kann nicht rückgängig gemacht werden. diff --git a/docs/content/asset_modelling/PRO_surveys/PRO__surveys.es.md b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.es.md new file mode 100644 index 00000000000..dc1f4584973 --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.es.md @@ -0,0 +1,147 @@ +--- +title: Encuestas +description: Cómo funcionan las Encuestas en DefectDojo Pro +audience: pro +weight: 2 +--- + +En DefectDojo, una plantilla de Encuesta es un conjunto reutilizable de Preguntas que sirve para recopilar información de desarrolladores, equipos y partes interesadas tanto internas como externas. Se pueden usar para recabar información antes de que comience el trabajo, garantizar la alineación entre individuos y equipos a medida que avanza el trabajo, y permitir un análisis retrospectivo una vez que el trabajo se ha completado. + +En DefectDojo, un sistema de Encuestas consta de tres componentes: +- **Plantillas de Encuesta**, que agrupan y ordenan las Preguntas. +- **Implementaciones de Encuesta**, que son instancias activas que recopilan respuestas. +- **Respuestas**, que son las contestaciones enviadas por los Usuarios. + +Crear una plantilla de Encuesta no la pone automáticamente disponible para recibir respuestas. Para recopilar respuestas, se debe implementar una plantilla de Encuesta. + +## Permisos + +La sección Encuestas de la barra lateral solo es visible para los Usuarios con estado de Superusuario, y solo los Superusuarios pueden crear plantillas de Encuesta, crear Preguntas e implementar Encuestas. + +Los Usuarios sin estado de Superusuario pueden responder a las Encuestas que se comparten con ellos, pero no pueden crearlas ni gestionarlas, ni gestionar sus Preguntas asociadas. + +## Acceso a Encuestas y Preguntas + +Los Usuarios con estado de Superusuario pueden acceder a Encuestas y Preguntas desde la barra lateral haciendo clic en la opción **Encuestas**. El submenú brinda acceso a **Todas las encuestas** y **Todas las preguntas**, además de la opción para crear nuevas Encuestas y Preguntas. + +![imagen](images/pq_ss1.png) + +### Acceso a Encuestas + +La vista de Todas las encuestas incluye una tabla con todas las plantillas de Encuesta, incluyendo su ID, nombre, descripción y estado activo. La tabla se puede filtrar mediante palabras clave y se puede reorganizar haciendo clic en el encabezado de cada columna. + +### Acceso a Preguntas + +La vista de Todas las preguntas incluye una tabla de Preguntas que se pueden agregar a una Encuesta. La tabla se puede filtrar mediante palabras clave y se puede reorganizar haciendo clic en el encabezado de cada columna. + +## Gestión de plantillas de Encuesta + +### Crear plantillas de Encuesta + +Las plantillas de Encuesta se pueden crear haciendo clic en **Nueva encuesta** en la barra lateral, o haciendo clic en el botón **Nueva encuesta** en la parte superior de la vista Todas las encuestas. + +![imagen](images/pq_ss2.png) + +A la plantilla de Encuesta se le debe asignar un nombre y una descripción, y debe tener al menos una Pregunta elegida en el menú desplegable antes de crearse. + +#### Agregar Preguntas a una plantilla de Encuesta existente + +Para agregar Preguntas a una plantilla de Encuesta existente, haga clic en el icono de kebab ⋮ a la izquierda de la Encuesta deseada, haga clic en **Editar encuesta**, seleccione en el menú desplegable las nuevas Preguntas que desea agregar a la Encuesta y luego haga clic en **Enviar**. + +Como buena práctica, se recomienda encarecidamente evitar modificar o agregar Preguntas a una plantilla de Encuesta mientras tenga implementaciones activas. Agregar nuevas Preguntas no afectará a las Respuestas existentes, pero esas Respuestas se habrán enviado sin responder a las Preguntas recién agregadas, lo que puede dar lugar a datos incompletos. + +### Crear Preguntas + +De manera similar a las plantillas de Encuesta, las Preguntas se pueden crear haciendo clic en **Nueva pregunta** en la barra lateral, o haciendo clic en el botón **Nueva pregunta** en la parte superior de la vista Todas las preguntas. + +#### Tipos de pregunta + +Al crear una nueva Pregunta, se puede dar formato como pregunta de texto o como pregunta de opción múltiple seleccionando **Pregunta de texto** o **Pregunta de opción múltiple** en la parte superior de la vista Nueva pregunta. + +![imagen](images/pq_ss3.png) + +#### Orden de las preguntas + +Determine el orden de una Pregunta asignándole un número de orden. Por ejemplo, si una Pregunta tiene 1 en el campo Orden, esa Pregunta aparecerá por encima de una Pregunta con 2 en el campo Orden. + +#### Respuestas opcionales + +Tanto las preguntas de texto como las preguntas de opción múltiple se pueden marcar como **Opcional** haciendo clic en la casilla correspondiente. + +#### Permitir múltiples respuestas + +Se puede agregar un número ilimitado de posibles respuestas a una pregunta de opción múltiple. Al hacer clic en la casilla **Permitir selecciones múltiples** se permite seleccionar varias respuestas (solo disponible para preguntas de opción múltiple). + +### Editar Preguntas + +Para cambiar una Pregunta, vaya a la vista Todas las preguntas, haga clic en el icono de kebab ⋮ a la izquierda de la Pregunta que desea cambiar, haga clic en Editar pregunta, realice el cambio deseado y finalícelo haciendo clic en Enviar. Las Preguntas no se pueden eliminar. + +![imagen](images/pq_ss4.png) + +Es importante evitar editar Preguntas que formen parte de Cuestionarios activos o agregar Preguntas a Cuestionarios activos. Hacerlo no afectará ninguna respuesta recopilada previamente, pero puede dar lugar a datos incompletos o poco confiables. + +## Implementación de Encuestas + +Una vez que se ha creado correctamente una plantilla de Encuesta, implementar una Encuesta crea una instancia activa que acepta respuestas. + +Para implementar una Encuesta, vaya a la vista Todas las encuestas, haga clic en el icono de kebab ⋮ a la izquierda de la Encuesta que desea implementar, haga clic en **Abrir encuesta**, establezca la fecha de vencimiento y haga clic en Enviar. + +Si desea implementar la misma Encuesta nuevamente, siga el mismo proceso. Todas las implementaciones aparecerán en la tabla de Instancias de encuesta abiertas dentro de la vista de la Encuesta, y se pueden distinguir por su ID, hora de creación y fecha de vencimiento. + +![imagen](images/pq_ss10.png) + +Una Encuesta se cerrará en la fecha elegida, a la misma hora en que fue implementada. Por ejemplo, si implementa una Encuesta a las 8:00 a. m. del 1 de febrero de 2026 y la programa para que se cierre el 1 de marzo de 2026, la encuesta se cerrará a las 8:00 a. m. de la mañana del 1 de marzo de 2026. + +Una vez que se ha abierto una Encuesta, su fecha y hora de vencimiento no se pueden cambiar. Si se requiere un plazo diferente, se debe crear una nueva implementación. + +Una vez que ha pasado la fecha de vencimiento, ya no será posible enviar respuestas a esa implementación de la Encuesta, pero la implementación seguirá apareciendo en la tabla de Instancias de encuesta abiertas de la vista de esa Encuesta. + +#### Compartir una Encuesta + +Una vez que se ha implementado una Encuesta, se puede compartir con otros Usuarios haciendo clic en el icono ↗ a la izquierda de la Encuesta dentro de la tabla de Instancias de encuesta abiertas en la vista de la plantilla de Encuesta. Esto mostrará un enlace único para esa implementación que se puede copiar y compartir con los destinatarios previstos. + +![imagen](images/pq_ss5.png) + +![imagen](images/pq_ss9.png) + +#### Cerrar una Encuesta + +Para cerrar una Encuesta, haga clic en la **X** roja a la izquierda de la Encuesta dentro de la tabla de Instancias de encuesta abiertas en la vista de la plantilla de Encuesta. + +![imagen](images/pq_ss13.png) + +Como se indica en la sección Respuestas más adelante, esto solo evitará que se envíen más respuestas. Las Respuestas enviadas anteriormente seguirán visibles en la tabla de Respuestas en la parte inferior de la vista de la plantilla de Encuesta. + +## Responder Encuestas + +Para responder a una Encuesta, los usuarios que no son Superusuarios deben recibir el enlace compartido directamente siguiendo las instrucciones de la sección [Compartir una Encuesta](#sharing-a-survey) mencionada anteriormente. Los Superusuarios también pueden responder usando el mismo enlace. + +#### Habilitar respuestas anónimas + +De forma predeterminada, las Encuestas solo son accesibles para los Usuarios de DefectDojo. Para permitir que terceros externos respondan a las Encuestas de DefectDojo, asegúrese de que la opción **Habilitar respuestas anónimas de encuesta** esté activada en la **Configuración del sistema**, que se encuentra en **Configuración > Sistema** en la barra lateral (dentro del submenú **Configuración Pro** en las instancias que aún usan el diseño de menú anterior). + +![imagen](images/pq_ss6.png) + +Las respuestas externas aparecerán como anónimas porque no hay ningún ID de usuario de DefectDojo asociado con la respuesta. + +Si el alcance de una Encuesta incluye tanto Usuarios internos como externos, especifique el nombre del Compromiso en la descripción al momento de la creación, lo que permitirá filtrar los resultados. + +![imagen](images/pq_ss7.png) + +![imagen](images/pq_ss8.png) + +## Gestión de Respuestas + +Una misma plantilla de Encuesta se puede implementar varias veces simultáneamente. Todas las respuestas a las múltiples implementaciones de la misma plantilla de Encuesta se mostrarán juntas en la tabla de Respuestas en la parte inferior de la vista de esa Encuesta. + +![imagen](images/pq_ss11.png) + +Incluso después de que una implementación de Encuesta haya vencido o se haya cerrado, sus respuestas permanecen visibles en la tabla de Respuestas en la parte inferior de la vista de la Encuesta, siempre que la propia plantilla de Encuesta no se haya eliminado. Estas respuestas son permanentes y no se pueden eliminar. + +Como se muestra en la imagen a continuación, actualmente no hay implementaciones de Encuesta abiertas, pero las respuestas de implementaciones anteriores todavía están presentes en la tabla de Respuestas. + +![imagen](images/pq_ss12.png) + +### Eliminar plantillas de Encuesta + +Para eliminar una plantilla de Encuesta, vaya a la vista Todas las encuestas, haga clic en el icono de kebab ⋮ a la izquierda de la Encuesta elegida y haga clic en **Eliminar encuesta**. Esto elimina permanentemente la plantilla de Encuesta y todas las implementaciones y Respuestas asociadas. Esta acción no se puede deshacer. diff --git a/docs/content/asset_modelling/PRO_surveys/PRO__surveys.fr.md b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.fr.md new file mode 100644 index 00000000000..f44f36b156c --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.fr.md @@ -0,0 +1,147 @@ +--- +title: Sondages +description: Comprendre les sondages dans DefectDojo Pro +audience: pro +weight: 2 +--- + +Dans DefectDojo, un modèle de sondage est un ensemble réutilisable de questions qui sert à recueillir des informations auprès des développeurs, des équipes et des parties prenantes internes comme externes. Ils peuvent être utilisés pour recueillir des avis avant le début des travaux, garantir l'alignement entre les individus et les équipes à mesure que le travail progresse, et permettre une analyse rétrospective une fois le travail terminé. + +Dans DefectDojo, un système de sondage se compose de trois éléments : +- les **modèles de sondage**, qui regroupent et ordonnent les questions. +- les **déploiements de sondage**, qui sont des instances actives collectant des réponses. +- les **réponses**, qui sont les réponses soumises par les utilisateurs. + +Créer un modèle de sondage ne le rend pas automatiquement disponible pour recevoir des réponses. Pour collecter des réponses, un modèle de sondage doit être déployé. + +## Autorisations + +La section Sondages dans la barre latérale n'est visible que pour les utilisateurs ayant le statut de Superutilisateur, et seuls les Superutilisateurs peuvent créer des modèles de sondage, créer des questions et déployer des sondages. + +Les utilisateurs sans statut de Superutilisateur peuvent tout de même répondre aux sondages qui sont partagés avec eux, mais ils ne peuvent ni les créer ni les gérer, ni gérer leurs questions associées. + +## Accéder aux sondages et aux questions + +Les utilisateurs ayant le statut de Superutilisateur peuvent accéder aux sondages et aux questions depuis la barre latérale en cliquant sur l'option **Surveys**. Le sous-menu donne accès à **All Surveys** et **All Questions**, ainsi qu'à l'option permettant de créer de nouveaux sondages et de nouvelles questions. + +![image](images/pq_ss1.png) + +### Accéder aux sondages + +La vue All Surveys comprend un tableau contenant tous les modèles de sondage, avec leur ID, leur nom, leur description et leur statut actif. Le tableau peut être filtré à l'aide de mots-clés, et il peut être réorganisé en cliquant sur l'en-tête de chaque colonne. + +### Accéder aux questions + +La vue All Questions comprend un tableau des questions pouvant être ajoutées à un sondage. Le tableau peut être filtré à l'aide de mots-clés, et il peut être réorganisé en cliquant sur l'en-tête de chaque colonne. + +## Gérer les modèles de sondage + +### Créer des modèles de sondage + +Les modèles de sondage peuvent être créés soit en cliquant sur **New Survey** dans la barre latérale, soit en cliquant sur le bouton **New Survey** en haut de la vue All Surveys. + +![image](images/pq_ss2.png) + +Le modèle de sondage doit se voir attribuer un nom et une description, et comporter au moins une question choisie dans le menu déroulant, avant de pouvoir être créé. + +#### Ajouter des questions à un modèle de sondage existant + +Pour ajouter des questions à un modèle de sondage existant, cliquez sur l'icône kebab ⋮ à gauche du sondage souhaité, cliquez sur **Edit Survey**, sélectionnez les nouvelles questions à ajouter au sondage dans le menu déroulant, puis cliquez sur **Submit**. + +En bonne pratique, il est fortement recommandé d'éviter de modifier ou d'ajouter des questions à un modèle de sondage pendant qu'il a des déploiements actifs. L'ajout de nouvelles questions n'affectera pas les réponses existantes, mais ces réponses auront été soumises sans répondre aux questions nouvellement ajoutées, ce qui peut entraîner des données incomplètes. + +### Créer des questions + +Comme pour les modèles de sondage, les questions peuvent être créées soit en cliquant sur **New Question** dans la barre latérale, soit en cliquant sur le bouton **New Question** en haut de la vue All Questions. + +#### Types de questions + +Lors de la création d'une nouvelle question, elle peut être formatée soit comme une question textuelle, soit comme une question à choix multiples, en sélectionnant **Text Question** ou **Choice Question** en haut de la vue New Question. + +![image](images/pq_ss3.png) + +#### Ordre des questions + +Déterminez l'ordre d'une question en lui attribuant un numéro d'ordre. Par exemple, si une question a la valeur 1 dans le champ Order, cette question apparaîtra au-dessus d'une question ayant la valeur 2 dans le champ Order. + +#### Réponses optionnelles + +Les questions textuelles comme les questions à choix multiples peuvent être marquées comme **Optional** en cochant la case correspondante. + +#### Autoriser plusieurs réponses + +Un nombre illimité de réponses potentielles peut être ajouté à une question à choix multiples. Cocher la case **Allow Multiple Selections** permet de sélectionner plusieurs réponses (disponible uniquement pour les questions à choix multiples). + +### Modifier des questions + +Pour modifier une question, accédez à la vue All Questions, cliquez sur l'icône kebab ⋮ à gauche de la question à modifier, cliquez sur Edit Question, effectuez la modification souhaitée, puis validez-la en cliquant sur Submit. Les questions ne peuvent pas être supprimées. + +![image](images/pq_ss4.png) + +Il est important d'éviter de modifier des questions faisant partie de sondages actifs, ou d'ajouter des questions à des sondages actifs. Cela n'affectera pas les réponses déjà collectées, mais peut entraîner des données incomplètes ou peu fiables. + +## Déployer des sondages + +Une fois qu'un modèle de sondage a été créé avec succès, le déploiement d'un sondage crée une instance active qui accepte les réponses. + +Pour déployer un sondage, accédez à la vue All Surveys, cliquez sur l'icône kebab ⋮ à gauche du sondage à déployer, cliquez sur **Open Survey**, définissez la date d'expiration, puis cliquez sur Submit. + +Si vous souhaitez déployer à nouveau le même sondage, suivez la même procédure. Tous les déploiements apparaîtront dans le tableau Open Survey Instances, dans la vue du sondage, et peuvent être distingués par leur ID, leur heure de création et leur date d'expiration. + +![image](images/pq_ss10.png) + +Un sondage se clôturera à la date choisie, à la même heure que celle de son déploiement. Par exemple, si vous déployez un sondage à 8h00 le 1er février 2026, et programmez sa clôture au 1er mars 2026, le sondage se clôturera à 8h00 le matin du 1er mars 2026. + +Une fois qu'un sondage a été ouvert, sa date et son heure d'expiration ne peuvent plus être modifiées. Si un délai différent est nécessaire, un nouveau déploiement doit être créé. + +Une fois qu'une date d'expiration est passée, il ne sera plus possible de soumettre des réponses à ce déploiement du sondage, mais le déploiement continuera d'apparaître dans le tableau Open Survey Instances de la vue de ce sondage. + +#### Partager un sondage + +Une fois qu'un sondage a été déployé, il peut être partagé avec d'autres utilisateurs en cliquant sur l'icône ↗ à gauche du sondage dans le tableau Open Survey Instances, dans la vue du modèle de sondage. Cela révèle un lien propre à ce déploiement, qui peut être copié et partagé avec les destinataires visés. + +![image](images/pq_ss5.png) + +![image](images/pq_ss9.png) + +#### Clôturer un sondage + +Pour clôturer un sondage, cliquez sur le **X** rouge à gauche du sondage dans le tableau Open Survey Instances, dans la vue du modèle de sondage. + +![image](images/pq_ss13.png) + +Comme indiqué dans la section Responses plus bas, cela empêchera uniquement la soumission de nouvelles réponses. Les réponses soumises précédemment resteront visibles dans le tableau des réponses en bas de la vue du modèle de sondage. + +## Répondre aux sondages + +Pour répondre à un sondage, les utilisateurs non-Superutilisateurs doivent avoir reçu le lien directement, en suivant les instructions de la section [Sharing a Survey](#sharing-a-survey) ci-dessus. Les Superutilisateurs peuvent également répondre en utilisant le même lien. + +#### Activer les réponses anonymes + +Par défaut, les sondages ne sont accessibles qu'aux utilisateurs DefectDojo. Pour permettre à des parties externes de répondre aux sondages DefectDojo, assurez-vous que l'option **Enable Anonymous Survey Responses** a été activée dans les **System Settings**, accessibles via **Settings > System** dans la barre latérale (dans le sous-menu **Pro Settings** sur les instances utilisant encore l'ancienne disposition de menu). + +![image](images/pq_ss6.png) + +Les réponses externes apparaîtront comme anonymes, car aucun ID d'utilisateur DefectDojo n'est associé à la réponse. + +Si le périmètre d'un sondage inclut à la fois des utilisateurs internes et externes, indiquez le nom de l'Engagement dans la description lors de la création, ce qui permettra de filtrer les résultats. + +![image](images/pq_ss7.png) + +![image](images/pq_ss8.png) + +## Gérer les réponses + +Un même modèle de sondage peut être déployé plusieurs fois simultanément. Toutes les réponses aux multiples déploiements d'un même modèle de sondage seront affichées ensemble dans le tableau des réponses en bas de la vue de ce sondage. + +![image](images/pq_ss11.png) + +Même après l'expiration ou la clôture d'un déploiement de sondage, ses réponses restent visibles dans le tableau des réponses en bas de la vue du sondage, à condition que le modèle de sondage lui-même n'ait pas été supprimé. Ces réponses sont permanentes et ne peuvent pas être supprimées. + +Comme le montre l'image ci-dessous, aucun déploiement de sondage n'est actuellement ouvert, mais les réponses des déploiements précédents sont toujours présentes dans le tableau des réponses. + +![image](images/pq_ss12.png) + +### Supprimer des modèles de sondage + +Pour supprimer un modèle de sondage, accédez à la vue All Surveys, cliquez sur l'icône kebab ⋮ à gauche du sondage choisi, puis cliquez sur **Delete Survey**. Cela supprime définitivement le modèle de sondage ainsi que tous les déploiements et réponses associés. Cette action est irréversible. diff --git a/docs/content/asset_modelling/PRO_surveys/PRO__surveys.ja.md b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.ja.md new file mode 100644 index 00000000000..c29cd963c9e --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.ja.md @@ -0,0 +1,147 @@ +--- +title: アンケート +description: DefectDojo Proにおけるアンケートについて +audience: pro +weight: 2 +--- + +DefectDojoでは、アンケートテンプレートは、開発者、チーム、および社内外のステークホルダーから情報を収集するための、再利用可能な質問のセットです。作業開始前に意見を集めたり、作業が進行する中で個人やチーム間の足並みをそろえたり、作業完了後に振り返り分析を行ったりするために使用できます。 + +DefectDojoでは、アンケートシステムは3つの要素で構成されます。 +- **アンケートテンプレート**:質問をグループ化して順序付けします。 +- **アンケートのデプロイ**:回答を収集するアクティブなインスタンスです。 +- **回答**:ユーザーによって送信された回答です。 + +アンケートテンプレートを作成しただけでは、自動的に回答を受け付けられるようにはなりません。回答を収集するには、アンケートをデプロイする必要があります。 + +## 権限 + +サイドバーの「アンケート」セクションは、スーパーユーザー権限を持つユーザーにのみ表示され、アンケートテンプレートの作成、質問の作成、アンケートのデプロイができるのはスーパーユーザーのみです。 + +スーパーユーザー権限を持たないユーザーも、自分と共有されたアンケートに回答することはできますが、それらやそれに関連する質問を作成または管理することはできません。 + +## アンケートと質問へのアクセス + +スーパーユーザー権限を持つユーザーは、サイドバーの**アンケート**オプションをクリックすることで、アンケートと質問にアクセスできます。サブメニューからは、**すべてのアンケート**と**すべての質問**、および新しいアンケートと質問を作成するオプションにアクセスできます。 + +![image](images/pq_ss1.png) + +### アンケートへのアクセス + +「すべてのアンケート」のビューには、ID、名前、説明、アクティブステータスを含む、すべてのアンケートテンプレートのテーブルが表示されます。このテーブルはキーワードでフィルタリングでき、各列のヘッダーをクリックすることで並べ替えることもできます。 + +### 質問へのアクセス + +「すべての質問」のビューには、アンケートに追加できる質問のテーブルが表示されます。このテーブルはキーワードでフィルタリングでき、各列のヘッダーをクリックすることで並べ替えることもできます。 + +## アンケートテンプレートの管理 + +### アンケートテンプレートの作成 + +アンケートテンプレートは、サイドバーの**新しいアンケート**をクリックするか、「すべてのアンケート」ビューの上部にある**新しいアンケート**ボタンをクリックすることで作成できます。 + +![image](images/pq_ss2.png) + +アンケートテンプレートを作成する前に、名前と説明を入力し、ドロップダウンメニューから少なくとも1つの質問を選択する必要があります。 + +#### 既存のアンケートテンプレートへの質問の追加 + +既存のアンケートテンプレートに質問を追加するには、対象のアンケートの左にある⋮ケバブアイコンをクリックし、**アンケートを編集**をクリックして、ドロップダウンメニューからアンケートに追加する新しい質問を選択し、**送信**をクリックします。 + +ベストプラクティスとして、アクティブなデプロイがあるアンケートテンプレートに対して質問を変更したり追加したりすることは強く避けることが推奨されます。新しい質問を追加しても既存の回答には影響しませんが、それらの回答は新しく追加された質問に回答しないまま送信されたことになり、データが不完全になる可能性があります。 + +### 質問の作成 + +アンケートテンプレートと同様に、質問はサイドバーの**新しい質問**をクリックするか、「すべての質問」ビューの上部にある**新しい質問**ボタンをクリックすることで作成できます。 + +#### 質問の種類 + +新しい質問を作成する際、新しい質問のビューの上部で**テキスト質問**または**選択質問**を選択することで、テキストベースの質問または選択式の質問としてフォーマットできます。 + +![image](images/pq_ss3.png) + +#### 質問の順序 + +質問に順序番号を付けることで、質問の順序を決定します。例えば、ある質問の「順序」フィールドに1が設定されている場合、その質問は「順序」フィールドに2が設定されている質問より上に表示されます。 + +#### 任意の回答 + +テキストベースの質問と選択式の質問はどちらも、対応するチェックボックスをクリックすることで**任意**として切り替えることができます。 + +#### 複数回答の許可 + +選択式の質問には、無制限の数の候補回答を追加できます。**複数選択を許可**チェックボックスをクリックすると、複数の回答を選択できるようになります(選択式の質問でのみ利用可能)。 + +### 質問の編集 + +質問を変更するには、「すべての質問」ビューに移動し、変更する質問の左にある⋮ケバブアイコンをクリックして、「質問を編集」をクリックし、必要な変更を行った後、「送信」をクリックして変更を確定します。質問を削除することはできません。 + +![image](images/pq_ss4.png) + +アクティブなアンケートの一部である質問を編集したり、アクティブなアンケートに質問を追加したりすることは避けることが重要です。そうしても、それ以前に収集された回答には影響しませんが、データが不完全または信頼性の低いものになる可能性があります。 + +## アンケートのデプロイ + +アンケートテンプレートが正常に作成されたら、アンケートをデプロイすることで、回答を受け付けるアクティブなインスタンスが作成されます。 + +アンケートをデプロイするには、「すべてのアンケート」ビューに移動し、デプロイするアンケートの左にある⋮ケバブアイコンをクリックして、**アンケートを開く**をクリックし、有効期限を設定して、「送信」をクリックします。 + +同じアンケートを再度デプロイしたい場合は、同じ手順に従ってください。すべてのデプロイは、そのアンケートのビュー内の「公開中のアンケートインスタンス」テーブルに表示され、ID、作成日時、有効期限によって区別できます。 + +![image](images/pq_ss10.png) + +アンケートは、選択した日付のデプロイと同じ時刻にクローズされます。例えば、2026年2月1日午前8時にアンケートをデプロイし、2026年3月1日にクローズするように設定した場合、そのアンケートは2026年3月1日の午前8時にクローズされます。 + +アンケートが一度開始されると、その有効期限の日時を変更することはできません。異なる期間が必要な場合は、新しいデプロイを作成する必要があります。 + +有効期限が過ぎると、そのデプロイに対して回答を送信することはできなくなりますが、そのデプロイは引き続きそのアンケートのビューの「公開中のアンケートインスタンス」テーブルに表示されます。 + +#### アンケートの共有 + +アンケートがデプロイされたら、アンケートテンプレートのビュー内の「公開中のアンケートインスタンス」テーブルにあるそのアンケートの左の↗アイコンをクリックすることで、他のユーザーと共有できます。これにより、そのデプロイに固有のリンクが表示され、コピーして対象の受信者と共有できます。 + +![image](images/pq_ss5.png) + +![image](images/pq_ss9.png) + +#### アンケートのクローズ + +アンケートをクローズするには、アンケートテンプレートのビュー内の「公開中のアンケートインスタンス」テーブルにあるそのアンケートの左の赤い**X**をクリックします。 + +![image](images/pq_ss13.png) + +後述の「回答」セクションで述べるように、これによって以降の回答の送信が妨げられるだけです。それ以前に送信された回答は、アンケートテンプレートのビューの下部にある「回答」テーブルに引き続き表示されます。 + +## アンケートへの回答 + +アンケートに回答するには、スーパーユーザーでないユーザーは、上記の[アンケートの共有](#sharing-a-survey)セクションの手順に従って、直接共有されたリンクを持っている必要があります。スーパーユーザーも同じリンクを使用して回答できます。 + +#### 匿名回答の有効化 + +デフォルトでは、アンケートはDefectDojoユーザーのみがアクセスできます。外部の関係者がDefectDojoのアンケートに回答できるようにするには、サイドバーの**設定 > システム**にある**システム設定**(以前のメニューレイアウトを使用しているインスタンスでは**Pro設定**サブメニュー内)で、**匿名アンケート回答を有効にする**オプションが有効になっていることを確認してください。 + +![image](images/pq_ss6.png) + +外部からの回答には、回答に紐づくDefectDojoのユーザーIDが存在しないため、匿名として表示されます。 + +アンケートの対象範囲に社内と社外の両方のユーザーが含まれる場合は、作成時に説明欄にエンゲージメント名を指定してください。これにより、結果のフィルタリングが可能になります。 + +![image](images/pq_ss7.png) + +![image](images/pq_ss8.png) + +## 回答の管理 + +1つのアンケートテンプレートは、同時に複数回デプロイできます。同じアンケートテンプレートの複数のデプロイに対するすべての回答は、そのアンケートのビューの下部にある「回答」テーブルにまとめて表示されます。 + +![image](images/pq_ss11.png) + +アンケートのデプロイが期限切れになったりクローズされたりした後も、アンケートテンプレート自体が削除されていない限り、その回答はそのアンケートのビューの下部にある「回答」テーブルに引き続き表示されます。これらの回答は永続的なものであり、削除することはできません。 + +以下の画像に示すように、現在公開中のアンケートのデプロイは存在しませんが、以前のデプロイからの回答は依然として「回答」テーブルに残っています。 + +![image](images/pq_ss12.png) + +### アンケートテンプレートの削除 + +アンケートテンプレートを削除するには、「すべてのアンケート」ビューに移動し、選択したアンケートの左にある⋮ケバブアイコンをクリックして、**アンケートを削除**をクリックします。これにより、アンケートテンプレートと、それに関連するすべてのデプロイおよび回答が完全に削除されます。この操作は元に戻せません。 diff --git a/docs/content/asset_modelling/PRO_surveys/_index.de.md b/docs/content/asset_modelling/PRO_surveys/_index.de.md new file mode 100644 index 00000000000..ebf739b67aa --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/_index.de.md @@ -0,0 +1,9 @@ +--- +title: Umfragen +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +audience: pro +--- diff --git a/docs/content/asset_modelling/PRO_surveys/_index.es.md b/docs/content/asset_modelling/PRO_surveys/_index.es.md new file mode 100644 index 00000000000..9ce2a34e9cf --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/_index.es.md @@ -0,0 +1,9 @@ +--- +title: Encuestas +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +audience: pro +--- diff --git a/docs/content/asset_modelling/PRO_surveys/_index.fr.md b/docs/content/asset_modelling/PRO_surveys/_index.fr.md new file mode 100644 index 00000000000..fb89a175ab4 --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/_index.fr.md @@ -0,0 +1,9 @@ +--- +title: Sondages +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +audience: pro +--- diff --git a/docs/content/asset_modelling/PRO_surveys/_index.ja.md b/docs/content/asset_modelling/PRO_surveys/_index.ja.md new file mode 100644 index 00000000000..506edbba3f5 --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/_index.ja.md @@ -0,0 +1,9 @@ +--- +title: アンケート +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +audience: pro +--- diff --git a/docs/content/asset_modelling/_index.de.md b/docs/content/asset_modelling/_index.de.md new file mode 100644 index 00000000000..1bb362e1660 --- /dev/null +++ b/docs/content/asset_modelling/_index.de.md @@ -0,0 +1,10 @@ +--- +title: DefectDojo organisieren +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/_index.es.md b/docs/content/asset_modelling/_index.es.md new file mode 100644 index 00000000000..ac2bc111462 --- /dev/null +++ b/docs/content/asset_modelling/_index.es.md @@ -0,0 +1,10 @@ +--- +title: Organizar DefectDojo +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/_index.fr.md b/docs/content/asset_modelling/_index.fr.md new file mode 100644 index 00000000000..daa8f9ae2c3 --- /dev/null +++ b/docs/content/asset_modelling/_index.fr.md @@ -0,0 +1,10 @@ +--- +title: Organiser DefectDojo +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/_index.ja.md b/docs/content/asset_modelling/_index.ja.md new file mode 100644 index 00000000000..56b79aa9fe7 --- /dev/null +++ b/docs/content/asset_modelling/_index.ja.md @@ -0,0 +1,10 @@ +--- +title: DefectDojoを整理する +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/components/PRO__components.de.md b/docs/content/asset_modelling/components/PRO__components.de.md new file mode 100644 index 00000000000..8874cf39070 --- /dev/null +++ b/docs/content/asset_modelling/components/PRO__components.de.md @@ -0,0 +1,69 @@ +--- +title: Komponenten +description: Nachverfolgung von Drittanbieter-Bibliotheken und Softwarekomponenten + in DefectDojo Pro +audience: pro +weight: 1 +--- + +In DefectDojo repräsentieren Komponenten Drittanbieter-Bibliotheken, Softwarekomponenten und Module, die potenziell Schwachstellen aufweisen. + + +## Komponentenansichten + +DefectDojo Pro enthält eine eigene Tabellenansicht für Komponenten, die Sie in der Seitenleiste finden. Diese Ansicht zeigt für jede Komponente die aktiven Findings, die doppelten Findings und die Gesamtzahl der Findings. Diese Zahlen umfassen alle Assets der DefectDojo-Instanz. + +Die Komponenten eines einzelnen Assets sehen Sie in der Asset-Ansicht. + +## Die Komponententabelle + +Die Komponententabelle zeigt die folgenden Spalten: + +* **Komponente** — der Name der Komponente, befüllt aus den Scan-Daten. +* **Version** — die Version der Komponente, befüllt aus den Scan-Daten. +* **Aktive Findings** — Anzahl der aktiven Findings, die dieser Komponente zugeordnet sind. +* **Doppelte Findings** — Anzahl der doppelten Findings, die dieser Komponente zugeordnet sind. +* **Findings insgesamt** — Gesamtzahl aller Findings, die dieser Komponente zugeordnet sind. + +Wenn Sie auf den Komponentennamen oder auf die Werte für Aktive Findings, Doppelte Findings oder Findings insgesamt klicken, öffnet sich eine nach dem jeweiligen Feld gefilterte Liste von Findings. + +In der Tabelle wird eine Komponente **None** angezeigt, die alle Findings enthält, die keiner Komponente zugeordnet sind. + +Importierte Komponenten bleiben auch dann in der Tabelle, wenn alle zugehörigen Findings behoben wurden. Wenn Findings für eine bestimmte Komponente importiert werden, wird die Komponententabelle aktualisiert, um die neuen Finding-Summen korrekt widerzuspiegeln. + + +### Beispiel + +Eine Komponente, die aus einem Dependency-Check-Scan einer Anwendung mit einer anfälligen `lodash`-Abhängigkeit importiert wurde, könnte in der Tabelle wie folgt aussehen: + +| Komponente | Version | Aktive Findings | Doppelte Findings | Findings insgesamt | +| --- | --- | --- | --- | --- | +| npm:lodash | 4.17.15 | 3 | 1 | 5 | + +Ein Klick auf `npm:lodash` öffnet die Liste aller Findings, die auf diese Komponente verweisen. Ein Klick auf `3` öffnet dieselbe Liste, gefiltert auf nur aktive Findings. + +## Komponenten hinzufügen + +Komponenten können aus einem Scan-Import geparst oder durch manuelles Bearbeiten eines Findings hinzugefügt werden. Sobald ein Komponentenname mit einem Finding verknüpft ist, wird der Komponententabelle automatisch ein entsprechender Eintrag hinzugefügt. Wenn die Komponente bereits mit anderen Findings in DefectDojo verknüpft ist, werden die Summen für Aktive Findings, Doppelte Findings und Findings insgesamt entsprechend aktualisiert. + +### Wie Komponenten aus Scan-Daten geparst werden + +Beim Importieren eines Scans befüllen die Parser bei jedem Finding die Felder **Komponentenname** und **Komponentenversion** anhand der Scan-Ausgabe. Die Komponententabelle wird anschließend aus diesen Werten erstellt. Der Detailgrad und die Namenskonvention hängen vom Tool ab, mit dem der Scan erstellt wurde: + +* **Software Composition Analysis (SCA)-Tools** melden in der Regel einen Paketnamen und eine genaue Version. OWASP Dependency-Check leitet die Komponente beispielsweise aus der [Package URL](https://github.com/package-url/purl-spec) in ihrer ID ab — aus einer purl `pkg:npm/lodash@4.17.15` wird `Component Name: npm:lodash`, `Component Version: 4.17.15`. +* **Container- und Betriebssystem-Paket-Scanner** wie Trivy, Anchore Grype und Anchore Engine melden das betroffene Betriebssystem- oder Sprachpaket — zum Beispiel `Component Name: curl`, `Component Version: 7.68.0`. +* **Sprachspezifische Abhängigkeits-Scanner** wie npm Audit, pip-audit, bundler-audit, Retire.js, Govulncheck und OSV-Scanner befüllen das betreffende Paket und die Version anhand der jeweiligen Ökosystem-Manifeste. + +Scanner, die sich auf Konfiguration, Infrastruktur oder Quellcode-Logik konzentrieren (wie SAST- und IaC-Tools), befüllen die Komponentenfelder in der Regel nicht; ihre Findings erscheinen unter der Komponente **None**. + +Um eine Komponente manuell hinzuzufügen oder zu ändern, bearbeiten Sie das Finding und setzen Sie die Felder **Komponentenname** und **Komponentenversion** direkt. Die Komponententabelle wird aktualisiert, sobald das Finding gespeichert wird. + +## Komponenten aktualisieren + +Um einen Komponentennamen oder eine Version zu aktualisieren, müssen bei allen mit der Komponente verknüpften Findings die Felder Komponentenname oder Komponentenversion aktualisiert werden. + +## Komponenten entfernen + +Um eine Komponente aus der Komponententabelle zu entfernen, müssen bei allen mit der Komponente verknüpften Findings die Felder Komponentenname und Komponentenversion entfernt werden. Komponenten werden außerdem entfernt, wenn alle zugehörigen Findings gelöscht werden. + +Wenn alle Findings einer Komponente behoben sind, bleibt die Komponente in der Tabelle, aber ihr Wert für Aktive Findings wird auf 0 gesetzt. diff --git a/docs/content/asset_modelling/components/PRO__components.es.md b/docs/content/asset_modelling/components/PRO__components.es.md new file mode 100644 index 00000000000..e3ab1b5c7fb --- /dev/null +++ b/docs/content/asset_modelling/components/PRO__components.es.md @@ -0,0 +1,69 @@ +--- +title: Componentes +description: Seguimiento de bibliotecas de terceros y componentes de software en DefectDojo + Pro +audience: pro +weight: 1 +--- + +En DefectDojo, los Componentes representan bibliotecas de terceros, componentes de software y módulos que potencialmente presentan vulnerabilidades. + + +## Vistas de componentes + +DefectDojo Pro incluye una vista de tabla dedicada para Componentes, que se encuentra en la barra lateral. Esta vista muestra los Hallazgos activos, los Hallazgos duplicados y el total de Hallazgos de cada Componente. Estas cifras incluyen todos los Activos de la instancia de DefectDojo. + +Los Componentes de un Activo individual se pueden ver en la vista del Activo. + +## La tabla de componentes + +La tabla de componentes muestra las siguientes columnas: + +* **Componente** — el nombre del componente, obtenido de los datos del escaneo. +* **Versión** — la versión del componente, obtenida de los datos del escaneo. +* **Hallazgos activos** — cantidad de Hallazgos activos asociados con el componente. +* **Hallazgos duplicados** — cantidad de Hallazgos duplicados asociados con el componente. +* **Total de hallazgos** — cantidad total de todos los Hallazgos asociados con el componente. + +Al hacer clic en el nombre del componente o en los valores de Hallazgos activos, Hallazgos duplicados o Total de hallazgos se abre una lista filtrada de Hallazgos para el campo correspondiente. + +En la tabla se muestra un Componente **None**, que agrupa todos los Hallazgos que no están asociados con ningún Componente. + +Los Componentes importados permanecen en la tabla incluso si todos sus Hallazgos asociados están Mitigados. Cuando se importan Hallazgos para un Componente específico, la tabla de componentes se actualiza para reflejar con precisión los nuevos totales de Hallazgos. + + +### Ejemplo + +Un Componente importado de un escaneo de Dependency-Check contra una aplicación con una dependencia `lodash` vulnerable podría aparecer en la tabla de la siguiente manera: + +| Componente | Versión | Hallazgos activos | Hallazgos duplicados | Total de hallazgos | +| --- | --- | --- | --- | --- | +| npm:lodash | 4.17.15 | 3 | 1 | 5 | + +Al hacer clic en `npm:lodash` se abre la lista de todos los Hallazgos que hacen referencia a este Componente. Al hacer clic en `3` se abre la misma lista filtrada solo a Hallazgos activos. + +## Agregar componentes + +Los Componentes se pueden analizar a partir de la importación de un escaneo o editando manualmente un Hallazgo. Una vez que un Nombre de componente se asocia con un Hallazgo, se agregará automáticamente una entrada correspondiente a la tabla de componentes. Si el Componente ya está asociado con otros Hallazgos en DefectDojo, los totales de Hallazgos activos, Hallazgos duplicados y Total de hallazgos se actualizan en consecuencia. + +### Cómo se analizan los componentes a partir de los datos del escaneo + +Cuando se importa un escaneo, los parsers completan los campos **Component Name** y **Component Version** de cada Hallazgo a partir de la salida del escaneo. La tabla de componentes se construye luego a partir de esos valores. El nivel de detalle y la convención de nomenclatura dependen de la herramienta que generó el escaneo: + +* Las herramientas de **Análisis de composición de software (SCA)** generalmente informan un nombre de paquete y una versión exacta. Por ejemplo, OWASP Dependency-Check obtiene el Componente a partir de la [Package URL](https://github.com/package-url/purl-spec) de su identificador — un purl `pkg:npm/lodash@4.17.15` se convierte en `Component Name: npm:lodash`, `Component Version: 4.17.15`. +* Los **escáneres de contenedores y paquetes del SO**, como Trivy, Anchore Grype y Anchore Engine, informan el paquete de SO o de lenguaje afectado — por ejemplo, `Component Name: curl`, `Component Version: 7.68.0`. +* Los **escáneres de dependencias específicos de lenguaje**, como npm Audit, pip-audit, bundler-audit, Retire.js, Govulncheck y OSV-Scanner, completan el paquete y la versión responsables a partir de los manifiestos de su respectivo ecosistema. + +Los escáneres enfocados en configuración, infraestructura o lógica del código fuente (como las herramientas SAST e IaC) generalmente no completan los campos de Componente, y sus Hallazgos aparecen bajo el Componente **None**. + +Para agregar o cambiar un Componente manualmente, edite el Hallazgo y establezca directamente los campos **Nombre del componente** y **Versión del componente**. La tabla de componentes se actualiza en cuanto se guarda el Hallazgo. + +## Actualizar componentes + +Para actualizar el nombre o la versión de un Componente, se debe actualizar el campo Nombre del componente o Versión del componente de todos los Hallazgos asociados con ese Componente. + +## Quitar componentes + +Para quitar un Componente de la tabla de componentes, se deben actualizar todos los Hallazgos asociados con el Componente para eliminar sus campos Nombre del componente y Versión del componente. Los Componentes también se eliminan si se eliminan todos sus Hallazgos asociados. + +Si todos los Hallazgos de un Componente están Mitigados, el Componente permanece en la tabla, pero su valor de Hallazgos activos se establece en 0. diff --git a/docs/content/asset_modelling/components/PRO__components.fr.md b/docs/content/asset_modelling/components/PRO__components.fr.md new file mode 100644 index 00000000000..654407d0f99 --- /dev/null +++ b/docs/content/asset_modelling/components/PRO__components.fr.md @@ -0,0 +1,69 @@ +--- +title: Composants +description: Suivi des bibliothèques tierces et des composants logiciels dans DefectDojo + Pro +audience: pro +weight: 1 +--- + +Dans DefectDojo, les Composants représentent des bibliothèques tierces, des composants logiciels et des modules susceptibles de comporter des vulnérabilités. + + +## Vues des composants + +DefectDojo Pro inclut une vue tableau dédiée aux Composants, accessible depuis la barre latérale. Cette vue affiche les Constatations actives, les Constatations en doublon et le Total des constatations pour chaque Composant. Ces chiffres incluent tous les Actifs de l'instance DefectDojo. + +Les Composants d'un Actif donné peuvent être consultés sur la vue de cet Actif. + +## Le tableau des composants + +Le tableau des composants affiche les colonnes suivantes : + +* **Composant** — le nom du composant, renseigné à partir des données du scan. +* **Version** — la version du composant, renseignée à partir des données du scan. +* **Constatations actives** — nombre de Constatations actives associées au composant. +* **Constatations en doublon** — nombre de Constatations en doublon associées au composant. +* **Total des constatations** — nombre total de toutes les Constatations associées au composant. + +Cliquer sur le nom du composant ou sur les valeurs des Constatations actives, des Constatations en doublon ou du Total des constatations ouvre une liste filtrée des Constatations pour le champ correspondant. + +Un composant **None** est affiché dans le tableau ; il regroupe toutes les Constatations qui ne sont associées à aucun composant. + +Les composants importés restent dans le tableau même si toutes leurs Constatations associées sont Atténuées. Lorsque des Constatations sont importées pour un composant spécifique, le tableau des composants est mis à jour pour refléter précisément les nouveaux totaux de constatations. + + +### Exemple + +Un composant importé à partir d'un scan Dependency-Check portant sur une application avec une dépendance `lodash` vulnérable pourrait apparaître dans le tableau comme suit : + +| Composant | Version | Constatations actives | Constatations en doublon | Total des constatations | +| --- | --- | --- | --- | --- | +| npm:lodash | 4.17.15 | 3 | 1 | 5 | + +Cliquer sur `npm:lodash` ouvre la liste de toutes les Constatations référençant ce composant. Cliquer sur `3` ouvre la même liste filtrée aux seules Constatations actives. + +## Ajout de composants + +Les composants peuvent être extraits d'une importation de scan ou ajoutés en modifiant manuellement une Constatation. Une fois qu'un nom de composant est associé à une Constatation, une entrée correspondante est automatiquement ajoutée au tableau des composants. Si le composant est déjà associé à d'autres Constatations dans DefectDojo, les totaux des Constatations actives, des Constatations en doublon et du Total des constatations sont mis à jour en conséquence. + +### Comment les composants sont extraits des données de scan + +Lors de l'importation d'un scan, les parseurs renseignent les champs **Nom du composant** et **Version du composant** de chaque Constatation à partir de la sortie du scan. Le tableau des composants est ensuite construit à partir de ces valeurs. Le niveau de détail et la convention de nommage dépendent de l'outil ayant produit le scan : + +* Les **outils d'analyse de composition logicielle (SCA)** rapportent généralement un nom de package et une version exacte. Par exemple, OWASP Dependency-Check dérive le composant à partir du [Package URL](https://github.com/package-url/purl-spec) dans son identifiant — un purl `pkg:npm/lodash@4.17.15` devient `Component Name: npm:lodash`, `Component Version: 4.17.15`. +* Les **scanners de conteneurs et de packages OS** tels que Trivy, Anchore Grype et Anchore Engine rapportent le package OS ou langage affecté — par exemple, `Component Name: curl`, `Component Version: 7.68.0`. +* Les **scanners de dépendances spécifiques à un langage** tels que npm Audit, pip-audit, bundler-audit, Retire.js, Govulncheck et OSV-Scanner renseignent le package fautif et sa version à partir des manifestes de leur écosystème respectif. + +Les scanners axés sur la configuration, l'infrastructure ou la logique du code source (comme les outils SAST et IaC) ne renseignent généralement pas les champs de composant, et leurs Constatations apparaissent sous le composant **None**. + +Pour ajouter ou modifier un composant manuellement, modifiez la Constatation et définissez directement les champs **Nom du composant** et **Version du composant**. Le tableau des composants se met à jour dès que la Constatation est enregistrée. + +## Mise à jour des composants + +Pour mettre à jour un nom ou une version de composant, toutes les Constatations associées au composant doivent avoir leur champ Nom du composant ou Version du composant mis à jour. + +## Suppression des composants + +Pour supprimer un composant du tableau des composants, toutes les Constatations associées au composant doivent être mises à jour afin de retirer leurs champs Nom du composant et Version du composant. Les composants sont également supprimés si toutes leurs Constatations associées sont supprimées. + +Si toutes les Constatations d'un composant sont Atténuées, le composant reste dans le tableau, mais sa valeur de Constatations actives est fixée à 0. diff --git a/docs/content/asset_modelling/components/PRO__components.ja.md b/docs/content/asset_modelling/components/PRO__components.ja.md new file mode 100644 index 00000000000..24023201e08 --- /dev/null +++ b/docs/content/asset_modelling/components/PRO__components.ja.md @@ -0,0 +1,68 @@ +--- +title: コンポーネント +description: DefectDojo Proでサードパーティライブラリとソフトウェアコンポーネントを追跡する +audience: pro +weight: 1 +--- + +DefectDojoにおいて、コンポーネントは、脆弱性を含む可能性のあるサードパーティライブラリ、ソフトウェアコンポーネント、モジュールを表します。 + + +## コンポーネントビュー + +DefectDojo Proには、サイドバーからアクセスできるコンポーネント専用のテーブルビューが含まれています。このビューには、各コンポーネントのアクティブな検出事項、重複した検出事項、検出事項の合計数が表示されます。これらの数値には、DefectDojoインスタンス上のすべてのアセットが含まれます。 + +個々のアセットのコンポーネントは、アセットビューで確認できます。 + +## コンポーネントテーブル + +コンポーネントテーブルには以下の列が表示されます。 + +* **コンポーネント** — スキャンデータから取得されるコンポーネントの名前。 +* **バージョン** — スキャンデータから取得されるコンポーネントのバージョン。 +* **アクティブな検出事項** — コンポーネントに関連付けられたアクティブな検出事項の数。 +* **重複した検出事項** — コンポーネントに関連付けられた重複した検出事項の数。 +* **検出事項の合計数** — コンポーネントに関連付けられたすべての検出事項の合計数。 + +コンポーネント名、またはアクティブな検出事項、重複した検出事項、検出事項の合計数の値をクリックすると、それぞれのフィールドに対応する検出事項のフィルター済みリストが開きます。 + +テーブルには**None**コンポーネントが表示され、これはどのコンポーネントにも関連付けられていないすべての検出事項を示します。 + +インポートされたコンポーネントは、関連付けられたすべての検出事項が緩和済みになった場合でもテーブルに残ります。特定のコンポーネントに対して検出事項がインポートされると、コンポーネントテーブルは新しい検出事項の合計を正確に反映するように更新されます。 + + +### 例 + +脆弱な`lodash`依存関係を持つアプリケーションに対するDependency-Checkスキャンからインポートされたコンポーネントは、テーブル上で次のように表示される場合があります。 + +| Component | Version | Active Findings | Duplicate Findings | Total Findings | +| --- | --- | --- | --- | --- | +| npm:lodash | 4.17.15 | 3 | 1 | 5 | + +`npm:lodash`をクリックすると、このコンポーネントを参照するすべての検出事項のリストが開きます。`3`をクリックすると、アクティブな検出事項のみにフィルタリングされた同じリストが開きます。 + +## コンポーネントの追加 + +コンポーネントは、スキャンのインポートから解析されるか、検出事項を手動で編集することで追加できます。コンポーネント名が検出事項に関連付けられると、対応するエントリが自動的にコンポーネントテーブルに追加されます。そのコンポーネントがDefectDojo内の他の検出事項に既に関連付けられている場合、アクティブな検出事項、重複した検出事項、検出事項の合計数の値がそれに応じて更新されます。 + +### スキャンデータからのコンポーネントの解析方法 + +スキャンがインポートされると、パーサーはスキャン出力から各検出事項の**コンポーネント名**と**コンポーネントバージョン**フィールドに値を設定します。コンポーネントテーブルはこれらの値をもとに作成されます。詳細度と命名規則は、スキャンを生成したツールによって異なります。 + +* **ソフトウェアコンポジション解析(SCA)ツール**は通常、パッケージ名と正確なバージョンを報告します。例えば、OWASP Dependency-Checkは識別子内の[Package URL](https://github.com/package-url/purl-spec)からコンポーネントを導出します。`pkg:npm/lodash@4.17.15`というpurlは`Component Name: npm:lodash`、`Component Version: 4.17.15`になります。 +* **コンテナおよびOSパッケージスキャナー**(Trivy、Anchore Grype、Anchore Engineなど)は、影響を受けるOSまたは言語パッケージを報告します。例えば、`Component Name: curl`、`Component Version: 7.68.0`のようになります。 +* **言語固有の依存関係スキャナー**(npm Audit、pip-audit、bundler-audit、Retire.js、Govulncheck、OSV-Scannerなど)は、それぞれのエコシステムのマニフェストから問題のあるパッケージとバージョンを設定します。 + +設定、インフラストラクチャ、またはソースコードのロジックに焦点を当てたスキャナー(SASTやIaCツールなど)は、通常コンポーネントフィールドに値を設定せず、それらの検出事項は**None**コンポーネントの下に表示されます。 + +コンポーネントを手動で追加または変更するには、検出事項を編集して**コンポーネント名**と**コンポーネントバージョン**フィールドを直接設定します。検出事項が保存されるとすぐに、コンポーネントテーブルが更新されます。 + +## コンポーネントの更新 + +コンポーネント名またはバージョンを更新するには、そのコンポーネントに関連付けられたすべての検出事項のコンポーネント名またはコンポーネントバージョンフィールドを更新する必要があります。 + +## コンポーネントの削除 + +コンポーネントテーブルからコンポーネントを削除するには、そのコンポーネントに関連付けられたすべての検出事項を更新して、コンポーネント名とコンポーネントバージョンフィールドを削除する必要があります。また、関連付けられたすべての検出事項が削除された場合も、コンポーネントは削除されます。 + +コンポーネントのすべての検出事項が緩和済みになった場合、コンポーネントはテーブルに残りますが、そのアクティブな検出事項の値は0に設定されます。 diff --git a/docs/content/asset_modelling/components/_index.de.md b/docs/content/asset_modelling/components/_index.de.md new file mode 100644 index 00000000000..703ca1b9c43 --- /dev/null +++ b/docs/content/asset_modelling/components/_index.de.md @@ -0,0 +1,10 @@ +--- +title: Komponenten & Endpunkte +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/components/_index.es.md b/docs/content/asset_modelling/components/_index.es.md new file mode 100644 index 00000000000..21473218be9 --- /dev/null +++ b/docs/content/asset_modelling/components/_index.es.md @@ -0,0 +1,10 @@ +--- +title: Componentes y Endpoints +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/components/_index.fr.md b/docs/content/asset_modelling/components/_index.fr.md new file mode 100644 index 00000000000..0c129b29fa4 --- /dev/null +++ b/docs/content/asset_modelling/components/_index.fr.md @@ -0,0 +1,10 @@ +--- +title: Composants et points de terminaison +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/components/_index.ja.md b/docs/content/asset_modelling/components/_index.ja.md new file mode 100644 index 00000000000..78bd722575c --- /dev/null +++ b/docs/content/asset_modelling/components/_index.ja.md @@ -0,0 +1,10 @@ +--- +title: コンポーネントとエンドポイント +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/components/services.de.md b/docs/content/asset_modelling/components/services.de.md new file mode 100644 index 00000000000..a7cf7044b20 --- /dev/null +++ b/docs/content/asset_modelling/components/services.de.md @@ -0,0 +1,39 @@ +--- +title: Services +description: Nachverfolgung von Microservices +weight: 1 +--- + +## Was ist ein Service? + +Services (kurz für Microservices) sind eine optionale Funktion innerhalb von Assets, die zusätzlichen Kontext dazu liefert, wo genau innerhalb eines Assets ein Finding seinen Ursprung hat. Sie helfen dabei, Findings einer bestimmten Komponente eines Assets zuzuordnen, anstatt sie dem gesamten Asset zuzuschreiben, und sorgen so für Klarheit und präzisere Berichte in Umgebungen mit komplexen Architekturen. + +Services sind nützlich, wenn Sie die Ergebnisse eines Tests weiter segmentieren möchten oder wenn Sie erwarten, dass mehrere Instanzen desselben Findings innerhalb einer Reimport-Pipeline auftreten, die Sie nicht deduplizieren möchten. Manche Scan-Tools erstellen für jeden Dateispeicherort separate Findings. Wenn Sie diese Instanzen eines Findings lieber als eigenständige Findings beibehalten möchten, können Services eine nützliche Möglichkeit sein, diese unterschiedlichen Speicherorte zu kennzeichnen. + +## Services in Pro + +Services sind in der Pro-Version verfügbar, wurden jedoch weitgehend durch die Möglichkeit abgelöst, übergeordnete-untergeordnete Beziehungen zwischen Assets herzustellen. Services erzielen dasselbe Ergebnis und können weiterhin nützlich sein, wenn eine Umstrukturierung der Assets nicht praktikabel ist oder wenn eine Deduplizierung auf Scan-Ebene erforderlich ist, ohne die Asset-Hierarchie zu verändern – allerdings gehen dabei Kontextinformationen verloren. So lassen sich beispielsweise Geschäftskritikalität, Umsatz und Personal Assets, aber nicht Services zuordnen. Services sind daher in erster Linie im Kontext von OS DefectDojo nützlich. + +## Wie gebe ich einen Service an? + +Die Option zur Angabe eines Service finden Sie auf den Formularen Import Scan bzw. Reimport im Dropdown-Menü Optional Fields. Danach wird die Deduplizierung auf Tests beschränkt, die denselben Service-Wert aufweisen. + +Wichtig: Bei Services wird zwischen Groß- und Kleinschreibung unterschieden. Wenn der Service beim ursprünglichen Import als „Service 1“ (großes S) angegeben wurde und Sie einen Scan reimportieren, bei dem alle vorherigen Probleme behoben wurden, den Service dabei aber als „service 1“ (kleines s) angeben, greift die Deduplizierung nicht für den beabsichtigten Service. + +## Wie funktionieren Services? + +Services funktionieren, indem Sie festlegen können, auf welche vorherigen Tests die Deduplizierungsregeln beim Reimport angewendet werden. + +Wenn Sie beispielsweise einen Scan importieren und den Service als „Service 1“ festlegen und dann einen zweiten Scan reimportieren und den Service als „Service 2“ festlegen, greift zwischen diesen beiden Scans keine Deduplizierung, da sich der Service unterscheidet. + +Bei allen nachfolgenden Reimports werden frühere Ergebnisse des ersten Scans nur dann dedupliziert, wenn der Service als „Service 1“ festgelegt wurde, und frühere Ergebnisse des zweiten Scans nur dann, wenn der Service als „Service 2“ festgelegt wurde. Wenn sich der Service zwischen zwei Versionen eines reimportierten Scans unterscheidet, werden sie im Grunde als unterschiedliche Findings behandelt, selbst wenn die Scans selbst identisch sind. + +Wenn in diesem Beispiel beim Reimport der Service weder als Service 1 noch als Service 2 festgelegt, sondern leer gelassen wird, greift die Deduplizierung weder für den ersten noch für den zweiten Scan, und es werden nur Findings ohne Service geschlossen. + +## Wie sollten Services eingesetzt werden? + +In der Praxis sind Services vor allem dann nützlich, wenn: + +* Ein einzelnes Asset mehrere unabhängig bereitgestellte Komponenten enthält. +* Verschiedene Teams für unterschiedliche Teile desselben Assets verantwortlich sind. +* Sicherheitstests gegen einzelne Services durchgeführt werden (zum Beispiel das Scannen einer bestimmten API oder eines bestimmten Microservice). diff --git a/docs/content/asset_modelling/components/services.es.md b/docs/content/asset_modelling/components/services.es.md new file mode 100644 index 00000000000..309375ac3c0 --- /dev/null +++ b/docs/content/asset_modelling/components/services.es.md @@ -0,0 +1,39 @@ +--- +title: Servicios +description: Seguimiento de microservicios +weight: 1 +--- + +## ¿Qué es un Servicio? + +Los Servicios (abreviatura de Microservicios) son una función opcional dentro de los Activos que proporciona contexto adicional sobre el origen de los Hallazgos dentro de un Activo. Ayudan a aislar los Hallazgos a un componente particular de un Activo, en lugar de a todo el Activo en su conjunto, lo que aporta claridad y precisión en los informes en entornos con arquitecturas complejas. + +Los Servicios son útiles cuando necesita segmentar aún más los resultados que provienen de un Test, o si espera tener múltiples instancias del mismo Hallazgo dentro de un flujo de Reimportación que no desea deduplicar. Algunas herramientas de escaneo pueden crear Hallazgos separados para cada ubicación de archivo, y si prefiere mantener esas instancias de un Hallazgo como Hallazgos separados, los servicios pueden ser una manera útil de etiquetar esas diferentes ubicaciones. + +## Servicios en Pro + +Los Servicios están disponibles en la versión Pro, pero en gran medida han sido reemplazados por la capacidad de establecer relaciones padre-hijo entre Activos. Los Servicios logran el mismo resultado y aún pueden ser útiles cuando reestructurar los Activos no es viable o cuando se requiere delimitar la deduplicación a nivel de escaneo sin alterar la jerarquía de Activos, pero eliminan el contexto. Por ejemplo, la criticidad de negocio, los ingresos y el personal se pueden atribuir a los Activos, pero no a los Servicios. Por lo tanto, los Servicios son principalmente útiles en el contexto de DefectDojo OS. + +## ¿Cómo especifico un Servicio? + +La opción para especificar un Servicio está disponible en los formularios de Importar escaneo o Reimportar, dentro del menú desplegable de Campos opcionales. A partir de entonces, la deduplicación se limita a los Tests que comparten el mismo valor de Servicio. + +Es importante destacar que los Servicios distinguen entre mayúsculas y minúsculas. Si el Servicio de la importación inicial se identificó como “Service 1” (S mayúscula) y reimporta un escaneo que ha resuelto todos los problemas anteriores pero identifica el Servicio como “service 1” (s minúscula), la deduplicación no se aplicará al Servicio previsto. + +## ¿Cómo funcionan los Servicios? + +Los Servicios funcionan permitiéndole especificar a qué Tests anteriores se aplicarán las reglas de deduplicación al reimportar. + +Si, por ejemplo, importa un escaneo y establece el Servicio como “Service 1” y luego reimporta un segundo escaneo estableciendo el Servicio como “Service 2”, la deduplicación no se aplicará entre esos dos escaneos porque el Servicio es diferente. + +Cualquier reimportación posterior solo deduplicará los resultados anteriores del primer escaneo si el Servicio se ha establecido como “Service 1”, y solo deduplicará los resultados anteriores del segundo escaneo si el Servicio se ha establecido como “Service 2”. En esencia, si el Servicio es diferente entre dos versiones de un escaneo reimportado, se tratarán como Hallazgos distintos, incluso si los escaneos en sí son idénticos. + +En este ejemplo, si al reimportar el Servicio no se establece como Service 1 ni como Service 2, y en su lugar se deja en blanco, la deduplicación no se aplicará ni al primer ni al segundo escaneo, y solo se cerrarán los Hallazgos que no tengan un Servicio. + +## ¿Cómo se deben usar los Servicios? + +En la práctica, los Servicios son más útiles cuando: + +* Un único Activo contiene múltiples componentes desplegados de forma independiente. +* Diferentes equipos son responsables de distintas partes del mismo Activo. +* Las pruebas de seguridad se realizan contra servicios individuales (por ejemplo, escaneando una API o microservicio específico). diff --git a/docs/content/asset_modelling/components/services.fr.md b/docs/content/asset_modelling/components/services.fr.md new file mode 100644 index 00000000000..798e682ae08 --- /dev/null +++ b/docs/content/asset_modelling/components/services.fr.md @@ -0,0 +1,39 @@ +--- +title: Services +description: Suivi des microservices +weight: 1 +--- + +## Qu'est-ce qu'un Service ? + +Les Services (abréviation de microservices) sont une fonctionnalité optionnelle au sein des Actifs qui apporte un contexte supplémentaire sur l'origine des Constatations au sein d'un Actif. Ils permettent d'isoler les Constatations à un composant particulier d'un Actif, plutôt qu'à l'Actif entier, offrant clarté et précision de reporting dans les environnements aux architectures complexes. + +Les Services sont utiles lorsque vous devez segmenter davantage les résultats issus d'un Test, ou si vous prévoyez d'avoir plusieurs instances de la même Constatation au sein d'un pipeline de réimportation que vous ne souhaitez pas dédupliquer. Certains outils de scan peuvent créer des Constatations distinctes pour chaque emplacement de fichier, et si vous préférez conserver ces instances d'une Constatation comme des Constatations séparées, les services peuvent être un bon moyen d'étiqueter ces différents emplacements. + +## Les Services dans Pro + +Les Services sont disponibles dans la version Pro, mais sont largement remplacés par la possibilité d'établir des relations parent-enfant entre les Actifs. Les Services obtiennent le même résultat et peuvent encore être utiles lorsque la restructuration des Actifs n'est pas envisageable ou lorsqu'un périmètre de déduplication au niveau du scan est nécessaire sans modifier la hiérarchie des Actifs, mais ils suppriment le contexte. Par exemple, la criticité métier, le revenu et le personnel peuvent être attribués aux Actifs mais pas aux Services. Ainsi, les Services sont principalement utiles dans le contexte de DefectDojo Open Source. + +## Comment spécifier un Service ? + +L'option permettant de spécifier un Service est disponible sur les formulaires d'importation ou de réimportation de scan, dans le menu déroulant des champs optionnels. Par la suite, la déduplication est limitée aux Tests partageant la même valeur de Service. + +Il est important de noter que les Services sont sensibles à la casse. Si le Service de l'importation initiale a été identifié comme « Service 1 » (S majuscule) et que vous réimportez un scan ayant résolu tous les problèmes précédents mais identifiez le Service comme « service 1 » (s minuscule), la déduplication ne s'appliquera pas au Service visé. + +## Comment fonctionnent les Services ? + +Les Services fonctionnent en vous permettant de spécifier à quels Tests antérieurs les règles de déduplication s'appliqueront lors de la réimportation. + +Si, par exemple, vous importez un premier scan et définissez le Service comme « Service 1 », puis réimportez un second scan en définissant le Service comme « Service 2 », la déduplication ne s'appliquera pas entre ces deux scans car le Service est différent. + +Toute réimportation ultérieure ne dédupliquera les résultats antérieurs du premier scan que si le Service a été défini comme « Service 1 », et ne dédupliquera les résultats antérieurs du second scan que si le Service a été défini comme « Service 2 ». Autrement dit, si le Service diffère entre deux versions d'un scan réimporté, elles seront traitées comme des Constatations différentes, même si les scans eux-mêmes sont identiques. + +Dans cet exemple, si, lors de la réimportation, le Service n'est défini ni comme Service 1 ni comme Service 2, et est au contraire laissé vide, la déduplication ne s'appliquera ni au premier ni au second scan, et seules les Constatations sans Service seront clôturées. + +## Comment les Services doivent-ils être utilisés ? + +En pratique, les Services sont surtout utiles lorsque : + +* Un seul Actif contient plusieurs composants déployés indépendamment. +* Différentes équipes possèdent différentes parties d'un même Actif. +* Les tests de sécurité sont effectués sur des services individuels (par exemple, l'analyse d'une API ou d'un microservice spécifique). diff --git a/docs/content/asset_modelling/components/services.ja.md b/docs/content/asset_modelling/components/services.ja.md new file mode 100644 index 00000000000..190d3b59b5b --- /dev/null +++ b/docs/content/asset_modelling/components/services.ja.md @@ -0,0 +1,39 @@ +--- +title: サービス +description: マイクロサービスの追跡 +weight: 1 +--- + +## サービスとは? + +サービス(マイクロサービスの略)は、アセット内のオプション機能であり、検出事項がアセットのどこで発生したかについて追加のコンテキストを提供します。これにより、検出事項をアセット全体ではなく、アセットの特定のコンポーネントに絞り込むことができ、複雑なアーキテクチャの環境において明確さとレポートの精度が向上します。 + +サービスは、テストから返される結果をさらに細分化する必要がある場合や、重複排除したくない同一の検出事項がReimportパイプライン内に複数存在すると予想される場合に役立ちます。一部のスキャンツールは、ファイルの場所ごとに個別の検出事項を作成することがあり、検出事項のそれらのインスタンスを別々の検出事項として保持したい場合、サービスはそれらの異なる場所にラベルを付けるための有用な方法となります。 + +## Proにおけるサービス + +サービスはPro版でも利用できますが、アセット間で親子関係を確立できる機能によってその役割の多くが置き換えられています。サービスも同じ結果を達成でき、アセットの再構成が現実的でない場合や、アセット階層を変更せずにスキャンレベルの重複排除のスコープ設定が必要な場合には依然として有用ですが、コンテキストが失われます。例えば、ビジネスクリティカリティ、収益、担当者はアセットには関連付けられますが、サービスには関連付けられません。そのため、サービスは主にOS版DefectDojoの文脈で有用です。 + +## サービスの指定方法 + +サービスを指定するオプションは、インポートスキャンまたは再インポートフォームの「オプションフィールド」ドロップダウンメニュー内で利用できます。以降、重複排除は同じサービス値を共有するテストに限定されます。 + +重要な点として、サービスは大文字と小文字を区別します。最初のインポートのサービスが「Service 1」(大文字のS)として識別され、以前のすべての問題を解決したスキャンを再インポートする際にサービスを「service 1」(小文字のs)として識別した場合、重複排除は意図したサービスに適用されません。 + +## サービスはどのように機能するか? + +サービスは、再インポート時にどの以前のテストに重複排除ルールを適用するかを指定できるようにすることで機能します。 + +例えば、あるスキャンをインポートしてサービスを「Service 1」に設定し、次に2つ目のスキャンを再インポートしてサービスを「Service 2」に設定した場合、サービスが異なるため、これら2つのスキャン間で重複排除は適用されません。 + +それ以降の再インポートは、サービスが「Service 1」に設定されている場合にのみ最初のスキャンの以前の結果と重複排除を行い、サービスが「Service 2」に設定されている場合にのみ2つ目のスキャンの以前の結果と重複排除を行います。つまり、再インポートされたスキャンの2つのバージョン間でサービスが異なる場合、スキャン自体が同一であっても、それらは異なる検出事項として扱われます。 + +この例で、再インポート時にサービスがService 1にもService 2にも設定されず、代わりに空白のままにされた場合、重複排除は最初のスキャンにも2番目のスキャンにも適用されず、サービスが設定されていない検出事項のみがクローズされます。 + +## サービスはどのように使用すべきか? + +実際には、サービスは以下のような場合に最も有用です。 + +* 単一のアセットに独立してデプロイされる複数のコンポーネントが含まれている場合。 +* 同じアセットの異なる部分を異なるチームが所有している場合。 +* 個々のサービスに対してセキュリティテストが実施される場合(例えば、特定のAPIやマイクロサービスをスキャンする場合)。 diff --git a/docs/content/asset_modelling/engagements_tests/OS__assets.de.md b/docs/content/asset_modelling/engagements_tests/OS__assets.de.md new file mode 100644 index 00000000000..f290cd860d2 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__assets.de.md @@ -0,0 +1,181 @@ +--- +title: Assets +description: Assets in DefectDojo OS verstehen +audience: opensource +weight: 2 +aliases: +- /de/asset_modelling/engagements_tests/os__products/ +- /de/en/asset_modelling/engagements_tests/os__products/ +--- + +Organizations → **ASSETS** → Engagements → Tests → Befunde + +## Überblick + +**Assets** stehen im Zentrum der Art und Weise, wie Sicherheitsarbeit innerhalb der Objekthierarchie von DefectDojo organisiert wird. Assets repräsentieren jedes Projekt, Programm, jede Software oder jedes physische Objekt, das Ihr Sicherheitsteam testet, und beherbergen die gesamte Sicherheitsarbeit und Testhistorie im Zusammenhang mit diesem Testziel. Beispiele für Assets sind unter anderem: +- Software-Releases +- Drittanbieter-Software +- Virtuelle Maschinen oder Assets in Produktion +- Eine einzelne Anwendung +- Ein Microservice +- Eine API +- Eine SaaS-Plattform +- Eine mobile App +- Ein internes System +- Ein Geschäftsservice +- Eine kundenorientierte Plattform +- Eine Cloud-Umgebung oder Infrastrukturdomäne + +Im Allgemeinen sollte ein Asset das „Ding" repräsentieren, dessen Sicherheitslage Sie im Zeitverlauf verfolgen möchten. Dazu gehören die zugehörige Testhistorie, Befunde, Kennzahlen, Zuständigkeiten, Integrationen und Remediation-Workflows im Zusammenhang mit diesem „Ding". + +### Asset-Beispiele + +Assets können je nach den Anforderungen Ihrer Organisation noch granularer werden. Beispielsweise könnten Sie in folgenden Szenarien in Erwägung ziehen, separate DefectDojo-Assets zu erstellen: + +- „ExampleAsset" hat eine Windows-Version, eine Mac-Version und eine Cloud-Version +- „ExampleAsset 1.0" verwendet völlig andere Softwarekomponenten als „ExampleAsset 2.0", und beide Versionen werden von Ihrem Unternehmen aktiv unterstützt. +- Das Team, das an „ExampleAsset Version A" arbeitet, unterscheidet sich vom Asset-Team, das an „ExampleAsset Version B" arbeitet, und benötigt daher unterschiedliche Sicherheitsberechtigungen. + +Sie können diese Varianten zwar auch als Engagements innerhalb eines einzigen Assets abbilden, RBAC lässt sich jedoch nur auf Ebene von Assets oder Organizations festlegen, was den Zugriff der Benutzer auf das jeweilige Engagement (sowie die Tests und Befunde innerhalb dieser Engagements) einschränken kann, wenn sie so organisiert sind. Weitere Informationen zu RBAC und Berechtigungen in DefectDojo finden Sie [hier](/admin/user_management/about_perms_and_roles/). + +## Asset-Daten + +Assets enthalten immer die folgenden Komponenten: + +- **Eindeutiger Name** +- **Beschreibung** +- **Organization** +- **SLA-Konfiguration** + +Optionale Asset-Metadaten umfassen: + +- **Tags** +- **Personalinformationen** (z. B. Asset Manager, Team Manager, technischer Kontakt usw.) +- **Vorschriften** (z. B. HIPAA, GLBA, OPPA usw.) +- **Geschäftskritikalität** +- **Plattform** (z. B. API, Desktop, IoT, Mobil, Web usw.) +- **Lebenszyklus** (z. B. Aufbau, Produktion, Außerbetriebnahme usw.) +- **Herkunft** (z. B. Drittanbieter-Bibliothek, gekauft, Open Source usw.) +- **Benutzerdatensätze** (d. h. die geschätzte Anzahl der Benutzerdatensätze im Asset) +- **Umsatz** + +Diese Metadaten verbessern das Filtern, die Berichterstattung und die Priorisierung innerhalb Ihres Sicherheitsprogramms. Noch wichtiger ist jedoch, dass Assets auch alle Engagements, Tests und Befunde enthalten, die sich auf die Testaktivitäten rund um dieses Asset beziehen. Alle Befunde aus Tests werden letztlich auf Asset-Ebene aggregiert, was langfristiges Tracking, Trendanalysen und Berichterstattung ermöglicht. + +## Zugriff auf Assets + +Assets sind über die Seitenleiste zugänglich. Das Untermenü bietet außerdem die Möglichkeit, ein neues Asset zu erstellen. + +![image](images/asset_ss3.png) + +### Berechtigungen + +Auf Assets können Role-Based-Access-Control-Regeln (RBAC) angewendet werden, die die Möglichkeit der Teammitglieder einschränken, sie anzuzeigen und mit ihnen zu interagieren. + +Berechtigungen werden nach unten vererbt, das heißt, der Zugriff auf ein Asset gewährt automatisch Zugriff auf alle Objekte innerhalb dieses Assets (z. B. Engagements, Tests und Befunde). + +Weitere Informationen zu Benutzerrollen finden Sie in unserem [Artikel zur Einführung in Rollen](/admin/user_management/about_perms_and_roles/). + +## Asset-Ansicht + +Asset-Ansichten enthalten eine Vielzahl von Tabellen und Diagrammen, um den Status eines Assets auf einen Blick zu erfassen. Dazu gehören: + +- **Metadaten** + - Einschließlich Organization, Geschäftskritikalität, Umsatz und weiterer Details, die über die Asset-Einstellungen hinzugefügt wurden. +- **Metriken** + - Eine Liste offener Befunde innerhalb des Assets, gruppiert nach Schweregrad +- **Service Level Agreement nach Schweregrad** + - Wendet die SLA-Konfiguration des Assets aus den Einstellungen auf die Befunde innerhalb des Assets an. +- **Technologien** + - Z. B. next.js, vue.js, npm v.1.2.3, Django, nginx, Hugo +- **Vorschriften** +- **Benchmark-Fortschritt** +- **Mitglieder** +- **Gruppen** +- **Kontakte** +- **Benachrichtigungen** + - Schaltet Benachrichtigungen je nach bestimmten Ereignissen ein oder aus (z. B. wenn ein Engagement hinzugefügt oder geschlossen wurde) + +## Arbeiten mit Assets + +### Assets erstellen + +Es gibt mehrere Möglichkeiten, ein neues Asset zu erstellen, unter anderem: + +- Die Schaltfläche **Add Asset** in der Liste „All Assets" + +![image](images/asset_ss2.png) + +- Über das Dropdown-Menü der Assets-Tabelle innerhalb der Ansicht einer Organization + - Dadurch wird das Asset automatisch innerhalb dieser Organization erstellt. + +![image](images/asset_ss1.png) + +- Die Schaltfläche **Add Asset** in der Seitenleiste + +![image](images/asset_ss5.png) + +### Assets bearbeiten + +Ein Asset kann über seine Einstellungen bearbeitet werden, auf die Sie auf zwei Arten zugreifen können: + +- Die Schaltfläche **Edit** im ⋮-Kebab-Menü links neben dem Asset in der Ansicht „All Assets" + +![image](images/asset_ss6.png) + +- Die Schaltfläche **Edit** im Dropdown-Menü **Settings** in der Ansicht des Assets + +![image](images/asset_ss7.png) + +### Assets löschen + +Die Option zum Löschen eines Assets finden Sie unten in denselben Menüs, die im obigen Abschnitt **Assets bearbeiten** beschrieben sind. Diese Aktion kann nicht rückgängig gemacht werden. Ein Asset kann nicht geschlossen und später wieder geöffnet werden. + +Beim Löschen eines Assets werden auch die folgenden Elemente gelöscht: +- Alle im Asset enthaltenen Engagements und Tests +- Der gesamte zugehörige Sicherheitsverlauf, einschließlich Befunde und Integrationen +- Alle verknüpften Jira Epics +- Alle Notizen und Datei-Uploads, die den Engagements und Tests des Assets zugeordnet sind + +## Asset-Grenzen + +### Deduplizierung + +Assets sind „abgeschottet" und interagieren nicht mit anderen Assets. Die Smart Features von DefectDojo, wie z. B. Deduplication, gelten nur innerhalb des Kontexts eines einzelnen Assets. Befunde in unterschiedlichen Assets werden nicht automatisch dedupliziert. + +### Metriken + +Die meisten Berichte und Kennzahlen aggregieren Daten auf Asset-Ebene, wodurch Assets die primäre Einheit zur Messung und Verfolgung von Risiken darstellen. + +Infolgedessen werden viele wichtige Kennzahlen pro Asset berechnet, darunter: + +- Gesamtzahl der Befunde (nach Schweregrad oder Status) +- Mittlere Zeit bis zur Behebung (MTTR) +- SLA-Einhaltungs- und Verstoßraten +- Risikotrends im Zeitverlauf + +Das bedeutet, dass die Struktur der Assets sich direkt auf die Genauigkeit und den Nutzen von Berichten auswirkt. Wenn beispielsweise mehrere nicht zusammenhängende Systeme unter einem einzigen Asset zusammengefasst werden, kann dies die Risikotransparenz beeinträchtigen, während zu granulare Asset-Strukturen die Berichterstattung fragmentieren und es erschweren können, umfassendere Trends zu erkennen. + +Asset-spezifische Kennzahlen sind über die Schaltfläche **Metrics** in der oberen Leiste der Ansicht des ausgewählten Assets zugänglich. + +![image](images/asset_ss8.png) + +### CI/CD-Pipeline + +CI/CD-Pipelines automatisieren den Import von Scan-Ergebnissen. Unabhängig von der Integrationsmethode müssen alle Scan-Importe einem Asset zugeordnet werden, wodurch das Asset zum Ankerpunkt für pipelinegesteuerte Sicherheitsdaten wird. + +Wenn eine Pipeline Scan-Ergebnisse übermittelt, muss sie entweder: + +- Ein bestehendes Asset (und optional ein Engagement) angeben, oder +- So konfiguriert sein, dass Ergebnisse konsistent dem richtigen Asset zugeordnet werden + +Alle importierten Befunde übernehmen den Kontext des Assets, einschließlich Zuständigkeit, Berechtigungen, SLA-Konfiguration und Berichtsumfang. + +In der Praxis sollten Assets so definiert werden, dass sie widerspiegeln, wie Systeme innerhalb von CI/CD gebaut und bereitgestellt werden, damit Sicherheitsergebnisse konsistent der richtigen Anwendung oder dem richtigen Service zugeordnet werden. + +### Jira-Beziehungen + +Assets können direkt Jira Projects zugeordnet werden, die die Befunde des Assets in eine Jira-Instanz übertragen. + +Da Befunde Risiko, Priorität und Zuständigkeit von ihrem übergeordneten Asset erben, bestimmt das Asset faktisch den Remediation-Kontext, der in Jira-Tickets und Downstream-Connector-Workflows einfließt. + +Wichtig ist außerdem, dass Assets auch der wichtigste Faktor für die SLA-Eigenschaften eines Befunds sind. Die SLA eines Befunds hängt daher von der SLA-Konfiguration seines übergeordneten Assets ab. Weitere Informationen zu SLA-Konfigurationen finden Sie [hier](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). diff --git a/docs/content/asset_modelling/engagements_tests/OS__assets.es.md b/docs/content/asset_modelling/engagements_tests/OS__assets.es.md new file mode 100644 index 00000000000..d3bdd275d6e --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__assets.es.md @@ -0,0 +1,181 @@ +--- +title: Activos +description: Comprender los Activos en DefectDojo OS +audience: opensource +weight: 2 +aliases: +- /es/asset_modelling/engagements_tests/os__products/ +- /es/en/asset_modelling/engagements_tests/os__products/ +--- + +Organizations → **ACTIVOS** → Engagements → Tests → Findings + +## Descripción general + +Los **Activos** están en el centro de cómo se organiza el trabajo de seguridad dentro de la jerarquía de objetos de DefectDojo. Los Activos representan cualquier proyecto, programa, software o activo físico que su equipo de seguridad esté probando, y alojan todo el trabajo de seguridad y el historial de pruebas relacionado con el objetivo de las pruebas. Ejemplos de Activos pueden incluir: +- Versiones de software +- Software de terceros +- Máquinas virtuales o activos en producción +- Una única aplicación +- Un microservicio +- Una API +- Una plataforma SaaS +- Una aplicación móvil +- Un sistema interno +- Un servicio de negocio +- Una plataforma orientada al cliente +- Un entorno en la nube o dominio de infraestructura + +En general, un Activo debe representar la “cosa” cuya postura de seguridad desea rastrear a lo largo del tiempo. Esto incluye el historial de pruebas asociado, los Hallazgos, las métricas, la propiedad, las integraciones y los flujos de trabajo de remediación relacionados con esa “cosa”. + +### Ejemplos de Activos + +Los Activos pueden volverse aún más granulares según las necesidades de su organización. Por ejemplo, puede considerar crear Activos de DefectDojo separados en los siguientes escenarios: + +- “ExampleAsset” tiene una versión para Windows, una versión para Mac y una versión en la nube +- “ExampleAsset 1.0” usa componentes de software completamente diferentes de “ExampleAsset 2.0”, y ambas versiones cuentan con soporte activo por parte de su empresa. +- El equipo asignado para trabajar en “ExampleAsset version A” es distinto del equipo de Activo asignado para trabajar en “ExampleAsset version B”, y por ello necesita tener asignados permisos de seguridad diferentes. + +Si bien también puede optar por representar estas variaciones como Compromisos dentro de un único Activo, el RBAC solo puede configurarse a nivel de Activos u Organizaciones, lo que puede limitar el acceso de los usuarios al Compromiso correspondiente (así como a los Tests y Hallazgos dentro de esos Compromisos) si se organizan de esa manera. Para obtener más información sobre RBAC y permisos en DefectDojo, haga clic [aquí](/admin/user_management/about_perms_and_roles/). + +## Datos del Activo + +Los Activos siempre incluirán los siguientes componentes: + +- **Nombre único** +- **Descripción** +- **Organización** +- **Configuración de SLA** + +Los metadatos opcionales del Activo incluyen: + +- **Etiquetas** +- **Información de personal** (por ejemplo, Asset Manager, Team Manager, Technical Contact, etc.) +- **Regulaciones** (por ejemplo, HIPAA, GLBA, OPPA, etc.) +- **Criticidad del negocio** +- **Plataforma** (por ejemplo, API, Desktop, IoT, Mobile, Web, etc.) +- **Ciclo de vida** (por ejemplo, Construction, Production, Retirement, etc.) +- **Origen** (por ejemplo, Third-Party Library, Purchased, Open Source, etc.) +- **Registros de usuario** (es decir, el número estimado de registros de usuario en el Activo) +- **Ingresos** + +Estos metadatos mejoran el filtrado, la generación de informes y la priorización en todo su programa de seguridad, pero lo más importante es que los Activos también contienen todos los Compromisos, Tests y Hallazgos relacionados con los esfuerzos de prueba en torno a ese Activo. Todos los Hallazgos de los Tests finalmente se consolidan al nivel del Activo, lo que permite el seguimiento a largo plazo, el análisis de tendencias y la generación de informes. + +## Acceder a los Activos + +Se puede acceder a los Activos a través de la barra lateral. El submenú también ofrece la opción de crear un nuevo Activo. + +![imagen](images/asset_ss3.png) + +### Permisos + +Los Activos pueden tener reglas de Control de acceso basado en roles (RBAC) aplicadas, que limitan la capacidad de los miembros del equipo para verlos e interactuar con ellos. + +Los permisos se propagan en cascada hacia abajo, lo que significa que el acceso a un Activo otorga automáticamente acceso a todos los objetos dentro de ese Activo (por ejemplo, Compromisos, Tests y Hallazgos). + +Para obtener más información sobre los roles de usuario, consulte nuestro [artículo de introducción a los roles](/admin/user_management/about_perms_and_roles/). + +## Vista del Activo + +Las vistas de Activo contienen una variedad de tablas y gráficos para interpretar el estado de un Activo de un vistazo. Esto incluye: + +- **Metadatos** + - Incluye Organización, criticidad del negocio, ingresos y otros detalles agregados desde la configuración del Activo. +- **Métricas** + - Una lista de Hallazgos abiertos dentro del Activo, agrupados por severidad +- **Acuerdo de nivel de servicio por severidad** + - Aplica la configuración de SLA del Activo desde la configuración a los Hallazgos dentro del Activo. +- **Tecnologías** + - Por ejemplo, next.js, vue.js, npm v.1.2.3, Django, nginx, Hugo +- **Regulaciones** +- **Progreso del Benchmark** +- **Miembros** +- **Grupos** +- **Contactos** +- **Notificaciones** + - Activa y desactiva las notificaciones según eventos específicos (por ejemplo, se ha agregado o cerrado un Compromiso) + +## Trabajar con Activos + +### Crear Activos + +Hay varias formas de crear un nuevo Activo, entre ellas: + +- El botón **Agregar Activo** en la lista Todos los Activos + +![imagen](images/asset_ss2.png) + +- Desde el menú desplegable de la tabla de Activos dentro de la vista de una Organización + - Esto creará automáticamente el Activo dentro de esa Organización. + +![imagen](images/asset_ss1.png) + +- El botón **Agregar Activo** en la barra lateral + +![imagen](images/asset_ss5.png) + +### Editar Activos + +Un Activo se puede editar desde su configuración, a la que se puede acceder de dos maneras: + +- El botón **Editar** dentro del menú kebab ⋮ a la izquierda del Activo en la vista Todos los Activos + +![imagen](images/asset_ss6.png) + +- El botón **Editar** dentro del menú desplegable **Configuración** en la vista del Activo + +![imagen](images/asset_ss7.png) + +### Eliminar Activos + +La opción para eliminar un Activo se encuentra en la parte inferior de los mismos menús descritos en la sección **Editar Activos** anterior. Esta acción no se puede deshacer. El Activo no se puede cerrar y volver a abrir más tarde. + +Eliminar un Activo también eliminará lo siguiente: +- Cualquier Compromiso y Test contenidos dentro del Activo +- Todo el historial de seguridad asociado, incluidos los Hallazgos y las integraciones +- Cualquier Jira Epic vinculado +- Todas las notas y archivos cargados asociados con los Compromisos y Tests del Activo + +## Límites del Activo + +### Deduplicación + +Los Activos están “aislados” y no interactúan con otros Activos. Las Smart Features de DefectDojo, como la Deduplicación, solo se aplican dentro del contexto de un único Activo. Los Hallazgos de distintos Activos no se deduplicarán automáticamente. + +### Métricas + +La mayoría de los informes y métricas agregan datos a nivel de Activo, lo que convierte a los Activos en la unidad principal para medir y rastrear el riesgo. + +Como resultado, muchas métricas clave se calculan por Activo, entre ellas: + +- Número total de Hallazgos (por severidad o estado) +- Tiempo medio de remediación (MTTR) +- Tasas de cumplimiento e incumplimiento de SLA +- Tendencias de riesgo a lo largo del tiempo + +Esto significa que la forma en que se estructuran los Activos afectará directamente la precisión y utilidad de los informes. Por ejemplo, agrupar varios sistemas no relacionados bajo un único Activo puede oscurecer la visibilidad del riesgo, mientras que estructuras de Activos demasiado granulares pueden fragmentar los informes, dificultando la identificación de tendencias más amplias. + +Se puede acceder a las métricas específicas del Activo desde el botón **Métricas** en la barra superior de la vista del Activo elegido. + +![imagen](images/asset_ss8.png) + +### Pipeline de CI/CD + +Los pipelines de CI/CD automatizan la importación de resultados de escaneo. Independientemente del método de integración, todas las importaciones de escaneo deben asociarse con un Activo, lo que convierte al Activo en el punto de anclaje de los datos de seguridad impulsados por el pipeline. + +Cuando un pipeline envía resultados de escaneo, debe hacer una de dos cosas: + +- Especificar un Activo existente (y opcionalmente un Compromiso), o +- Estar configurado de manera que asigne los resultados de forma consistente al Activo correcto + +Todos los Hallazgos importados heredarán el contexto del Activo, incluida la propiedad, los permisos, la configuración de SLA y el alcance de los informes. + +En la práctica, los Activos deben definirse de manera que reflejen cómo se construyen y despliegan los sistemas dentro de CI/CD, para garantizar que los resultados de seguridad se asocien de forma consistente con la aplicación o el servicio correcto. + +### Relaciones con Jira + +Los Activos se pueden asignar directamente a Jira Projects, que envían los Hallazgos del Activo a una instancia de Jira. + +Dado que los Hallazgos heredan el riesgo, la prioridad y la propiedad de su Activo padre, el Activo determina efectivamente el contexto de remediación que fluye hacia los tickets de Jira y los flujos de trabajo de Downstream Connector. + +Es importante destacar que los Activos también son el factor determinante principal en las características de SLA de un Hallazgo. Por lo tanto, el SLA de un Hallazgo depende de la configuración de SLA de su Activo padre. Puede encontrar más información sobre las configuraciones de SLA [aquí](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). diff --git a/docs/content/asset_modelling/engagements_tests/OS__assets.fr.md b/docs/content/asset_modelling/engagements_tests/OS__assets.fr.md new file mode 100644 index 00000000000..8d4addb4c56 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__assets.fr.md @@ -0,0 +1,181 @@ +--- +title: Actifs +description: Comprendre les Actifs dans DefectDojo OS +audience: opensource +weight: 2 +aliases: +- /fr/asset_modelling/engagements_tests/os__products/ +- /fr/en/asset_modelling/engagements_tests/os__products/ +--- + +Organisations → **ACTIFS** → Engagements → Tests → Constatations + +## Vue d'ensemble + +Les **Actifs** sont au centre de l'organisation du travail de sécurité au sein de la hiérarchie d'objets de DefectDojo. Les Actifs représentent tout projet, programme, logiciel ou bien physique que votre équipe de sécurité teste, et hébergent tout le travail de sécurité et l'historique de tests liés à l'objectif de test. Voici des exemples d'Actifs : +- Versions logicielles +- Logiciels tiers +- Machines virtuelles ou actifs en production +- Une application unique +- Un microservice +- Une API +- Une plateforme SaaS +- Une application mobile +- Un système interne +- Un service métier +- Une plateforme destinée aux clients +- Un environnement cloud ou un domaine d'infrastructure + +En général, un Actif doit représenter la « chose » dont vous souhaitez suivre la posture de sécurité dans le temps. Cela inclut l'historique de tests associé, les Constatations, les métriques, la propriété, les intégrations, et les flux de remédiation liés à cette « chose ». + +### Exemples d'Actifs + +Les Actifs peuvent devenir encore plus granulaires selon les besoins de votre organisation. Par exemple, vous pouvez envisager de créer des Actifs DefectDojo distincts dans les scénarios suivants : + +- « ExampleAsset » a une version Windows, une version Mac et une version Cloud +- « ExampleAsset 1.0 » utilise des composants logiciels complètement différents de « ExampleAsset 2.0 », et les deux versions sont activement prises en charge par votre entreprise. +- L'équipe chargée de travailler sur « ExampleAsset version A » est différente de l'équipe d'Actif chargée de travailler sur « ExampleAsset version B », et doit se voir attribuer des permissions de sécurité différentes en conséquence. + +Bien que vous puissiez également choisir de représenter ces variations sous forme d'Engagements au sein d'un seul Actif, le RBAC ne peut être défini qu'au niveau des Actifs ou des Organisations, ce qui peut limiter l'accès des utilisateurs à l'Engagement approprié (ainsi qu'aux Tests et Constatations au sein de ces Engagements) s'ils sont organisés ainsi. Pour plus d'informations sur le RBAC et les permissions dans DefectDojo, cliquez [ici](/admin/user_management/about_perms_and_roles/). + +## Données d'Actif + +Les Actifs incluent toujours les éléments suivants : + +- **Nom unique** +- **Description** +- **Organisation** +- **Configuration SLA** + +Les métadonnées optionnelles d'Actif incluent : + +- **Étiquettes** +- **Informations sur le personnel** (par ex. responsable de l'Actif, responsable d'équipe, contact technique, etc.) +- **Réglementations** (par ex. HIPAA, GLBA, OPPA, etc.) +- **Criticité métier** +- **Plateforme** (par ex. API, Desktop, IoT, Mobile, Web, etc.) +- **Cycle de vie** (par ex. Construction, Production, Retrait, etc.) +- **Origine** (par ex. bibliothèque tierce, achetée, open source, etc.) +- **Enregistrements utilisateur** (c'est-à-dire le nombre estimé d'enregistrements utilisateur dans l'Actif) +- **Revenu** + +Ces métadonnées améliorent le filtrage, le reporting et la priorisation au sein de votre programme de sécurité, mais surtout, les Actifs contiennent également tous les Engagements, Tests et Constatations liés aux efforts de test entourant cet Actif. Toutes les Constatations issues des Tests remontent finalement au niveau de l'Actif, ce qui permet un suivi à long terme, une analyse des tendances et un reporting. + +## Accéder aux Actifs + +Les Actifs sont accessibles depuis la barre latérale. Le sous-menu offre également la possibilité de créer un nouvel Actif. + +![image](images/asset_ss3.png) + +### Permissions + +Des règles de contrôle d'accès basé sur les rôles (RBAC) peuvent être appliquées aux Actifs, ce qui limite la capacité des membres de l'équipe à les consulter et à interagir avec eux. + +Les permissions se propagent vers le bas, ce qui signifie que l'accès à un Actif accorde automatiquement l'accès à tous les objets au sein de cet Actif (par ex. Engagements, Tests et Constatations). + +Pour plus d'informations sur les rôles utilisateur, consultez notre [article d'introduction aux rôles](/admin/user_management/about_perms_and_roles/). + +## Vue d'Actif + +Les vues d'Actif contiennent divers tableaux et graphiques permettant d'interpréter le statut d'un Actif en un coup d'œil. Cela inclut : + +- **Métadonnées** + - Incluant l'Organisation, la criticité métier, le revenu, et d'autres détails ajoutés depuis les paramètres de l'Actif. +- **Métriques** + - Une liste des Constatations ouvertes au sein de l'Actif, regroupées par sévérité +- **Accord de niveau de service par sévérité** + - Applique la configuration SLA de l'Actif définie dans les paramètres aux Constatations au sein de l'Actif. +- **Technologies** + - Par ex. next.js, vue.js, npm v.1.2.3, Django, nginx, Hugo +- **Réglementations** +- **Progression du Benchmark** +- **Membres** +- **Groupes** +- **Contacts** +- **Notifications** + - Active ou désactive les notifications en fonction d'événements spécifiques (par ex. un Engagement a été ajouté ou clôturé) + +## Utilisation des Actifs + +### Créer des Actifs + +Il existe plusieurs façons de créer un nouvel Actif, notamment : + +- Le bouton **Ajouter un Actif** dans la liste Tous les Actifs + +![image](images/asset_ss2.png) + +- Depuis le menu déroulant du tableau des Actifs dans la vue d'une Organisation + - Cela créera automatiquement l'Actif au sein de cette Organisation. + +![image](images/asset_ss1.png) + +- Le bouton **Ajouter un Actif** dans la barre latérale + +![image](images/asset_ss5.png) + +### Modifier des Actifs + +Un Actif peut être modifié depuis ses paramètres, accessibles de deux façons : + +- Le bouton **Modifier** dans le menu kebab ⋮ à gauche de l'Actif dans la vue Tous les Actifs + +![image](images/asset_ss6.png) + +- Le bouton **Modifier** dans le menu déroulant **Paramètres** de la vue de l'Actif + +![image](images/asset_ss7.png) + +### Supprimer des Actifs + +L'option permettant de supprimer un Actif se trouve en bas des mêmes menus décrits dans la section **Modifier des Actifs** ci-dessus. Cette action est irréversible. Un Actif ne peut pas être clôturé puis rouvert ultérieurement. + +La suppression d'un Actif supprime également ce qui suit : +- Tout Engagement et Test contenu dans l'Actif +- Tout l'historique de sécurité associé, y compris les Constatations et les intégrations +- Toute Épopée Jira liée +- Toutes les notes et tous les fichiers importés associés aux Engagements et Tests de l'Actif + +## Limites des Actifs + +### Déduplication + +Les Actifs sont « cloisonnés » et n'interagissent pas avec d'autres Actifs. Les fonctionnalités intelligentes de DefectDojo, telles que la Déduplication, ne s'appliquent que dans le contexte d'un seul Actif. Les Constatations réparties sur différents Actifs ne seront pas dédupliquées automatiquement. + +### Métriques + +La plupart des rapports et métriques agrègent les données au niveau de l'Actif, ce qui fait des Actifs l'unité principale de mesure et de suivi du risque. + +Par conséquent, de nombreuses métriques clés sont calculées par Actif, notamment : + +- Nombre total de Constatations (par sévérité ou statut) +- Délai moyen de remédiation (MTTR) +- Taux de conformité et de dépassement des SLA +- Évolution des tendances de risque dans le temps + +Cela signifie que la manière dont les Actifs sont structurés a un impact direct sur l'exactitude et l'utilité des rapports. Par exemple, regrouper plusieurs systèmes sans rapport sous un seul Actif peut masquer la visibilité du risque, tandis que des structures d'Actif trop granulaires peuvent fragmenter le reporting, rendant difficile l'identification de tendances plus larges. + +Les métriques spécifiques à un Actif sont accessibles depuis le bouton **Métriques** dans la barre supérieure de la vue de l'Actif choisi. + +![image](images/asset_ss8.png) + +### Pipeline CI/CD + +Les pipelines CI/CD automatisent l'import des résultats d'analyse. Quelle que soit la méthode d'intégration, tous les imports d'analyse doivent être associés à un Actif, ce qui fait de l'Actif le point d'ancrage des données de sécurité pilotées par le pipeline. + +Lorsqu'un pipeline soumet des résultats d'analyse, il doit soit : + +- Spécifier un Actif existant (et éventuellement un Engagement), soit +- Être configuré de manière à toujours faire correspondre les résultats au bon Actif + +Toutes les Constatations importées hériteront du contexte de l'Actif, y compris la propriété, les permissions, la configuration SLA et le périmètre de reporting. + +En pratique, les Actifs doivent être définis de manière à refléter la façon dont les systèmes sont construits et déployés au sein du CI/CD, afin de garantir que les résultats de sécurité soient systématiquement associés à la bonne application ou au bon service. + +### Relations Jira + +Les Actifs peuvent être mappés directement à des Projets Jira, qui poussent les Constatations de l'Actif vers une instance Jira. + +Étant donné que les Constatations héritent du risque, de la priorité et de la propriété de leur Actif parent, l'Actif détermine en pratique le contexte de remédiation qui alimente les tickets Jira et les flux de travail des connecteurs en aval. + +Il est important de noter que les Actifs constituent également le principal facteur déterminant des caractéristiques SLA d'une Constatation. Ainsi, le SLA d'une Constatation dépend de la configuration SLA de son Actif parent. Plus d'informations sur les configurations SLA sont disponibles [ici](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). diff --git a/docs/content/asset_modelling/engagements_tests/OS__assets.ja.md b/docs/content/asset_modelling/engagements_tests/OS__assets.ja.md new file mode 100644 index 00000000000..77d96f1b93d --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__assets.ja.md @@ -0,0 +1,181 @@ +--- +title: アセット +description: DefectDojo OSにおけるアセットの理解 +audience: opensource +weight: 2 +aliases: +- /ja/asset_modelling/engagements_tests/os__products/ +- /ja/en/asset_modelling/engagements_tests/os__products/ +--- + +組織 → **アセット** → エンゲージメント → テスト → 検出事項 + +## 概要 + +**アセット**は、DefectDojoのオブジェクト階層においてセキュリティ業務がどのように整理されるかの中心に位置します。アセットは、セキュリティチームがテストしているあらゆるプロジェクト、プログラム、ソフトウェア、または物理的な資産を表し、そのテスト目標に関連するすべてのセキュリティ業務とテスト履歴を保持します。アセットの例には次のようなものがあります。 +- ソフトウェアリリース +- サードパーティ製ソフトウェア +- 本番環境の仮想マシンまたは資産 +- 単一のアプリケーション +- マイクロサービス +- API +- SaaSプラットフォーム +- モバイルアプリ +- 社内システム +- ビジネスサービス +- 顧客向けプラットフォーム +- クラウド環境またはインフラストラクチャドメイン + +一般に、アセットはセキュリティ体制を長期的に追跡したい「対象」を表すべきものです。これには、その「対象」に関連するテスト履歴、検出事項、メトリクス、所有権、インテグレーション、修復ワークフローが含まれます。 + +### アセットの例 + +アセットは、組織のニーズに応じてさらに細かく分割することもできます。たとえば、次のようなシナリオでは、別々のDefectDojoアセットを作成することを検討してもよいでしょう。 + +- 「ExampleAsset」にWindows版、Mac版、クラウド版がある +- 「ExampleAsset 1.0」が「ExampleAsset 2.0」とはまったく異なるソフトウェアコンポーネントを使用しており、両方のバージョンが自社によって積極的にサポートされている +- 「ExampleAsset version A」の作業を担当するチームが「ExampleAsset version B」を担当するアセットチームとは異なり、その結果として異なるセキュリティ権限を割り当てる必要がある + +これらの違いを単一のアセット内のエンゲージメントとして表現することもできますが、RBACはアセットまたは組織のレベルでしか設定できないため、そのように整理した場合、ユーザーが適切なエンゲージメント(およびそのエンゲージメント内のテストと検出事項)にアクセスできる範囲が制限される可能性があります。DefectDojoにおけるRBACと権限の詳細については、[こちら](/admin/user_management/about_perms_and_roles/)をクリックしてください。 + +## アセットデータ + +アセットには、常に次の項目が含まれます。 + +- **一意の名前** +- **説明** +- **組織** +- **SLA設定** + +オプションのアセットメタデータには、次のものが含まれます。 + +- **タグ** +- **担当者情報**(例: アセットマネージャー、チームマネージャー、テクニカルコンタクトなど) +- **規制**(例: HIPAA、GLBA、OPPAなど) +- **ビジネス上の重要度** +- **プラットフォーム**(例: API、デスクトップ、IoT、モバイル、Webなど) +- **ライフサイクル**(例: 構築、本番稼働、廃止など) +- **出所**(例: サードパーティライブラリ、購入品、オープンソースなど) +- **ユーザーレコード**(すなわち、アセット内のユーザーレコードの推定数) +- **収益** + +このメタデータは、セキュリティプログラム全体にわたるフィルタリング、レポート作成、優先順位付けを向上させます。しかし何よりも重要なのは、アセットにはそのアセットを取り巻くテスト活動に関連するすべてのエンゲージメント、テスト、検出事項が含まれるという点です。テストから得られたすべての検出事項は、最終的にアセットレベルに集約され、長期的な追跡、トレンド分析、レポート作成を可能にします。 + +## アセットへのアクセス + +アセットにはサイドバーからアクセスできます。サブメニューには、新しいアセットを作成するオプションも用意されています。 + +![image](images/asset_ss3.png) + +### 権限 + +アセットには、ロールベースアクセス制御(RBAC)ルールを適用でき、チームメンバーがアセットを閲覧・操作できる範囲を制限できます。 + +権限は下位へと継承されます。つまり、あるアセットへのアクセス権を持つと、そのアセット内のすべてのオブジェクト(エンゲージメント、テスト、検出事項など)へのアクセス権も自動的に付与されます。 + +ユーザーロールの詳細については、[ロールの紹介記事](/admin/user_management/about_perms_and_roles/)を参照してください。 + +## アセットビュー + +アセットビューには、アセットのステータスを一目で把握するためのさまざまな表やグラフが含まれます。具体的には次のとおりです。 + +- **メタデータ** + - 組織、ビジネス上の重要度、収益など、アセット設定から追加された詳細情報を含みます。 +- **メトリクス** + - アセット内の未対応の検出事項の一覧を、深刻度別にグループ化したもの +- **深刻度別のサービスレベルアグリーメント** + - 設定で定義されたアセットのSLA設定を、アセット内の検出事項に適用します。 +- **テクノロジー** + - 例: next.js、vue.js、npm v.1.2.3、Django、nginx、Hugo +- **規制** +- **ベンチマークの進捗** +- **メンバー** +- **グループ** +- **連絡先** +- **通知** + - 特定のイベント(例: エンゲージメントが追加または終了した場合)に応じて、通知のオン・オフを切り替えます。 + +## アセットの操作 + +### アセットの作成 + +新しいアセットを作成する方法は複数あります。 + +- 「すべてのアセット」一覧にある**アセットを追加**ボタン + +![image](images/asset_ss2.png) + +- 組織のビュー内にあるアセットテーブルのドロップダウンメニューから + - この方法では、その組織内に自動的にアセットが作成されます。 + +![image](images/asset_ss1.png) + +- サイドバーにある**アセットを追加**ボタン + +![image](images/asset_ss5.png) + +### アセットの編集 + +アセットは、その設定から編集できます。設定には次の2つの方法でアクセスできます。 + +- 「すべてのアセット」ビューでアセットの左側にある⋮(縦三点)メニュー内の**編集**ボタン + +![image](images/asset_ss6.png) + +- アセットのビューにある**設定**ドロップダウン内の**編集**ボタン + +![image](images/asset_ss7.png) + +### アセットの削除 + +アセットを削除するオプションは、上記の**アセットの編集**セクションで説明したのと同じメニューの下部にあります。この操作は元に戻せません。アセットは、後でクローズして再度開くことはできません。 + +アセットを削除すると、次のものも削除されます。 +- アセットに含まれるすべてのエンゲージメントとテスト +- 検出事項やインテグレーションを含む、関連するすべてのセキュリティ履歴 +- リンクされているすべてのJira Epic +- アセットのエンゲージメントとテストに関連するすべてのメモとアップロードされたファイル + +## アセットの境界 + +### 重複排除 + +アセットは互いに「隔離」されており、他のアセットと影響し合うことはありません。重複排除などのDefectDojoのスマート機能は、単一のアセットの範囲内でのみ適用されます。異なるアセットにまたがる検出事項が自動的に重複排除されることはありません。 + +### メトリクス + +ほとんどのレポートとメトリクスは、アセットレベルでデータを集計するため、アセットはリスクを測定・追跡するための主要な単位となります。 + +その結果、多くの主要なメトリクスがアセットごとに算出されます。例えば次のとおりです。 + +- 検出事項の総数(深刻度またはステータス別) +- 平均修復時間(MTTR) +- SLA遵守率および違反率 +- 時間経過に伴うリスクの傾向 + +つまり、アセットの構造の取り方が、レポートの正確性と有用性に直接影響します。たとえば、複数の無関係なシステムを1つのアセットにまとめると、リスクの可視性が損なわれる可能性がある一方、アセットの構造を細かく分割しすぎると、レポートが分断され、より広範な傾向を把握しにくくなることがあります。 + +アセット固有のメトリクスには、選択したアセットのビューの上部バーにある**メトリクス**ボタンからアクセスできます。 + +![image](images/asset_ss8.png) + +### CI/CDパイプライン + +CI/CDパイプラインは、スキャン結果のインポートを自動化します。連携方法にかかわらず、すべてのスキャンインポートはアセットに関連付けられる必要があり、アセットはパイプライン駆動のセキュリティデータの基点となります。 + +パイプラインがスキャン結果を送信する際は、次のいずれかを行う必要があります。 + +- 既存のアセット(および任意でエンゲージメント)を指定する、または +- 結果が常に正しいアセットにマッピングされるように設定する + +インポートされたすべての検出事項は、所有権、権限、SLA設定、レポートの範囲を含むアセットのコンテキストを継承します。 + +実務上、アセットは、CI/CD内でシステムがどのように構築・デプロイされるかを反映するように定義し、セキュリティの結果が常に正しいアプリケーションやサービスに関連付けられるようにすべきです。 + +### Jiraとの関係 + +アセットは、Jiraプロジェクトに直接マッピングでき、それによりアセットの検出事項がJiraインスタンスにプッシュされます。 + +検出事項は親アセットからリスク、優先度、所有権を継承するため、アセットは実質的に、Jiraチケットやダウンストリームコネクタのワークフローに流れ込む修復コンテキストを決定します。 + +重要な点として、アセットは検出事項のSLA特性を決定する主要な要因でもあります。そのため、検出事項のSLAは、その親アセットのSLA設定に依存します。SLA設定の詳細については、[こちら](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content)を参照してください。 diff --git a/docs/content/asset_modelling/engagements_tests/OS__calendar.de.md b/docs/content/asset_modelling/engagements_tests/OS__calendar.de.md new file mode 100644 index 00000000000..fe163f19a70 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__calendar.de.md @@ -0,0 +1,61 @@ +--- +title: Kalender +description: So verwenden Sie den Kalender in DefectDojo Pro +audience: opensource +weight: 9 +--- + +Der Kalender von DefectDojo bietet eine zentrale Zeitleistenansicht aller Engagements und Tests mit definiertem Start- und Enddatum. So können Benutzer die Testaktivität über Produkte hinweg schnell erfassen, Terminüberschneidungen erkennen und direkt zu den zugehörigen Objekten navigieren. + +Wenn ein Benutzer ein Engagement oder einen Test erstellt und Start- und Enddatum festlegt, wird automatisch ein entsprechender Eintrag im Kalender angelegt. Einträge erscheinen an allen Tagen vom festgelegten Startdatum bis einschließlich des festgelegten Enddatums. + +## Zugriff auf den Kalender + +Die Kalenderseite ist über die Schaltfläche „Kalender“ in der Seitenleiste erreichbar. + +![image](images/OSC_ss3.png) + +## Sichtbarkeit und Berechtigungen + +### Sichtbarkeit + +Die Kalenderseite enthält oben Filter und darunter ein monatliches Kalenderraster. Über die Navigationselemente oberhalb des Kalenders wechseln Sie zwischen den Monaten. + +Die Monatsansicht wird als festes Raster mit sechs Wochen dargestellt und beginnt mit der Woche, die den ersten Tag des ausgewählten Monats enthält. + +Die im Kalender sichtbaren Einträge können nach Objekttyp (Engagements oder Tests) und nach der Testleitung gefiltert werden, die in den Einstellungen des Engagements oder Tests festgelegt wird. Klicken Sie nach dem Auswählen der Filterkriterien auf „Anwenden“, um die Kalenderansicht zu aktualisieren. + +Es kann jeweils nur ein Objekttyp angezeigt werden. Beim Wechsel zwischen Engagements und Tests wird die Kalenderansicht entsprechend aktualisiert. + +### Berechtigungen + +Der Kalender berücksichtigt die objektbezogenen Berechtigungen von DefectDojo. Benutzer sehen nur Engagements und Tests, auf die sie zugriffsberechtigt sind. + +## Einträge ansehen und nutzen + +Innerhalb jeder Datumszelle sind die Einträge alphabetisch nach dem Namen des Objekts sortiert. Ein Klick auf einen Eintrag führt zum entsprechenden Objekt. + +Die Anzahl der pro Tag sichtbaren Einträge ist dynamisch und hängt von der Bildschirmgröße und der Zoomstufe des Browsers ab. Übersteigt die Zahl der Einträge den verfügbaren Platz in einer Datumszelle, erscheint am unteren Rand der Zelle ein Link in der Form „+X weitere“. + +![image](images/OSC_ss1.png) + +Klicken Sie auf den Link „+X weitere“, um ein Dialogfenster mit allen Einträgen dieses Datums zu öffnen. + +![image](images/OSC_ss2.png) + +Wichtig: Der Kalender selbst ist eine reine Leseansicht. Datumsangaben müssen in den Einstellungen des Engagement- oder Test-Objekts selbst geändert werden. + +### Benennungslogik + +Die Benennung der Einträge im Kalender unterscheidet sich je nach Objekttyp leicht. + +Engagement-Einträge enthalten: +- Produktname +- Engagement-Name +- Testleitung + +Test-Einträge enthalten: +- Produktname +- Engagement-Name +- Testtyp +- Testleitung diff --git a/docs/content/asset_modelling/engagements_tests/OS__calendar.es.md b/docs/content/asset_modelling/engagements_tests/OS__calendar.es.md new file mode 100644 index 00000000000..8dbca17fc92 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__calendar.es.md @@ -0,0 +1,61 @@ +--- +title: Calendario +description: Cómo usar el Calendario en DefectDojo Pro +audience: opensource +weight: 9 +--- + +El Calendario de DefectDojo ofrece una vista de línea de tiempo centralizada de todos los Compromisos y Tests con fechas de inicio y fin definidas, lo que permite a los Usuarios comprender rápidamente la actividad de pruebas en todos los Productos, identificar solapamientos de programación y navegar directamente a los objetos relacionados. + +Cuando un Usuario crea un Compromiso o Test y define fechas de inicio y fin, se agrega automáticamente una entrada correspondiente al Calendario. Las entradas aparecen en todas las fechas desde la fecha de inicio definida hasta la fecha de fin definida, inclusive. + +## Acceder al Calendario + +Se puede acceder a la página del Calendario a través del botón Calendario en la barra lateral. + +![imagen](images/OSC_ss3.png) + +## Visibilidad y permisos + +### Visibilidad + +La página del Calendario incluye filtros en la parte superior y una cuadrícula mensual del Calendario debajo. Use los controles de navegación encima del Calendario para moverse entre meses. + +La vista mensual se muestra como una cuadrícula fija de seis semanas, comenzando con la semana que contiene el primer día del mes seleccionado. + +Las entradas visibles dentro del Calendario se pueden filtrar según el tipo de objeto (Compromisos o Tests) y el Testing Lead, que se establece dentro de la configuración del Compromiso o Test. Después de seleccionar los criterios de filtro, haga clic en Aplicar para actualizar la vista del Calendario. + +Solo se puede mostrar un tipo de objeto a la vez. Cambiar entre Compromisos y Tests actualiza la vista del Calendario en consecuencia. + +### Permisos + +El Calendario respeta los permisos a nivel de objeto de DefectDojo. Los Usuarios solo ven los Compromisos y Tests a los que están autorizados a acceder. + +## Ver e interactuar con las entradas + +Dentro de cada celda de fecha, las entradas se ordenan alfabéticamente según el nombre del objeto. Al hacer clic en una entrada, se redirige al objeto correspondiente. + +La cantidad de entradas visibles cada día es dinámica y cambia según el tamaño de pantalla y el nivel de zoom del navegador. Si la cantidad de entradas supera el espacio disponible en una celda de fecha, aparece en la parte inferior de la celda un enlace con el formato “+X more”. + +![imagen](images/OSC_ss1.png) + +Haga clic en el enlace “+X more” para abrir un modal que muestra todas las entradas de esa fecha. + +![imagen](images/OSC_ss2.png) + +Es importante destacar que el Calendario en sí es una vista de solo lectura. Las fechas deben modificarse dentro de la configuración del objeto Compromiso o Test correspondiente. + +### Lógica de nomenclatura + +La nomenclatura de las entradas en el Calendario varía ligeramente según el tipo de objeto. + +Las entradas de Compromiso incluyen: +- Nombre del Producto +- Nombre del Compromiso +- Testing Lead + +Las entradas de Test incluyen: +- Nombre del Producto +- Nombre del Compromiso +- Tipo de Test +- Testing Lead diff --git a/docs/content/asset_modelling/engagements_tests/OS__calendar.fr.md b/docs/content/asset_modelling/engagements_tests/OS__calendar.fr.md new file mode 100644 index 00000000000..085d0cbe455 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__calendar.fr.md @@ -0,0 +1,61 @@ +--- +title: Calendrier +description: Comment utiliser le Calendrier dans DefectDojo Pro +audience: opensource +weight: 9 +--- + +Le Calendrier de DefectDojo fournit une vue chronologique centralisée de tous les Engagements et Tests ayant des dates de début et de fin définies, permettant aux Utilisateurs de comprendre rapidement l'activité de test à travers les Produits, d'identifier les chevauchements de planification, et de naviguer directement vers les objets associés. + +Lorsqu'un Utilisateur crée un Engagement ou un Test et définit des dates de début et de fin, une entrée correspondante est automatiquement ajoutée au Calendrier. Les entrées apparaissent à toutes les dates depuis la date de début définie jusqu'à la date de fin définie incluse. + +## Accéder au Calendrier + +La page Calendrier est accessible via le bouton Calendrier dans la barre latérale. + +![image](images/OSC_ss3.png) + +## Visibilité et permissions + +### Visibilité + +La page Calendrier comprend des filtres en haut et une grille de calendrier mensuelle en dessous. Utilisez les commandes de navigation au-dessus du Calendrier pour passer d'un mois à l'autre. + +La vue mensuelle s'affiche sous la forme d'une grille fixe de six semaines, commençant par la semaine contenant le premier jour du mois sélectionné. + +Les entrées visibles dans le Calendrier peuvent être filtrées selon le type d'objet (Engagements ou Tests) et le responsable de test, défini dans les paramètres de l'Engagement ou du Test. Après avoir sélectionné les critères de filtre, cliquez sur Appliquer pour actualiser la vue du Calendrier. + +Un seul type d'objet peut être affiché à la fois. Le basculement entre Engagements et Tests met à jour la vue du Calendrier en conséquence. + +### Permissions + +Le Calendrier respecte les permissions au niveau des objets de DefectDojo. Les Utilisateurs ne voient que les Engagements et Tests auxquels ils sont autorisés à accéder. + +## Consulter et interagir avec les entrées + +Au sein de chaque cellule de date, les entrées sont triées par ordre alphabétique selon le nom de l'objet. Cliquer sur une entrée redirige vers l'objet correspondant. + +Le nombre d'entrées visibles chaque jour est dynamique et varie selon la taille de l'écran et le niveau de zoom du navigateur. Si le nombre d'entrées dépasse l'espace disponible dans une cellule de date, un lien au format « +X de plus » apparaît en bas de la cellule. + +![image](images/OSC_ss1.png) + +Cliquez sur le lien « +X de plus » pour ouvrir une fenêtre modale affichant toutes les entrées de cette date. + +![image](images/OSC_ss2.png) + +Il est important de noter que le Calendrier lui-même est une vue en lecture seule. Les dates doivent être modifiées dans les paramètres de l'objet Engagement ou Test lui-même. + +### Logique de dénomination + +La dénomination des entrées dans le Calendrier varie légèrement selon le type d'objet. + +Les entrées d'Engagement incluent : +- Nom du Produit +- Nom de l'Engagement +- Responsable de test + +Les entrées de Test incluent : +- Nom du Produit +- Nom de l'Engagement +- Type de Test +- Responsable de test diff --git a/docs/content/asset_modelling/engagements_tests/OS__calendar.ja.md b/docs/content/asset_modelling/engagements_tests/OS__calendar.ja.md new file mode 100644 index 00000000000..220161f0f4e --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__calendar.ja.md @@ -0,0 +1,61 @@ +--- +title: カレンダー +description: DefectDojo Proでカレンダーを使用する方法 +audience: opensource +weight: 9 +--- + +DefectDojoのカレンダーは、開始日と終了日が定義されているすべてのエンゲージメントとテストを、一元化されたタイムラインビューとして提供します。これにより、ユーザーは製品間のテスト活動を素早く把握し、スケジュールの重複を特定し、関連するオブジェクトへ直接移動できます。 + +ユーザーがエンゲージメントまたはテストを作成し、開始日と終了日を定義すると、対応するエントリが自動的にカレンダーに追加されます。エントリは、定義された開始日から終了日までのすべての日付(終了日を含む)に表示されます。 + +## カレンダーへのアクセス + +カレンダーページには、サイドバーのカレンダーボタンからアクセスできます。 + +![image](images/OSC_ss3.png) + +## 表示と権限 + +### 表示 + +カレンダーページには、上部にフィルタ、その下に月表示のカレンダーグリッドがあります。カレンダーの上にあるナビゲーションコントロールを使って、月を移動できます。 + +月表示は、選択した月の1日を含む週から始まる、固定6週間のグリッドとして表示されます。 + +カレンダー内に表示されるエントリは、オブジェクトの種類(エンゲージメントまたはテスト)と、エンゲージメントまたはテストの設定内で設定されるテスト責任者(Testing Lead)に基づいてフィルタできます。フィルタ条件を選択した後、「適用」をクリックしてカレンダービューを更新してください。 + +一度に表示できるオブジェクトの種類は1つだけです。エンゲージメントとテストを切り替えると、それに応じてカレンダービューが更新されます。 + +### 権限 + +カレンダーは、DefectDojoのオブジェクトレベルの権限を尊重します。ユーザーには、アクセスが許可されているエンゲージメントとテストのみが表示されます。 + +## エントリの表示と操作 + +各日付のセル内では、エントリはオブジェクトの名前に基づいてアルファベット順に並べられます。エントリをクリックすると、対応するオブジェクトに移動します。 + +各日に表示できるエントリの数は、画面サイズやブラウザのズームレベルに応じて動的に変化します。エントリの数が日付セル内の表示可能なスペースを超えると、セルの下部に「+X more」という形式のリンクが表示されます。 + +![image](images/OSC_ss1.png) + +「+X more」リンクをクリックすると、その日付のすべてのエントリを表示するモーダルが開きます。 + +![image](images/OSC_ss2.png) + +重要な点として、カレンダー自体は読み取り専用のビューです。日付を変更するには、エンゲージメントまたはテストオブジェクト自体の設定内で行う必要があります。 + +### 命名ロジック + +カレンダー内のエントリの名称は、オブジェクトの種類によって若干異なります。 + +エンゲージメントのエントリには次が含まれます。 +- 製品名 +- エンゲージメント名 +- テスト責任者 + +テストのエントリには次が含まれます。 +- 製品名 +- エンゲージメント名 +- テスト種別 +- テスト責任者 diff --git a/docs/content/asset_modelling/engagements_tests/OS__engagements.de.md b/docs/content/asset_modelling/engagements_tests/OS__engagements.de.md new file mode 100644 index 00000000000..578a8c83b04 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__engagements.de.md @@ -0,0 +1,182 @@ +--- +title: Engagements +description: Engagements in DefectDojo OS verstehen +audience: opensource +weight: 3 +--- + +Organisationen → Assets → **ENGAGEMENTS** → Tests → Befunde + +## Überblick + +In der Produkthierarchie von DefectDojo sind Engagements zeit- oder pipelinegebundene Container, die Gruppen zusammengehöriger Tests innerhalb eines bestimmten Produkts darstellen. Wenn Sie eine geplante Testaktivität vorgesehen haben, egal ob routinemäßig oder einmalig, bietet Ihnen ein Engagement einen Ort, an dem Sie alle zugehörigen Ergebnisse speichern können. + +Beispiele für Engagements sind: +- Einmalige Penetrationstests +- Wiederkehrende monatliche oder vierteljährliche Scans +- Bug-Bounty-Prüfzeiträume +- CI/CD-Pipeline-Durchläufe (für Teams, die jede Pipeline als eigenes Engagement behandeln) +- Code-Release-Zyklen (z. B. „Sicherheitsüberprüfung für Release v4.2“) + +### Engagement-Typen + +DefectDojo unterstützt zwei Engagement-Typen: **Interaktiv** und **CI/CD**. Diese Typen bestimmen, wie Tests typischerweise erstellt werden und wie Scan-Ergebnisse importiert werden. + +Ein interaktives Engagement wird in der Regel von einem Ingenieur durchgeführt. Interaktive Engagements konzentrieren sich darauf, eine Anwendung während des Betriebs zu testen, sei es durch einen automatisierten Test, einen menschlichen Tester oder eine andere Aktivität, die mit der Funktionalität der Anwendung „interagiert“. + +Ein CI/CD-Engagement dient der automatisierten Integration mit einer CI/CD-Pipeline. CI/CD-Engagements sind dafür gedacht, Daten als automatisierte Aktion zu importieren, die durch einen Schritt im Release-Prozess ausgelöst wird. + +| **Kategorie** | **Interaktive Engagements** | **CI/CD-Engagements** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **Primärer Anwendungsfall** | Manuelle oder Ad-hoc-Sicherheitstests | Automatisierte, wiederkehrende Sicherheitstests innerhalb von Pipelines | +| **Dauer** | Zeitlich begrenzt und endlich | Potenziell unbegrenzte Dauer | +| **Häufigkeit** | Periodisch oder einmalig | Kontinuierlich oder pro Commit | +| **Workflow** | Menschlicher Tester führt Tool aus → importiert Ergebnisse manuell | Pipeline führt Tool aus → überträgt Ergebnisse automatisch an DefectDojo | +| **Methode des Ergebnisimports** | Manueller Upload über UI oder CLI | API-gesteuerter Import per Automatisierung (z. B. CLI, Connectors, Cron-Jobs, Pipeline-Skripte) | +| **Typischer Testtyp** | Penetrationstests, Red-Team-Übungen, manuelle Bewertungen | Statische Analyse, Dependency-Scanning, Container-Scanning | + +### Engagement-Daten + +Als die Container, die Testaktivitäten organisieren, können Engagements eine Vielzahl von Daten speichern oder nachverfolgen: + +- Geplante Start- und Enddaten +- Beschreibung und Hinweise zum Umfang +- Status (laufend, geplant, abgeschlossen usw.) +- Verantwortlicher / Lead +- Zugehörige Tests (z. B. Scans, Penetrationstests, manuelle Tests usw.) +- Befunde und Befundtypen (z. B. aktiv, behoben, Risiko akzeptiert, Duplikat usw.) +- Bedrohungsmodelle oder Informationen zur Risikoakzeptanz +- Tags +- Dateien und Notizen +- Jira-Projekteinstellungen +- Umgebungsdetails (z. B. Staging vs. Produktion) +- Build-IDs (falls mit CI/CD verknüpft) +- Historische Daten aus früheren Tests innerhalb des Engagements + +## Zugriff auf Engagements + +Engagements sind über die Seitenleiste zugänglich. Das Untermenü bietet Zugriff auf Aktive Engagements und Alle Engagements sowie die Möglichkeit, Engagements nach Produkt, Testtypen und Umgebungen organisiert anzuzeigen. + +![image](images/engagement_ss17.png) + +Alternativ können Engagements innerhalb eines bestimmten Produkts über das Untermenü der Option Engagements in der oberen Leiste aufgerufen werden. + +![image](images/engagement_ss18.png) + +### Berechtigungen + +Engagements stehen in der Objekthierarchie unterhalb von Produkten und oberhalb von Tests. Daher gewährt der Zugriff auf ein Produkt automatisch Zugriff auf alle Engagements innerhalb dieses Produkts. Engagements verfügen über keine eigenständigen Zugriffskontrolllisten. + +## Arbeiten mit Engagements + +### Engagements erstellen + +Es gibt mehrere Möglichkeiten, ein Engagement zu erstellen. Jede Möglichkeit erfordert, dass Sie zunächst ein Produkt erstellen, das das Engagement enthalten soll. + +Sobald Sie ein Produkt erstellt haben, können Sie im Bereich Engagements der Navigationsleiste des Produkts ein neues interaktives oder CI/CD-Engagement hinzufügen. + +![image](images/engagement_ss4.png) + +Für jedes Engagement müssen folgende Felder definiert sein: +- Typ (Interaktiv oder CI/CD) +- Ein eindeutiger Name +- Geplante Start- und Enddaten + - Diese bestimmen, wie das Engagement im Kalenderbereich angezeigt wird +- Produkt +- Status + +#### Engagement-Status + +Engagements können bei der Erstellung mit verschiedenen Status versehen werden. Der Status kann anschließend auch in den Einstellungen des Engagements geändert werden. + +Ein Engagement kann einen der folgenden Status haben: +- Nicht gestartet +- Blockiert +- Abgebrochen +- Abgeschlossen +- In Bearbeitung +- Angehalten +- Geplant +- Wartet auf Ressource + +Wenn der Status eines Engagements auf „Abgeschlossen“ geändert wird, bedeutet dies, dass die meisten Schreibvorgänge (z. B. das Hinzufügen von Tests, der Import von Scans) nicht mehr verfügbar oder ausgeblendet sind. Andere Status wirken sich nicht wesentlich auf die Funktionalität des Engagements aus und dienen eher der Filterung bzw. Information. + +### Engagements bearbeiten + +Engagements können bearbeitet werden, indem Sie auf die Schaltfläche **Bearbeiten** in den Einstellungen des Engagements klicken. Alle daraufhin bearbeitbaren Felder stehen auch bei der Erstellung des Engagements zur Verfügung. + +### Engagements kopieren + +Sie können Engagements einfach duplizieren, indem Sie zur Liste der Engagements innerhalb eines Produkts navigieren und im ⋮-Kebab-Menü neben dem zu kopierenden Engagement auf **Kopieren** klicken. Dadurch wird eine exakte Kopie des ursprünglichen Engagements innerhalb des übergeordneten Produkts erstellt, einschließlich der Metadaten, Tests und Befunde darin. + +![image](images/engagement_ss19.png) + +### Engagements schließen + +Engagements können geschlossen werden, indem Sie zur Liste der Engagements innerhalb eines Produkts navigieren und im ⋮-Kebab-Menü des gewählten Engagements auf „Schließen“ klicken. + +![image](images/engagement_ss20.png) + +Nach dem Schließen wird der Status des Engagements auf „Abgeschlossen“ geändert. Dennoch bleiben die meisten Schreibvorgänge (z. B. das Hinzufügen von Tests, der Import von Scans) weiterhin verfügbar. + +Das Schließen eines Engagements ändert nicht den Status der Befunde innerhalb der Tests des Engagements. Befunde bleiben je nach ihrem eigenen Lebenszyklus offen, behoben oder risikoakzeptiert und bleiben zur Ansicht und für Berichte weiterhin zugänglich. + +Wenn das Engagement mit einem Jira-Epic verknüpft ist (siehe **[Jira-Integration: Engagement-Epic-Zuordnung aktivieren](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**), löst das Schließen des Engagements eine asynchrone Aufgabe aus, die das zugehörige Jira-Epic in Ihrem verbundenen Jira-Space schließt. + +### Engagements erneut öffnen + +Wenn ein Engagement geschlossen ist, kann es erneut geöffnet werden, indem Sie in der Tabelle der geschlossenen Engagements im zugehörigen ⋮-Kebab-Menü auf **Erneut öffnen** klicken. Dadurch wird das Engagement wieder aktiv und sein Status kehrt zu „In Bearbeitung“ zurück. + +![image](images/engagement_ss21.png) + +### Abgelaufene Engagements + +Ein Engagement läuft ab, sobald sein geplantes Enddatum überschritten ist. + +Der Ablauf eines Engagements hat keine direkten Auswirkungen auf dessen Funktionalität und dient in erster Linie als Überwachungs- bzw. Benachrichtigungsmechanismus. + +Nach Ablauf erscheint im Feld „Dauer“ des Engagements eine rote Benachrichtigung „X Tage überfällig“, dies schränkt jedoch keine der Funktionen des Engagements ein. Der Status des Engagements wird weiterhin als „In Bearbeitung“ angezeigt. + +Obwohl standardmäßig nicht aktiviert, gibt es in den Systemeinstellungen eine Option, ein Engagement automatisch zu schließen, sobald es eine bestimmte Anzahl von Tagen abgelaufen ist. + +![image](images/engagement_ss22.png) + +### Engagements löschen + +Das Löschen eines Engagements erfolgt über die Auswahl von **Löschen** in den Einstellungen des Engagements. Diese Aktion kann nicht rückgängig gemacht werden. + +Das Löschen eines Engagements löscht auch Folgendes: +- Alle mit dem Engagement verbundenen Tests +- Alle Befunde innerhalb dieser Tests +- Alle verknüpften Jira-Epic-Zuordnungen (das Epic selbst bleibt in Jira erhalten, aber die Verknüpfung zwischen DefectDojo und Jira wird entfernt) +- Alle Notizen und Datei-Uploads, die mit dem Engagement verbunden sind + +Aus Gründen der Nachvollziehbarkeit wird empfohlen, abgeschlossene Engagements zu schließen, anstatt sie zu löschen. + +| **Vorgang** | **Ergebnisse** | **Umkehrbar** | +|----------|---------|------------| +| **Schließen** | Markiert als inaktiv; Daten bleiben erhalten; kann erneut geöffnet werden | Ja (erneut öffnen) | +| **Ablaufen** | Nur visuelle Warnung; optionales automatisches Schließen; Benachrichtigungen | N/A | +| **Löschen** | Entfernt Engagement, Tests, Befunde, Notizen, Dateien und alle Jira-Epic-Zuordnungen dauerhaft (Epics bleiben in Jira erhalten) | Nein | + +## Jira-Integration + +Engagements können mit einem verbundenen Jira-Space verknüpft werden, sodass Befunde innerhalb des Engagements als Issues an Jira übertragen werden können. Eine vollständige Anleitung zur Einrichtung von Jira finden Sie unter **[DefectDojo mit Jira verbinden](/connectors/os_jira/os__jira_guide/)**. + +### Engagement-Epic-Zuordnung + +Wenn **Engagement-Epic-Zuordnung aktivieren** in den Jira-Einstellungen eines Produkts aktiviert ist, werden Engagements als Epics an Jira übertragen. Befunde innerhalb des Engagements werden als untergeordnete Issues unter dem Epic übertragen und spiegeln damit die Hierarchie Engagement → Befunde von DefectDojo in der Struktur Epic → Issue von Jira wider. + +Weitere Informationen zu dieser Einstellung finden Sie unter **[Engagement-Epic-Zuordnung aktivieren](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**. + +### Jira-Einstellungen auf Engagement-Ebene + +Standardmäßig übernehmen Engagements ihre Jira-Einstellungen vom übergeordneten Produkt. Einzelne Engagements können diese Einstellungen jedoch überschreiben, um abweichende Jira-Konfigurationen zu verwenden. Folgende Einstellungen können pro Engagement angepasst werden: + +- **Projektschlüssel** — leitet Befunde an einen anderen Jira-Space weiter +- **Issue-Vorlage** — verwendet eine andere Vorlage für Issues, die aus diesem Engagement erstellt werden +- **Benutzerdefinierte Felder** — wendet abweichende Zuordnungen benutzerdefinierter Felder an +- **Jira-Labels** — versieht Issues mit engagementspezifischen Labels +- **Standardzuweisung** — weist Issues einem anderen Teammitglied zu + +Diese Einstellungen sind über die Seite **Engagement bearbeiten** zugänglich. Weitere Details finden Sie unter **[Jira-Einstellungen auf Engagement-Ebene](/connectors/os_jira/os__jira_guide/#engagement-level-jira-settings)**. diff --git a/docs/content/asset_modelling/engagements_tests/OS__engagements.es.md b/docs/content/asset_modelling/engagements_tests/OS__engagements.es.md new file mode 100644 index 00000000000..701663f007c --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__engagements.es.md @@ -0,0 +1,182 @@ +--- +title: Compromisos +description: Información sobre los Compromisos en DefectDojo OS +audience: opensource +weight: 3 +--- + +Organizaciones → Activos → **COMPROMISOS** → Tests → Hallazgos + +## Descripción general + +En la jerarquía de productos de DefectDojo, los Compromisos son contenedores delimitados por tiempo o por pipeline que representan grupos de Tests relacionados dentro de un Producto específico. Si tiene previsto un esfuerzo de testing programado, ya sea de forma rutinaria o puntual, un Compromiso le ofrece un lugar donde almacenar todos los resultados relacionados. + +Ejemplos de Compromisos incluyen: +- Pruebas de penetración puntuales +- Escaneos mensuales o trimestrales recurrentes +- Períodos de revisión de bug bounty +- Ejecuciones de pipeline de CI/CD (para equipos que tratan cada pipeline como su propio Compromiso) +- Ciclos de lanzamiento de código (p. ej., “revisión de seguridad del lanzamiento v4.2”) + +### Tipos de Compromiso + +DefectDojo admite dos tipos de Compromiso: **Interactivo** y **CI/CD**. Estos tipos determinan cómo se crean normalmente los Tests y cómo se importan los resultados del escaneo. + +Un Compromiso Interactivo suele ser ejecutado por un ingeniero. Los Compromisos Interactivos se centran en probar una aplicación mientras está en ejecución, mediante un test automatizado, un probador humano o cualquier actividad que “interactúe” con la funcionalidad de la aplicación. + +Un Compromiso de CI/CD es para la integración automatizada con un pipeline de CI/CD. Los Compromisos de CI/CD están pensados para importar datos como una acción automatizada, desencadenada por un paso del proceso de lanzamiento. + +| **Categoría** | **Compromisos Interactivos** | **Compromisos de CI/CD** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **Caso de uso principal** | Testing de seguridad manual o puntual | Testing de seguridad automatizado y recurrente dentro de pipelines | +| **Duración** | Delimitada en el tiempo y finita | Potencialmente de duración infinita | +| **Frecuencia** | Periódica o puntual | Continua o por cada commit | +| **Flujo de trabajo** | El probador humano ejecuta la herramienta → importa los resultados manualmente | El pipeline ejecuta la herramienta → envía automáticamente los resultados a DefectDojo | +| **Método de importación de resultados** | Carga manual mediante la UI o la CLI | Importación mediante API a través de automatización (p. ej., CLI, conectores, cron jobs, scripts de pipeline) | +| **Tipo de testing habitual** | Pruebas de penetración, ejercicios de red team, evaluaciones manuales | Análisis estático, escaneo de dependencias, escaneo de contenedores | + +### Datos del Compromiso + +Como contenedores que organizan la actividad de testing, los Compromisos pueden almacenar o registrar una variedad de datos: + +- Fechas objetivo de inicio y fin +- Descripción y notas de alcance +- Estado (en curso, planificado, completado, etc.) +- Responsable / Líder +- Tests asociados (p. ej., escaneos, pruebas de penetración, tests manuales, etc.) +- Hallazgos y tipos de Hallazgo (p. ej., activo, mitigado, riesgo aceptado, duplicado, etc.) +- Modelos de amenaza o información de aceptación de riesgo +- Etiquetas +- Archivos y notas +- Configuración del proyecto de Jira +- Detalles del entorno (p. ej., staging frente a producción) +- IDs de build (si está vinculado a CI/CD) +- Datos históricos de Tests anteriores dentro del Compromiso + +## Acceso a los Compromisos + +Se puede acceder a los Compromisos desde la barra lateral. El submenú ofrece acceso a los Compromisos activos y a todos los Compromisos, así como la opción de ver los Compromisos organizados por Producto, tipos de Test y Entornos. + +![image](images/engagement_ss17.png) + +Alternativamente, se puede acceder a los Compromisos dentro de un Producto concreto desde el submenú de la opción Compromisos en la barra superior. + +![image](images/engagement_ss18.png) + +### Permisos + +Los Compromisos se sitúan por debajo de los Productos y por encima de los Tests en la jerarquía de objetos. Por lo tanto, el acceso a un Producto otorga automáticamente acceso a todos los Compromisos dentro de ese Producto. Los Compromisos no tienen listas de control de acceso independientes. + +## Trabajar con Compromisos + +### Crear Compromisos + +Existen varios enfoques para crear un Compromiso. Cada enfoque requiere que primero cree un Producto que lo contenga. + +Una vez creado un Producto, puede añadir un nuevo Compromiso Interactivo o de CI/CD en la sección Compromisos de la barra de navegación del Producto. + +![image](images/engagement_ss4.png) + +Todo Compromiso debe tener definidos los siguientes campos: +- Tipo (Interactivo o CI/CD) +- Un nombre único +- Fechas objetivo de inicio y fin + - Esto determinará la aparición del Compromiso en la sección Calendario +- Producto +- Estado + +#### Estados del Compromiso + +Los Compromisos pueden etiquetarse con diferentes estados al crearlos. El estado también se puede cambiar posteriormente en la configuración del Compromiso. + +Un Compromiso puede tener cualquiera de los siguientes estados: +- No iniciado +- Bloqueado +- Cancelado +- Completado +- En curso +- En espera +- Programado +- Esperando recurso + +Cambiar el estado de un Compromiso a “Completado” significará que la mayoría de las operaciones de escritura (p. ej., añadir tests, importar escaneos) dejarán de estar disponibles o quedarán ocultas. Otros estados no afectarán materialmente a la funcionalidad del Compromiso, y son más bien para fines de filtrado/información. + +### Editar Compromisos + +Los Compromisos se pueden editar haciendo clic en el botón **Editar** dentro de la configuración del Compromiso. Todos los campos editables subsiguientes también están disponibles al crear el Compromiso. + +### Copiar Compromisos + +Puede duplicar fácilmente los Compromisos navegando a la lista de Compromisos dentro de un Producto y haciendo clic en el botón **Copiar** dentro del menú kebab ⋮ junto al Compromiso que desea copiar. Esto creará una copia exacta del Compromiso original dentro del Producto principal, incluyendo los metadatos, Tests y Hallazgos que contiene. + +![image](images/engagement_ss19.png) + +### Cerrar Compromisos + +Los Compromisos se pueden cerrar navegando a la lista de Compromisos dentro de un Producto y haciendo clic en “Cerrar” dentro del menú kebab ⋮ del Compromiso elegido. + +![image](images/engagement_ss20.png) + +Una vez cerrado, el estado del Compromiso cambiará a “Completado”. No obstante, la mayoría de las operaciones de escritura (p. ej., añadir tests, importar escaneos) seguirán estando disponibles. + +Cerrar un Compromiso no cambia el estado de los Hallazgos dentro de ninguno de los Tests del Compromiso. Los Hallazgos permanecen abiertos, mitigados o con riesgo aceptado según su propio ciclo de vida, y siguen siendo accesibles para su visualización e informes. + +Si el Compromiso está vinculado a un Epic de Jira (consulte **[Integración con Jira: Habilitar el mapeo de Epics de Compromiso](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**), cerrar el Compromiso desencadenará una tarea asíncrona que cierra el Epic de Jira asociado en su Espacio de Jira conectado. + +### Reabrir Compromisos + +Si un Compromiso está cerrado, se puede reabrir haciendo clic en **Reabrir** dentro de su menú kebab ⋮ en la tabla de Compromisos cerrados. Esto hará que el Compromiso vuelva a estar activo y su estado regresará a “En curso”. + +![image](images/engagement_ss21.png) + +### Compromisos vencidos + +Un Compromiso vence una vez que pasa su fecha objetivo de fin. + +El vencimiento del Compromiso no tiene un impacto directo en su funcionalidad, y sirve principalmente como mecanismo de monitoreo/notificación. + +Una vez vencido, aparecerá una notificación en rojo de “X días de retraso” en el campo “Duración” del Compromiso, pero no restringirá ninguna de sus funcionalidades. El estado del Compromiso seguirá apareciendo como “En curso”. + +Aunque no está habilitado de forma predeterminada, existe una opción dentro de la configuración del sistema para cerrar automáticamente un Compromiso una vez que ha estado vencido durante un determinado número de días. + +![image](images/engagement_ss22.png) + +### Eliminar Compromisos + +La eliminación de un Compromiso se puede realizar seleccionando **Eliminar** en la configuración del Compromiso. Esta acción no se puede deshacer. + +Eliminar un Compromiso también eliminará lo siguiente: +- Cualquier Test asociado al Compromiso +- Todos los Hallazgos dentro de esos Tests +- Cualquier mapeo de Epic de Jira vinculado (el Epic en sí permanecerá en Jira, pero se eliminará el vínculo entre DefectDojo y Jira) +- Todas las notas y archivos adjuntos asociados al Compromiso + +Por motivos de auditoría, se recomienda cerrar los Compromisos completados en lugar de eliminarlos. + +| **Operación** | **Resultados** | **Reversible** | +|----------|---------|------------| +| **Cerrar** | Se marca como inactivo; los datos permanecen; se puede reabrir | Sí (reabrir) | +| **Vencer** | Solo advertencia visual; cierre automático opcional; notificaciones | N/D | +| **Eliminar** | Elimina permanentemente el Compromiso, los Tests, los Hallazgos, las notas, los archivos y cualquier mapeo de Epic de Jira (los Epics permanecen en Jira) | No | + +## Integración con Jira + +Los Compromisos se pueden vincular a un Espacio de Jira conectado, lo que permite que los Hallazgos dentro del Compromiso se envíen a Jira como Issues. Para obtener una guía completa sobre cómo configurar Jira, consulte **[Conectar DefectDojo a Jira](/connectors/os_jira/os__jira_guide/)**. + +### Mapeo de Epics de Compromiso + +Cuando la opción **Habilitar el mapeo de Epics de Compromiso** está marcada en la configuración de Jira de un Producto, los Compromisos se enviarán a Jira como Epics. Los Hallazgos dentro del Compromiso se envían como Issues secundarios bajo el Epic, reflejando la jerarquía Compromiso → Hallazgos de DefectDojo en la estructura Epic → Issue de Jira. + +Para más información sobre esta configuración, consulte **[Habilitar el mapeo de Epics de Compromiso](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**. + +### Configuración de Jira a nivel de Compromiso + +De forma predeterminada, los Compromisos heredan su configuración de Jira de su Producto principal. Sin embargo, los Compromisos individuales pueden anular esta configuración para usar configuraciones de Jira diferentes. Los siguientes ajustes se pueden personalizar por Compromiso: + +- **Clave del proyecto** — enrutar los Hallazgos a un Espacio de Jira diferente +- **Plantilla de Issue** — usar una plantilla diferente para los Issues creados a partir de este Compromiso +- **Campos personalizados** — aplicar diferentes mapeos de campos personalizados +- **Etiquetas de Jira** — etiquetar los Issues con etiquetas específicas del Compromiso +- **Responsable predeterminado** — asignar los Issues a otro miembro del equipo + +Estos ajustes están disponibles desde la página **Editar Compromiso**. Para más detalles, consulte **[Configuración de Jira a nivel de Compromiso](/connectors/os_jira/os__jira_guide/#engagement-level-jira-settings)**. diff --git a/docs/content/asset_modelling/engagements_tests/OS__engagements.fr.md b/docs/content/asset_modelling/engagements_tests/OS__engagements.fr.md new file mode 100644 index 00000000000..a612d843b8e --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__engagements.fr.md @@ -0,0 +1,182 @@ +--- +title: Engagements +description: Comprendre les Engagements dans DefectDojo OS +audience: opensource +weight: 3 +--- + +Organisations → Actifs → **ENGAGEMENTS** → Tests → Constatations + +## Aperçu + +Dans la hiérarchie des produits de DefectDojo, les Engagements sont des conteneurs limités dans le temps ou liés à un pipeline qui représentent des groupes de Tests associés au sein d’un Produit spécifique. Si vous avez prévu un effort de test planifié, que ce soit de façon routinière ou ponctuelle, un Engagement vous offre un endroit où stocker tous les résultats associés. + +Voici des exemples d’Engagements : +- Tests d’intrusion ponctuels +- Analyses mensuelles ou trimestrielles récurrentes +- Périodes de revue de bug bounty +- Exécutions de pipeline CI/CD (pour les équipes qui traitent chaque pipeline comme son propre Engagement) +- Cycles de publication de code (par exemple, « revue de sécurité de la version v4.2 ») + +### Types d’Engagement + +DefectDojo prend en charge deux types d’Engagement : **Interactif** et **CI/CD**. Ces types déterminent la façon dont les Tests sont généralement créés et dont les résultats d’analyse sont importés. + +Un Engagement Interactif est généralement mené par un ingénieur. Les Engagements Interactifs se concentrent sur le test d’une application pendant son exécution, à l’aide d’un test automatisé, d’un testeur humain, ou de toute activité « interagissant » avec les fonctionnalités de l’application. + +Un Engagement CI/CD sert à l’intégration automatisée avec un pipeline CI/CD. Les Engagements CI/CD sont destinés à importer des données sous forme d’action automatisée, déclenchée par une étape du processus de publication. + +| **Catégorie** | **Engagements Interactifs** | **Engagements CI/CD** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **Cas d’usage principal** | Test de sécurité manuel ou ad hoc | Test de sécurité automatisé et récurrent au sein des pipelines | +| **Durée** | Limitée dans le temps et finie | Durée potentiellement infinie | +| **Fréquence** | Périodique ou ponctuelle | Continue ou par commit | +| **Flux de travail** | Un testeur humain exécute l’outil → importe manuellement les résultats | Le pipeline exécute l’outil → transmet automatiquement les résultats à DefectDojo | +| **Méthode d’import des résultats** | Import manuel via l’interface ou la CLI | Import piloté par API via l’automatisation (par exemple, CLI, connecteurs, tâches cron, scripts de pipeline) | +| **Type de test typique** | Tests d’intrusion, exercices d’équipe rouge, évaluations manuelles | Analyse statique, analyse des dépendances, analyse de conteneurs | + +### Données de l’Engagement + +En tant que conteneurs organisant l’activité de test, les Engagements peuvent stocker ou suivre diverses données : + +- Dates de début et de fin cibles +- Description et notes de périmètre +- Statut (en cours, planifié, terminé, etc.) +- Assigné / Responsable +- Tests associés (par exemple, analyses, tests d’intrusion, tests manuels, etc.) +- Constatations et types de Constatations (par exemple, actif, atténué, risque accepté, doublon, etc.) +- Modèles de menace ou informations sur l’acceptation du risque +- Étiquettes +- Fichiers et notes +- Paramètres de projet Jira +- Détails sur l’environnement (par exemple, préproduction vs production) +- ID de build (si lié à un pipeline CI/CD) +- Données historiques des Tests précédents au sein de l’Engagement + +## Accéder aux Engagements + +Les Engagements sont accessibles via la barre latérale. Le sous-menu donne accès aux Engagements actifs et à tous les Engagements, ainsi qu’à l’option d’afficher les Engagements organisés par Produit, types de Test et environnements. + +![image](images/engagement_ss17.png) + +Autrement, les Engagements au sein d’un Produit particulier sont accessibles depuis le sous-menu de l’option Engagements dans la barre supérieure. + +![image](images/engagement_ss18.png) + +### Permissions + +Les Engagements se situent en dessous des Produits et au-dessus des Tests dans la hiérarchie des objets. Ainsi, l’accès à un Produit accorde automatiquement l’accès à tous les Engagements de ce Produit. Les Engagements n’ont pas de listes de contrôle d’accès indépendantes. + +## Utiliser les Engagements + +### Créer des Engagements + +Il existe plusieurs façons de créer un Engagement. Chaque méthode nécessite d’abord de créer un Produit pour le contenir. + +Une fois un Produit créé, vous pouvez ajouter un nouvel Engagement Interactif ou CI/CD dans la section Engagements de la barre de navigation du Produit. + +![image](images/engagement_ss4.png) + +Chaque Engagement doit avoir les champs suivants définis : +- Type (Interactif ou CI/CD) +- Un nom unique +- Dates de début et de fin cibles + - Cela déterminera l’apparition de l’Engagement dans la section Calendrier +- Produit +- Statut + +#### Statuts d’Engagement + +Les Engagements peuvent être marqués de différents statuts lors de leur création. Le statut peut également être modifié par la suite dans les paramètres de l’Engagement. + +Un Engagement peut avoir l’un des statuts suivants : +- Non démarré +- Bloqué +- Annulé +- Terminé +- En cours +- En attente +- Planifié +- En attente de ressource + +Changer le statut d’un Engagement en « Terminé » signifie que la plupart des opérations d’écriture (par exemple, ajouter des tests, importer des analyses) deviendront indisponibles ou masquées. Les autres statuts n’affectent pas matériellement les fonctionnalités de l’Engagement et servent surtout au filtrage ou à des fins informatives. + +### Modifier des Engagements + +Les Engagements peuvent être modifiés en cliquant sur le bouton **Modifier** dans les paramètres de l’Engagement. Tous les champs modifiables qui en découlent sont également disponibles lors de la création de l’Engagement. + +### Copier des Engagements + +Vous pouvez facilement dupliquer des Engagements en accédant à la liste des Engagements au sein d’un Produit et en cliquant sur le bouton **Copier** dans le menu kebab ⋮ situé à côté de l’Engagement à copier. Cela créera une copie exacte de l’Engagement d’origine au sein du Produit parent, y compris les métadonnées, les Tests et les Constatations qu’il contient. + +![image](images/engagement_ss19.png) + +### Fermer des Engagements + +Les Engagements peuvent être fermés en accédant à la liste des Engagements au sein d’un Produit et en cliquant sur « Fermer » dans le menu kebab ⋮ de l’Engagement choisi. + +![image](images/engagement_ss20.png) + +Une fois fermé, le statut de l’Engagement passera à « Terminé ». Néanmoins, la plupart des opérations d’écriture (par exemple, ajouter des tests, importer des analyses) resteront disponibles. + +La fermeture d’un Engagement ne modifie pas le statut des Constatations au sein des Tests de l’Engagement. Les Constatations restent actives, atténuées ou à risque accepté selon leur propre cycle de vie, et restent accessibles pour consultation et création de rapports. + +Si l’Engagement est lié à une Épopée (Epic) Jira (voir **[Intégration Jira : activer le mappage des Épopées d’Engagement](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**), la fermeture de l’Engagement déclenchera une tâche asynchrone qui fermera l’Épopée Jira associée dans votre Espace Jira connecté. + +### Rouvrir des Engagements + +Si un Engagement est fermé, il peut être rouvert en cliquant sur **Rouvrir** dans son menu kebab ⋮ dans le tableau des Engagements fermés. Cela réactivera l’Engagement et ramènera son statut à « En cours ». + +![image](images/engagement_ss21.png) + +### Engagements expirés + +Un Engagement expire une fois que sa date de fin cible est dépassée. + +L’expiration d’un Engagement n’a pas d’impact direct sur ses fonctionnalités et sert principalement de mécanisme de surveillance/notification. + +Une fois expiré, une notification rouge « X jours de retard » apparaîtra dans le champ « Durée » de l’Engagement, mais cela ne restreindra aucune de ses fonctionnalités. Le statut de l’Engagement continuera d’afficher « En cours ». + +Bien que cela ne soit pas activé par défaut, une option dans les paramètres système permet de fermer automatiquement un Engagement une fois qu’il a expiré depuis un certain nombre de jours. + +![image](images/engagement_ss22.png) + +### Supprimer des Engagements + +La suppression d’un Engagement peut être effectuée en sélectionnant **Supprimer** dans les paramètres de l’Engagement. Cette action est irréversible. + +Supprimer un Engagement supprimera également ce qui suit : +- Tous les Tests associés à l’Engagement +- Toutes les Constatations au sein de ces Tests +- Tous les mappages d’Épopées Jira liés (l’Épopée elle-même restera dans Jira, mais le lien entre DefectDojo et Jira sera supprimé) +- Toutes les notes et tous les fichiers téléchargés associés à l’Engagement + +À des fins d’audit, il est recommandé de fermer les Engagements terminés plutôt que de les supprimer. + +| **Opération** | **Résultats** | **Réversible** | +|----------|---------|------------| +| **Fermer** | Marque comme inactif ; les données restent ; peut être rouvert | Oui (réouverture) | +| **Expirer** | Avertissement visuel uniquement ; fermeture automatique optionnelle ; notifications | S/O | +| **Supprimer** | Supprime définitivement l’Engagement, les Tests, les Constatations, les notes, les fichiers et tous les mappages d’Épopées Jira (les Épopées restent dans Jira) | Non | + +## Intégration Jira + +Les Engagements peuvent être liés à un Espace Jira connecté, permettant aux Constatations de l’Engagement d’être transmises à Jira sous forme de Tickets. Pour un guide complet de configuration de Jira, voir **[Connecter DefectDojo à Jira](/connectors/os_jira/os__jira_guide/)**. + +### Mappage des Épopées d’Engagement + +Lorsque **Activer le mappage des Épopées d’Engagement** est coché dans les paramètres Jira d’un Produit, les Engagements seront transmis à Jira sous forme d’Épopées. Les Constatations au sein de l’Engagement sont transmises comme Tickets enfants sous l’Épopée, reflétant la hiérarchie Engagement → Constatations de DefectDojo dans la structure Épopée → Ticket de Jira. + +Pour plus d’informations sur ce paramètre, voir **[Activer le mappage des Épopées d’Engagement](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**. + +### Paramètres Jira au niveau de l’Engagement + +Par défaut, les Engagements héritent de leurs paramètres Jira depuis leur Produit parent. Cependant, chaque Engagement peut redéfinir ces paramètres pour utiliser des configurations Jira différentes. Les paramètres suivants peuvent être personnalisés par Engagement : + +- **Clé de projet** — router les Constatations vers un autre Espace Jira +- **Modèle de ticket** — utiliser un modèle différent pour les Tickets créés à partir de cet Engagement +- **Champs personnalisés** — appliquer des mappages de champs personnalisés différents +- **Étiquettes Jira** — étiqueter les Tickets avec des étiquettes spécifiques à l’Engagement +- **Assigné par défaut** — assigner les Tickets à un autre membre de l’équipe + +Ces paramètres sont accessibles depuis la page **Modifier l’Engagement**. Pour plus de détails, voir **[Paramètres Jira au niveau de l’Engagement](/connectors/os_jira/os__jira_guide/#engagement-level-jira-settings)**. diff --git a/docs/content/asset_modelling/engagements_tests/OS__engagements.ja.md b/docs/content/asset_modelling/engagements_tests/OS__engagements.ja.md new file mode 100644 index 00000000000..3651723efa5 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__engagements.ja.md @@ -0,0 +1,182 @@ +--- +title: エンゲージメント +description: DefectDojo OSにおけるエンゲージメントの理解 +audience: opensource +weight: 3 +--- + +組織 → アセット → **エンゲージメント** → テスト → 検出事項 + +## 概要 + +DefectDojoの製品階層において、エンゲージメントは特定の製品内で関連するテストをグループ化する、期間またはパイプラインに紐づいたコンテナです。定期的であれ単発であれ、計画されたテスト活動がある場合、エンゲージメントはその関連する結果をすべて格納する場所を提供します。 + +エンゲージメントの例には、以下のようなものがあります。 +- 単発のペネトレーションテスト +- 毎月または四半期ごとに実施される定期スキャン +- バグバウンティのレビュー期間 +- CI/CDパイプラインの実行(各パイプラインを個別のエンゲージメントとして扱うチームの場合) +- コードリリースサイクル(例:「v4.2リリースのセキュリティレビュー」) + +### エンゲージメントの種類 + +DefectDojoは、**インタラクティブ**と**CI/CD**の2種類のエンゲージメントをサポートしています。これらの種類によって、テストが通常どのように作成され、スキャン結果がどのようにインポートされるかが決まります。 + +インタラクティブエンゲージメントは、通常エンジニアによって実施されます。インタラクティブエンゲージメントは、自動テスト、人間のテスター、またはアプリケーションの機能と「対話」する何らかの活動を用いて、アプリケーションが稼働している状態でテストを行うことに重点を置いています。 + +CI/CDエンゲージメントは、CI/CDパイプラインとの自動連携を目的としています。CI/CDエンゲージメントは、リリースプロセスの一部のステップによってトリガーされる自動アクションとしてデータをインポートすることを想定しています。 + +| **カテゴリ** | **インタラクティブエンゲージメント** | **CI/CDエンゲージメント** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **主なユースケース** | 手動またはアドホックなセキュリティテスト | パイプライン内での自動化された定期的なセキュリティテスト | +| **期間** | 期間が定められた有限のもの | 無期限になり得るもの | +| **頻度** | 定期的または単発 | 継続的またはコミットごと | +| **ワークフロー** | 人間のテスターがツールを実行 → 手動で結果をインポート | パイプラインがツールを実行 → 自動的に結果をDefectDojoにプッシュ | +| **結果のインポート方法** | UIまたはCLI経由での手動アップロード | 自動化(CLI、コネクタ、cronジョブ、パイプラインスクリプトなど)によるAPI駆動のインポート | +| **一般的なテストの種類** | ペネトレーションテスト、レッドチーム演習、手動評価 | 静的解析、依存関係スキャン、コンテナスキャン | + +### エンゲージメントのデータ + +テスト活動を整理するコンテナとして、エンゲージメントはさまざまなデータを格納・追跡できます。 + +- 目標開始日と終了日 +- 説明とスコープに関するメモ +- ステータス(進行中、計画中、完了など) +- 担当者/リード +- 関連するテスト(スキャン、ペネトレーションテスト、手動テストなど) +- 検出事項と検出事項の種類(アクティブ、緩和済み、リスク受容済み、重複など) +- 脅威モデルまたはリスク受容に関する情報 +- タグ +- ファイルとメモ +- Jiraプロジェクトの設定 +- 環境の詳細(ステージング環境か本番環境かなど) +- ビルドID(CI/CDに連携している場合) +- エンゲージメント内の過去のテストの履歴データ + +## エンゲージメントへのアクセス + +エンゲージメントにはサイドバーからアクセスできます。サブメニューからは、アクティブなエンゲージメントとすべてのエンゲージメントにアクセスできるほか、製品別、テストの種類別、環境別にエンゲージメントを表示するオプションも利用できます。 + +![image](images/engagement_ss17.png) + +また、特定の製品内のエンゲージメントは、トップバーの「エンゲージメント」オプションのサブメニューからアクセスすることもできます。 + +![image](images/engagement_ss18.png) + +### 権限 + +エンゲージメントは、オブジェクト階層において製品の下、テストの上に位置します。そのため、製品へのアクセス権を持っていると、その製品内のすべてのエンゲージメントへのアクセス権が自動的に付与されます。エンゲージメントは独自のアクセス制御リストを持ちません。 + +## エンゲージメントの操作 + +### エンゲージメントの作成 + +エンゲージメントの作成にはいくつかの方法があります。いずれの方法でも、まずエンゲージメントを格納する製品を作成しておく必要があります。 + +製品を作成したら、製品のナビゲーションバーの「エンゲージメント」セクションから、新しいインタラクティブエンゲージメントまたはCI/CDエンゲージメントを追加できます。 + +![image](images/engagement_ss4.png) + +すべてのエンゲージメントには、以下のフィールドを設定する必要があります。 +- 種類(インタラクティブまたはCI/CD) +- 一意の名前 +- 目標開始日と終了日 + - これにより、カレンダーセクションにおけるエンゲージメントの表示が決まります +- 製品 +- ステータス + +#### エンゲージメントのステータス + +エンゲージメントには、作成時にさまざまなステータスを設定できます。ステータスは、エンゲージメントの設定から後で変更することもできます。 + +エンゲージメントには、以下のいずれかのステータスを設定できます。 +- 未着手 +- ブロック中 +- キャンセル済み +- 完了 +- 進行中 +- 保留中 +- 予定済み +- リソース待ち + +エンゲージメントのステータスを「完了」に変更すると、テストの追加やスキャンのインポートといった大半の書き込み操作が利用できなくなるか、非表示になります。それ以外のステータスは、エンゲージメントの機能には実質的な影響を与えず、主にフィルタリングや情報提供の目的で使用されます。 + +### エンゲージメントの編集 + +エンゲージメントは、エンゲージメントの設定内にある**編集**ボタンをクリックすることで編集できます。編集可能なフィールドは、エンゲージメントの作成時にも同様に利用できます。 + +### エンゲージメントのコピー + +製品内のエンゲージメント一覧に移動し、コピーしたいエンゲージメントの横にある⋮ケバブメニューから**コピー**ボタンをクリックすることで、エンゲージメントを簡単に複製できます。これにより、メタデータ、テスト、検出事項を含む元のエンゲージメントの完全なコピーが、親製品内に作成されます。 + +![image](images/engagement_ss19.png) + +### エンゲージメントのクローズ + +エンゲージメントをクローズするには、製品内のエンゲージメント一覧に移動し、対象のエンゲージメントの⋮ケバブメニューから「クローズ」をクリックします。 + +![image](images/engagement_ss20.png) + +クローズすると、エンゲージメントのステータスは「完了」に変更されます。ただし、テストの追加やスキャンのインポートといった大半の書き込み操作は、引き続き利用可能です。 + +エンゲージメントをクローズしても、そのエンゲージメント内のテストに含まれる検出事項のステータスは変更されません。検出事項は、それぞれのライフサイクルに従ってオープン、緩和済み、またはリスク受容済みのままとなり、閲覧やレポート作成のために引き続きアクセス可能です。 + +エンゲージメントがJiraのEpicにリンクされている場合(**[Jira連携:エンゲージメントEpicマッピングの有効化](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**を参照)、エンゲージメントをクローズすると、連携先のJiraスペース内の対応するEpicをクローズする非同期タスクがトリガーされます。 + +### エンゲージメントの再オープン + +クローズされたエンゲージメントは、クローズ済みエンゲージメントのテーブル内にある⋮ケバブメニューから**再オープン**をクリックすることで再オープンできます。これにより、エンゲージメントは再度アクティブになり、ステータスは「進行中」に戻ります。 + +![image](images/engagement_ss21.png) + +### 期限切れのエンゲージメント + +エンゲージメントは、目標終了日を過ぎると期限切れになります。 + +エンゲージメントの期限切れは、エンゲージメントの機能に直接的な影響を与えるものではなく、主に監視/通知の仕組みとして機能します。 + +期限切れになると、エンゲージメントの「期間」フィールドに赤色で「X日超過」という通知が表示されますが、エンゲージメントの機能が制限されることはありません。エンゲージメントのステータスは引き続き「進行中」と表示されます。 + +デフォルトでは有効になっていませんが、エンゲージメントが一定の日数だけ期限切れになった時点で自動的にクローズするオプションがシステム設定内に用意されています。 + +![image](images/engagement_ss22.png) + +### エンゲージメントの削除 + +エンゲージメントの削除は、エンゲージメントの設定から**削除**を選択することで実行できます。この操作は元に戻せません。 + +エンゲージメントを削除すると、以下も併せて削除されます。 +- エンゲージメントに関連するすべてのテスト +- それらのテストに含まれるすべての検出事項 +- リンクされているJira Epicのマッピング(Epic自体はJira上に残りますが、DefectDojoとJiraの間のリンクは削除されます) +- エンゲージメントに関連するすべてのメモとアップロードされたファイル + +監査の観点から、完了したエンゲージメントは削除するのではなく、クローズすることを推奨します。 + +| **操作** | **結果** | **元に戻せるか** | +|----------|---------|------------| +| **クローズ** | 非アクティブとしてマークされる。データは残る。再オープン可能 | はい(再オープン) | +| **期限切れ** | 視覚的な警告のみ。オプションで自動クローズ。通知あり | 該当なし | +| **削除** | エンゲージメント、テスト、検出事項、メモ、ファイル、Jira Epicマッピング(Epic自体はJiraに残る)を完全に削除 | いいえ | + +## Jira連携 + +エンゲージメントは連携先のJiraスペースにリンクでき、エンゲージメント内の検出事項をJiraにIssueとしてプッシュできるようになります。Jiraの設定に関する完全なガイドについては、**[DefectDojoとJiraの連携](/connectors/os_jira/os__jira_guide/)**を参照してください。 + +### エンゲージメントEpicマッピング + +製品のJira設定で**エンゲージメントEpicマッピングを有効化**がチェックされている場合、エンゲージメントはJiraにEpicとしてプッシュされます。エンゲージメント内の検出事項は、そのEpicの下に子Issueとしてプッシュされ、DefectDojoのエンゲージメント→検出事項という階層が、JiraのEpic→Issueという構造に反映されます。 + +この設定の詳細については、**[エンゲージメントEpicマッピングの有効化](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**を参照してください。 + +### エンゲージメントレベルのJira設定 + +デフォルトでは、エンゲージメントは親製品からJira設定を継承します。ただし、個々のエンゲージメントでこれらの設定を上書きし、異なるJira構成を使用することも可能です。エンゲージメントごとにカスタマイズできる設定は以下のとおりです。 + +- **プロジェクトキー** — 検出事項を別のJiraスペースに振り分ける +- **Issueテンプレート** — このエンゲージメントから作成されるIssueに別のテンプレートを使用する +- **カスタムフィールド** — 異なるカスタムフィールドのマッピングを適用する +- **Jiraラベル** — エンゲージメント固有のラベルをIssueに付与する +- **デフォルトの担当者** — Issueを別のチームメンバーに割り当てる + +これらの設定は、**エンゲージメントの編集**ページからアクセスできます。詳細については、**[エンゲージメントレベルのJira設定](/connectors/os_jira/os__jira_guide/#engagement-level-jira-settings)**を参照してください。 diff --git a/docs/content/asset_modelling/engagements_tests/OS__findings.de.md b/docs/content/asset_modelling/engagements_tests/OS__findings.de.md new file mode 100644 index 00000000000..9d2bdc02a11 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__findings.de.md @@ -0,0 +1,302 @@ +--- +title: Befunde +description: Befunde in DefectDojo OS verstehen +audience: opensource +weight: 5 +--- + +Organisationen → Assets → Engagements → Tests → **BEFUNDE** + +## Überblick + +**Befunde** repräsentieren die unterste Ebene der Produkthierarchie, auf der einzelne Schwachstellen erfasst und verwaltet werden, und sind die wichtigste Methode, mit der DefectDojo den Melde- und Behebungsprozess Ihrer Sicherheitstools standardisiert und steuert. Unabhängig davon, ob eine Schwachstelle in SonarQube, Acunetix oder dem individuellen Tool Ihres Teams gemeldet wurde, ermöglichen Ihnen Befunde, jede Schwachstelle auf die gleiche Weise zu verwalten. + +Beispiele für Befunde sind: +- Cookie nicht als HttpOnly markiert +- Veraltete Version (PHP) +- Out-of-Band-Codeauswertung (PHP) +- Veraltete Version (MySQL) +- Backup-Quellcode entdeckt +- Blindes Cross-Site-Scripting + +Zusätzlich zur Speicherung der Schwachstellendaten und zur Bereitstellung eines Behebungsrahmens verbessert DefectDojo Ihre Befunde auf folgende Weise: +- Automatisches Hinzufügen zugehöriger EPSS-Werte zu einem Befund, um dessen Ausnutzbarkeit zu beschreiben +- Automatische Übersetzung der Schweregradmetrik eines Sicherheitstools in einen Schweregrad-Wert für jeden Befund, der dem Befund gemäß der SLA-Konfiguration Ihres Assets eine SLA zuweist. Weitere Informationen zur SLA-Konfiguration finden Sie [hier](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). + +Insgesamt sind Befunde darauf ausgelegt, mit der Produkthierarchie zusammenzuarbeiten, um Ihre Bemühungen zu standardisieren und eine einheitliche Methode auf jedes Asset anzuwenden. + +## Zugriff auf Befunde + +Befunde sind über die Seitenleiste zugänglich. Das Untermenü bietet Zugriff auf Offene und Geschlossene Befunde, Alle Befunde (unabhängig vom Status Offen oder Geschlossen), [Risikoakzeptierte Befunde](/triage_findings/findings_workflows/os__risk_acceptance/), sowie Befundvorlagen. Einzelne Befunde sind auch innerhalb des Tests zugänglich, der sie enthält. + +![image](images/osfindings_ss1.png) + +### Berechtigungen + +Jeder Befund gehört zu einem Test, wodurch DefectDojo nachverfolgen kann, welcher Scan oder welche Bewertung die Schwachstelle ursprünglich identifiziert hat. + +Da Befunde zu Tests gehören, wird der Zugriff auf Befunde durch den Zugriff eines Benutzers auf das Asset bestimmt, das den Test enthält. Tests verfügen über keine eigenständigen Zugriffskontrolllisten. + +## Befundansicht +Befundansichten enthalten eine Vielzahl von Tabellen, die dabei helfen, den Status eines Befunds auf einen Blick zu erfassen. Dazu gehören: +- **Überblick** + - **ID**: Die eindeutige ID-Nummer dieses Befunds. + - **Schweregrad**: Die Schweregrad-Bewertung dieses Befunds, die automatisch vergeben wird. + - Wie oben erwähnt, übersetzt DefectDojo automatisch die Schweregradmetrik eines Sicherheitstools in einen Schweregrad-Wert für jeden Befund, der dem Befund gemäß der SLA-Konfiguration Ihres Assets eine SLA zuweist. + - **SLA**: Das vorgesehene Fälligkeitsdatum, bis zu dem der Befund behoben sein soll. + - **Status**: Der Status des Befunds (z. B. Aktiv, Verifiziert, Falsch-positiv, Duplikat, Außerhalb des Geltungsbereichs und Unter Fehlerprüfung). + - **Befundtyp**: Ob der Befund Statisch (SAST) oder Dynamisch (DAST) ist. + - **Entdeckungsdatum**: Das Datum, an dem der Befund entdeckt wurde. + - **CWE**: Die CWE-Klassifizierung des Befunds. + - **Schwachstellen-ID**: IDs von Schwachstellen in Sicherheitshinweisen, die dem Befund zugeordnet sind (z. B. CVE oder andere Quellen). + - **Gefunden von**: Das Tool, das den Befund aufgedeckt hat. +- **Ähnliche Befunde**: Andere Befunde innerhalb desselben Assets, die keine exakten Duplikate sind, aber ähnliche Werte für Schwachstellen-ID, CWE, file_path, Zeilennummer usw. aufweisen. +- **Import-Verlauf**: Liste der Importe/Re-Importe, die diesen Befund in einem beliebigen Test erstellt/geschlossen/reaktiviert haben. +- **Verwundbare Endpunkte/Systeme**: Endpunkte/Systeme, die laut Befund verwundbar sind. +- **Beschreibung**: Die Beschreibung des Befunds (je nach Befundtyp automatisch hinzugefügt oder manuell erstellt). +- **Behebung**: Vorgeschlagene Schritte zur Behebung. +- **Auswirkung**: Mögliche Auswirkung, wenn der Befund unbehoben bleibt. +- **Schritte zur Reproduktion**: Schritte zur Reproduktion des Befunds. +- **Schweregrad-Begründung**: Schriftliche Beschreibung, warum dem Befund ein bestimmter Schweregrad zugeordnet wurde. +- **Referenzen**: URL zur Querverweisung auf die spezifische Beschreibung des Befunds durch das Drittanbieter-Scan-Tool. Referenzen können beispielsweise Links zu einem relevanten Eintrag in einem Befundkatalog oder eine einzelne Advisory-URL sein. +- **Notizen**: Von Benutzern zum Befund hinterlassene Notizen. Wird eine Notiz als Privat markiert, wird sie nicht in generierte Berichte aufgenommen, die den ausgewählten Befund enthalten. + +## Befund-Daten + +Für Befunde sind folgende Metadaten erforderlich: +**Titel** +**Datum** +**Schweregrad** +**Beschreibung** + +Zusätzlich zu den Metadaten, die den Tabellen in der Ansicht eines Befunds entsprechen, gehören zu den optionalen Metadatenfeldern: +- **Gruppe**: Befundgruppen, die den ausgewählten Befund enthalten. +- **CVSS3/CVSS4-Vektor und -Wert**: Der CVSS3- und CVSS4-Vektor und -Wert des ausgewählten Befunds. +- **Request- und Response-Paare**: Eine Kopie der vom Client gesendeten Nachricht und der Antwort des Servers auf die Anfrage. +- **Hinzuzufügende Endpunkte**: Verwundbare Endpunkte, die vom ausgewählten Befund betroffen sein könnten und die nicht in der vorstehenden Liste der Systeme/Endpunkte erfasst sind. +- **EPSS-Wert und -Perzentil**: EPSS-Wert und -Perzentil für die CVE. +- **KEV-Hinzufügedatum**: Das Datum, an dem der Befund dem KEV-Katalog hinzugefügt wurde. +- **Verfügbarkeit und Version der Fehlerbehebung**: Legt fest, ob für die Schwachstelle eine Fehlerbehebung verfügbar ist, und die Version der betroffenen Komponente, in der die Behebung implementiert wurde. +- **Benutzer, der eine Fehlerprüfung angefordert hat**: Erfasst, wer eine Fehlerprüfung für den betreffenden Mangel angefordert hat. +- **Zeilennummer**: Quellzeilennummer des Angriffsvektors. +- **Dateipfad**: Identifizierte Dateien, die den Mangel enthalten. +- **Komponentenname und -version**: Name und Version der betroffenen Komponente. +- **Eindeutige ID vom Tool**: Technische Schwachstellen-ID aus dem Quelltool. +- **Schwachstellen-ID vom Tool**: Nicht eindeutige technische ID aus dem Quelltool. +- **SAST-Quellobjekt, Zeilennummer und Dateipfad**: Quellobjekt, Zeilennummer und Dateipfad des Angriffsvektors. +- **SAST-Zielobjekt (Sink)**: Zielobjekt (Sink) des Angriffsvektors. +- **Anzahl der Vorkommen**: Anzahl der Vorkommen im Quelltool, wenn mehrere Schwachstellen gefunden und vom Scanner aggregiert wurden. +- **Veröffentlichungsdatum**: Datum, an dem der Befund veröffentlicht wurde. +- **Service**: Verbundene Services (in sich geschlossene Funktionseinheiten innerhalb eines Assets), die vom ausgewählten Befund betroffen sind. Wenn dieses Feld ausgefüllt ist, wird es in den Deduplizierungsabgleich einbezogen (d. h. Befunde mit identischen Service-Feldern werden dedupliziert). +- **Geplantes Behebungsdatum und -version**: Das Datum, an dem der Befund voraussichtlich behoben wird, und die Version der betroffenen Komponente, in der die Behebung implementiert wird. +- **Aufwand für die Behebung**: Der Aufwand, der mit der Behebung des Befunds verbunden ist (z. B. Niedrig, Mittel oder Hoch). +- **Tags**: Alle Tags, die dem Befund hinzugefügt wurden. + +Die genauen verfügbaren Metadaten hängen vom Parser/Scanner ab, der den Befund aufgedeckt hat. Manche liefern nur grundlegende Informationen wie Titel und Schweregrad, während andere CVSS-Vektoren, verwundbare Komponenten, Endpunkte, Request/Response-Paare und andere scannerspezifische Metadaten enthalten. + +Diese Metadaten verbessern die Filterung, Berichterstattung und Priorisierung in Ihrem gesamten Sicherheitsprogramm und ermöglichen eine langfristige Nachverfolgung und Trendanalyse. Zusätzliche Details und Beschreibungen der Metadaten finden Sie [hier](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page). + +### Deduplizierung + +DefectDojo bietet Deduplizierungsfunktionen, die dabei helfen, Befunde zu identifizieren und zu verwalten, die dieselbe zugrunde liegende Schwachstelle darstellen. Wenn Scan-Ergebnisse aus einem oder mehreren Tools importiert werden, verwendet DefectDojo konfigurierbare Abgleichlogik, um Befunde zu identifizieren, die dieselbe Schwachstelle repräsentieren. + +Die Deduplizierung verhindert, dass dieselbe Schwachstelle mehrfach erscheint, wenn sie wiederholt vom gleichen oder von unterschiedlichen Scannern entdeckt wird, und sorgt dafür, dass der Behebungsverlauf an einem einzigen Befund erhalten bleibt. + +Weitere Informationen zur Deduplizierung finden Sie [hier](/triage_findings/finding_deduplication/about_deduplication/). + +### Reimport + +Die Reimport-Funktion von DefectDojo ermöglicht die Aktualisierung von Befunden, wenn neue Scan-Ergebnisse importiert werden. Beim Reimport eines Scans vergleicht DefectDojo die eingehenden Ergebnisse mit bestehenden Befunden und aktualisiert übereinstimmende Datensätze, anstatt völlig neue zu erstellen. Dadurch bleiben wertvolle Kontextinformationen wie Statusänderungen, Behebungsverlauf, Kommentare und Zuständigkeitsinformationen erhalten, sodass ein durchgehender Nachweis über den Lebenszyklus eines Befunds über mehrere Testzyklen hinweg entsteht. + +Weitere Informationen zur Reimport-Funktion finden Sie [hier](/import_data/import_intro/reimport/#main-content). + +### Risikoakzeptanzen + +Risikoakzeptanzen sind ein besonderer Status, der Befunden zugewiesen werden kann, um die Entscheidung, sie ohne sofortige Behebung zu akzeptieren, formal zu dokumentieren und umzusetzen. + +Weitere Informationen zu Risikoakzeptanzen finden Sie [hier](/triage_findings/findings_workflows/os__risk_acceptance/). + +### Status + +Jeder in DefectDojo erstellte Befund hat einen Status, der relevante Informationen vermittelt und Ihrem Team hilft, den Fortschritt bei der Behebung von Problemen im Blick zu behalten. + +Weitere Informationen zu Status finden Sie [hier](/triage_findings/findings_workflows/finding_status_definitions/). + +## Arbeiten mit Befunden + +### Befunde erstellen + +Während die meisten Befunde automatisch durch Scan-Importe und Integrationen erzeugt werden, unterstützt DefectDojo auch die manuelle Erstellung von Befunden. Manuelle Befunde eignen sich zur Nachverfolgung von Schwachstellen und Sicherheitsbedenken, die durch Penetrationstests, Architektur-Reviews, Compliance-Bewertungen, Bug-Bounty-Programme, Beratereinsätze oder andere Aktivitäten identifiziert wurden, die keine Scanner-Ausgabe erzeugen. + +So erstellen Sie einen Befund manuell: +1. Navigieren Sie zu dem Test, in dem Sie den Befund manuell hinzufügen möchten, klicken Sie auf das Pluszeichen +, und klicken Sie dann auf **Neuer Befund**. + +![image](images/osfindings_ss2.png) + +2. Dadurch öffnet sich das Formular „Neuer Befund“, das Sie mit allen relevanten Informationen zu Ihrem Befund ausfüllen können. + +3. Wählen Sie entweder **Weiteren Befund hinzufügen**, um manuell einen weiteren Befund hinzuzufügen, oder **Fertig**, um den Prozess der manuellen Befunderstellung abzuschließen. + +Der Befund erscheint nun in der Liste der Befunde, die im ursprünglichen Test enthalten sind. + +Wichtig: Wenn ein Befund manuell über die obere Leiste hinzugefügt wird, werden dadurch automatisch ein Ad-hoc-Engagement und ein Ad-hoc-Test erstellt, um den neuen Befund zu enthalten, anstatt ihn dem gerade angezeigten Test hinzuzufügen (siehe Abbildung unten). Dies liegt daran, dass sich die obere Leiste auf das Asset als Ganzes bezieht. Wenn Sie einem bestimmten, bereits vorhandenen Test manuell einen Befund hinzufügen möchten, sollten Sie dies am besten innerhalb des Tests selbst tun, wie in den obigen Schritten 1–3 beschrieben. + +![image](images/osfindings_ss3.png) + +### Befunde bearbeiten + +#### ⋮ Kebab-Menü + +Das ⋮-Kebab-Menü neben Befunden enthält folgende Funktionen: +- **Ansehen**: Den Befund öffnen und ansehen. +- **Bearbeiten**: Den Befund bearbeiten. +- **Kopieren**: Eine Kopie des Befunds erstellen. Die Kopie kann in einem beliebigen Test innerhalb des zugehörigen Engagements gespeichert werden. +- **Peer-Review anfordern**: Startet den Peer-Review-Prozess und ändert den Status des Befunds in „Unter Überprüfung“. Weitere Informationen zu Peer-Reviews finden Sie [hier](/triage_findings/findings_workflows/finding_status_definitions/#under-review). +- **Befund berühren (Touch)**: Protokolliert eine Interaktion mit dem Befund im Verlauf des Befunds. +- **Befund zu Vorlage machen**: Erstellt automatisch eine Befundvorlage auf Basis des ausgewählten Befunds. +- **Vorlage auf Befund anwenden**: Ermöglicht das Anwenden einer bereits vorhandenen Befundvorlage auf einen Befund. +- **Befund schließen**: Startet den Prozess zum Schließen des Befunds. +- **Risikoakzeptanz hinzufügen**: Startet den Prozess der Risikoakzeptanz. Weitere Informationen finden Sie [hier](/triage_findings/findings_workflows/os__risk_acceptance/#main-content). +- **Verlauf anzeigen**: Zeigt den Verlauf des ausgewählten Befunds an. +- **Löschen**: Löscht den ausgewählten Befund. + +#### Dateien an Befunde anhängen +Sie können jedem Befund Dateien anhängen, um visuellen Kontext bereitzustellen — zum Beispiel einen Screenshot einer Schwachstelle in Aktion oder ein Proof-of-Concept-Bild. + +Unterstützte Dateitypen sind: + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +So hängen Sie eine Datei an einen Befund an: +1. Öffnen Sie den Befund, an den Sie eine Datei anhängen möchten. +2. Öffnen Sie das Aktionsmenü (die Schaltfläche ☰ oben rechts im Befund) und klicken Sie auf Dateien verwalten. + +![image](images/OS_manage_files_menu.png) + +3. Geben Sie auf der Seite „Dateien hinzufügen“ einen Titel für die Datei ein und wählen Sie die Datei von Ihrem Computer aus. Sie können bis zu drei Dateien gleichzeitig hinzufügen; speichern Sie und kehren Sie bei Bedarf zurück, um weitere hinzuzufügen. + +![image](images/OS_manage_files_form.png) + +4. Klicken Sie auf **Speichern**. + +Die Datei wird anschließend im Bereich **Dateien** des Befunds aufgelistet. Bilddateien werden als Miniaturansichten angezeigt: + +![image](images/OS_finding_files_panel.png) + +#### Befunde in großen Mengen bearbeiten + +Befunde können in großen Mengen aus einer Befundliste bearbeitet werden, z. B. aus der Tabelle Alle Befunde, die über die Seitenleiste zugänglich ist, oder aus der Tabelle der Befunde innerhalb eines bestimmten Tests. + +Weitere Informationen zur Massenbearbeitung von Befunden finden Sie [hier](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings). + +### Befunde schließen + +Sobald die Arbeit an einem Befund abgeschlossen ist, können Sie ihn manuell schließen, indem Sie im ⋮-Kebab-Menü oder ☰-Aktionsmenü des Befunds auf **Befund schließen** klicken. Wird alternativ ein Scan erneut in DefectDojo importiert, der einen zuvor erfassten Befund nicht mehr enthält, wird dieser zuvor erfasste Befund automatisch geschlossen. + +Wenn Sie nicht möchten, dass Befunde geschlossen werden, können Sie dieses Verhalten beim Reimport deaktivieren: + +- Deaktivieren Sie das Kontrollkästchen Close Old Findings, wenn Sie die UI verwenden +- Setzen Sie close_old_findings auf False, wenn Sie die API verwenden ​ + +### Befunde löschen + +Das Löschen eines Befunds kann über das ⋮-Kebab-Menü oder ☰-Aktionsmenü des Befunds erfolgen. Diese Aktion kann nicht rückgängig gemacht werden. + +Aus Gründen der Nachvollziehbarkeit wird empfohlen, behobene Befunde zu schließen, anstatt sie zu löschen. + +## Befundgruppen + +**Befundgruppen** ermöglichen es Ihnen, mehrere zusammengehörige Befunde als eine einzige logische Einheit für Triage, Berichterstattung und Koordination der Behebung zu behandeln. + +Ein Scan könnte beispielsweise 10 SQL-Injection-Befunde über verschiedene Endpunkte hinweg erzeugen. Anstatt jeden einzeln zu verwalten, können Sie diese in einer einzigen Befundgruppe zusammenfassen, die das übergeordnete SQL-Injection-Problem repräsentiert. + +Eine Befundgruppe ersetzt nicht die einzelnen Befunde. Jeder Befund existiert weiterhin mit seinem eigenen Schweregrad, Status, Metadaten, Kommentaren und Behebungsverlauf. Eine Befundgruppe bietet lediglich eine zusätzliche organisatorische Ebene über den enthaltenen Befunden. + +### Zugriff auf Befundgruppen + +Befundgruppen sind über die Seitenleiste zugänglich. Das Untermenü bietet Zugriff auf Offene und Geschlossene Befundgruppen sowie Alle Befundgruppen (unabhängig vom Status Offen). + +![image](images/osfindings_ss1.png) + +### Befundgruppen erstellen + + +Befundgruppen können entweder manuell oder automatisch erstellt werden. + +Wichtig: Befundgruppen können nur aus den Befunden erstellt werden, die in einem einzigen Test enthalten sind. Befunde aus unterschiedlichen Tests, Engagements oder Produkten können nicht derselben Befundgruppe hinzugefügt werden. + +#### Manuelle Befundgruppen + +So führen Sie Aktionen für Befundgruppen manuell durch: +1. Navigieren Sie zu einer Liste von Befunden innerhalb eines Tests. +2. Wählen Sie den/die Befund(e) aus, den/die Sie einer Befundgruppe hinzufügen möchten, indem Sie das entsprechende Kontrollkästchen anklicken. +3. Klicken Sie auf das Kontrollkästchen **Gruppe**. +4. Klicken Sie auf die entsprechende Aktion, die Sie ausführen möchten. + - **Erstellen**: Erstellt eine Befundgruppe, die die ausgewählten Befunde enthält. + - **Hinzufügen zu**: Fügt die ausgewählten Befunde einer bereits vorhandenen Befundgruppe hinzu. + - **Aus jeder Gruppe entfernen**: Entfernt die ausgewählten Befunde aus allen Befundgruppen, denen sie zuvor angehörten. + - **Gruppieren nach**: Gruppiert die ausgewählten Befunde basierend auf der gewählten Option (z. B. Komponentenname, Dateipfad, Befundtitel usw.) +5. Klicken Sie auf **Absenden**. + +![image](images/osfindings_ss4.png) + +Beachten Sie, dass beim Auswählen von Befunden aus der Liste Alle Befunde die einzig mögliche Aktion darin besteht, die ausgewählten Befunde aus einer beliebigen Befundgruppe zu entfernen. Dies liegt daran, dass Befundgruppen, wie bereits erwähnt, nur aus den Befunden erstellt werden können, die in einem einzigen Test enthalten sind. + +#### Automatische Befundgruppen + +Beim Importieren eines Scans kann die Funktion „Gruppieren nach“ automatisch Befundgruppen basierend auf einer gewählten Gruppierungsmethode erstellen. Dies ist nützlich, wenn ein Scanner viele zusammengehörige Befunde erzeugt, die gemeinsam verwaltet werden sollen. + +Das dazugehörige Kontrollkästchen **Befundgruppen für alle Befunde erstellen** erfüllt zwei Funktionen: +- **Aktiviert**: Erstellt für jeden importierten Befund eine Befundgruppe, selbst wenn dieser Befund das einzige Mitglied der Gruppe ist. +- **Deaktiviert**: Erstellt Befundgruppen nur, wenn tatsächlich mehrere Befunde zum Gruppieren vorhanden sind. + +![image](images/osfindings_ss5.png) + +Wenn im Dropdown-Menü „Gruppieren nach“ während des Imports keine Option ausgewählt wird, erfolgt keine Gruppierung. + +Wenn die Gruppierungskriterien (z. B. Komponentenname, Schwachstellen-ID usw.) im Befund nicht ausgefüllt sind, wird für ihn keine Gruppe erstellt und er wird auch keiner bereits vorhandenen Befundgruppe hinzugefügt. + +Wenn ein Scan importiert wird, der 10 nicht gruppierte Befunde ergibt, und derselbe Scan erneut importiert wird, wobei die Befunde diesmal gruppiert werden, werden die ursprünglichen 10 Befunde nicht zu dieser Befundgruppe hinzugefügt (d. h. die Befundgruppe enthält nur die 10 Befunde aus dem Reimport, nicht die 10 Befunde aus dem ursprünglichen und den nachfolgenden Import). + +## Befundvorlagen + +**Befundvorlagen** ermöglichen es Benutzern, wiederverwendbare Vorlagen für häufig gemeldete Schwachstellen und Sicherheitsprobleme zu erstellen. Eine Vorlage kann standardisierte Informationen wie Titel, Beschreibung, Auswirkung, Schritte zur Reproduktion, Behebung, Referenzen und andere Befundmetadaten enthalten. + +Befundvorlagen sind besonders nützlich in Situationen, in denen Benutzer wiederholt manuelle Befunde erstellen müssen und vermeiden möchten, jedes Mal dieselben unterstützenden Informationen erneut einzugeben. + +### Zugriff auf Befundvorlagen + +Befundvorlagen finden Sie im Untermenü Befunde in der Seitenleiste. + +![image](images/osfindings_ss6.png) + +### Befundvorlagen erstellen + +Befundvorlagen können erstellt werden, indem Sie auf die Schaltfläche + oben rechts in der Ansicht Befundvorlagen klicken. + +Die daraufhin angezeigte Seite bietet einen Überblick über die Metadaten, die auf einen Befund angewendet werden, wenn eine Befundvorlage verwendet wird. + +Sie können auch einen bereits vorhandenen Befund als Grundlage für eine neue Befundvorlage verwenden, indem Sie im ⋮-Kebab-Menü des Befunds auf **Befund zu Vorlage machen** klicken. + +### Befundvorlagen anwenden + +Befundvorlagen können auf Befunde angewendet werden, indem Sie im ⋮-Kebab-Menü des ausgewählten Befunds auf die Schaltfläche **Vorlage auf Befund anwenden** klicken. + +![image](images/osfindings_ss7.png) + +Auf der daraufhin angezeigten Seite können Sie die Vorlage auswählen, die auf den betreffenden Befund angewendet werden soll, und anschließend festlegen, ob die Metadaten des Befunds beibehalten, durch die der Vorlage ersetzt oder mit ihr kombiniert werden sollen. + +### Berichte + +Der Berichts-Generator von DefectDojo ermöglicht es Ihnen, aus einer Reihe von Inhalts-Widgets einen individuellen Bericht zusammenzustellen, ihn auszuführen und das Ergebnis zu exportieren (zum Beispiel durch Drucken als PDF). Individuelle Berichte können die Befunde oder Endpunkte zusammenfassen, die Sie mit einem externen Publikum teilen möchten, und können Branding sowie Standardtexte enthalten. + +Weitere Informationen zum Berichts-Generator von DefectDojo finden Sie [hier](/metrics_reports/reports/using-the-report-builder/). + +#### Befunde exportieren + +Seiten, die eine Liste von Befunden oder eine Liste von Engagements anzeigen, verfügen im Dropdown-Menü oben rechts über eine CSV- und Excel-Exportoption. + +Öffnen Sie auf einer beliebigen Befundlisten-Seite das Dropdown-Menü oben rechts, um die sichtbaren Befunde als CSV- oder Excel-Datei zu exportieren. Die Liste der Engagements kann über dasselbe Dropdown-Menü auf der Engagements-Listenseite ebenfalls als CSV oder Excel exportiert werden. diff --git a/docs/content/asset_modelling/engagements_tests/OS__findings.es.md b/docs/content/asset_modelling/engagements_tests/OS__findings.es.md new file mode 100644 index 00000000000..c176aa80e45 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__findings.es.md @@ -0,0 +1,302 @@ +--- +title: Hallazgos +description: Información sobre los Hallazgos en DefectDojo OS +audience: opensource +weight: 5 +--- + +Organizaciones → Activos → Compromisos → Tests → **HALLAZGOS** + +## Descripción general + +Los **Hallazgos** representan el nivel más bajo de la Jerarquía de Productos donde se rastrean y gestionan las vulnerabilidades individuales, y son la forma principal en que DefectDojo estandariza y guía el proceso de reporte y remediación de sus herramientas de seguridad. Independientemente de si una vulnerabilidad fue reportada en SonarQube, Acunetix o la herramienta personalizada de su equipo, los Hallazgos le permiten gestionar cada vulnerabilidad de la misma manera. + +Ejemplos de Hallazgos incluyen: +- Cookie no marcada como HttpOnly +- Versión desactualizada (PHP) +- Evaluación de código fuera de banda (PHP) +- Versión desactualizada (MySQL) +- Código fuente de respaldo detectado +- Cross-Site Scripting ciego + +Además de almacenar los datos de la vulnerabilidad y proporcionar un marco de remediación, DefectDojo también mejora sus Hallazgos de las siguientes maneras: +- Añadiendo automáticamente las puntuaciones EPSS relacionadas a un Hallazgo para describir su explotabilidad +- Traduciendo automáticamente la métrica de severidad de una herramienta de seguridad en una puntuación de Severidad para cada Hallazgo, lo que confiere un SLA al Hallazgo según la configuración de SLA de su Activo. Para más información sobre la configuración de SLA, haga clic [aquí](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). + +En general, los Hallazgos están diseñados para trabajar con la Jerarquía de Productos con el fin de estandarizar sus esfuerzos y aplicar un método coherente a cada Activo. + +## Acceso a los Hallazgos + +Se puede acceder a los Hallazgos desde la barra lateral. El submenú ofrece acceso a los Hallazgos abiertos y cerrados, a todos los Hallazgos (independientemente de su estado abierto o cerrado), a los [Hallazgos con riesgo aceptado](/triage_findings/findings_workflows/os__risk_acceptance/), así como a las Plantillas de Hallazgos. También se puede acceder a los Hallazgos individuales desde dentro del Test que los contiene. + +![image](images/osfindings_ss1.png) + +### Permisos + +Todo Hallazgo pertenece a un Test, lo que permite a DefectDojo conservar qué escaneo o evaluación identificó originalmente la vulnerabilidad. + +Dado que los Hallazgos pertenecen a Tests, el acceso a los Hallazgos está determinado por el acceso de un Usuario al Activo que contiene el Test. Los Tests no tienen listas de control de acceso independientes. + +## Vista de Hallazgos +Las vistas de Hallazgo contienen una variedad de tablas para ayudar a interpretar de un vistazo el estado de un Hallazgo. Esto incluye: +- **Descripción general** + - **ID**: El número de ID único de ese Hallazgo. + - **Severidad**: La calificación de severidad de ese Hallazgo, que se aplica automáticamente. + - Como se mencionó anteriormente, DefectDojo traduce automáticamente la métrica de severidad de una herramienta de seguridad en una puntuación de Severidad para cada Hallazgo, lo que confiere un SLA al Hallazgo según la configuración de SLA de su Activo. + - **SLA**: La fecha de vencimiento prevista para la resolución del Hallazgo. + - **Estado**: El estado del Hallazgo (p. ej., Activo, Verificado, Falso positivo, Duplicado, Fuera de alcance y En revisión por defecto). + - **Tipo de Hallazgo**: Si el Hallazgo es Estático (SAST) o Dinámico (DAST). + - **Fecha de descubrimiento**: La fecha en que se descubrió el Hallazgo. + - **CWE**: La clasificación CWE del Hallazgo. + - **ID de vulnerabilidad**: IDs de vulnerabilidades en avisos de seguridad asociados al Hallazgo (p. ej., CVE u otras fuentes). + - **Encontrado por**: La herramienta que reveló el Hallazgo. +- **Hallazgos similares**: Otros Hallazgos dentro del mismo Activo que no son duplicados exactos pero tienen valores similares de ID de vulnerabilidad, CWE, file_path, número de línea, etc. +- **Historial de importación**: Lista de importaciones/reimportaciones que crearon/cerraron/reactivaron este Hallazgo en cualquier Test. +- **Endpoints/sistemas vulnerables**: Endpoints/Sistemas que el Hallazgo revela como vulnerables. +- **Descripción**: La descripción del Hallazgo (añadida automáticamente según el tipo de Hallazgo, o creada manualmente). +- **Mitigación**: Pasos sugeridos para mitigar. +- **Impacto**: Impacto potencial de dejar el Hallazgo sin resolver. +- **Pasos para reproducir**: Pasos para reproducir el Hallazgo. +- **Justificación de la severidad**: Descripción escrita de por qué se asoció una determinada calificación de Severidad al Hallazgo. +- **Referencias**: URL para hacer referencia cruzada a la descripción específica de la herramienta de escaneo de terceros del Hallazgo. Por ejemplo, las Referencias podrían ser enlaces a una entrada relevante en un catálogo de Hallazgos, o una única URL de aviso. +- **Notas**: Notas dejadas por los Usuarios relacionadas con el Hallazgo. Marcar una nota como Privada significará que no se incluirá en ningún informe generado que incluya el Hallazgo seleccionado. + +## Datos de los Hallazgos + +Los Hallazgos requieren los siguientes metadatos: +**Título** +**Fecha** +**Severidad** +**Descripción** + +Además de los metadatos correspondientes a las tablas en la vista de un Hallazgo, los campos de metadatos opcionales incluyen: +- **Grupo**: Grupos de Hallazgos que incluyen el Hallazgo seleccionado. +- **Vector y puntuación CVSS3/CVSS4**: El vector y la puntuación CVSS3 y CVSS4 del Hallazgo seleccionado. +- **Pares de solicitud y respuesta**: Una copia del mensaje enviado por el cliente y la respuesta del servidor a la solicitud. +- **Endpoints a añadir**: Endpoints vulnerables que pueden verse afectados por el Hallazgo seleccionado y que no se reflejan en la lista anterior de sistemas/endpoints. +- **Puntuación y percentil EPSS**: Puntuación y percentil EPSS para el CVE. +- **Fecha de incorporación a KEV**: La fecha en que se añadió el Hallazgo al catálogo KEV. +- **Disponibilidad y versión de la corrección**: Define si existe una corrección disponible para la vulnerabilidad, y la versión del componente afectado en la que se implementó la corrección. +- **Usuario que solicitó una revisión de defecto**: Registra quién solicitó una revisión de defecto para el fallo en cuestión. +- **Número de línea**: Número de línea de origen del vector de ataque. +- **Ruta del archivo**: Archivos identificados que contienen el fallo. +- **Nombre y versión del componente**: Nombre y versión del componente afectado. +- **ID único de la herramienta**: ID técnico de la vulnerabilidad proveniente de la herramienta de origen. +- **ID de vulnerabilidad de la herramienta**: ID técnico no único proveniente de la herramienta de origen. +- **Objeto de origen, número de línea y ruta de archivo SAST**: Objeto de origen, número de línea y ruta de archivo del vector de ataque. +- **Objeto de destino SAST**: Objeto de destino del vector de ataque. +- **Número de repeticiones**: Número de repeticiones en la herramienta de origen cuando se encontraron y agregaron varias vulnerabilidades por el escáner. +- **Fecha de publicación**: Fecha en que se publicó el Hallazgo. +- **Servicio**: Servicios conectados (piezas autónomas de funcionalidad dentro de un Activo) que se ven afectados por el Hallazgo seleccionado. Cuando se completa, este campo se incluye en la coincidencia de deduplicación (es decir, los Hallazgos con campos de Servicio idénticos se deduplicarán). +- **Fecha y versión de remediación planificada**: La fecha en que está previsto remediar el Hallazgo, y la versión del componente afectado en la que se implementará la corrección. +- **Esfuerzo de corrección**: El nivel de esfuerzo que implica corregir el Hallazgo (p. ej., Baja, Media o Alta). +- **Etiquetas**: Cualquier etiqueta que se haya añadido al Hallazgo. + +Los metadatos exactos disponibles dependerán del analizador/escáner que reveló el Hallazgo. Algunos proporcionan solo información básica como título y severidad, mientras que otros incluyen vectores CVSS, componentes vulnerables, endpoints, pares de solicitud/respuesta y otros metadatos específicos del escáner. + +Estos metadatos mejoran el filtrado, los informes y la priorización en todo su programa de seguridad, permitiendo el seguimiento a largo plazo y el análisis de tendencias. Puede encontrar más detalles y descripciones de metadatos [aquí](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page). + +### Deduplicación + +DefectDojo incluye capacidades de deduplicación que ayudan a identificar y gestionar Hallazgos que representan la misma vulnerabilidad subyacente. A medida que se importan los resultados de escaneo desde una o más herramientas, DefectDojo utiliza una lógica de coincidencia configurable para identificar Hallazgos que representan la misma vulnerabilidad. + +La deduplicación evita que la misma vulnerabilidad aparezca varias veces cuando es descubierta repetidamente por el mismo escáner o por escáneres diferentes, permitiendo que el historial de remediación permanezca vinculado a un único Hallazgo. + +Puede encontrar más información sobre la deduplicación [aquí](/triage_findings/finding_deduplication/about_deduplication/). + +### Reimportación + +La función de Reimportación de DefectDojo permite actualizar los Hallazgos a medida que se importan nuevos resultados de escaneo. Cuando se reimporta un escaneo, DefectDojo compara los resultados entrantes con los Hallazgos existentes y actualiza los registros coincidentes en lugar de crear otros completamente nuevos. Esto preserva un contexto valioso, como los cambios de estado, el historial de remediación, los comentarios y la información de propiedad, proporcionando un registro continuo del ciclo de vida de un Hallazgo a lo largo de múltiples ciclos de testing. + +Puede encontrar más información sobre la función de Reimportación [aquí](/import_data/import_intro/reimport/#main-content). + +### Aceptaciones de riesgo + +Las Aceptaciones de riesgo son un estado especial que se puede aplicar a los Hallazgos para documentar formalmente y operacionalizar la decisión de reconocerlos sin remediarlos de inmediato. + +Puede encontrar más información sobre las Aceptaciones de riesgo [aquí](/triage_findings/findings_workflows/os__risk_acceptance/). + +### Estados + +Cada Hallazgo creado en DefectDojo tiene un Estado que comunica información relevante y ayuda a su equipo a llevar un seguimiento de su progreso en la resolución de problemas. + +Puede encontrar más información sobre los Estados [aquí](/triage_findings/findings_workflows/finding_status_definitions/). + +## Trabajar con Hallazgos + +### Creación de Hallazgos + +Si bien la mayoría de los Hallazgos se generan automáticamente mediante importaciones de escaneos e integraciones, DefectDojo también admite la creación manual de Hallazgos. Los Hallazgos manuales son útiles para rastrear vulnerabilidades y problemas de seguridad identificados mediante pruebas de penetración, revisiones de arquitectura, evaluaciones de cumplimiento, programas de bug bounty, compromisos con consultores u otras actividades que no producen salida de escáner. + +Para crear un Hallazgo manualmente: +1. Navegue hasta el Test en el que desea añadir manualmente el Hallazgo, haga clic en el signo + Más y luego haga clic en **New Finding**. + +![image](images/osfindings_ss2.png) + +2. Esto abre el formulario New Finding, que puede completar con cualquier información relevante sobre su Hallazgo. + +3. Seleccione **Add Another Finding** para añadir manualmente otro Hallazgo, o **Finished** para finalizar el proceso de creación manual del Hallazgo. + +El Hallazgo aparecerá ahora dentro de la lista de Hallazgos contenidos en el Test original. + +Es importante destacar que añadir manualmente un Hallazgo desde la barra superior creará automáticamente un Compromiso y un Test ad hoc para contener el nuevo Hallazgo, en lugar de añadirlo al Test que se está viendo actualmente (vea la imagen a continuación). Esto se debe a que la barra superior corresponde al Activo en su conjunto. Si desea añadir manualmente un Hallazgo a un Test específico ya existente, es mejor hacerlo desde dentro del propio Test, como se describe en los pasos 1-3 anteriores. + +![image](images/osfindings_ss3.png) + +### Edición de Hallazgos + +#### Menú kebab ⋮ + +El menú kebab ⋮ junto a los Hallazgos contiene las siguientes funciones: +- **View**: Abre y visualiza el Hallazgo. +- **Edit**: Edita el Hallazgo. +- **Copy**: Crea una copia del Hallazgo. La copia se puede guardar en cualquiera de los Tests contenidos dentro del Compromiso correspondiente. +- **Request Peer Review**: Inicia el proceso de Revisión por Pares y cambia el estado del Hallazgo a “Under Review”. Puede encontrar más información sobre las Revisiones por Pares [aquí](/triage_findings/findings_workflows/finding_status_definitions/#under-review). +- **Touch Finding**: Registrará la interactividad con el Hallazgo en el historial del Hallazgo. +- **Make Finding a Template**: Creará automáticamente una Plantilla de Hallazgo basada en el Hallazgo seleccionado. +- **Apply Template to Finding**: Permitirá aplicar una Plantilla de Hallazgo ya existente a un Hallazgo. +- **Close Finding**: Iniciará el proceso de cierre del Hallazgo. +- **Add Risk Acceptance**: Iniciará el proceso de Aceptación de riesgo. Puede encontrar más información [aquí](/triage_findings/findings_workflows/os__risk_acceptance/#main-content). +- **View History**: Muestra el historial del Hallazgo seleccionado. +- **Delete**: Elimina el Hallazgo seleccionado. + +#### Adjuntar archivos a los Hallazgos +Puede adjuntar archivos a cualquier Hallazgo para proporcionar contexto visual; por ejemplo, una captura de pantalla de una vulnerabilidad en acción o una imagen de prueba de concepto. + +Los tipos de archivo admitidos incluyen: + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +Para adjuntar un archivo a un Hallazgo: +1. Abra el Hallazgo al que desea adjuntar un archivo. +2. Abra el menú de acciones (el botón ☰ en la parte superior derecha del Hallazgo) y haga clic en Manage Files. + +![image](images/OS_manage_files_menu.png) + +3. En la página Add files, introduzca un Título para el archivo y elija el archivo desde su ordenador. Puede añadir hasta tres archivos a la vez; guarde y vuelva para añadir más si es necesario. + +![image](images/OS_manage_files_form.png) + +4. Haga clic en **Save**. + +El archivo se muestra entonces en el panel **Files** del Hallazgo. Los archivos de imagen aparecen como miniaturas: + +![image](images/OS_finding_files_panel.png) + +#### Edición masiva de Hallazgos + +Los Hallazgos se pueden editar de forma masiva desde una lista de Hallazgos, como la tabla de All Findings accesible desde la barra lateral, o desde la tabla de Hallazgos dentro de un Test específico. + +Puede encontrar más información sobre cómo editar Hallazgos de forma masiva [aquí](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings). + +### Cierre de Hallazgos + +Una vez completado el trabajo en un Hallazgo, puede cerrarlo manualmente haciendo clic en **Close Finding** dentro del menú kebab ⋮ o del menú de acciones ☰ del Hallazgo. Alternativamente, si se reimporta un escaneo en DefectDojo que no contiene un Hallazgo previamente registrado, ese Hallazgo se cerrará automáticamente. + +Si no desea que se cierre ningún Hallazgo, puede deshabilitar este comportamiento en la Reimportación: + +- Desmarque la casilla Close Old Findings si utiliza la UI +- Establezca close_old_findings en False si utiliza la API ​ + +### Eliminación de Hallazgos + +La eliminación de un Hallazgo se puede realizar desde el menú kebab ⋮ o el menú de acciones ☰ del Hallazgo. Esta acción no se puede deshacer. + +Por motivos de auditoría, se recomienda cerrar los Hallazgos remediados en lugar de eliminarlos. + +## Grupos de Hallazgos + +Los **Grupos de Hallazgos** le permiten tratar varios Hallazgos relacionados como una sola unidad lógica para la triaje, los informes y la coordinación de la remediación. + +Por ejemplo, un escaneo podría producir 10 Hallazgos de inyección SQL en diferentes endpoints. En lugar de gestionar cada uno de forma independiente, puede agruparlos en un único Grupo de Hallazgos que represente el problema de inyección SQL más amplio. + +Un Grupo de Hallazgos no reemplaza a los Hallazgos individuales. Cada Hallazgo sigue existiendo con su propia severidad, estado, metadatos, comentarios e historial de remediación. Un Grupo de Hallazgos simplemente proporciona una capa organizativa adicional por encima de los Hallazgos que contiene. + +### Acceso a los Grupos de Hallazgos + +Se puede acceder a los Grupos de Hallazgos desde la barra lateral. El submenú ofrece acceso a los Grupos de Hallazgos abiertos y cerrados, así como a todos los Grupos de Hallazgos (independientemente de su estado abierto). + +![image](images/osfindings_ss1.png) + +### Creación de Grupos de Hallazgos + + +Los Grupos de Hallazgos se pueden crear de forma manual o automática. + +Cabe destacar que los Grupos de Hallazgos solo se pueden crear a partir de los Hallazgos contenidos dentro de un único Test. Los Hallazgos de diferentes Tests, Compromisos o Productos no se pueden añadir al mismo Grupo de Hallazgos. + +#### Grupos de Hallazgos manuales + +Para realizar acciones de Grupo de Hallazgos manualmente: +1. Navegue hasta una lista de Hallazgos dentro de un Test. +2. Seleccione el/los Hallazgo(s) que desea añadir a un Grupo de Hallazgos haciendo clic en la casilla correspondiente. +3. Haga clic en la casilla **Group**. +4. Haga clic en la acción correspondiente que desea completar. + - **Create**: Crea un Grupo de Hallazgos que incluye los Hallazgos seleccionados. + - **Add to**: Añade los Hallazgos seleccionados a un Grupo de Hallazgos ya existente. + - **Remove from any group**: Elimina los Hallazgos seleccionados de cualquier Grupo de Hallazgos del que formaran parte anteriormente. + - **Group by**: Agrupa los Hallazgos seleccionados según la opción elegida (p. ej., nombre de componente, ruta de archivo, título del Hallazgo, etc.) +5. Haga clic en **Submit**. + +![image](images/osfindings_ss4.png) + +Tenga en cuenta que la única acción posible al seleccionar Hallazgos desde la lista All Findings es eliminar los Hallazgos seleccionados de cualquier Grupo de Hallazgos. Esto se debe a que, como se mencionó, los Grupos de Hallazgos solo se pueden crear a partir de los Hallazgos contenidos dentro de un único Test. + +#### Grupos de Hallazgos automáticos + +Al importar un escaneo, la función “Group By” puede crear automáticamente Grupos de Hallazgos según un método de agrupación elegido. Esto es útil cuando un escáner produce muchos Hallazgos relacionados que deben gestionarse juntos. + +La casilla adyacente **Create Finding Groups for all Findings** cumple dos funciones: +- **Marcada**: Crea un Grupo de Hallazgos para cada Hallazgo importado, incluso si ese Hallazgo es el único miembro del grupo. +- **Desmarcada**: Crea Grupos de Hallazgos solo cuando realmente hay varios Hallazgos que agrupar. + +![image](images/osfindings_ss5.png) + +Si no se selecciona ninguna opción en el menú desplegable Group By durante la importación, no se producirá ninguna agrupación. + +Si el criterio de agrupación (p. ej., nombre de componente, ID de vulnerabilidad, etc.) no está completado en el Hallazgo, no se creará un grupo para él ni se añadirá a un Grupo de Hallazgos ya existente. + +Si se importa un escaneo que revela 10 Hallazgos que no están agrupados, y se reimporta el mismo escaneo y los Hallazgos se agrupan, los primeros 10 Hallazgos no se añadirán a ese Grupo de Hallazgos (es decir, el Grupo de Hallazgos solo incluirá los 10 Hallazgos de la reimportación, no los 10 Hallazgos de la importación inicial y las subsiguientes). + +## Plantillas de Hallazgos + +Las **Plantillas de Hallazgos** permiten a los Usuarios crear plantillas reutilizables para vulnerabilidades y problemas de seguridad reportados habitualmente. Una plantilla puede incluir información estandarizada como título, descripción, impacto, pasos para reproducir, mitigación, referencias y otros metadatos del Hallazgo. + +Las Plantillas de Hallazgos son más útiles en situaciones donde los Usuarios necesitan crear Hallazgos manuales repetidamente y quieren evitar volver a introducir la misma información de respaldo cada vez. + +### Acceso a las Plantillas de Hallazgos + +Las Plantillas de Hallazgos se encuentran dentro del submenú de Hallazgos en la barra lateral. + +![image](images/osfindings_ss6.png) + +### Creación de Plantillas de Hallazgos + +Las Plantillas de Hallazgos se pueden crear haciendo clic en el botón + Más en la parte superior derecha de la vista Finding Templates. + +La página resultante ofrece una visión general de los metadatos que se aplicarán a un Hallazgo cuando se utilice una Plantilla de Hallazgo. + +También puede usar un Hallazgo ya existente como base para una nueva Plantilla de Hallazgo haciendo clic en **Make Finding a Template** dentro del menú kebab ⋮ del Hallazgo. + +### Aplicación de Plantillas de Hallazgos + +Las Plantillas de Hallazgos se pueden aplicar a los Hallazgos haciendo clic en el botón **Apply Template to Finding** dentro del menú kebab ⋮ del Hallazgo seleccionado. + +![image](images/osfindings_ss7.png) + +La página resultante le permitirá seleccionar la plantilla que se aplicará al Hallazgo en cuestión, y luego decidir si mantener, reemplazar o combinar los metadatos del Hallazgo con los de la plantilla. + +### Informes + +El generador de informes de DefectDojo le permite ensamblar un informe personalizado a partir de un conjunto de widgets de contenido, ejecutarlo y exportar el resultado (por ejemplo, imprimiéndolo en PDF). Los informes personalizados pueden resumir los Hallazgos o Endpoints que desea compartir con una audiencia externa, y pueden incluir branding y texto estándar. + +Puede encontrar más información sobre el Generador de Informes de DefectDojo [aquí](/metrics_reports/reports/using-the-report-builder/). + +#### Exportar Hallazgos + +Las páginas que muestran una lista de Hallazgos o una lista de Compromisos tienen una opción de exportación a CSV y Excel en el menú desplegable de la parte superior derecha. + +Desde cualquier página de lista de Hallazgos, abra el menú desplegable en la esquina superior derecha para exportar los Hallazgos visibles como archivo CSV o Excel. La lista de Compromisos también se puede exportar como CSV o Excel utilizando el mismo menú desplegable en la página de lista de Compromisos. diff --git a/docs/content/asset_modelling/engagements_tests/OS__findings.fr.md b/docs/content/asset_modelling/engagements_tests/OS__findings.fr.md new file mode 100644 index 00000000000..a828faae68c --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__findings.fr.md @@ -0,0 +1,302 @@ +--- +title: Constatations +description: Comprendre les Constatations dans DefectDojo OS +audience: opensource +weight: 5 +--- + +Organisations → Actifs → Engagements → Tests → **CONSTATATIONS** + +## Aperçu + +**Les Constatations** représentent le niveau le plus bas de la hiérarchie des produits, où les vulnérabilités individuelles sont suivies et gérées, et constituent le principal moyen par lequel DefectDojo standardise et guide le processus de signalement et de remédiation de vos outils de sécurité. Qu’une vulnérabilité ait été signalée dans SonarQube, Acunetix, ou l’outil personnalisé de votre équipe, les Constatations vous permettent de gérer chaque vulnérabilité de la même manière. + +Voici des exemples de Constatations : +- Cookie non marqué comme HttpOnly +- Version obsolète (PHP) +- Évaluation de code hors bande (PHP) +- Version obsolète (MySQL) +- Code source de sauvegarde détecté +- Cross-Site Scripting aveugle + +En plus de stocker les données de vulnérabilité et de fournir un cadre de remédiation, DefectDojo enrichit également vos Constatations des façons suivantes : +- Ajout automatique des scores EPSS associés à une Constatation pour décrire son exploitabilité +- Traduction automatique de la métrique de sévérité d’un outil de sécurité en un score de Sévérité pour chaque Constatation, ce qui confère un SLA à la Constatation selon la configuration SLA de votre Actif. Pour plus d’informations sur la configuration des SLA, cliquez [ici](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). + +Dans l’ensemble, les Constatations sont conçues pour fonctionner avec la hiérarchie des produits afin de standardiser vos efforts et d’appliquer une méthode cohérente à chaque Actif. + +## Accéder aux Constatations + +Les Constatations sont accessibles via la barre latérale. Le sous-menu donne accès aux Constatations ouvertes et fermées, à toutes les Constatations (quel que soit leur statut ouvert ou fermé), aux [Constatations à risque accepté](/triage_findings/findings_workflows/os__risk_acceptance/), ainsi qu’aux Modèles de Constatation. Les Constatations individuelles sont également accessibles depuis le Test qui les contient. + +![image](images/osfindings_ss1.png) + +### Permissions + +Chaque Constatation appartient à un Test, ce qui permet à DefectDojo de conserver la trace de l’analyse ou de l’évaluation ayant initialement identifié la vulnérabilité. + +Comme les Constatations appartiennent à des Tests, l’accès aux Constatations est déterminé par l’accès d’un Utilisateur à l’Actif qui contient le Test. Les Tests n’ont pas de listes de contrôle d’accès indépendantes. + +## Vue des Constatations +Les vues de Constatation contiennent divers tableaux permettant d’interpréter le statut d’une Constatation en un coup d’œil. Cela comprend : +- **Aperçu** + - **ID** : le numéro d’identification unique de cette Constatation. + - **Sévérité** : l’évaluation de sévérité de cette Constatation, appliquée automatiquement. + - Comme mentionné précédemment, DefectDojo traduit automatiquement la métrique de sévérité d’un outil de sécurité en un score de Sévérité pour chaque Constatation, ce qui confère un SLA à la Constatation selon la configuration SLA de votre Actif. + - **SLA** : la date d’échéance prévue pour la résolution de la Constatation. + - **Statut** : le statut de la Constatation (par exemple, Actif, Vérifié, Faux positif, Doublon, Hors périmètre, et En revue de défaut). + - **Type de Constatation** : si la Constatation est Statique (SAST) ou Dynamique (DAST). + - **Date de découverte** : la date à laquelle la Constatation a été découverte. + - **CWE** : la classification CWE de la Constatation. + - **ID de vulnérabilité** : identifiants des vulnérabilités dans les avis de sécurité associés à la Constatation (par exemple, CVE ou autres sources). + - **Détecté par** : l’outil ayant révélé la Constatation. +- **Constatations similaires** : d’autres Constatations au sein du même Actif qui ne sont pas des doublons exacts mais qui présentent des valeurs similaires pour l’ID de vulnérabilité, le CWE, le file_path, le numéro de ligne, etc. +- **Historique d’import** : liste des imports/réimports ayant créé/fermé/réactivé cette Constatation dans un Test quelconque. +- **Points de terminaison/systèmes vulnérables** : les Points de terminaison/systèmes que la Constatation révèle comme vulnérables. +- **Description** : la description de la Constatation (ajoutée automatiquement selon le type de Constatation, ou créée manuellement). +- **Atténuation** : étapes suggérées pour atténuer. +- **Impact** : impact potentiel de laisser la Constatation non résolue. +- **Étapes de reproduction** : étapes pour reproduire la Constatation. +- **Justification de la sévérité** : description écrite expliquant pourquoi une certaine évaluation de Sévérité a été associée à la Constatation. +- **Références** : URL permettant de recouper la description spécifique de la Constatation fournie par l’outil d’analyse tiers. Par exemple, les Références peuvent être des liens vers une entrée pertinente d’un catalogue de Constatations, ou une simple URL d’avis. +- **Notes** : notes laissées par les Utilisateurs concernant la Constatation. Marquer une note comme Privée signifie qu’elle ne sera incluse dans aucun rapport généré comprenant la Constatation sélectionnée. + +## Données des Constatations + +Les Constatations requièrent les métadonnées suivantes : +**Titre** +**Date** +**Sévérité** +**Description** + +En plus des métadonnées correspondant aux tableaux dans la vue d’une Constatation, les champs de métadonnées optionnels comprennent : +- **Groupe** : les Groupes de Constatations qui incluent la Constatation sélectionnée. +- **Vecteur et score CVSS3/CVSS4** : le vecteur et le score CVSS3 et CVSS4 de la Constatation sélectionnée. +- **Paires requête/réponse** : une copie du message envoyé par le client et de la réponse du serveur à la requête. +- **Points de terminaison à ajouter** : les points de terminaison vulnérables susceptibles d’être affectés par la Constatation sélectionnée et qui ne figurent pas dans la liste précédente des systèmes/points de terminaison. +- **Score et percentile EPSS** : le score et le percentile EPSS pour le CVE. +- **Date d’ajout au KEV** : la date à laquelle la Constatation a été ajoutée au catalogue KEV. +- **Disponibilité et version du correctif** : indique si un correctif est disponible pour la vulnérabilité, et la version du composant affecté dans laquelle le correctif a été implémenté. +- **Utilisateur ayant demandé une revue de défaut** : enregistre qui a demandé une revue de défaut pour la faille en question. +- **Numéro de ligne** : numéro de ligne source du vecteur d’attaque. +- **Chemin du fichier** : les fichiers identifiés contenant la faille. +- **Nom et version du composant** : nom et version du composant affecté. +- **ID unique de l’outil** : identifiant technique de la vulnérabilité provenant de l’outil source. +- **ID de vulnérabilité de l’outil** : identifiant technique non unique provenant de l’outil source. +- **Objet source, numéro de ligne et chemin de fichier SAST** : objet source, numéro de ligne et chemin de fichier du vecteur d’attaque. +- **Objet destination (sink) SAST** : objet destination du vecteur d’attaque. +- **Nombre d’occurrences** : nombre d’occurrences dans l’outil source lorsque plusieurs vulnérabilités ont été trouvées et agrégées par le scanner. +- **Date de publication** : date à laquelle la Constatation a été publiée. +- **Service** : les Services connectés (éléments de fonctionnalité autonomes au sein d’un Actif) affectés par la Constatation sélectionnée. Lorsqu’il est renseigné, ce champ est pris en compte dans la correspondance de déduplication (c’est-à-dire que les Constatations ayant des champs Service identiques seront dédupliquées). +- **Date et version de remédiation planifiées** : la date à laquelle la Constatation est prévue d’être remédiée, et la version du composant affecté dans laquelle le correctif sera implémenté. +- **Effort de correction** : le niveau d’effort nécessaire pour corriger la Constatation (par exemple, Faible, Moyenne, ou Élevée). +- **Étiquettes** : les étiquettes ajoutées à la Constatation. + +Les métadonnées exactes disponibles dépendront du parseur/scanner ayant révélé la Constatation. Certains ne fournissent que des informations de base telles que le titre et la sévérité, tandis que d’autres incluent des vecteurs CVSS, des composants vulnérables, des points de terminaison, des paires requête/réponse, et d’autres métadonnées spécifiques au scanner. + +Ces métadonnées améliorent le filtrage, le reporting et la priorisation au sein de votre programme de sécurité, permettant un suivi à long terme et une analyse des tendances. Des détails supplémentaires et des descriptions des métadonnées sont disponibles [ici](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page). + +### Déduplication + +DefectDojo intègre des fonctionnalités de déduplication qui aident à identifier et gérer les Constatations représentant la même vulnérabilité sous-jacente. Au fur et à mesure que les résultats d’analyse sont importés depuis un ou plusieurs outils, DefectDojo utilise une logique de correspondance configurable pour identifier les Constatations représentant la même vulnérabilité. + +La déduplication évite qu’une même vulnérabilité n’apparaisse plusieurs fois lorsqu’elle est détectée à répétition par le même scanner ou par des scanners différents, permettant à l’historique de remédiation de rester rattaché à une seule Constatation. + +Plus d’informations sur la déduplication sont disponibles [ici](/triage_findings/finding_deduplication/about_deduplication/). + +### Réimport + +La fonction de Réimport de DefectDojo permet de mettre à jour les Constatations à mesure que de nouveaux résultats d’analyse sont importés. Lorsqu’une analyse est réimportée, DefectDojo compare les résultats entrants aux Constatations existantes et met à jour les enregistrements correspondants au lieu d’en créer de nouveaux. Cela préserve un contexte précieux tel que les changements de statut, l’historique de remédiation, les commentaires et les informations de propriété, offrant un enregistrement continu du cycle de vie d’une Constatation à travers plusieurs cycles de test. + +Plus d’informations sur la fonction de Réimport sont disponibles [ici](/import_data/import_intro/reimport/#main-content). + +### Acceptations du risque + +Les Acceptations du risque constituent un statut spécial pouvant être appliqué aux Constatations pour documenter formellement et opérationnaliser la décision de les reconnaître sans les remédier immédiatement. + +Plus d’informations sur les Acceptations du risque sont disponibles [ici](/triage_findings/findings_workflows/os__risk_acceptance/). + +### Statuts + +Chaque Constatation créée dans DefectDojo possède un Statut qui communique des informations pertinentes et aide votre équipe à suivre l’avancement de la résolution des problèmes. + +Plus d’informations sur les Statuts sont disponibles [ici](/triage_findings/findings_workflows/finding_status_definitions/). + +## Utiliser les Constatations + +### Créer des Constatations + +Bien que la plupart des Constatations soient générées automatiquement via les imports d’analyse et les intégrations, DefectDojo prend également en charge la création manuelle de Constatations. Les Constatations manuelles sont utiles pour suivre les vulnérabilités et les problèmes de sécurité identifiés lors de tests d’intrusion, de revues d’architecture, d’évaluations de conformité, de programmes de bug bounty, de missions de consultants, ou d’autres activités qui ne produisent pas de résultats de scanner. + +Pour créer une Constatation manuellement : +1. Accédez au Test dans lequel vous souhaitez ajouter manuellement la Constatation, cliquez sur le signe + Plus, puis cliquez sur **Nouvelle Constatation**. + +![image](images/osfindings_ss2.png) + +2. Cela ouvre le formulaire Nouvelle Constatation, que vous pouvez remplir avec toute information pertinente concernant votre Constatation. + +3. Sélectionnez soit **Ajouter une autre Constatation** pour ajouter manuellement une autre Constatation, soit **Terminé** pour finaliser le processus de création manuelle de Constatation. + +La Constatation apparaîtra désormais dans la liste des Constatations contenues dans le Test d’origine. + +Il est important de noter que l’ajout manuel d’une Constatation depuis la barre supérieure créera automatiquement un Engagement et un Test ad hoc pour contenir la nouvelle Constatation, plutôt que de l’ajouter au Test actuellement consulté (voir l’image ci-dessous). En effet, la barre supérieure concerne l’Actif dans son ensemble. Si vous souhaitez ajouter manuellement une Constatation à un Test spécifique déjà existant, il est préférable de le faire depuis le Test lui-même, comme décrit dans les étapes 1 à 3 ci-dessus. + +![image](images/osfindings_ss3.png) + +### Modifier des Constatations + +#### Menu kebab ⋮ + +Le menu kebab ⋮ situé à côté des Constatations contient les fonctions suivantes : +- **Afficher** : ouvre et affiche la Constatation. +- **Modifier** : modifie la Constatation. +- **Copier** : crée une copie de la Constatation. La copie peut être enregistrée dans n’importe lequel des Tests contenus dans l’Engagement correspondant. +- **Demander une revue par les pairs** : lance le processus de revue par les pairs et change le statut de la Constatation en « En revue ». Plus d’informations sur les revues par les pairs sont disponibles [ici](/triage_findings/findings_workflows/finding_status_definitions/#under-review). +- **Toucher la Constatation** : enregistre une interaction avec la Constatation dans son historique. +- **Faire de la Constatation un modèle** : crée automatiquement un Modèle de Constatation basé sur la Constatation sélectionnée. +- **Appliquer un modèle à la Constatation** : permet d’appliquer un Modèle de Constatation existant à une Constatation. +- **Fermer la Constatation** : lance le processus de fermeture de la Constatation. +- **Ajouter une Acceptation du risque** : lance le processus d’Acceptation du risque. Plus d’informations sont disponibles [ici](/triage_findings/findings_workflows/os__risk_acceptance/#main-content). +- **Afficher l’historique** : révèle l’historique de la Constatation sélectionnée. +- **Supprimer** : supprime la Constatation sélectionnée. + +#### Joindre des fichiers aux Constatations +Vous pouvez joindre des fichiers à n’importe quelle Constatation pour fournir un contexte visuel — par exemple, une capture d’écran d’une vulnérabilité en action ou une image de preuve de concept. + +Les types de fichiers pris en charge comprennent : + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +Pour joindre un fichier à une Constatation : +1. Ouvrez la Constatation à laquelle vous souhaitez joindre un fichier. +2. Ouvrez le menu d’actions (le bouton ☰ en haut à droite de la Constatation) et cliquez sur Gérer les fichiers. + +![image](images/OS_manage_files_menu.png) + +3. Sur la page Ajouter des fichiers, saisissez un Titre pour le fichier et choisissez le fichier depuis votre ordinateur. Vous pouvez ajouter jusqu’à trois fichiers à la fois ; enregistrez et revenez pour en ajouter d’autres si nécessaire. + +![image](images/OS_manage_files_form.png) + +4. Cliquez sur **Enregistrer**. + +Le fichier est ensuite répertorié dans le panneau **Fichiers** de la Constatation. Les fichiers image apparaissent sous forme de vignettes : + +![image](images/OS_finding_files_panel.png) + +#### Modifier des Constatations en masse + +Les Constatations peuvent être modifiées en masse depuis une liste de Constatations, telle que le tableau de toutes les Constatations accessible depuis la barre latérale, ou depuis le tableau des Constatations au sein d’un Test spécifique. + +Plus d’informations sur la modification en masse des Constatations sont disponibles [ici](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings). + +### Fermer des Constatations + +Une fois le travail sur une Constatation terminé, vous pouvez la fermer manuellement en cliquant sur **Fermer la Constatation** dans le menu kebab ⋮ ou le menu d’actions ☰ de la Constatation. Autrement, si une analyse est réimportée dans DefectDojo sans contenir une Constatation précédemment enregistrée, cette dernière se fermera automatiquement. + +Si vous ne souhaitez qu’aucune Constatation ne soit fermée, vous pouvez désactiver ce comportement lors du Réimport : + +- Décochez la case Close Old Findings si vous utilisez l’interface +- Définissez close_old_findings sur False si vous utilisez l’API ​ + +### Supprimer des Constatations + +La suppression d’une Constatation peut être effectuée depuis le menu kebab ⋮ ou le menu d’actions ☰ de la Constatation. Cette action est irréversible. + +À des fins d’audit, il est recommandé de fermer les Constatations remédiées plutôt que de les supprimer. + +## Groupes de Constatations + +Les **Groupes de Constatations** vous permettent de traiter plusieurs Constatations liées comme une seule unité logique pour le triage, le reporting et la coordination de la remédiation. + +Par exemple, une analyse peut produire 10 Constatations d’injection SQL réparties sur différents points de terminaison. Plutôt que de gérer chacune indépendamment, vous pouvez les regrouper en un seul Groupe de Constatations représentant le problème d’injection SQL dans son ensemble. + +Un Groupe de Constatations ne remplace pas les Constatations individuelles. Chaque Constatation continue d’exister avec sa propre sévérité, son statut, ses métadonnées, ses commentaires et son historique de remédiation. Un Groupe de Constatations fournit simplement une couche organisationnelle supplémentaire au-dessus des Constatations qu’il contient. + +### Accéder aux Groupes de Constatations + +Les Groupes de Constatations sont accessibles via la barre latérale. Le sous-menu donne accès aux Groupes de Constatations ouverts et fermés, ainsi qu’à tous les Groupes de Constatations (quel que soit leur statut d’ouverture). + +![image](images/osfindings_ss1.png) + +### Créer des Groupes de Constatations + + +Les Groupes de Constatations peuvent être créés manuellement ou automatiquement. + +Notamment, les Groupes de Constatations ne peuvent être créés qu’à partir des Constatations contenues au sein d’un seul Test. Les Constatations provenant de Tests, d’Engagements ou de Produits différents ne peuvent pas être ajoutées au même Groupe de Constatations. + +#### Groupes de Constatations manuels + +Pour effectuer manuellement des actions sur les Groupes de Constatations : +1. Accédez à une liste de Constatations au sein d’un Test. +2. Sélectionnez la ou les Constatations que vous souhaitez ajouter à un Groupe de Constatations en cliquant sur la case à cocher correspondante. +3. Cliquez sur la case à cocher **Groupe**. +4. Cliquez sur l’action correspondante que vous souhaitez effectuer. + - **Créer** : crée un Groupe de Constatations incluant les Constatations sélectionnées. + - **Ajouter à** : ajoute les Constatations sélectionnées à un Groupe de Constatations existant. + - **Retirer de tout groupe** : retire les Constatations sélectionnées de tout Groupe de Constatations dont elles faisaient précédemment partie. + - **Grouper par** : regroupe les Constatations sélectionnées selon l’option choisie (par exemple, Nom du composant, Chemin du fichier, Titre de la Constatation, etc.) +5. Cliquez sur **Envoyer**. + +![image](images/osfindings_ss4.png) + +Notez que la seule action possible lors de la sélection de Constatations depuis la liste Toutes les Constatations est de retirer les Constatations sélectionnées de tout Groupe de Constatations. Cela s’explique par le fait que, comme mentionné, les Groupes de Constatations ne peuvent être créés qu’à partir des Constatations contenues au sein d’un seul Test. + +#### Groupes de Constatations automatiques + +Lors de l’import d’une analyse, la fonctionnalité « Grouper par » peut créer automatiquement des Groupes de Constatations selon une méthode de regroupement choisie. Cela est utile lorsqu’un scanner produit de nombreuses Constatations liées qui devraient être gérées ensemble. + +La case à cocher adjacente **Créer des Groupes de Constatations pour toutes les Constatations** remplit deux fonctions : +- **Cochée** : crée un Groupe de Constatations pour chaque Constatation importée, même si cette Constatation est l’unique membre du groupe. +- **Décochée** : crée des Groupes de Constatations uniquement lorsqu’il y a effectivement plusieurs Constatations à regrouper. + +![image](images/osfindings_ss5.png) + +Si aucune option n’est sélectionnée dans le menu déroulant Grouper par lors de l’import, aucun regroupement n’aura lieu. + +Si le critère de regroupement (par exemple, nom du composant, ID de vulnérabilité, etc.) n’est pas renseigné dans la Constatation, aucun groupe ne sera créé pour elle et elle ne sera pas ajoutée à un Groupe de Constatations existant. + +Si une analyse importée révèle 10 Constatations non groupées, puis que la même analyse est réimportée avec un regroupement des Constatations, les 10 premières Constatations ne seront pas ajoutées à ce Groupe de Constatations (c’est-à-dire que le Groupe de Constatations n’inclura que les 10 Constatations du réimport, et non les 10 Constatations de l’import initial et suivant). + +## Modèles de Constatation + +Les **Modèles de Constatation** permettent aux Utilisateurs de créer des modèles réutilisables pour les vulnérabilités et problèmes de sécurité couramment signalés. Un modèle peut inclure des informations standardisées telles qu’un titre, une description, un impact, des étapes de reproduction, une atténuation, des références, et d’autres métadonnées de Constatation. + +Les Modèles de Constatation sont particulièrement utiles lorsque les Utilisateurs doivent créer des Constatations manuelles de façon répétée et souhaitent éviter de ressaisir les mêmes informations à chaque fois. + +### Accéder aux Modèles de Constatation + +Les Modèles de Constatation se trouvent dans le sous-menu Constatations de la barre latérale. + +![image](images/osfindings_ss6.png) + +### Créer des Modèles de Constatation + +Les Modèles de Constatation peuvent être créés en cliquant sur le bouton + Plus en haut à droite de la vue Modèles de Constatation. + +La page qui s’affiche ensuite offre un aperçu des métadonnées qui seront appliquées à une Constatation lorsqu’un Modèle de Constatation est utilisé. + +Vous pouvez également utiliser une Constatation existante comme base pour un nouveau Modèle de Constatation en cliquant sur **Faire de la Constatation un modèle** dans le menu kebab ⋮ de la Constatation. + +### Appliquer des Modèles de Constatation + +Les Modèles de Constatation peuvent être appliqués aux Constatations en cliquant sur le bouton **Appliquer un modèle à la Constatation** dans le menu kebab ⋮ de la Constatation sélectionnée. + +![image](images/osfindings_ss7.png) + +La page qui s’affiche ensuite vous permettra de sélectionner le modèle à appliquer à la Constatation en question, puis de choisir de conserver, remplacer ou combiner les métadonnées de la Constatation avec celles du modèle. + +### Rapports + +Le générateur de rapports de DefectDojo vous permet d’assembler un rapport personnalisé à partir d’un ensemble de widgets de contenu, de l’exécuter, et d’exporter le résultat (par exemple, en l’imprimant en PDF). Les rapports personnalisés peuvent résumer les Constatations ou les Points de terminaison que vous souhaitez partager avec un public externe, et peuvent inclure des éléments de marque et du texte standard. + +Plus d’informations sur le générateur de rapports de DefectDojo sont disponibles [ici](/metrics_reports/reports/using-the-report-builder/). + +#### Exporter les Constatations + +Les pages affichant une liste de Constatations ou une liste d’Engagements disposent d’une option d’export CSV et Excel dans le menu déroulant en haut à droite. + +Depuis n’importe quelle page de liste de Constatations, ouvrez le menu déroulant en haut à droite pour exporter les Constatations visibles au format CSV ou Excel. La liste des Engagements peut également être exportée au format CSV ou Excel en utilisant le même menu déroulant sur la page de liste des Engagements. diff --git a/docs/content/asset_modelling/engagements_tests/OS__findings.ja.md b/docs/content/asset_modelling/engagements_tests/OS__findings.ja.md new file mode 100644 index 00000000000..a43ea10d7ad --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__findings.ja.md @@ -0,0 +1,302 @@ +--- +title: 検出事項 +description: DefectDojo OSにおける検出事項の理解 +audience: opensource +weight: 5 +--- + +組織 → アセット → エンゲージメント → テスト → **検出事項** + +## 概要 + +**検出事項**は、個々の脆弱性が追跡・管理される製品階層の最下層を表すものであり、DefectDojoがセキュリティツールの報告・修復プロセスを標準化し、導くための主要な手段です。脆弱性がSonarQube、Acunetix、あるいはチーム独自のツールのいずれで報告されたものであっても、検出事項によってすべての脆弱性を同じ方法で管理できます。 + +検出事項の例には、以下のようなものがあります。 +- HttpOnly属性が設定されていないCookie +- バージョンが古い(PHP) +- 帯域外コード評価(PHP) +- バージョンが古い(MySQL) +- バックアップソースコードの検出 +- ブラインドクロスサイトスクリプティング + +脆弱性データを保存し、修復のためのフレームワークを提供することに加えて、DefectDojoは以下の方法で検出事項を強化します。 +- 悪用可能性を示す関連のEPSSスコアを検出事項に自動的に追加する +- セキュリティツールの深刻度指標を各検出事項の深刻度スコアに自動的に変換し、アセットのSLA設定に応じて検出事項にSLAを付与する。SLA設定の詳細については、[こちら](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content)をクリックしてください。 + +全体として、検出事項は製品階層と連携して機能するように設計されており、取り組みを標準化し、各アセットに一貫した方法を適用します。 + +## 検出事項へのアクセス + +検出事項にはサイドバーからアクセスできます。サブメニューからは、オープンおよびクローズされた検出事項、(オープン/クローズの状態にかかわらない)すべての検出事項、[リスク受容済みの検出事項](/triage_findings/findings_workflows/os__risk_acceptance/)、さらに検出事項テンプレートにアクセスできます。個々の検出事項は、それを含むテスト内からもアクセスできます。 + +![image](images/osfindings_ss1.png) + +### 権限 + +すべての検出事項はテストに属しており、これによりDefectDojoは、その脆弱性を最初に特定したスキャンまたは評価がどれであるかを保持できます。 + +検出事項はテストに属しているため、検出事項へのアクセスは、そのテストを含むアセットに対するユーザーのアクセス権によって決まります。テストは独自のアクセス制御リストを持ちません。 + +## 検出事項ビュー +検出事項ビューには、検出事項のステータスを一目で把握できるよう、さまざまなテーブルが含まれています。具体的には以下のとおりです。 +- **概要** + - **ID**:その検出事項の一意なID番号。 + - **深刻度**:自動的に適用される、その検出事項の深刻度評価。 + - 前述のとおり、DefectDojoはセキュリティツールの深刻度指標を各検出事項の深刻度スコアに自動的に変換し、アセットのSLA設定に応じて検出事項にSLAを付与します。 + - **SLA**:検出事項が解決されるべき目標期限。 + - **ステータス**:検出事項のステータス(アクティブ、検証済み、誤検知、重複、対象外、不具合レビュー中など)。 + - **検出事項の種類**:検出事項が静的(SAST)か動的(DAST)かを示します。 + - **発見日**:検出事項が発見された日付。 + - **CWE**:検出事項のCWE分類。 + - **脆弱性ID**:検出事項に関連するセキュリティアドバイザリ内の脆弱性ID(CVEなど)。 + - **検出元**:その検出事項を明らかにしたツール。 +- **類似の検出事項**:完全な重複ではないものの、脆弱性ID、CWE、file_path、行番号などの値が類似している、同一アセット内の他の検出事項。 +- **インポート履歴**:いずれかのテストにおいて、この検出事項を作成/クローズ/再アクティブ化したインポート/再インポートの一覧。 +- **脆弱なエンドポイント/システム**:検出事項によって脆弱であることが判明したエンドポイント/システム。 +- **説明**:検出事項の説明(検出事項の種類に応じて自動的に追加される場合と、手動で作成される場合があります)。 +- **緩和策**:緩和のために推奨される手順。 +- **影響**:検出事項を未解決のまま放置した場合に想定される影響。 +- **再現手順**:検出事項を再現するための手順。 +- **深刻度の根拠**:特定の深刻度評価が検出事項に紐づけられた理由についての記述。 +- **参考情報**:サードパーティのスキャンツールによる検出事項固有の説明を相互参照するためのURL。例えば、参考情報は検出事項カタログ内の該当エントリへのリンクや、単一のアドバイザリURLである場合があります。 +- **メモ**:検出事項に関連してユーザーが残したメモ。メモを非公開に設定すると、選択した検出事項を含む生成レポートには含まれなくなります。 + +## 検出事項のデータ + +検出事項には、以下のメタデータが必須です。 +**タイトル** +**日付** +**深刻度** +**説明** + +検出事項ビューのテーブルに対応するメタデータに加えて、以下の任意のメタデータフィールドがあります。 +- **グループ**:選択した検出事項を含む検出事項グループ。 +- **CVSS3/CVSS4ベクターとスコア**:選択した検出事項のCVSS3およびCVSS4のベクターとスコア。 +- **リクエストとレスポンスのペア**:クライアントから送信されたメッセージと、それに対するサーバーの応答のコピー。 +- **追加するエンドポイント**:選択した検出事項の影響を受ける可能性があるものの、前述のシステム/エンドポイントの一覧には反映されていない脆弱なエンドポイント。 +- **EPSSスコアとパーセンタイル**:CVEのEPSSスコアとパーセンタイル。 +- **KEV追加日**:検出事項がKEVカタログに追加された日付。 +- **修正の有無とバージョン**:脆弱性に対する修正が利用可能かどうか、また修正が実装された影響コンポーネントのバージョンを定義します。 +- **不具合レビューを依頼したユーザー**:該当する不具合についてレビューを依頼したユーザーを記録します。 +- **行番号**:攻撃ベクターのソース内での行番号。 +- **ファイルパス**:不具合を含むことが特定されたファイル。 +- **コンポーネント名とバージョン**:影響を受けるコンポーネントの名前とバージョン。 +- **ツールからの一意のID**:提供元ツールによる脆弱性の技術ID。 +- **ツールからの脆弱性ID**:提供元ツールによる一意ではない技術ID。 +- **SASTのソースオブジェクト、行番号、ファイルパス**:攻撃ベクターのソースオブジェクト、行番号、ファイルパス。 +- **SASTのシンクオブジェクト**:攻撃ベクターのシンクオブジェクト。 +- **発生回数**:スキャナーによって複数の脆弱性が検出・集約された際の、提供元ツールにおける発生回数。 +- **公開日**:検出事項が公開された日付。 +- **サービス**:選択した検出事項の影響を受ける、連携済みのサービス(アセット内の自己完結的な機能単位)。この項目に値が設定されている場合、重複排除のマッチングに使用されます(つまり、サービスの項目が同一の検出事項は重複排除されます)。 +- **修復予定日とバージョン**:検出事項の修復が予定されている日付、および修正が実装される予定の影響コンポーネントのバージョン。 +- **修正の工数**:検出事項の修正に要する工数のレベル(低、中、高など)。 +- **タグ**:検出事項に追加されたタグ。 + +利用可能なメタデータの詳細は、検出事項を明らかにしたパーサー/スキャナーによって異なります。タイトルや深刻度といった基本情報のみを提供するものもあれば、CVSSベクター、脆弱なコンポーネント、エンドポイント、リクエスト/レスポンスのペア、その他スキャナー固有のメタデータを含むものもあります。 + +これらのメタデータにより、セキュリティプログラム全体にわたるフィルタリング、レポート作成、優先順位付けが向上し、長期的な追跡とトレンド分析が可能になります。詳細およびメタデータの説明は[こちら](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page)を参照してください。 + +### 重複排除 + +DefectDojoには、同一の根本的な脆弱性を表す検出事項を特定・管理するための重複排除機能が備わっています。1つまたは複数のツールからスキャン結果がインポートされると、DefectDojoは設定可能なマッチングロジックを使用して、同一の脆弱性を表す検出事項を特定します。 + +重複排除により、同一または異なるスキャナーによって同じ脆弱性が繰り返し検出された場合でも、それが複数回表示されることを防ぎ、修復履歴が単一の検出事項に紐づいたまま維持されます。 + +重複排除の詳細については[こちら](/triage_findings/finding_deduplication/about_deduplication/)を参照してください。 + +### 再インポート + +DefectDojoの再インポート機能により、新しいスキャン結果がインポートされる際に検出事項を更新できます。スキャンが再インポートされると、DefectDojoは受信した結果を既存の検出事項と比較し、まったく新しいレコードを作成する代わりに、一致するレコードを更新します。これにより、ステータスの変更、修復履歴、コメント、所有者情報といった重要なコンテキストが保持され、複数のテストサイクルにわたる検出事項のライフサイクルの継続的な記録が提供されます。 + +再インポート機能の詳細については[こちら](/import_data/import_intro/reimport/#main-content)を参照してください。 + +### リスク受容 + +リスク受容は、検出事項に適用できる特別なステータスであり、直ちに修復することなくその存在を認識するという判断を、正式に文書化し運用に反映させるためのものです。 + +リスク受容の詳細については[こちら](/triage_findings/findings_workflows/os__risk_acceptance/)を参照してください。 + +### ステータス + +DefectDojoで作成された各検出事項にはステータスがあり、関連する情報を伝えるとともに、チームが問題解決の進捗を追跡するのに役立ちます。 + +ステータスの詳細については[こちら](/triage_findings/findings_workflows/finding_status_definitions/)を参照してください。 + +## 検出事項の操作 + +### 検出事項の作成 + +ほとんどの検出事項はスキャンのインポートや連携を通じて自動的に生成されますが、DefectDojoでは検出事項を手動で作成することもサポートしています。手動での検出事項は、ペネトレーションテスト、アーキテクチャレビュー、コンプライアンス評価、バグバウンティプログラム、コンサルタントによるエンゲージメントなど、スキャナー出力を伴わない活動によって特定された脆弱性やセキュリティ上の懸念事項を追跡するのに役立ちます。 + +検出事項を手動で作成するには: +1. 検出事項を手動で追加したいテストに移動し、+(プラス)記号をクリックしてから、**新規検出事項**をクリックします。 + +![image](images/osfindings_ss2.png) + +2. これにより新規検出事項フォームが開くので、検出事項に関する必要な情報を入力します。 + +3. さらに検出事項を手動で追加する場合は**別の検出事項を追加**を、手動での検出事項作成プロセスを終了する場合は**完了**を選択します。 + +作成された検出事項は、元のテストに含まれる検出事項の一覧に表示されるようになります。 + +重要な点として、トップバーから検出事項を手動で追加すると、現在表示中のテストに追加されるのではなく、新しい検出事項を格納するためのアドホックなエンゲージメントとテストが自動的に作成されます(下の画像を参照)。これは、トップバーがアセット全体に関連するものであるためです。特定の既存のテストに検出事項を手動で追加したい場合は、上記の手順1~3のとおり、そのテスト自体の中から行うことを推奨します。 + +![image](images/osfindings_ss3.png) + +### 検出事項の編集 + +#### ⋮ケバブメニュー + +検出事項の横にある⋮ケバブメニューには、以下の機能があります。 +- **表示**:検出事項を開いて表示します。 +- **編集**:検出事項を編集します。 +- **コピー**:検出事項のコピーを作成します。コピーは、対応するエンゲージメント内に含まれる任意のテストに保存できます。 +- **ピアレビューを依頼**:ピアレビューのプロセスを開始し、検出事項のステータスを「レビュー中」に変更します。ピアレビューの詳細については[こちら](/triage_findings/findings_workflows/finding_status_definitions/#under-review)を参照してください。 +- **検出事項にタッチ**:検出事項の履歴に、その検出事項とのやり取りを記録します。 +- **検出事項をテンプレート化**:選択した検出事項をもとに、検出事項テンプレートを自動的に作成します。 +- **検出事項にテンプレートを適用**:既存の検出事項テンプレートを検出事項に適用できるようにします。 +- **検出事項をクローズ**:検出事項をクローズするプロセスを開始します。 +- **リスク受容を追加**:リスク受容のプロセスを開始します。詳細については[こちら](/triage_findings/findings_workflows/os__risk_acceptance/#main-content)を参照してください。 +- **履歴を表示**:選択した検出事項の履歴を表示します。 +- **削除**:選択した検出事項を削除します。 + +#### 検出事項へのファイルの添付 +検出事項には、視覚的なコンテキストを提供するためにファイルを添付できます。例えば、脆弱性が実際に動作している様子のスクリーンショットや、概念実証(PoC)の画像などです。 + +サポートされているファイルの種類は以下のとおりです。 + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +検出事項にファイルを添付するには: +1. ファイルを添付したい検出事項を開きます。 +2. アクションメニュー(検出事項の右上にある☰ボタン)を開き、「ファイルの管理」をクリックします。 + +![image](images/OS_manage_files_menu.png) + +3. ファイル追加ページで、ファイルのタイトルを入力し、コンピューターからファイルを選択します。一度に最大3件のファイルを追加できます。さらに追加したい場合は、保存してから再度この画面に戻ってください。 + +![image](images/OS_manage_files_form.png) + +4. **保存**をクリックします。 + +ファイルは、検出事項の**ファイル**パネルに一覧表示されます。画像ファイルはサムネイルとして表示されます。 + +![image](images/OS_finding_files_panel.png) + +#### 検出事項の一括編集 + +検出事項は、サイドバーからアクセスできるすべての検出事項のテーブルや、特定のテスト内の検出事項のテーブルなど、検出事項の一覧から一括編集できます。 + +検出事項の一括編集方法の詳細については[こちら](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings)を参照してください。 + +### 検出事項のクローズ + +検出事項に対する作業が完了したら、検出事項の⋮ケバブメニューまたは☰アクションメニュー内の**検出事項をクローズ**をクリックすることで、手動でクローズできます。また、以前記録された検出事項が含まれていないスキャンがDefectDojoに再インポートされた場合、その以前記録された検出事項は自動的にクローズされます。 + +検出事項をクローズさせたくない場合は、再インポート時にこの動作を無効にできます。 + +- UIを使用している場合は、「古い検出事項をクローズ」チェックボックスのチェックを外します +- APIを使用している場合は、close_old_findingsをFalseに設定します ​ + +### 検出事項の削除 + +検出事項の削除は、検出事項の⋮ケバブメニューまたは☰アクションメニューから行えます。この操作は元に戻せません。 + +監査の観点から、修復済みの検出事項は削除するのではなく、クローズすることを推奨します。 + +## 検出事項グループ + +**検出事項グループ**を使用すると、トリアージ、レポート作成、修復対応の調整のために、複数の関連する検出事項を単一の論理的な単位として扱うことができます。 + +例えば、あるスキャンで異なるエンドポイントにまたがる10件のSQLインジェクションの検出事項が発生することがあります。それぞれを個別に管理する代わりに、それらをより広範なSQLインジェクションの問題を表す単一の検出事項グループにまとめることができます。 + +検出事項グループは、個々の検出事項を置き換えるものではありません。各検出事項は、それぞれの深刻度、ステータス、メタデータ、コメント、修復履歴を保持したまま存在し続けます。検出事項グループは、それに含まれる検出事項の上に、追加の整理レイヤーを提供するに過ぎません。 + +### 検出事項グループへのアクセス + +検出事項グループにはサイドバーからアクセスできます。サブメニューからは、オープンおよびクローズされた検出事項グループ、ならびに(オープンの状態にかかわらない)すべての検出事項グループにアクセスできます。 + +![image](images/osfindings_ss1.png) + +### 検出事項グループの作成 + + +検出事項グループは、手動または自動で作成できます。 + +重要な点として、検出事項グループは単一のテストに含まれる検出事項からのみ作成できます。異なるテスト、エンゲージメント、または製品に属する検出事項を、同じ検出事項グループに追加することはできません。 + +#### 手動での検出事項グループ + +検出事項グループの操作を手動で行うには: +1. テスト内の検出事項一覧に移動します。 +2. 対応するチェックボックスをクリックして、検出事項グループに追加したい検出事項を選択します。 +3. **グループ**チェックボックスをクリックします。 +4. 実行したい対応するアクションをクリックします。 + - **作成**:選択した検出事項を含む検出事項グループを作成します。 + - **追加**:選択した検出事項を既存の検出事項グループに追加します。 + - **グループから削除**:選択した検出事項を、これまで所属していたすべての検出事項グループから削除します。 + - **グループ化**:選択したオプション(コンポーネント名、ファイルパス、検出事項のタイトルなど)に基づいて、選択した検出事項をグループ化します。 +5. **送信**をクリックします。 + +![image](images/osfindings_ss4.png) + +なお、すべての検出事項の一覧から検出事項を選択した場合に実行できるアクションは、選択した検出事項をあらゆる検出事項グループから削除することのみです。これは、前述のとおり、検出事項グループが単一のテストに含まれる検出事項からのみ作成できるためです。 + +#### 自動での検出事項グループ + +スキャンをインポートする際、「グループ化」機能を使用すると、選択したグループ化方法に基づいて検出事項グループを自動的に作成できます。これは、スキャナーがまとめて管理すべき多数の関連する検出事項を生成する場合に役立ちます。 + +隣接する**すべての検出事項に検出事項グループを作成する**チェックボックスには、以下の2つの機能があります。 +- **チェックあり**:インポートされたすべての検出事項について、たとえそのグループのメンバーがその検出事項1件のみであっても、検出事項グループを作成します。 +- **チェックなし**:実際にグループ化すべき検出事項が複数存在する場合にのみ、検出事項グループを作成します。 + +![image](images/osfindings_ss5.png) + +インポート時に「グループ化」のドロップダウンメニューからオプションが選択されていない場合、グループ化は行われません。 + +グループ化の基準(コンポーネント名や脆弱性IDなど)が検出事項に設定されていない場合、その検出事項に対してグループが作成されたり、既存の検出事項グループに追加されたりすることはありません。 + +グループ化されていない10件の検出事項を明らかにするスキャンがインポートされた後、同じスキャンが再インポートされて検出事項がグループ化された場合、最初の10件の検出事項はその検出事項グループには追加されません(つまり、検出事項グループには再インポート時の10件の検出事項のみが含まれ、最初およびそれに続くインポート時の10件は含まれません)。 + +## 検出事項テンプレート + +**検出事項テンプレート**を使用すると、ユーザーはよく報告される脆弱性やセキュリティ上の問題について、再利用可能なテンプレートを作成できます。テンプレートには、タイトル、説明、影響、再現手順、緩和策、参考情報、その他の検出事項のメタデータなど、標準化された情報を含めることができます。 + +検出事項テンプレートは、ユーザーが手動での検出事項の作成を繰り返し行う必要があり、その都度同じ補足情報を再入力することを避けたい場合に特に役立ちます。 + +### 検出事項テンプレートへのアクセス + +検出事項テンプレートは、サイドバーの検出事項サブメニュー内にあります。 + +![image](images/osfindings_ss6.png) + +### 検出事項テンプレートの作成 + +検出事項テンプレートは、検出事項テンプレートビューの右上にある+(プラス)ボタンをクリックすることで作成できます。 + +続いて表示されるページには、検出事項テンプレートが使用された際に検出事項に適用されるメタデータの概要が表示されます。 + +また、検出事項の⋮ケバブメニュー内の**検出事項をテンプレート化**をクリックすることで、既存の検出事項を新しい検出事項テンプレートの基とすることもできます。 + +### 検出事項テンプレートの適用 + +検出事項テンプレートは、選択した検出事項の⋮ケバブメニュー内にある**検出事項にテンプレートを適用**ボタンをクリックすることで、検出事項に適用できます。 + +![image](images/osfindings_ss7.png) + +続いて表示されるページでは、該当する検出事項に適用するテンプレートを選択し、その後、検出事項のメタデータをそのまま維持するか、テンプレートのメタデータで置き換えるか、あるいは両者を組み合わせるかを選択できます。 + +### レポート作成 + +DefectDojoのレポートビルダーを使用すると、一連のコンテンツウィジェットからカスタムレポートを作成し、実行して結果をエクスポートできます(例えばPDFとして印刷するなど)。カスタムレポートは、外部の読み手と共有したい検出事項やエンドポイントを要約でき、ブランディングや定型文を含めることもできます。 + +DefectDojoのレポートビルダーの詳細については[こちら](/metrics_reports/reports/using-the-report-builder/)を参照してください。 + +#### 検出事項のエクスポート + +検出事項の一覧またはエンゲージメントの一覧を表示するページには、右上のドロップダウンメニューにCSVおよびExcelのエクスポートオプションがあります。 + +任意の検出事項一覧ページで、右上隅のドロップダウンメニューを開くと、表示されている検出事項をCSVまたはExcelファイルとしてエクスポートできます。エンゲージメントの一覧も、エンゲージメント一覧ページの同様のドロップダウンメニューを使用して、CSVまたはExcelとしてエクスポートできます。 diff --git a/docs/content/asset_modelling/engagements_tests/OS__organizations.de.md b/docs/content/asset_modelling/engagements_tests/OS__organizations.de.md new file mode 100644 index 00000000000..f3abd53c17d --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__organizations.de.md @@ -0,0 +1,139 @@ +--- +title: Organizations +description: Organizations in DefectDojo OS verstehen +audience: opensource +weight: 1 +aliases: +- /de/asset_modelling/engagements_tests/os_producttype/ +- /de/en/asset_modelling/engagements_tests/os_producttype/ +--- + +**ORGANIZATIONS** → Assets → Engagements → Tests → Befunde + +## Überblick + +**Organizations** stehen ganz oben in der Objekthierarchie von DefectDojo. Organizations unterscheiden sich von den untergeordneten Objekten der Hierarchie – Assets, Engagements, Tests und Befunde – dadurch, dass sie keine technischen Scan-Ziele sind, sondern in erster Linie als organisatorische Abstraktionen dienen, die Ihre Sicherheitsarbeit unterteilen nach: +- Geschäftsbereich +- Entwicklungsteam +- Sicherheitsteam +- Softwareanwendungen +- Übergeordnete Produktfamilie +- Kunde oder Tochtergesellschaft +- Berichtsstruktur +- usw. + +Das gemeinsame Thema der obigen Beispiele veranschaulicht den wesentlichen Nutzen von Organizations: Sie sollten in der Regel stabile, langlebige Grenzen innerhalb Ihres Sicherheitsprogramms darstellen. + +## Organization-Daten und -Struktur + +Da Organizations nicht direkt gescannt werden, ist der Name das einzige Pflichtfeld, das zu ihrer Erstellung erforderlich ist. Darüber hinaus fungieren sie als Container für Assets und deren untergeordnete Engagements, Tests und Befunde. + +Überlegen Sie beim Erstellen einer Organization, wie sich deren Struktur auf Ihre Berichterstattung auswirkt. Benötigen Sie Organizations in erster Linie, um die Teams abzubilden, die an den darin enthaltenen Projekten (Assets) arbeiten? Oder sollen Organizations eher übergeordnete Projekte darstellen, die verschiedene Iterationen der darin enthaltenen Projekte (Assets) umfassen? + +Wenn eine einzelne Organization alle relevanten Informationen für einen bestimmten Geschäftsbereich oder ein bestimmtes Entwicklungsteam enthält, erleichtert deren Abbildung als Organization eine reibungslosere Berichterstattung, anstatt einen Bericht aus verschiedenen Assets und Organizations zusammenstellen zu müssen. + +Wenn ein bestimmtes Softwareprojekt viele unterschiedliche Deployments oder Versionen hat, kann es sinnvoll sein, eine einzelne Organization zu erstellen, die den Geltungsbereich des gesamten Projekts abdeckt, wobei jede Version als eigenständiges Asset existiert. In manchen Workflows werden Organizations auch verwendet, um Phasen des Software-Lebenszyklus zu trennen: eine Organization für „In Development“, eine Organization für „In Production“ usw. + +Organizations können verwendet werden, um für RBAC-Zwecke den Zugriff auf Tochtergesellschaften, übernommene Unternehmen oder andere regulierte Geschäftseinheiten festzulegen. In komplexen Unternehmen mit vielen individuellen Projekten und unterschiedlichen Zugriffsregeln sind Organizations besonders relevant. + +Letztlich hängt die Entscheidung, wie Sie Organizations und Assets einsetzen, davon ab, wie Sie Ihre individuelle Organisationsstruktur und die Anforderungen Ihres Sicherheitsteams am besten abbilden möchten. + +Nachfolgend finden Sie einige Beispielstrukturen, die Ihnen helfen zu entscheiden, ob Sie Ihre Objekte als Organizations oder als Assets festlegen. + +- **Organization**: Payments Division + - Asset: Payments API - Production + - Asset: Payments API - Staging + - Asset: Billing Worker + +- **Organization**: Software Product A + - Asset: Web Portal + - Asset: Mobile Backend + +Die folgende Übersicht dient außerdem als Orientierungshilfe dafür, ob etwas besser als Organization oder als Asset abgebildet werden sollte: + +| Organizations | Assets | +|--------------|--------| +| Geschäftseinheiten | Einzelne Anwendungen | +| Abteilungen | Deployments/Umgebungen | +| Sicherheits-Verantwortungsbereiche | Infrastrukturkomponenten | +| Produktfamilien | Spezifische Microservices | +| Berichterstattung auf Portfolio-Ebene | Scan-Ziele | +| Kunden | Spezifische Softwareversionen | + +Wie bereits erwähnt, kann Ihre Struktur je nach Ihren individuellen Sicherheitsanforderungen abweichen. + +## Zugriff auf Organizations + +Organizations sind über die Seitenleiste zugänglich. Das Untermenü bietet außerdem die Möglichkeit, neue Organizations zu erstellen. + +![image](images/organization_ss1.png) + +### Organization-Ansicht + +Die Ansicht einer Organization enthält verschiedene Tabellen und Diagramme, um ihren Status auf einen Blick zu erfassen. Dazu gehören: +- **Beschreibung** +- **Key/Critical-Checkbox** + - Das Aktivieren von Critical oder Key dient ausschließlich Filterzwecken +- **Liste der Assets innerhalb der Organization** +- **Autorisierte Benutzer** (DefectDojo-Benutzer) + +## Arbeiten mit Organizations + +### Organizations erstellen + +Es gibt zwei Möglichkeiten, Organizations zu erstellen: + +- Über die Option **Add Organization** im Seitenmenü +- Über die Schaltfläche **Add Organization** oben in der Liste All Organizations + +### Organizations bearbeiten + +Organizations können bearbeitet werden, indem Sie in der Ansicht der Organization oben rechts in der Description-Tabelle im Dropdown-Menü auf **Edit** klicken. Dasselbe Menü ist auch über das Kebab-Menü ⋮ links neben der Organization in der Liste All Organizations erreichbar. + +Alle weiteren bearbeitbaren Felder stehen auch beim Erstellen der Organization zur Verfügung. + +### Organizations löschen + +Eine Organization können Sie löschen, indem Sie in den Einstellungen der Organization **Delete Organization** auswählen. + +Da Organizations ganz oben in der Hierarchie stehen, entfernt das Löschen den gesamten nachgelagerten Sicherheitsverlauf, alle Beziehungen und untergeordneten Objekte, darunter: +- Alle in der Organization enthaltenen Assets, Engagements und Tests +- Der gesamte zugehörige Sicherheitsverlauf, einschließlich Befunde und Integrationen +- Alle verknüpften Jira Epics +- Alle Notizen und hochgeladenen Dateien, die mit den Assets, Engagements und Tests dieser Organization verknüpft sind + +Das Löschen einer Organization kann nicht rückgängig gemacht werden. Wenn Sie eine Organization „stilllegen“ möchten, ohne die zugrunde liegenden Daten zu löschen (zum Beispiel um alte Testaufzeichnungen aus Audit-Gründen zu erhalten), können Sie den Namen der Organization ändern oder einen Tag hinzufügen, der den veralteten Status kennzeichnet. + +## Organizations vs. Metadaten + +Organizations sollen strukturelle Zuständigkeiten oder Berichtsgrenzen abbilden und keine leichtgewichtigen Klassifizierungen. Attribute wie Deployment-Status, interne Kennzeichnungen oder temporäre Workflow-Zustände lassen sich oft besser über Tags oder Metadaten abbilden als über separate Organizations. + +## Organization-Grenzen + +Organizations legen sowohl Berichts- als auch Zugriffsgrenzen innerhalb von DefectDojo fest. Da Integrationen, RBAC-Berechtigungen, Zuständigkeiten, Metriken und Deduplizierungsmodelle häufig die Struktur der Organizations übernehmen, hilft eine frühzeitig klar gestaltete Grenzziehung dabei, spätere Hierarchie-Wildwuchs und fragmentierte Berichterstattung zu vermeiden. + +### Befunde und Automatisierung + +Obwohl Integrationen üblicherweise auf untergeordneten Objekten wie Assets, Engagements oder Befunden konfiguriert werden, legen Organizations dennoch die Zuständigkeits-, Berichts- und Zugriffsgrenzen fest, innerhalb derer diese Integrationen arbeiten. + +Berechtigungen werden nach unten vererbt, das heißt, der Zugriff auf eine Organization gewährt automatisch Zugriff auf alle Objekte innerhalb dieser Organization (z. B. Assets, Engagements, Tests und Befunde). + +Das RBAC-Modell von DefectDojo kann verwendet werden, um den Zugriff menschlicher Benutzer zu steuern, aber auch, um den Zugriff von API-Tokens auf bestimmte Organizations zu beschränken. + +Weitere Informationen zu Benutzerrollen finden Sie in unserem Artikel [Permissions](/admin/user_management/os__authorized_users/). + +### Zuständigkeit + +Als Objekte auf oberster Ebene implizieren Organizations auch die Zuständigkeit für die darin enthaltenen untergeordneten Objekte. SLA-Tracking, Remediation-Workflows, Ticket-Routing und die allgemeine Governance funktionieren reibungsloser, wenn Organizations so eingerichtet sind, dass sie die verantwortlichen Personen korrekt widerspiegeln. + +### Metriken/Berichterstattung + +Metrik-Dashboards, Kacheln und Ansichten können nach Organization gefiltert werden, wodurch sie eine wesentliche Rolle dabei spielen, wie Ihre Sicherheitsdaten berechnet, visualisiert und letztlich exportiert werden. + +Für Berichtszwecke ist es in der Regel einfacher, mehrere Organizations in einem einzigen Dokument zusammenzufassen, als eine einzelne Organization in separate Dokumente aufzuteilen. Wir empfehlen daher, Organizations so granular anzulegen, wie es für die Berichte Ihres Teams sinnvoll ist. Es besteht beispielsweise keine Notwendigkeit, einen großen Geschäftsbereich als Organization abzubilden, wenn Sie hauptsächlich an einzelne Abteilungen innerhalb dieses Bereichs berichten werden. + +Eine wirksame Strukturierung Ihrer Organizations entsprechend Ihren Berichtsanforderungen ist entscheidend für eine präzise Bewertung Ihrer Sicherheitslage. Weitere Informationen zu Metrics finden Sie [hier](/metrics_reports/dashboards/introduction_dashboard/). + +### Deduplizierung + +Die Deduplizierung in DefectDojo erfolgt auf Asset-Ebene und wird von der übergeordneten Organization nicht beeinflusst. diff --git a/docs/content/asset_modelling/engagements_tests/OS__organizations.es.md b/docs/content/asset_modelling/engagements_tests/OS__organizations.es.md new file mode 100644 index 00000000000..d47ecc13159 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__organizations.es.md @@ -0,0 +1,139 @@ +--- +title: Organizaciones +description: Cómo entender las Organizaciones en DefectDojo OS +audience: opensource +weight: 1 +aliases: +- /es/asset_modelling/engagements_tests/os_producttype/ +- /es/en/asset_modelling/engagements_tests/os_producttype/ +--- + +**ORGANIZACIONES** → Activos → Compromisos → Tests → Hallazgos + +## Resumen + +Las **Organizaciones** se ubican en la parte más alta de la jerarquía de objetos de DefectDojo. Las Organizaciones se diferencian de los objetos descendentes en la jerarquía (Activos, Compromisos, Tests y Hallazgos) porque no son objetivos técnicos de escaneo, sino que sirven principalmente como abstracciones organizativas que compartimentan sus esfuerzos de seguridad según: +- Dominio de negocio +- Equipo de desarrollo +- Equipo de seguridad +- Aplicaciones de software +- Familia de productos general +- Cliente o subsidiaria +- Estructura de reporte +- etc. + +El hilo conductor de los ejemplos anteriores ilustra la utilidad esencial de las Organizaciones: en general, deben representar límites estables y duraderos dentro de su programa de seguridad. + +## Datos y estructura de la Organización + +Dado que las Organizaciones no se escanean directamente, el único campo obligatorio para crearlas es un nombre. Más allá de eso, actúan como contenedores de Activos y de los Compromisos, Tests y Hallazgos que descienden de ellos. + +Al crear una Organización, considere cómo su estructura influirá en sus informes. ¿Necesita principalmente que las Organizaciones representen a los equipos que trabajan en los proyectos (Activos) que contendrán? ¿O sería mejor que las Organizaciones representen proyectos generales que contienen distintas iteraciones de los proyectos (Activos) dentro de ellas? + +Si dispone de una sola Organización que contiene toda la información relevante de un determinado dominio de negocio o equipo de desarrollo, representarla como una Organización facilitará la elaboración de informes, en lugar de tener que reunir un informe a partir de varios Activos y Organizaciones. + +Si un proyecto de software concreto tiene muchos despliegues o versiones distintas, puede convenir crear una única Organización que abarque el alcance de todo el proyecto y que cada versión exista como Activos individuales. En algunos flujos de trabajo, las Organizaciones también pueden usarse para separar las etapas del ciclo de vida del software: una Organización para “En desarrollo”, otra Organización para “En producción”, etc. + +Las Organizaciones pueden usarse para determinar el acceso a subsidiarias, empresas adquiridas u otras unidades de negocio reguladas con fines de RBAC. En negocios complejos, donde existen muchos proyectos exclusivos con distintas reglas de acceso, las Organizaciones resultan particularmente relevantes. + +En última instancia, la decisión de cómo usar las Organizaciones y los Activos depende de cómo desee reflejar mejor su estructura organizativa particular y las necesidades de su equipo de seguridad. + +A continuación se muestran algunos ejemplos de estructuras que le ayudarán a determinar si sus objetos deben designarse como Organizaciones o como Activos. + +- **Organización**: División de Pagos + - Activo: API de Pagos - Producción + - Activo: API de Pagos - Staging + - Activo: Worker de Facturación + +- **Organización**: Producto de Software A + - Activo: Portal Web + - Activo: Backend Móvil + +Además, a continuación se ofrece una guía ilustrativa sobre si algo se representa mejor como una Organización o como un Activo: + +| Organizaciones | Activos | +|--------------|--------| +| Unidades de negocio | Aplicaciones individuales | +| Departamentos | Despliegues/entornos | +| Dominios de propiedad de seguridad | Componentes de infraestructura | +| Familias de productos | Microservicios específicos | +| Informes a nivel de cartera | Objetivos de escaneo | +| Clientes | Versiones específicas de software | + +Como se indicó, su estructura puede variar según las necesidades particulares de seguridad de su organización. + +## Acceso a las Organizaciones + +Se puede acceder a las Organizaciones desde la barra lateral. El submenú también ofrece la opción de crear nuevas Organizaciones. + +![image](images/organization_ss1.png) + +### Vista de la Organización + +La vista de una Organización contiene diversas tablas y gráficos para interpretar su estado de un vistazo. Esto incluye: +- **Descripción** +- **Casilla Clave/Crítica** + - Marcar Crítica o Clave se usa únicamente con fines de filtrado +- **Lista de Activos dentro de la Organización** +- **Usuarios autorizados** (Usuarios de DefectDojo) + +## Trabajar con Organizaciones + +### Crear Organizaciones + +Existen dos maneras de crear Organizaciones: + +- Desde la opción **Agregar Organización** en el menú lateral +- Desde el botón **Agregar Organización** en la parte superior de la lista de todas las Organizaciones + +### Editar Organizaciones + +Las Organizaciones se pueden editar haciendo clic en **Editar** desde el menú desplegable ubicado en la parte superior derecha de la tabla Descripción en la vista de la Organización. También se puede acceder al mismo menú haciendo clic en el menú de tres puntos (⋮) situado a la izquierda de la Organización en la lista de todas las Organizaciones. + +Todos los campos que se pueden editar posteriormente también están disponibles al crear la Organización. + +### Eliminar Organizaciones + +Para eliminar una Organización, seleccione **Eliminar Organización** en la configuración de la Organización. + +Debido a que las Organizaciones se ubican en la parte más alta de la jerarquía, al eliminarlas se elimina todo el historial de seguridad, las relaciones y los objetos secundarios posteriores, tales como: +- Cualquier Activo, Compromiso y Test contenido dentro de la Organización +- Todo el historial de seguridad asociado, incluidos los Hallazgos y las integraciones +- Cualquier Epic de Jira vinculado +- Todas las notas y archivos cargados asociados con los Activos, Compromisos y Tests dentro de esa Organización + +La eliminación de una Organización no se puede deshacer. Si desea “dar de baja” una Organización sin eliminar los datos subyacentes (por ejemplo, para conservar registros de pruebas de software heredado con fines de auditoría), puede cambiar el nombre de la Organización o agregar una Etiqueta que indique que se encuentra en estado obsoleto. + +## Organizaciones frente a Metadatos + +Las Organizaciones están pensadas para representar límites de propiedad estructural o de generación de informes, en lugar de clasificaciones ligeras. Atributos como el estado de despliegue, las etiquetas internas o los estados temporales de flujo de trabajo pueden representarse mejor mediante etiquetas o metadatos que mediante Organizaciones independientes. + +## Límites de la Organización + +Las Organizaciones establecen tanto los límites de generación de informes como los de acceso dentro de DefectDojo. Dado que las integraciones, los permisos de RBAC, la propiedad, las métricas y los modelos de deduplicación heredan con frecuencia la estructura de las Organizaciones, diseñar límites claros desde el principio ayuda a evitar una jerarquía excesiva y la fragmentación de los informes más adelante. + +### Hallazgos y automatización + +Aunque las integraciones normalmente se configuran en objetos de nivel inferior, como Activos, Compromisos o Hallazgos, las Organizaciones siguen definiendo los límites de propiedad, generación de informes y acceso dentro de los cuales operan dichas integraciones. + +Los permisos se propagan en cascada hacia abajo, lo que significa que el acceso a una Organización otorga automáticamente acceso a todos los objetos dentro de esa Organización (por ejemplo, Activos, Compromisos, Tests y Hallazgos). + +El modelo de RBAC de DefectDojo se puede usar para controlar el acceso de usuarios humanos, pero también puede restringir el acceso de los tokens de API a Organizaciones concretas. + +Para obtener más información sobre los roles de usuario, consulte nuestro artículo [Permisos](/admin/user_management/os__authorized_users/). + +### Propiedad + +Al ser objetos de nivel superior, las Organizaciones también implican la propiedad de los objetos secundarios que contienen. El seguimiento de SLA, los flujos de trabajo de remediación, el enrutamiento de tickets y la gobernanza general fluyen con mayor facilidad cuando las Organizaciones se configuran para reflejar con precisión a los responsables de las mismas. + +### Métricas/Informes + +Los paneles de métricas, los mosaicos y las vistas se pueden filtrar por Organización, lo que las convierte en un componente fundamental de cómo se calculan, visualizan y finalmente exportan sus datos de seguridad. + +Para fines de generación de informes, en general resulta más sencillo combinar varias Organizaciones en un solo documento que subdividir una única Organización en documentos independientes. Por ello, recomendamos configurar las Organizaciones con el nivel de granularidad que tenga sentido para los informes de su equipo. Por ejemplo, no es necesario representar una gran división de negocio como una Organización si, en su mayor parte, va a generar informes para departamentos individuales dentro de esa división. + +Estructurar de forma eficaz sus Organizaciones para reflejar sus necesidades de generación de informes es fundamental para evaluar con precisión su postura de seguridad. Para obtener más información sobre Métricas, haga clic [aquí](/metrics_reports/dashboards/introduction_dashboard/). + +### Deduplicación + +La deduplicación en DefectDojo se produce a nivel de Activo y no se ve afectada por la Organización principal. diff --git a/docs/content/asset_modelling/engagements_tests/OS__organizations.fr.md b/docs/content/asset_modelling/engagements_tests/OS__organizations.fr.md new file mode 100644 index 00000000000..d7917ccc803 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__organizations.fr.md @@ -0,0 +1,139 @@ +--- +title: Organisations +description: Comprendre les Organisations dans DefectDojo OS +audience: opensource +weight: 1 +aliases: +- /fr/asset_modelling/engagements_tests/os_producttype/ +- /fr/en/asset_modelling/engagements_tests/os_producttype/ +--- + +**ORGANISATIONS** → Actifs → Engagements → Tests → Constatations + +## Aperçu + +**Les Organisations** se situent tout en haut de la hiérarchie des objets de DefectDojo. Les Organisations se distinguent des objets qui descendent dans la hiérarchie (Actifs, Engagements, Tests et Constatations) car elles ne constituent pas des cibles de scan techniques, mais servent avant tout d'abstractions organisationnelles qui compartimentent vos efforts de sécurité selon : +- Domaine d'activité +- Équipe de développement +- Équipe de sécurité +- Applications logicielles +- Famille de produits globale +- Client ou filiale +- Structure de reporting +- etc. + +Le fil conducteur des exemples ci-dessus illustre l'utilité essentielle des Organisations : elles doivent généralement représenter des frontières stables et durables au sein de votre programme de sécurité. + +## Données et structure des Organisations + +Comme les Organisations ne sont pas scannées directement, le seul champ obligatoire pour les créer est un nom. Au-delà de cela, elles servent de conteneurs pour les Actifs et les Engagements, Tests et Constatations qui en descendent. + +Lors de la création d'une Organisation, réfléchissez à la façon dont sa structure influencera votre reporting. Avez-vous principalement besoin que les Organisations représentent les équipes travaillant sur les projets (Actifs) qu'elles contiendront ? Ou les Organisations représenteraient-elles mieux des projets globaux contenant différentes itérations des projets (Actifs) en leur sein ? + +Si vous disposez d'une seule Organisation contenant toutes les informations pertinentes pour un domaine d'activité ou une équipe de développement donné, le fait de la représenter comme une Organisation facilitera un reporting plus fluide, plutôt que de devoir assembler un rapport à partir de divers Actifs et Organisations. + +Si un projet logiciel particulier comporte de nombreux déploiements ou versions distincts, il peut être utile de créer une seule Organisation couvrant l'ensemble du périmètre du projet et de faire exister chaque version en tant qu'Actif individuel. Dans certains flux de travail, les Organisations peuvent également être utilisées pour séparer les étapes du cycle de vie logiciel : une Organisation pour « En développement », une Organisation pour « En production », etc. + +Les Organisations peuvent servir à déterminer l'accès aux filiales, aux entreprises acquises ou à d'autres unités commerciales réglementées à des fins de RBAC. Dans les entreprises complexes, où il existe de nombreux projets uniques avec des règles d'accès différentes, les Organisations sont particulièrement pertinentes. + +En définitive, la décision quant à la façon d'utiliser les Organisations et les Actifs dépend de la meilleure manière dont vous souhaitez refléter votre structure organisationnelle unique et les besoins de votre équipe de sécurité. + +Voici quelques exemples de structures pour vous aider à déterminer si vos objets doivent être désignés comme des Organisations ou des Actifs. + +- **Organisation** : Division des paiements + - Actif : API de paiement - Production + - Actif : API de paiement - Staging + - Actif : Billing Worker + +- **Organisation** : Produit logiciel A + - Actif : Portail Web + - Actif : Backend mobile + +De plus, voici un guide illustratif permettant de déterminer si un élément est mieux représenté par une Organisation ou par un Actif : + +| Organisations | Actifs | +|--------------|--------| +| Unités commerciales | Applications individuelles | +| Départements | Déploiements/environnements | +| Domaines de responsabilité en matière de sécurité | Composants d'infrastructure | +| Familles de produits | Microservices spécifiques | +| Reporting au niveau du portefeuille | Cibles de scan | +| Clients | Versions logicielles spécifiques | + +Comme indiqué, votre structure peut varier en fonction des besoins de sécurité qui vous sont propres. + +## Accéder aux Organisations + +Les Organisations sont accessibles depuis la barre latérale. Le sous-menu propose également l'option de créer de nouvelles Organisations. + +![image](images/organization_ss1.png) + +### Vue Organisation + +La vue d'une Organisation contient divers tableaux et graphiques permettant d'interpréter son état d'un coup d'œil. Cela inclut : +- **Description** +- **Case à cocher Clé/Critique** + - Cocher Critique ou Clé sert uniquement à des fins de filtrage +- **Liste des Actifs au sein de l'Organisation** +- **Utilisateurs autorisés** (Utilisateurs DefectDojo) + +## Utiliser les Organisations + +### Créer des Organisations + +Il existe deux façons de créer des Organisations : + +- Depuis l'option **Ajouter une Organisation** dans le menu latéral +- Depuis le bouton **Ajouter une Organisation** en haut de la liste Toutes les Organisations + +### Modifier des Organisations + +Les Organisations peuvent être modifiées en cliquant sur **Modifier** dans le menu déroulant situé en haut à droite du tableau Description dans la vue de l'Organisation. Ce même menu est également accessible en cliquant sur le menu kebab ⋮ à gauche de l'Organisation dans la liste Toutes les Organisations. + +Tous les champs modifiables qui en découlent sont également disponibles lors de la création de l'Organisation. + +### Supprimer des Organisations + +La suppression d'une Organisation s'effectue en sélectionnant **Supprimer l'Organisation** dans les paramètres de l'Organisation. + +Étant donné que les Organisations se situent au sommet de la hiérarchie, leur suppression entraîne la suppression de tout l'historique de sécurité en aval, des relations et des objets enfants, tels que : +- Tous les Actifs, Engagements et Tests contenus dans l'Organisation +- Tout l'historique de sécurité associé, y compris les Constatations et les intégrations +- Toutes les Epics Jira liées +- Toutes les notes et tous les fichiers téléversés associés aux Actifs, Engagements et Tests de cette Organisation + +La suppression d'une Organisation est irréversible. Si vous souhaitez « désaffecter » une Organisation sans supprimer les données sous-jacentes (par exemple, pour conserver des enregistrements de tests logiciels historiques à des fins d'audit), vous pouvez modifier le nom de l'Organisation ou ajouter une Étiquette pour indiquer qu'elle est dans un état obsolète. + +## Organisations et métadonnées + +Les Organisations sont destinées à représenter des responsabilités structurelles ou des frontières de reporting, plutôt que des classifications légères. Des attributs tels que le statut de déploiement, les libellés internes ou les états temporaires de flux de travail peuvent être mieux représentés par des étiquettes ou des métadonnées plutôt que par des Organisations distinctes. + +## Frontières des Organisations + +Les Organisations établissent à la fois des frontières de reporting et d'accès au sein de DefectDojo. Comme les intégrations, les permissions RBAC, la propriété, les métriques et les modèles de déduplication héritent fréquemment de la structure des Organisations, définir des frontières claires dès le départ permet d'éviter par la suite une prolifération de la hiérarchie et une fragmentation du reporting. + +### Constatations et automatisation + +Bien que les intégrations soient généralement configurées sur des objets de niveau inférieur tels que les Actifs, les Engagements ou les Constatations, les Organisations définissent malgré tout les frontières de propriété, de reporting et d'accès dans lesquelles ces intégrations opèrent. + +Les permissions se propagent vers le bas, ce qui signifie que l'accès à une Organisation accorde automatiquement l'accès à tous les objets qu'elle contient (par ex., Actifs, Engagements, Tests et Constatations). + +Le modèle RBAC de DefectDojo peut être utilisé pour contrôler l'accès des utilisateurs humains, mais peut également restreindre l'accès des jetons API à des Organisations particulières. + +Pour plus d'informations sur les rôles utilisateur, consultez notre article [Permissions](/admin/user_management/os__authorized_users/). + +### Propriété + +En tant qu'objets de premier niveau, les Organisations impliquent également la propriété des objets enfants qu'elles contiennent. Le suivi des SLA, les flux de remédiation, l'acheminement des tickets et la gouvernance générale fonctionnent tous de manière plus fluide lorsque les Organisations ont été configurées pour refléter fidèlement les personnes responsables de ces dernières. + +### Métriques/Reporting + +Les tableaux de bord de métriques, les tuiles et les vues peuvent être filtrés par Organisation, ce qui en fait un composant essentiel de la façon dont vos données de sécurité sont calculées, visualisées et finalement exportées. + +À des fins de reporting, il est généralement plus simple de combiner plusieurs Organisations en un seul document que de subdiviser une seule Organisation en documents distincts. Nous recommandons donc de configurer les Organisations au niveau de granularité le plus adapté aux rapports de votre équipe. Par exemple, il n'est pas nécessaire de représenter une grande division commerciale comme une Organisation si vous comptez principalement produire des rapports pour les différents départements de cette division. + +Structurer efficacement vos Organisations pour refléter vos besoins de reporting est essentiel pour évaluer avec précision votre posture de sécurité. Pour plus d'informations sur les Métriques, cliquez [ici](/metrics_reports/dashboards/introduction_dashboard/). + +### Déduplication + +La déduplication dans DefectDojo s'effectue au niveau de l'Actif et n'est pas affectée par l'Organisation parente. diff --git a/docs/content/asset_modelling/engagements_tests/OS__organizations.ja.md b/docs/content/asset_modelling/engagements_tests/OS__organizations.ja.md new file mode 100644 index 00000000000..cae590a67a1 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__organizations.ja.md @@ -0,0 +1,139 @@ +--- +title: 組織 +description: DefectDojo OSにおける組織の理解 +audience: opensource +weight: 1 +aliases: +- /ja/asset_modelling/engagements_tests/os_producttype/ +- /ja/en/asset_modelling/engagements_tests/os_producttype/ +--- + +**組織** → アセット → エンゲージメント → テスト → 検出事項 + +## 概要 + +**組織**は、DefectDojoのオブジェクト階層の最上位に位置します。組織は、階層内の下位オブジェクト(アセット、エンゲージメント、テスト、検出事項)とは異なり、技術的なスキャン対象ではなく、主に以下の観点でセキュリティ活動を区分するための組織的な抽象概念として機能します。 +- ビジネスドメイン +- 開発チーム +- セキュリティチーム +- ソフトウェアアプリケーション +- 包括的な製品ファミリー +- 顧客または子会社 +- レポート体制 +- など + +上記の例に共通するテーマは、組織の本質的な役割を示しています。組織は基本的に、セキュリティプログラム内で安定した長期的な境界を表すべきものです。 + +## 組織のデータと構造 + +組織は直接スキャンされる対象ではないため、作成時に必須となるフィールドは名前のみです。それ以外の点では、組織はアセットおよびその下位にあるエンゲージメント、テスト、検出事項を格納するコンテナとして機能します。 + +組織を作成する際は、その構造がレポートにどのような影響を与えるかを考慮してください。組織に含まれるプロジェクト(アセット)に取り組むチームを表すことを主な目的とするのか、それとも組織内に含まれる複数のプロジェクト(アセット)の反復版をまとめた、より包括的なプロジェクトを表す方が適切なのか、検討する必要があります。 + +特定のビジネスドメインや開発チームに関連するすべての情報を1つの組織にまとめられる場合、それを組織として表すことで、複数のアセットや組織からレポートをまとめる手間が省け、より円滑なレポート作成が可能になります。 + +特定のソフトウェアプロジェクトに多数の異なるデプロイメントやバージョンが存在する場合、プロジェクト全体の範囲をカバーする単一の組織を作成し、各バージョンを個別のアセットとして存在させる方法が有効な場合があります。また、ワークフローによっては、組織をソフトウェアのライフサイクル段階を区分するために使用することもできます。たとえば、「開発中」用の組織と「本番稼働中」用の組織を分けて作成する、といった形です。 + +組織は、RBAC(ロールベースアクセス制御)の目的で、子会社、買収した企業、その他の規制対象事業単位へのアクセスを決定するために使用できます。異なるアクセスルールを持つ独自のプロジェクトが多数存在する複雑な事業においては、組織が特に重要な役割を果たします。 + +最終的に、組織とアセットをどのように使い分けるかは、自社独自の組織構造やセキュリティチームのニーズをどのように反映させたいかによって決まります。 + +以下に、オブジェクトを組織またはアセットのどちらに割り当てるかを判断する際の参考となる、構造の例を示します。 + +- **組織**: Payments Division + - アセット: Payments API - Production + - アセット: Payments API - Staging + - アセット: Billing Worker + +- **組織**: Software Product A + - アセット: Web Portal + - アセット: Mobile Backend + +さらに、あるものを組織とアセットのどちらで表すべきかを判断するための参考ガイドを以下に示します。 + +| 組織 | アセット | +|--------------|--------| +| 事業部門 | 個々のアプリケーション | +| 部署 | デプロイメント/環境 | +| セキュリティ所有ドメイン | インフラストラクチャコンポーネント | +| 製品ファミリー | 特定のマイクロサービス | +| ポートフォリオレベルのレポート | スキャン対象 | +| 顧客 | 特定のソフトウェアバージョン | + +前述のとおり、構造は各組織固有のセキュリティニーズによって異なる場合があります。 + +## 組織へのアクセス + +組織にはサイドバーからアクセスできます。サブメニューには、新しい組織を作成するオプションも用意されています。 + +![image](images/organization_ss1.png) + +### 組織ビュー + +組織のビューには、その状態を一目で把握できるよう、さまざまな表やグラフが含まれています。具体的には以下のとおりです。 +- **説明** +- **キー/重大チェックボックス** + - 「重大」または「キー」にチェックを入れることは、フィルタリング目的にのみ使用されます +- **組織内のアセットのリスト** +- **認可されたユーザー**(DefectDojoのユーザー) + +## 組織の操作 + +### 組織の作成 + +組織を作成する方法は2つあります。 + +- サイドメニューの**組織を追加**オプションから +- 全組織一覧の上部にある**組織を追加**ボタンから + +### 組織の編集 + +組織は、組織ビューの説明テーブル右上にあるドロップダウンメニューから**編集**をクリックすることで編集できます。同じメニューには、全組織一覧で組織の左側にある⋮(縦三点)メニューをクリックしてもアクセスできます。 + +編集可能な各フィールドは、組織の作成時にも同様に利用できます。 + +### 組織の削除 + +組織は、組織の設定から**組織を削除**を選択することで削除できます。 + +組織は階層の最上位に位置するため、削除するとその下位にあるすべてのセキュリティ履歴、関連性、および子オブジェクトが削除されます。具体的には以下が含まれます。 +- 組織内に含まれるすべてのアセット、エンゲージメント、テスト +- 検出事項やインテグレーションを含む、関連するすべてのセキュリティ履歴 +- リンクされているすべてのJira Epic +- その組織内のアセット、エンゲージメント、テストに関連するすべてのメモおよびアップロードファイル + +組織の削除は元に戻せません。基盤となるデータを削除せずに組織を「廃止」したい場合(たとえば、監査目的でレガシーソフトウェアのテスト記録を保持したい場合など)は、組織の名前を変更するか、非推奨状態であることを示すタグを追加することができます。 + +## 組織とメタデータ + +組織は、軽量な分類ではなく、構造的な所有権やレポート境界を表すことを目的としています。デプロイメントの状態、内部ラベル、一時的なワークフロー状態といった属性は、個別の組織として表すよりも、タグやメタデータで表す方が適切な場合があります。 + +## 組織の境界 + +組織は、DefectDojo内でレポートとアクセスの両方の境界を確立します。インテグレーション、RBAC権限、所有権、メトリクス、重複排除モデルは組織の構造を引き継ぐことが多いため、早い段階で明確な境界を設計しておくことで、後々の階層の肥大化やレポートの断片化を防ぐことができます。 + +### 検出事項と自動化 + +インテグレーションは通常、アセット、エンゲージメント、検出事項といった下位のオブジェクトで設定されますが、それらのインテグレーションが機能する際の所有権、レポート、アクセスの境界を定義するのは、依然として組織です。 + +権限は下位に継承されるため、ある組織へのアクセス権を持つと、その組織内のすべてのオブジェクト(アセット、エンゲージメント、テスト、検出事項など)へのアクセス権が自動的に付与されます。 + +DefectDojoのRBACモデルは、人間のユーザーによるアクセスを制御するために使用できるだけでなく、APIトークンが特定の組織にアクセスできる範囲を制限するためにも使用できます。 + +ユーザーロールの詳細については、[権限](/admin/user_management/os__authorized_users/)の記事を参照してください。 + +### 所有権 + +組織は最上位のオブジェクトであるため、その内部の子オブジェクトに対する所有権も暗黙的に示します。組織が、その責任を負う担当者を正確に反映するように設定されている場合、SLA追跡、修復ワークフロー、チケットのルーティング、全般的なガバナンスがより円滑に機能します。 + +### メトリクス/レポート + +メトリクスダッシュボード、タイル、ビューは組織ごとにフィルタリングできるため、セキュリティデータの算出、可視化、そして最終的なエクスポートの方法において、組織は重要な役割を果たします。 + +レポート作成の観点では、一般的に、単一の組織を複数のドキュメントに分割するよりも、複数の組織を1つのドキュメントにまとめる方が簡単です。そのため、チームのレポートに適した粒度で組織を設定することをお勧めします。たとえば、主に大規模な事業部門内の各部署ごとにレポートを作成する予定であれば、その事業部門全体を1つの組織として表す必要はありません。 + +レポートのニーズを反映するように組織を効果的に構造化することは、セキュリティ体制を正確に評価する上で重要です。メトリクスの詳細については、[こちら](/metrics_reports/dashboards/introduction_dashboard/)をクリックしてください。 + +### 重複排除 + +DefectDojoにおける重複排除はアセットレベルで行われ、親組織の影響を受けません。 diff --git a/docs/content/asset_modelling/engagements_tests/OS__tests.de.md b/docs/content/asset_modelling/engagements_tests/OS__tests.de.md new file mode 100644 index 00000000000..dceed38d2ab --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__tests.de.md @@ -0,0 +1,274 @@ +--- +title: Tests +description: Tests in DefectDojo OS verstehen +audience: opensource +weight: 4 +--- + +Organisationen → Assets → Engagements → **TESTS** → Befunde + +## Überblick + +Ein Test ist ein Container für eine oder mehrere Scan-Ausführungen, mit denen Schwachstellen in einem Produkt aufgedeckt werden. Tests sind die letzte, feingranularste Komponente der Produkthierarchie von DefectDojo und dienen als Container für die Befunde, die aus der Ausführung eines Sicherheitstools oder einer manuellen Bewertung resultieren. Gleichzeitig liefern sie den Kontext, in dem solche Befunde gefunden wurden (z. B. welches Tool sie gemeldet hat, wann dieses Tool zuletzt ausgeführt wurde usw.). + +Beispiele für Tests sind: +- Static Application Security Testing +- Dynamic Application Security Testing +- Software Composition Analysis +- Container-Sicherheitsscans +- Infrastruktur-/Netzwerkscans +- Manuelle Penetrationstests +- CI/CD-Pipeline-Scans + +### Testarten + +Es gibt zwei primäre Möglichkeiten, Tests in DefectDojo zu erstellen: +1. **Herstellerspezifische Parser** (z. B. Burp, OWASP ZAP, Acunetix, Invicti) +2. **Generic Findings Import** + +Je nach Konfiguration und Deduplizierungsstrategie kann jede Methode neue Tests erstellen oder Befunde in bestehende Tests reimportieren. + +Auch wenn sich die Methoden vor allem darin unterscheiden, wie Scan-Daten geparst und aufgenommen werden, führen sie letztlich alle dazu, dass Befunde einem Test zugeordnet werden. + +#### Parser + +**Parser** sind Komponenten, die bestimmte Scan-Ausgabeformate (z. B. XML, JSON, CSV) verarbeiten und sie auf das interne Befund-Modell von DefectDojo abbilden. Beim Import von Scan-Ergebnissen verwendet DefectDojo den ausgewählten Parser, um Befunde zu extrahieren und sie einem neu erstellten oder bestehenden Test zuzuordnen. + +#### Generic Findings Import + +Wenn für ein bestimmtes Tool kein nativer Parser existiert, ermöglicht **Generic Findings Import** den Import von Befunden über ein standardisiertes JSON- oder CSV-Schema, unabhängig von der ursprünglichen Quelle. + +DefectDojo parst die bereitgestellten Daten, erstellt einen neuen Test (oder importiert in einen bestehenden) und ordnet die Befunde zu. Basierend auf dem optionalen Feld `type` des Reports wird außerdem ein entsprechender Test-Typ erstellt: Wird `type` weggelassen (oder entspricht es dem Scan-Typ), lautet der Test-Typ „Generic Findings Import“; wird `type` angegeben, wird daraus „{type} Scan (Generic Findings Import)“ (ein `type`, der bereits auf das Suffix „(Generic Findings Import)“ endet, wird unverändert übernommen). + +| | **Native Parser** | **Generic Findings Import** | +|----------|---------------|------------------------| +| **Primärer Zweck** | Verarbeitung der Ausgaben unterstützter Tools | Import nicht unterstützter/benutzerdefinierter Daten über ein festes Schema | +| **Eingabeformat** | Tool-spezifisch (z. B. ZAP XML, SARIF) | Striktes JSON-/CSV-Schema | +| **Wer übernimmt die Normalisierung** | DefectDojo (integrierter Parser) | Benutzer (muss dem Schema entsprechen) | +| **Auslöser für Testerstellung** | Manueller Upload oder API-Import | Manueller Upload oder API-Import | +| **Test-Typ** | Vordefiniert (z. B. „ZAP Scan“) | Automatisch erstellter „Generic“-Typ | +| **Einrichtungsaufwand** | Gering | Moderat (Datentransformation erforderlich) | +| **Flexibilität** | Gering (nur unterstützte Tools) | Mittel | +| **Automatisierungsgrad** | Gering–Moderat | Gering–Moderat | +| **Typischer Anwendungsfall** | Standard-Scanner (SAST, DAST, SCA) | Benutzerdefinierte Skripte, nicht unterstützte Tools | + +Unabhängig von der Importmethode werden alle Scan-Daten in DefectDojo letztlich als Befunde dargestellt, die einem Test zugeordnet sind, der als Einheit für Ausführung und Lebenszyklus-Tracking dient. + +### Testdaten + +Tests speichern eine Vielzahl von Metadaten, die dabei helfen, verschiedene Komponenten jeder Testaktivität zu dokumentieren, wie zum Beispiel: +- Testtitel / -name +- Testtyp +- Testbeschreibung / -notizen +- Start- und Enddatum +- Die Umgebung, in der der Test ausgeführt wurde (z. B. Development, Staging, Pre-Production, Production usw.) +- Version / Branch / Build-ID / Commit-Hash +- API-Scan-Konfiguration +- Zusätzliche Dateien, die für spätere Audits oder Reimporte verwendet werden können +- Das übergeordnete Engagement, Asset und die Organisation +- Import- und Reimport-Historie + +Jeder Test führt eine Import-Historie, in der alle mit dem Test verbundenen Scan-Importe und -Reimporte erfasst werden. Dazu gehören Metadaten wie Scan-Datum, Version, Branch, Commit-Hash und Build-ID. + +Diese Historie sorgt für Nachvollziehbarkeit über mehrere Scan-Ausführungen innerhalb desselben Tests hinweg. + +### Berechtigungen + +Mehrere Tests können in einem einzelnen Engagement gespeichert werden, und Engagements werden innerhalb von Produkten gespeichert. Daher gewährt der Zugriff auf ein Produkt automatisch Zugriff auf alle Tests (und Engagements) innerhalb dieses Produkts. Tests verfügen nicht über eigene Zugriffskontrolllisten. + +### Zugriff auf Tests + +Obwohl Tests in DefectDojo OS als eigenständiges Objekt existieren, gibt es für sie keinen eigenen Bereich in der Benutzeroberfläche. Daher ist jeder Test in erster Linie über das Produkt und/oder Engagement zugänglich, das ihn enthält. + +### Testansicht + +Die Testansicht enthält eine Vielzahl von Tabellen, darunter das übergeordnete Engagement, die Import- und Reimport-Historie, eine Liste der im Test enthaltenen Befunde sowie etwaige Befundgruppen. + +Zudem gibt es Tabellen für potenzielle Befunde, Dateien und Notizen, die alle manuell hinzugefügt werden können. + +#### Testeinstellungen + +In jeder Testansicht stehen folgende Einstellungen zur Verfügung: +- **Test bearbeiten** + - Ermöglicht die Bearbeitung von Testdaten wie Titel, Zeitplan, Umgebung und weiteren Details. +- **Test kopieren** + - Dupliziert einen Test einschließlich aller zugehörigen Metadaten und Befunde und ermöglicht es, ihn einem anderen Engagement zuzuordnen. +- **Scan erneut hochladen** + - Startet den Reimport-Prozess. Weitere Informationen zum Reimport finden Sie später in diesem Artikel. +- **Notizen hinzufügen** + - Ermöglicht es dem Benutzer, eine Notiz hinzuzufügen. Am unteren Rand der Seite befindet sich außerdem eine Notizen-Tabelle. + - Eine Notiz kann als Privat markiert werden; in diesem Fall wird sie nicht an Jira übertragen und nicht in Berichte oder Exporte von Befunden aufgenommen. +- **Bericht** + - Startet den Prozess zur Erstellung eines Berichts, bei dem zahlreiche Filter angewendet werden können, um einen Bericht zu erstellen, der nur die gefilterten Befunde enthält. +- **Zum Kalender hinzufügen** + - Lädt eine .ics-Datei des gewählten Tests herunter, die Sie zu einer externen Kalenderanwendung hinzufügen können. +- **Verlauf anzeigen** + - Öffnet einen Verlauf der am Test vorgenommenen Änderungen zu Tracking-, Berichts- und Auditzwecken. + +## Arbeiten mit Tests + +### Tests erstellen + +Tests können automatisch erstellt werden, wenn Scan-Daten direkt in ein Engagement importiert werden, wodurch ein neuer Test mit den Scan-Daten entsteht. Tests können auch im Vorgriff auf die Planung zukünftiger Engagements erstellt werden oder für manuell erfasste Sicherheitsbefunde, die Tracking und Behebung erfordern. + +#### Manuelle Workflows + +Es gibt mehrere Möglichkeiten, einen Test in der OS-Version zu erstellen: + +- Wählen Sie ein Produkt aus und klicken Sie im Menü „Befunde“ der Navigationsleiste auf „Scan-Ergebnisse importieren“ + - Dadurch wird ein Ad-hoc-Engagement erstellt, das den Test enthält + +![image](images/tests_ss5.png) + +- Wählen Sie ein Engagement innerhalb eines Produkts aus, klicken Sie auf das Dropdown-Menü im Bereich „Tests“ und klicken Sie entweder auf „Tests hinzufügen“ oder „Scan-Ergebnisse importieren“ + - Dadurch wird der resultierende Test direkt innerhalb des gewählten Engagements erstellt + +![image](images/tests_ss6.png) + +- Beim Erstellen eines Engagements + +![image](images/tests_ss7.png) + +Mit der dritten oben genannten Methode können Sie beim Erstellen eines Engagements Folgendes tun: + +- Scan-Ergebnisse sofort importieren +- Eine Test-Hülle erstellen (in die Sie später einen Scan importieren) +- Keines von beidem tun und das Engagement einfach durch Klicken auf „Fertig“ erstellen + +Sie haben die Möglichkeit, beim Importieren eines Scans oder beim Erstellen einer Test-Hülle Metadaten hinzuzufügen. Alle Metadaten werden im Bereich „Import-Historie“ der Testansicht angezeigt. + +#### Automatisierte Workflows + +In automatisierten Workflows können Tests programmatisch als Teil des Scan-Importprozesses erstellt werden, sodass Pipelines Ergebnisse hochladen können, ohne dass zuvor manuell ein Test erstellt werden muss. + +Wenn Sie die API zum Importieren von Scan-Ergebnissen verwenden, kann automatisch ein neuer Test erstellt werden, indem Sie ein Engagement anstelle eines Tests angeben. + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +Aufgrund der obigen Angaben wird ein neuer Test unter dem angegebenen Engagement erstellt, und die Scan-Ergebnisse werden diesem Test zugeordnet. + +Wird stattdessen eine `test`-ID angegeben, werden die Scan-Ergebnisse zu einem bestehenden Test hinzugefügt, was bei Reimport-Workflows üblich ist. + +### Tests bearbeiten + +Tests können bearbeitet werden, indem Sie entweder in der Tests-Tabelle der Ansicht des übergeordneten Engagements über das ⋮-Kebab-Menü auf **Test bearbeiten** klicken, oder über das Einstellungsmenü in der Testansicht. Alle daraufhin bearbeitbaren Felder stehen auch bei der Erstellung des Tests zur Verfügung. + +![image](images/tests_ss24.png) + +![image](images/tests_ss12.png) + +#### Befunde manuell zu einem Test hinzufügen + +Ein Befund kann manuell zu einem Test hinzugefügt werden, indem Sie entweder im ⋮-Kebab-Menü neben dem Test in der Ansicht des übergeordneten Engagements auf **Befund zu Test hinzufügen** klicken, oder über die Einstellungen der Befunde-Tabelle in der Testansicht. + +![image](images/tests_ss29.png) + +![image](images/tests_ss30.png) + +### Tests löschen + +Um einen Test zu löschen, wählen Sie **Test löschen** entweder im ⋮-Kebab-Menü neben dem Test in der Ansicht des übergeordneten Engagements oder im Einstellungsmenü der Testansicht aus. Diese Aktion kann nicht rückgängig gemacht werden. + +Beim Löschen eines Tests werden auch alle darin enthaltenen Befunde gelöscht. + +![image](images/tests_ss25.png) + +![image](images/tests_ss26.png) + +## Reimport + +Das Reimportieren von Scans innerhalb von Tests ist grundlegend für eine effektive Deduplizierung. Wenn Scan-Ergebnisse in denselben Test reimportiert werden: + +- Bestehende Befunde können aktualisiert werden +- Doppelte Befunde können unterdrückt werden +- Neue Befunde können erstellt werden, wenn keine Übereinstimmung gefunden wird + +Dieses Verhalten hängt von den konfigurierten Deduplizierungsregeln und dem Scan-Typ ab. + +Wird ein neuer Test erstellt, anstatt in einen bestehenden zu reimportieren, kann dies dazu führen, dass doppelte Befunde erstellt statt aktualisiert werden. + +#### Reimport vs. Import + +Reimport wird typischerweise verwendet, wenn: + +- Wiederkehrende Scans gegen dasselbe Ziel durchgeführt werden +- Die Entwicklung von Befunden im Zeitverlauf nachverfolgt wird +- Eine kontinuierliche Sicht auf die Sicherheitslage der Anwendung aufrechterhalten wird + +Im Gegensatz dazu eignet sich der Import (Erstellung eines neuen Tests) eher für einmalige oder unabhängige Scan-Ausführungen. + +### Reimportieren von Scan-Ergebnissen (UI) + +Um neue Daten zu einem bestehenden Test hinzuzufügen, klicken Sie entweder im ⋮-Kebab-Menü neben dem Test in der Ansicht des übergeordneten Engagements auf **Scan-Ergebnisse erneut hochladen**, oder klicken Sie im Einstellungsmenü der Testansicht auf **Scan erneut hochladen**. + +![image](images/tests_ss27.png) + +![image](images/tests_ss10.png) + +Beim Ausfüllen des Reimport-Scan-Formulars haben Sie die Möglichkeit, Metadaten für den reimportierten Scan zu aktualisieren, einschließlich Version, Branch-Tag, Commit-Hash und Build-ID. + +Diese Änderungen werden im Bereich „Import-Historie“ der Testansicht angezeigt, der auch dieselben Metadaten aus vorherigen Scan-Importen enthält. + +Im folgenden Screenshot beispielsweise wurden Branch-Tag, Build-ID, Commit-Hash und Version zwischen dem ursprünglichen Import und dem anschließenden Reimport alle manuell aktualisiert. + +![image](images/tests_ss28.png) + +Um die Metadaten des zuletzt reimportierten Scans zu bearbeiten, folgen Sie den vorherigen Anweisungen im Abschnitt „Tests bearbeiten“ oben und aktualisieren Sie die Metadaten nach Bedarf. Es können nur die Metadaten des jeweils letzten Imports bearbeitet werden. + +### Reimportieren von Scan-Ergebnissen (API) + +Wenn Tests über eine CI/CD-Pipeline erstellt oder aktualisiert werden, können Sie Metadaten aus dem Pipeline-Lauf einbeziehen, damit Tests korrekt mit dem gescannten Code verknüpft werden können. Dadurch können Sie: +- Scan-Ergebnisse einem bestimmten Commit oder Branch zuordnen. +- Nachverfolgen, wie sich Befunde im Zuge von Codeänderungen entwickeln. +- Die Deduplizierung verbessern, indem Sie nachvollziehen, wann sich zwei Scans auf dieselbe oder unterschiedliche Codeversionen beziehen. +- Die Auditierbarkeit unterstützen, indem genau gezeigt wird, welcher Code wann gescannt wurde. + +Die API von DefectDojo akzeptiert diese Werte während des Imports oder Reimports, sodass sie als Teil des Scan-Imports gespeichert und in der Import-Historie des Tests angezeigt werden können. Diese Metadaten können verwendet werden, um Commit-Hashes oder andere relevante Repository-Informationen im Zusammenhang mit einem CI/CD-Lauf zu identifizieren. + +#### Unterstützte Metadatenfelder + +Die API unterstützt eine definierte Reihe von Metadatenfeldern, die beim Reimport angegeben werden können. Dazu gehören: + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- `active / verified` flags + +Diese Felder stellen den primären Mechanismus dar, um während eines Reimport-Vorgangs kontextbezogene Metadaten anzuhängen. + +In automatisierten Pipelines gehören zu den am häufigsten bereitgestellten Metadaten: +- build_id (CI-Job-Kennung) +- commit_hash (Versionskontroll-Referenz) +- branch_tag (Branch- oder Umgebungskontext) +- tags (z. B. nightly, staging, production) + +Diese Felder sorgen für Nachvollziehbarkeit über mehrere Scans hinweg, ohne dass ein manueller Eingriff erforderlich ist. + +Obwohl Metadaten manuell über das Reimport-Scan-Formular aktualisiert werden können, erledigen die meisten automatisierten Umgebungen dies, indem sie direkt den Endpunkt `/api/v2/reimport-scan/` aufrufen. Dieser Ansatz ermöglicht es der Pipeline, Metadaten beim Reimport automatisch anzuhängen. + +##### API-Reimport mit Metadaten + +curl -X POST `"https:///api/v2/reimport-scan/"` \ + -H `"Authorization: Token "` \ + -F `"test=123"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` \ + -F `"tags=nightly,api-scan"` \ + -F `"version=1.4.2"` \ + -F `"build_id=jenkins-842"` \ + -F `"branch_tag=main"` \ + -F `"commit_hash=a1b2c3d4"` + +##### Metadaten, Reimport und geplante Scans + +Scans können auch so geplant werden, dass sie in regelmäßigen Abständen ausgeführt werden, etwa ausgelöst durch Cron-Jobs. Geplante Scans sind nicht an Repository-Aktivitäten gebunden, wodurch Metadaten wie Commit-Hashes oder Branch-Namen irrelevant werden, sofern sie nicht explizit vom Skript selbst eingefügt werden. Dennoch kann die Verwendung von Reimport sinnvoll sein, wenn Sie einen fortlaufenden Verlauf Ihrer Sicherheitslage innerhalb eines einzelnen Tests führen möchten. diff --git a/docs/content/asset_modelling/engagements_tests/OS__tests.es.md b/docs/content/asset_modelling/engagements_tests/OS__tests.es.md new file mode 100644 index 00000000000..ed36504ff19 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__tests.es.md @@ -0,0 +1,274 @@ +--- +title: Tests +description: Cómo entender los Tests en DefectDojo OS +audience: opensource +weight: 4 +--- + +Organizaciones → Activos → Compromisos → **TESTS** → Hallazgos + +## Resumen + +Un Test es un contenedor de una o más ejecuciones de escaneo, que se utilizan para descubrir fallos en un Producto. Los Tests son el componente final y más granular de la jerarquía de productos de DefectDojo, y sirven como contenedor de los Hallazgos que resultan de la ejecución de una herramienta de seguridad o de una evaluación manual, además de añadir el contexto en el que se encontraron dichos Hallazgos (es decir, qué herramienta lo reportó, cuándo se ejecutó esa herramienta por última vez, etc.). + +Algunos ejemplos de Tests incluyen: +- Pruebas estáticas de seguridad de aplicaciones +- Pruebas dinámicas de seguridad de aplicaciones +- Análisis de composición de software +- Escaneos de seguridad de contenedores +- Escaneos de infraestructura / red +- Tests de penetración manuales +- Escaneos de pipelines de CI/CD + +### Tipos de Test + +Existen dos formas principales de crear Tests en DefectDojo: +1. **Parsers específicos de proveedor** (por ejemplo, Burp, OWASP ZAP, Acunetix, Invicti) +2. **Generic Findings Import** + +Cada método puede crear nuevos Tests o reimportar Hallazgos en Tests existentes, según la configuración y la estrategia de deduplicación. + +Aunque cada método difiere principalmente en la forma en que se analizan e ingieren los datos de escaneo, todos ellos terminan asociando Hallazgos a un Test. + +#### Parsers + +Los **Parsers** son componentes que procesan formatos de salida de escaneo específicos (por ejemplo, XML, JSON, CSV) y los asignan al modelo interno de Hallazgos de DefectDojo. Cuando se importan resultados de escaneo, DefectDojo utiliza el parser seleccionado para extraer los Hallazgos y adjuntarlos a un Test nuevo o existente. + +#### Generic Findings Import + +Cuando no existe un parser nativo para una herramienta determinada, **Generic Findings Import** le permite importar hallazgos utilizando un esquema JSON o CSV estandarizado, independientemente del origen original. + +DefectDojo analiza los datos proporcionados, crea un nuevo Test (o los importa en uno existente) y adjunta los Hallazgos. También se crea un Test Type correspondiente en función del campo opcional `type` del informe: cuando se omite `type` (o es igual al scan type) el Test Type es “Generic Findings Import”; cuando se proporciona `type` se convierte en “{type} Scan (Generic Findings Import)” (un `type` que ya termina con el sufijo “(Generic Findings Import)” se utiliza tal cual). + +| | **Native Parsers** | **Generic Findings Import** | +|----------|---------------|------------------------| +| **Propósito principal** | Ingerir las salidas de herramientas compatibles | Ingerir datos no compatibles/personalizados mediante un esquema fijo | +| **Formato de entrada** | Específico de la herramienta (por ejemplo, ZAP XML, SARIF) | Esquema JSON/CSV estricto | +| **Quién gestiona la normalización** | DefectDojo (parser integrado) | Usuario (debe ajustarse al esquema) | +| **Disparador de creación de Test** | Carga manual o importación por API | Carga manual o importación por API | +| **Test Type** | Predefinido (por ejemplo, "ZAP Scan") | Tipo "Generic" creado automáticamente | +| **Esfuerzo de configuración** | Bajo | Moderado (requiere transformación de datos) | +| **Flexibilidad** | Baja (solo herramientas compatibles) | Media | +| **Nivel de automatización** | Bajo-Moderado | Bajo-Moderado | +| **Caso de uso típico** | Escáneres estándar (SAST, DAST, SCA) | Scripts personalizados, herramientas no compatibles | + +Independientemente del método de ingesta, todos los datos de escaneo en DefectDojo se representan finalmente como Hallazgos adjuntos a un Test, que sirve como unidad de ejecución y de seguimiento del ciclo de vida. + +### Datos del Test + +Los Tests almacenan una variedad de metadatos que ayudan a documentar los distintos componentes de cada esfuerzo de prueba, tales como: +- Título / nombre del Test +- Tipo de Test +- Descripción / notas del Test +- Fecha de inicio y finalización +- El Entorno en el que se ejecutó el Test (por ejemplo, Development, Staging, Pre-Production, Production, etc.) +- Versión / Branch / Build ID / Commit Hash +- Configuración de escaneo de la API +- Archivos adicionales que se pueden usar para auditorías o reimportaciones posteriores +- El Compromiso, Activo y Organización principal +- Historial de importación y reimportación + +Cada Test mantiene un historial de importación, que registra todas las importaciones y reimportaciones de escaneo asociadas con el Test. Esto incluye metadatos como la fecha de escaneo, la versión, el branch, el commit hash y el build ID. + +Este historial proporciona trazabilidad entre múltiples ejecuciones de escaneo dentro del mismo Test. + +### Permisos + +Se pueden almacenar varios Tests dentro de un mismo Compromiso, y los Compromisos se almacenan dentro de Productos. Por lo tanto, el acceso a un Producto otorga automáticamente acceso a todos los Tests (y Compromisos) dentro de ese Producto. Los Tests no cuentan con listas de control de acceso independientes. + +### Acceso a los Tests + +Aunque los Tests existen como un objeto independiente en DefectDojo OS, no cuentan con una sección específica dedicada a ellos dentro de la interfaz. Por ello, cada Test es accesible principalmente a través del Producto y/o el Compromiso que lo contiene. + +### Vista del Test + +La vista del Test alberga diversas tablas, incluyendo el Compromiso principal, el historial de importación y reimportación, una lista de los Hallazgos contenidos en el Test, así como cualquier Grupo de Hallazgos. + +También hay tablas para Hallazgos Potenciales, Archivos y Notas, todas las cuales se pueden agregar manualmente. + +#### Configuración del Test + +Los siguientes ajustes están disponibles en cada vista de Test: +- **Edit Test** + - Permite editar los datos del Test, como el título, la programación, el entorno y otros diversos detalles. +- **Copy Test** + - Duplica un Test, junto con todos los metadatos y Hallazgos asociados, y permite atribuirlo a un Compromiso diferente. +- **Re-Upload Scan** + - Inicia el proceso de reimportación. Más información sobre la reimportación se encuentra más adelante en este artículo. +- **Add Notes** + - Permite al usuario agregar una Nota. También hay una tabla de Notas en la parte inferior de la página. + - Una Nota se puede marcar como Privada, en cuyo caso se evita que se envíe a Jira, a los Informes y a las exportaciones de Hallazgos. +- **Report** + - Inicia el proceso de generación de un Informe, en el que se pueden aplicar múltiples filtros para crear un informe únicamente con los Hallazgos filtrados. +- **Add To Calendar** + - Descarga un archivo .ics del Test elegido que se puede agregar a su aplicación de calendario de terceros. +- **View History** + - Abre un historial de las ediciones realizadas al Test con fines de seguimiento, generación de informes y auditoría. + +## Trabajar con Tests + +### Crear Tests + +Los Tests se pueden crear automáticamente cuando los datos de escaneo se importan directamente en un Compromiso, lo que da como resultado un nuevo Test que contiene los datos de escaneo. Los Tests también se pueden crear anticipándose a la planificación de futuros Compromisos, o para hallazgos de seguridad introducidos manualmente que requieran seguimiento y remediación. + +#### Flujos de trabajo manuales + +Existen varias formas de crear un Test en la versión OS: + +- Seleccione un Producto y haga clic en “Import Scan Results” en el menú de Hallazgos de la barra de navegación + - Esto creará un Compromiso ad hoc para contener el Test + +![image](images/tests_ss5.png) + +- Seleccione un Compromiso dentro de un Producto, haga clic en el menú desplegable de la subsección Tests y haga clic en “Add Tests” o en “Import Scan Results” + - Esto creará el Test resultante directamente dentro del Compromiso elegido + +![image](images/tests_ss6.png) + +- Al crear un Compromiso + +![image](images/tests_ss7.png) + +Con el tercer método anterior, puede realizar lo siguiente al crear un Compromiso: + +- Importar inmediatamente los resultados del escaneo +- Crear un Test vacío (en el que posteriormente importará un escaneo) +- No hacer ninguna de las dos cosas y simplemente crear el Compromiso haciendo clic en “Done” + +Tendrá la oportunidad de agregar metadatos tanto al importar un escaneo como al crear un Test vacío. Cualquier metadato se reflejará en la sección Import History de la vista del Test. + +#### Flujos de trabajo automatizados + +En los flujos de trabajo automatizados, los Tests se pueden crear mediante programación como parte del proceso de importación de escaneo, lo que permite que los pipelines carguen resultados sin necesidad de crear un Test manualmente de antemano. + +Al usar la API para importar resultados de escaneo, se puede crear un nuevo Test automáticamente proporcionando un engagement en lugar de un test. + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +Dado lo anterior, se crea un nuevo Test bajo el Compromiso especificado, y los resultados del escaneo se adjuntan a ese Test. + +Si en su lugar se proporciona un ID de `test`, los resultados del escaneo se agregarán a un Test existente, lo cual es habitual en los flujos de trabajo de reimportación. + +### Editar Tests + +Los Tests se pueden editar haciendo clic en **Edit Test** desde el menú de tres puntos (⋮) en la tabla Tests dentro de la vista del Compromiso principal, o desde el menú de configuración dentro de la vista del Test. Todos los campos que se pueden editar posteriormente también están disponibles al crear el Test. + +![image](images/tests_ss24.png) + +![image](images/tests_ss12.png) + +#### Agregar Hallazgos manualmente a un Test + +Un Hallazgo se puede agregar manualmente a un Test haciendo clic en **Add Finding to Test** desde el menú de tres puntos (⋮) junto al Test en la vista del Compromiso principal, o desde la configuración de la tabla Findings en la vista del Test. + +![image](images/tests_ss29.png) + +![image](images/tests_ss30.png) + +### Eliminar Tests + +Para eliminar un Test, seleccione **Delete Test** en el menú de tres puntos (⋮) junto al Test en la vista del Compromiso principal, o en el menú de configuración dentro de la vista del Test. Esta acción no se puede deshacer. + +Eliminar un Test también eliminará cualquier Hallazgo contenido en ese Test. + +![image](images/tests_ss25.png) + +![image](images/tests_ss26.png) + +## Reimportación + +Reimportar escaneos dentro de los Tests es fundamental para una deduplicación eficaz. Cuando los resultados de un escaneo se reimportan en el mismo Test: + +- Los Hallazgos existentes pueden actualizarse +- Los Hallazgos duplicados pueden suprimirse +- Se pueden crear nuevos Hallazgos si no se encuentra una coincidencia + +Este comportamiento depende de las reglas de deduplicación configuradas y del tipo de escaneo. + +Crear un nuevo Test en lugar de reimportar en uno existente puede provocar que se creen Hallazgos duplicados en lugar de actualizarlos. + +#### Reimportación frente a Importación + +La reimportación se utiliza normalmente cuando: + +- Se ejecutan escaneos recurrentes contra el mismo objetivo +- Se realiza un seguimiento de cómo evolucionan los Hallazgos a lo largo del tiempo +- Se mantiene una vista continua de la postura de seguridad de la aplicación + +En cambio, importar (crear un nuevo Test) es más adecuado para ejecuciones de escaneo puntuales o independientes. + +### Reimportación de resultados de escaneo (UI) + +Para agregar nuevos datos a un Test existente, puede hacer clic en **Re-Upload Scan Results** desde el menú de tres puntos (⋮) junto al Test en la vista del Compromiso principal, o hacer clic en **Re-Upload Scan** en el menú de configuración dentro de la vista del Test. + +![image](images/tests_ss27.png) + +![image](images/tests_ss10.png) + +Al completar el formulario Reimport Scan, tendrá la opción de actualizar los metadatos del escaneo que se está reimportando, incluidos la versión, el branch tag, el commit hash y el build ID. + +Estos cambios se reflejan en la sección Import History de la vista del Test, que también incluirá los mismos metadatos de importaciones de escaneo anteriores. + +Por ejemplo, en la siguiente captura de pantalla, el branch tag, el build ID, el commit hash y la versión se actualizaron manualmente entre la importación inicial y la reimportación posterior. + +![image](images/tests_ss28.png) + +Para editar los metadatos del escaneo reimportado más recientemente, siga las instrucciones anteriores de la sección Editar Tests y actualice los metadatos según lo desee. Solo se pueden editar los metadatos de la importación más reciente. + +### Reimportación de resultados de escaneo (API) + +Cuando los Tests se crean o actualizan mediante un pipeline de CI/CD, puede incluir metadatos de la ejecución del pipeline para que los Tests se vinculen correctamente con el código que escanearon. Esto le permite: +- Asociar los resultados del escaneo con un commit o branch específico. +- Realizar un seguimiento de cómo evolucionan los Hallazgos a través de los cambios de código. +- Mejorar la Deduplicación al comprender cuándo dos escaneos se aplican a la misma versión del código o a versiones diferentes. +- Facilitar la auditabilidad al mostrar exactamente qué código se escaneó y cuándo. + +La API de DefectDojo acepta estos valores durante la importación o reimportación para que puedan almacenarse como parte de la importación del escaneo y reflejarse en el historial de importación del Test. Estos metadatos se pueden usar para identificar commit hashes o cualquier información relevante del repositorio asociada con una ejecución de CI/CD. + +#### Campos de metadatos admitidos + +La API admite un conjunto definido de campos de metadatos que se pueden incluir durante la reimportación. Estos incluyen: + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- Indicadores `active / verified` + +Estos campos representan el mecanismo principal para adjuntar metadatos contextuales durante una operación de reimportación. + +En los pipelines automatizados, los metadatos que se proporcionan con mayor frecuencia incluyen: +- build_id (identificador del job de CI) +- commit_hash (referencia de control de código fuente) +- branch_tag (contexto de branch o entorno) +- tags (por ejemplo, nightly, staging, production) + +Estos campos proporcionan trazabilidad entre escaneos sin necesidad de intervención manual. + +Aunque los metadatos se pueden actualizar manualmente mediante el formulario Reimport Scan, la mayoría de los entornos automatizados lo gestionan llamando directamente al endpoint `/api/v2/reimport-scan/`. Este enfoque permite que el pipeline adjunte automáticamente los metadatos al reimportar. + +##### Reimportación por API con metadatos + +curl -X POST `"https:///api/v2/reimport-scan/"` \ + -H `"Authorization: Token "` \ + -F `"test=123"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` \ + -F `"tags=nightly,api-scan"` \ + -F `"version=1.4.2"` \ + -F `"build_id=jenkins-842"` \ + -F `"branch_tag=main"` \ + -F `"commit_hash=a1b2c3d4"` + +##### Metadatos, reimportación y escaneos programados + +Los escaneos también se pueden programar para ejecutarse en intervalos rutinarios, como los desencadenados por cron jobs. Los escaneos programados no están vinculados a la actividad del repositorio, lo que hace que metadatos como los commit hashes o los nombres de branch sean irrelevantes a menos que el propio script los inyecte explícitamente. Aun así, usar la reimportación puede seguir siendo útil si prefiere mantener un registro continuo de su postura de seguridad dentro de un único Test. diff --git a/docs/content/asset_modelling/engagements_tests/OS__tests.fr.md b/docs/content/asset_modelling/engagements_tests/OS__tests.fr.md new file mode 100644 index 00000000000..966af7d4265 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__tests.fr.md @@ -0,0 +1,274 @@ +--- +title: Tests +description: Comprendre les Tests dans DefectDojo OS +audience: opensource +weight: 4 +--- + +Organisations → Actifs → Engagements → **TESTS** → Constatations + +## Aperçu + +Un Test est un conteneur pour une ou plusieurs exécutions de scan, utilisées pour découvrir des failles dans un Produit. Les Tests constituent le composant final, le plus granulaire, de la hiérarchie des produits de DefectDojo : ils servent de conteneur pour les Constatations résultant de l'exécution d'un outil de sécurité ou d'une évaluation manuelle, tout en ajoutant le contexte dans lequel ces Constatations ont été trouvées (c'est-à-dire quel outil les a signalées, quand cet outil a été exécuté pour la dernière fois, etc.). + +Voici des exemples de Tests : +- Test statique de sécurité des applications +- Test dynamique de sécurité des applications +- Analyse de la composition logicielle +- Scans de sécurité des conteneurs +- Scans d'infrastructure / réseau +- Tests d'intrusion manuels +- Scans de pipeline CI/CD + +### Types de Test + +Il existe deux principales façons de créer des Tests dans DefectDojo : +1. **Parseurs spécifiques à un éditeur** (par ex., Burp, OWASP ZAP, Acunetix, Invicti) +2. **Import générique de Constatations** + +Chaque méthode peut créer de nouveaux Tests ou réimporter des Constatations dans des Tests existants, selon la configuration et la stratégie de déduplication. + +Bien que chaque méthode diffère principalement dans la façon dont les données de scan sont analysées et ingérées, elles aboutissent toutes à l'association de Constatations à un Test. + +#### Parseurs + +Les **Parseurs** sont des composants qui traitent des formats de sortie de scan spécifiques (par ex., XML, JSON, CSV) et les font correspondre au modèle de Constatation interne de DefectDojo. Lorsque des résultats de scan sont importés, DefectDojo utilise le parseur sélectionné pour extraire les Constatations et les rattacher à un Test nouvellement créé ou existant. + +#### Import générique de Constatations + +Lorsqu'aucun parseur natif n'existe pour un outil donné, l'**Import générique de Constatations** vous permet d'importer des constatations à l'aide d'un schéma JSON ou CSV standardisé, quelle que soit la source d'origine. + +DefectDojo analyse les données fournies, crée un nouveau Test (ou importe dans un Test existant), et rattache les Constatations. Un Type de Test correspondant est également créé en fonction du champ optionnel `type` du rapport : lorsque `type` est omis (ou est égal au type de scan), le Type de Test est « Generic Findings Import » ; lorsque `type` est fourni, il devient « {type} Scan (Generic Findings Import) » (un `type` se terminant déjà par le suffixe « (Generic Findings Import) » est utilisé tel quel). + +| | **Parseurs natifs** | **Import générique de Constatations** | +|----------|---------------|------------------------| +| **Objectif principal** | Ingérer les sorties d'outils pris en charge | Ingérer des données non prises en charge/personnalisées via un schéma fixe | +| **Format d'entrée** | Spécifique à l'outil (par ex., ZAP XML, SARIF) | Schéma JSON/CSV strict | +| **Qui gère la normalisation** | DefectDojo (parseur intégré) | Utilisateur (doit se conformer au schéma) | +| **Déclencheur de création de Test** | Téléversement manuel ou import via API | Téléversement manuel ou import via API | +| **Type de Test** | Prédéfini (par ex., « ZAP Scan ») | Type « Generic » créé automatiquement | +| **Effort de configuration** | Faible | Modéré (transformation des données requise) | +| **Flexibilité** | Faible (uniquement les outils pris en charge) | Moyenne | +| **Niveau d'automatisation** | Faible à modéré | Faible à modéré | +| **Cas d'usage typique** | Scanners standards (SAST, DAST, SCA) | Scripts personnalisés, outils non pris en charge | + +Quelle que soit la méthode d'ingestion, toutes les données de scan dans DefectDojo sont finalement représentées sous forme de Constatations rattachées à un Test, qui sert d'unité d'exécution et de suivi du cycle de vie. + +### Données de Test + +Les Tests stockent diverses métadonnées qui aident à documenter les différents composants de chaque effort de test, telles que : +- Titre / nom du Test +- Type de Test +- Description / notes du Test +- Date de début et de fin +- L'Environnement dans lequel le Test a été exécuté (par ex., Développement, Staging, Pré-production, Production, etc.) +- Version / Branche / ID de build / Hash de commit +- Configuration de scan API +- Fichiers supplémentaires pouvant être utilisés pour des audits ultérieurs ou des réimportations +- L'Engagement, l'Actif et l'Organisation parents +- Historique d'import et de réimport + +Chaque Test conserve un historique d'import qui enregistre tous les imports et réimports de scan associés au Test. Cela inclut des métadonnées telles que la date du scan, la version, la branche, le hash de commit et l'ID de build. + +Cet historique assure la traçabilité à travers plusieurs exécutions de scan au sein d'un même Test. + +### Permissions + +Plusieurs Tests peuvent être stockés au sein d'un même Engagement, et les Engagements sont stockés au sein de Produits. Ainsi, l'accès à un Produit accorde automatiquement l'accès à tous les Tests (et Engagements) de ce Produit. Les Tests ne disposent pas de listes de contrôle d'accès indépendantes. + +### Accéder aux Tests + +Bien que les Tests existent en tant qu'objet indépendant dans DefectDojo OS, ils ne disposent pas d'une section spécifique qui leur soit dédiée dans l'interface. Ainsi, chaque Test est principalement accessible via le Produit et/ou l'Engagement qui le contient. + +### Vue Test + +La vue Test héberge divers tableaux, notamment l'Engagement parent, l'historique d'import et de réimport, une liste des Constatations contenues dans le Test ainsi que tous les Groupes de Constatations éventuels. + +Il existe également des tableaux pour les Constatations potentielles, les Fichiers et les Notes, qui peuvent tous être ajoutés manuellement. + +#### Paramètres du Test + +Les paramètres suivants sont disponibles dans chaque vue Test : +- **Modifier le Test** + - Permet de modifier les données du Test, telles que le titre, la planification, l'environnement et divers autres détails. +- **Copier le Test** + - Duplique un Test, avec toutes les métadonnées et Constatations associées, et permet de l'attribuer à un autre Engagement. +- **Retéléverser le scan** + - Lance le processus de réimport. Plus d'informations sur la Réimportation sont fournies plus loin dans cet article. +- **Ajouter des notes** + - Permet à l'utilisateur d'ajouter une Note. Un tableau de Notes est également présent en bas de la page. + - Une Note peut être basculée en Privée, auquel cas elle ne peut pas être poussée vers Jira, les Rapports et les exports de Constatations. +- **Rapport** + - Lance le processus de génération d'un Rapport, dans lequel de nombreux filtres peuvent être appliqués afin de créer un rapport ne contenant que les Constatations filtrées. +- **Ajouter au calendrier** + - Télécharge un fichier .ics du Test choisi, qui peut être ajouté à votre application de calendrier tierce. +- **Voir l'historique** + - Ouvre un historique des modifications apportées au Test à des fins de suivi, de reporting et d'audit. + +## Utiliser les Tests + +### Créer des Tests + +Les Tests peuvent être créés automatiquement lorsque des données de scan sont importées directement dans un Engagement, ce qui donne lieu à un nouveau Test contenant les données du scan. Les Tests peuvent également être créés en prévision de la planification de futurs Engagements, ou pour des constatations de sécurité saisies manuellement nécessitant un suivi et une remédiation. + +#### Flux de travail manuels + +Il existe plusieurs façons de créer un Test dans la version OS : + +- Sélectionnez un Produit et cliquez sur « Import Scan Results » dans le menu Findings de la barre de navigation + - Cela créera un Engagement ad hoc pour contenir le Test + +![image](images/tests_ss5.png) + +- Sélectionnez un Engagement au sein d'un Produit, cliquez sur le menu déroulant dans la sous-section Tests, puis cliquez sur « Add Tests » ou « Import Scan Results » + - Cela créera le Test correspondant directement au sein de l'Engagement choisi + +![image](images/tests_ss6.png) + +- Lors de la création d'un Engagement + +![image](images/tests_ss7.png) + +En utilisant la troisième méthode ci-dessus, vous pouvez effectuer les actions suivantes lors de la création d'un Engagement : + +- Importer immédiatement les résultats de scan +- Créer une coquille de Test (dans laquelle vous importerez un scan ultérieurement) +- Ne faire ni l'un ni l'autre et simplement créer l'Engagement en cliquant sur « Done » + +Vous aurez la possibilité d'ajouter des métadonnées lors de l'import d'un scan ou de la création d'une coquille de Test. Toute métadonnée sera reflétée dans la section Historique d'import de la Vue Test. + +#### Flux de travail automatisés + +Dans les flux de travail automatisés, les Tests peuvent être créés de manière programmatique dans le cadre du processus d'import de scan, ce qui permet aux pipelines de téléverser des résultats sans qu'un Test doive être créé manuellement au préalable. + +Lors de l'utilisation de l'API pour importer des résultats de scan, un nouveau Test peut être créé automatiquement en fournissant un engagement au lieu d'un test. + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +Compte tenu de ce qui précède, un nouveau Test est créé sous l'Engagement spécifié, et les résultats du scan sont rattachés à ce Test. + +Si un ID `test` est fourni à la place, les résultats du scan seront ajoutés à un Test existant, ce qui est courant dans les flux de travail de réimport. + +### Modifier des Tests + +Les Tests peuvent être modifiés en cliquant sur **Modifier le Test** dans le menu kebab ⋮ du tableau Tests au sein de la vue de l'Engagement parent, ou depuis le menu des paramètres dans la vue du Test. Tous les champs modifiables qui en découlent sont également disponibles lors de la création du Test. + +![image](images/tests_ss24.png) + +![image](images/tests_ss12.png) + +#### Ajouter manuellement des Constatations à un Test + +Une Constatation peut être ajoutée manuellement à un Test en cliquant sur **Ajouter une Constatation au Test** dans le menu kebab ⋮ à côté du Test dans la vue de l'Engagement parent, ou depuis les paramètres du tableau Constatations dans la vue du Test. + +![image](images/tests_ss29.png) + +![image](images/tests_ss30.png) + +### Supprimer des Tests + +La suppression d'un Test s'effectue en sélectionnant **Supprimer le Test** dans le menu kebab ⋮ à côté du Test dans la vue de l'Engagement parent, ou depuis le menu des paramètres dans la vue du Test. Cette action est irréversible. + +La suppression d'un Test supprimera également toutes les Constatations contenues dans ce Test. + +![image](images/tests_ss25.png) + +![image](images/tests_ss26.png) + +## Réimport + +Réimporter des scans au sein des Tests est fondamental pour une déduplication efficace. Lorsque des résultats de scan sont réimportés dans le même Test : + +- Les Constatations existantes peuvent être mises à jour +- Les Constatations en doublon peuvent être supprimées +- De nouvelles Constatations peuvent être créées si aucune correspondance n'est trouvée + +Ce comportement dépend des règles de déduplication configurées et du type de scan. + +Créer un nouveau Test au lieu de réimporter dans un Test existant peut entraîner la création de Constatations en doublon plutôt que leur mise à jour. + +#### Réimport et import + +Le Réimport est généralement utilisé lorsque : + +- Des scans récurrents sont exécutés sur la même cible +- Vous suivez l'évolution des Constatations au fil du temps +- Vous maintenez une vue continue de la posture de sécurité applicative + +En revanche, l'import (création d'un nouveau Test) est plus adapté aux exécutions de scan ponctuelles ou indépendantes. + +### Réimporter des résultats de scan (interface) + +Afin d'ajouter de nouvelles données à un Test existant, vous pouvez soit cliquer sur **Retéléverser les résultats du scan** dans le menu kebab ⋮ à côté du Test dans la vue de l'Engagement parent, soit cliquer sur **Retéléverser le scan** dans le menu des paramètres de la vue du Test. + +![image](images/tests_ss27.png) + +![image](images/tests_ss10.png) + +En remplissant le formulaire Réimporter le scan, vous aurez la possibilité de mettre à jour les métadonnées du scan en cours de réimport, notamment la version, l'étiquette de branche, le hash de commit et l'ID de build. + +Ces modifications sont reflétées dans la section Historique d'import de la Vue Test, qui inclura également les mêmes métadonnées des imports de scan précédents. + +Par exemple, dans la capture d'écran ci-dessous, l'étiquette de branche, l'ID de build, le hash de commit et la version ont tous été mis à jour manuellement entre l'import initial et le réimport suivant. + +![image](images/tests_ss28.png) + +Pour modifier les métadonnées du scan réimporté le plus récemment, suivez les instructions précédentes de la section Modifier des Tests ci-dessus et mettez à jour les métadonnées souhaitées. Seules les métadonnées de l'import le plus récent peuvent être modifiées. + +### Réimporter des résultats de scan (API) + +Lorsque des Tests sont créés ou mis à jour via un pipeline CI/CD, vous pouvez inclure des métadonnées de l'exécution du pipeline afin que les Tests puissent être correctement liés au code qu'ils ont scanné. Cela vous permet de : +- Associer les résultats du scan à un commit ou une branche spécifique. +- Suivre l'évolution des Constatations au fil des modifications de code. +- Améliorer la Déduplication en comprenant quand deux scans s'appliquent à la même version du code ou à des versions différentes. +- Faciliter l'auditabilité en montrant exactement quel code a été scanné et quand. + +L'API de DefectDojo accepte ces valeurs lors de l'import ou du réimport afin qu'elles puissent être stockées dans le cadre de l'import du scan et reflétées dans l'historique d'import du Test. Ces métadonnées peuvent être utilisées pour identifier des hash de commit ou toute information de dépôt pertinente associée à une exécution CI/CD. + +#### Champs de métadonnées pris en charge + +L'API prend en charge un ensemble défini de champs de métadonnées pouvant être inclus lors du réimport. Ceux-ci incluent : + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- indicateurs `active / verified` + +Ces champs représentent le mécanisme principal permettant de rattacher des métadonnées contextuelles lors d'une opération de réimport. + +Dans les pipelines automatisés, les métadonnées les plus couramment fournies incluent : +- build_id (identifiant du job CI) +- commit_hash (référence de contrôle de source) +- branch_tag (contexte de branche ou d'environnement) +- tags (par ex., nightly, staging, production) + +Ces champs assurent la traçabilité entre les scans sans nécessiter d'intervention manuelle. + +Bien que les métadonnées puissent être mises à jour manuellement via le formulaire Réimporter le scan, la plupart des environnements automatisés géreront cela en appelant directement le endpoint `/api/v2/reimport-scan/`. Cette approche permet au pipeline de rattacher automatiquement les métadonnées lors du réimport. + +##### Réimport via API avec métadonnées + +curl -X POST `"https:///api/v2/reimport-scan/"` \ + -H `"Authorization: Token "` \ + -F `"test=123"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` \ + -F `"tags=nightly,api-scan"` \ + -F `"version=1.4.2"` \ + -F `"build_id=jenkins-842"` \ + -F `"branch_tag=main"` \ + -F `"commit_hash=a1b2c3d4"` + +##### Métadonnées, réimport et scans planifiés + +Les scans peuvent également être planifiés pour s'exécuter à intervalles réguliers, comme ceux déclenchés par des tâches cron. Les scans planifiés ne sont pas liés à l'activité du dépôt, ce qui rend les métadonnées telles que les hash de commit ou les noms de branche non pertinentes, sauf si elles sont explicitement injectées par le script lui-même. Néanmoins, l'utilisation du réimport peut rester utile si vous préférez conserver un enregistrement continu de votre posture de sécurité au sein d'un seul Test. diff --git a/docs/content/asset_modelling/engagements_tests/OS__tests.ja.md b/docs/content/asset_modelling/engagements_tests/OS__tests.ja.md new file mode 100644 index 00000000000..a6d53e27b26 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__tests.ja.md @@ -0,0 +1,274 @@ +--- +title: テスト +description: DefectDojo OSにおけるテストの理解 +audience: opensource +weight: 4 +--- + +組織 → アセット → エンゲージメント → **テスト** → 検出事項 + +## 概要 + +テストとは、1つ以上のスキャン実行を格納するコンテナであり、製品内の欠陥を発見するために使用されます。テストはDefectDojoの製品階層における最終的かつ最も詳細な粒度のコンポーネントであり、セキュリティツールの実行または手動評価の結果として得られる検出事項を格納するコンテナとして機能するとともに、その検出事項がどのような文脈で発見されたか(どのツールが報告したか、そのツールが最後に実行されたのはいつかなど)という情報も付加します。 + +テストの例には、以下のようなものがあります。 +- 静的アプリケーションセキュリティテスト(SAST) +- 動的アプリケーションセキュリティテスト(DAST) +- ソフトウェア構成分析(SCA) +- コンテナセキュリティスキャン +- インフラストラクチャ/ネットワークスキャン +- 手動ペネトレーションテスト +- CI/CDパイプラインスキャン + +### テストの種類 + +DefectDojoでテストを作成する主な方法は2つあります。 +1. **ベンダー固有のパーサー**(例: Burp、OWASP ZAP、Acunetix、Invicti) +2. **汎用検出事項インポート** + +各方式は、設定や重複排除戦略に応じて、新しいテストを作成することも、既存のテストに検出事項を再インポートすることも可能です。 + +各方式は主にスキャンデータの解析および取り込み方法が異なりますが、最終的にはいずれも検出事項がテストに関連付けられる結果となります。 + +#### パーサー + +**パーサー**とは、特定のスキャン出力形式(XML、JSON、CSVなど)を処理し、DefectDojo内部の検出事項モデルにマッピングするコンポーネントです。スキャン結果がインポートされると、DefectDojoは選択されたパーサーを使用して検出事項を抽出し、新規作成または既存のテストに関連付けます。 + +#### 汎用検出事項インポート + +特定のツールに対応するネイティブパーサーが存在しない場合、**汎用検出事項インポート**を使用すると、元のソースにかかわらず、標準化されたJSONまたはCSVスキーマを使用して検出事項をインポートできます。 + +DefectDojoは提供されたデータを解析し、新しいテストを作成する(または既存のテストにインポートする)とともに、検出事項を関連付けます。レポートの任意フィールドである`type`に基づいて、対応するテストタイプも作成されます。`type`が省略されている場合(またはスキャンタイプと同じ場合)、テストタイプは「Generic Findings Import」になります。`type`が指定されている場合は「{type} Scan (Generic Findings Import)」になります(すでに「(Generic Findings Import)」という接尾辞で終わっている`type`は、そのまま使用されます)。 + +| | **ネイティブパーサー** | **汎用検出事項インポート** | +|----------|---------------|------------------------| +| **主な目的** | サポートされているツールの出力を取り込む | 固定スキーマを使用して非対応/カスタムデータを取り込む | +| **入力形式** | ツール固有(例: ZAP XML、SARIF) | 厳密なJSON/CSVスキーマ | +| **正規化を行う主体** | DefectDojo(組み込みパーサー) | ユーザー(スキーマに準拠する必要あり) | +| **テスト作成のトリガー** | 手動アップロードまたはAPIインポート | 手動アップロードまたはAPIインポート | +| **テストタイプ** | 事前定義済み(例:「ZAP Scan」) | 自動作成される「Generic」タイプ | +| **セットアップの手間** | 低 | 中程度(データ変換が必要) | +| **柔軟性** | 低(対応ツールのみ) | 中 | +| **自動化レベル** | 低~中 | 低~中 | +| **典型的な用途** | 標準的なスキャナー(SAST、DAST、SCA) | カスタムスクリプト、非対応ツール | + +取り込み方法にかかわらず、DefectDojo内のすべてのスキャンデータは、最終的にテストに関連付けられた検出事項として表現されます。テストは、実行単位およびライフサイクル追跡の単位として機能します。 + +### テストデータ + +テストは、各テスト活動のさまざまな要素を記録するのに役立つ、多様なメタデータを保存します。例えば以下のとおりです。 +- テストのタイトル/名前 +- テストタイプ +- テストの説明/メモ +- 開始日と終了日 +- テストが実行された環境(開発、ステージング、本番前、本番など) +- バージョン/ブランチ/ビルドID/コミットハッシュ +- APIスキャン設定 +- 後の監査や再インポートに使用できる追加ファイル +- 親となるエンゲージメント、アセット、組織 +- インポートおよび再インポートの履歴 + +各テストはインポート履歴を保持しており、そのテストに関連するすべてのスキャンのインポートおよび再インポートが記録されます。これには、スキャン日、バージョン、ブランチ、コミットハッシュ、ビルドIDなどのメタデータが含まれます。 + +この履歴により、同一テスト内で実行された複数回のスキャンにわたるトレーサビリティが確保されます。 + +### 権限 + +1つのエンゲージメント内に複数のテストを格納でき、エンゲージメントは製品内に格納されます。そのため、ある製品へのアクセス権を持つと、その製品内のすべてのテスト(およびエンゲージメント)へのアクセス権が自動的に付与されます。テストは独自のアクセス制御リストを持ちません。 + +### テストへのアクセス + +テストはDefectDojo OSにおいて独立したオブジェクトとして存在しますが、UI内に専用のセクションはありません。そのため、各テストは主に、それを含む製品またはエンゲージメント(あるいはその両方)を通じてアクセスします。 + +### テストビュー + +テストビューには、親エンゲージメント、インポートおよび再インポートの履歴、テスト内に含まれる検出事項の一覧、検出事項グループなど、さまざまな表が表示されます。 + +また、潜在的検出事項、ファイル、メモの表もあり、いずれも手動で追加できます。 + +#### テスト設定 + +各テストビューでは、以下の設定を利用できます。 +- **テストを編集** + - タイトル、スケジュール、環境などのテストデータの各種詳細を編集できます。 +- **テストをコピー** + - テストを関連するすべてのメタデータおよび検出事項とともに複製し、別のエンゲージメントに割り当てることができます。 +- **スキャンを再アップロード** + - 再インポートのプロセスを開始します。再インポートの詳細については、この記事の後半で説明します。 +- **メモを追加** + - ユーザーがメモを追加できます。ページ下部にはメモの表も表示されます。 + - メモは非公開に切り替えることができ、その場合、Jiraへのプッシュ、レポート、検出事項のエクスポートには反映されなくなります。 +- **レポート** + - レポート生成のプロセスを開始します。さまざまなフィルターを適用して、フィルタリングされた検出事項のみを含むレポートを作成できます。 +- **カレンダーに追加** + - 選択したテストの.icsファイルをダウンロードし、サードパーティ製のカレンダーアプリケーションに追加できます。 +- **履歴を表示** + - 追跡、レポート、監査を目的として、テストに対して行われた編集の履歴を表示します。 + +## テストの操作 + +### テストの作成 + +スキャンデータがエンゲージメントに直接インポートされると、そのスキャンデータを含む新しいテストが自動的に作成されます。また、将来のエンゲージメントを計画する目的や、追跡と修復が必要な手動入力のセキュリティ検出事項のために、テストを事前に作成することもできます。 + +#### 手動ワークフロー + +OS版でテストを作成する方法はいくつかあります。 + +- 製品を選択し、ナビゲーションバーの検出事項メニューから「スキャン結果をインポート」をクリックします + - この操作により、テストを格納するためのアドホックなエンゲージメントが作成されます + +![image](images/tests_ss5.png) + +- 製品内のエンゲージメントを選択し、テストサブセクションのドロップダウンメニューをクリックして、「テストを追加」または「スキャン結果をインポート」のいずれかをクリックします + - この操作により、選択したエンゲージメント内に直接テストが作成されます + +![image](images/tests_ss6.png) + +- エンゲージメントの作成中 + +![image](images/tests_ss7.png) + +上記3番目の方法を使用すると、エンゲージメントの作成中に以下の操作を行うことができます。 + +- すぐにスキャン結果をインポートする +- テストシェルを作成する(後でスキャンをインポートする) +- どちらも行わず、「完了」をクリックしてエンゲージメントのみを作成する + +スキャンのインポート時、またはテストシェルの作成時に、メタデータを追加することができます。追加したメタデータは、テストビューのインポート履歴セクションに反映されます。 + +#### 自動化されたワークフロー + +自動化されたワークフローでは、スキャンのインポート処理の一環としてテストをプログラムで作成できるため、パイプラインは事前に手動でテストを作成することなく結果をアップロードできます。 + +APIを使用してスキャン結果をインポートする場合、テストの代わりにエンゲージメントを指定することで、新しいテストを自動的に作成できます。 + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +上記の例では、指定したエンゲージメントの下に新しいテストが作成され、スキャン結果がそのテストに関連付けられます。 + +代わりに`test`のIDが指定された場合、スキャン結果は既存のテストに追加されます。これは再インポートのワークフローでよく見られるパターンです。 + +### テストの編集 + +テストは、親エンゲージメントビューのテスト表にある⋮(縦三点)メニューから**テストを編集**をクリックするか、テストビュー内の設定メニューから編集できます。編集可能な各フィールドは、テストの作成時にも同様に利用できます。 + +![image](images/tests_ss24.png) + +![image](images/tests_ss12.png) + +#### テストへの検出事項の手動追加 + +検出事項は、親エンゲージメントビューでテストの隣にある⋮(縦三点)メニューから**検出事項をテストに追加**をクリックするか、テストビューの検出事項表の設定から、テストに手動で追加できます。 + +![image](images/tests_ss29.png) + +![image](images/tests_ss30.png) + +### テストの削除 + +テストは、親エンゲージメントビューでテストの隣にある⋮(縦三点)メニューから**テストを削除**を選択するか、テストビュー内の設定メニューから削除できます。この操作は元に戻せません。 + +テストを削除すると、そのテストに含まれるすべての検出事項も削除されます。 + +![image](images/tests_ss25.png) + +![image](images/tests_ss26.png) + +## 再インポート + +テスト内でスキャンを再インポートすることは、効果的な重複排除の基本です。同じテストにスキャン結果が再インポートされると、以下のようになります。 + +- 既存の検出事項が更新される場合があります +- 重複する検出事項が抑制される場合があります +- 一致するものが見つからない場合は、新しい検出事項が作成されます + +この挙動は、設定されている重複排除ルールとスキャンタイプによって異なります。 + +既存のテストに再インポートする代わりに新しいテストを作成すると、検出事項が更新されるのではなく、重複して作成される可能性があります。 + +#### 再インポートとインポートの違い + +再インポートは通常、以下のような場合に使用されます。 + +- 同じ対象に対して繰り返しスキャンを実行する場合 +- 検出事項が時間の経過とともにどのように変化するかを追跡する場合 +- アプリケーションのセキュリティ体制を継続的に把握する場合 + +一方、インポート(新しいテストの作成)は、単発または独立したスキャン実行により適しています。 + +### スキャン結果の再インポート(UI) + +既存のテストに新しいデータを追加するには、親エンゲージメントビューでテストの隣にある⋮(縦三点)メニューから**スキャン結果を再アップロード**をクリックするか、テストビュー内の設定メニューで**スキャンを再アップロード**をクリックします。 + +![image](images/tests_ss27.png) + +![image](images/tests_ss10.png) + +再インポートスキャンフォームに入力する際、再インポートするスキャンのメタデータ(バージョン、ブランチタグ、コミットハッシュ、ビルドIDなど)を更新するオプションがあります。 + +これらの変更は、テストビューのインポート履歴セクションに反映され、そこには過去のスキャンインポート時と同じメタデータも含まれます。 + +たとえば、以下のスクリーンショットでは、最初のインポートとその後の再インポートの間に、ブランチタグ、ビルドID、コミットハッシュ、バージョンがすべて手動で更新されています。 + +![image](images/tests_ss28.png) + +直近に再インポートされたスキャンのメタデータを編集するには、前述の「テストの編集」セクションの手順に従い、必要に応じてメタデータを更新してください。編集できるのは、最も新しいインポートのメタデータのみです。 + +### スキャン結果の再インポート(API) + +CI/CDパイプラインを通じてテストが作成または更新される場合、パイプライン実行時のメタデータを含めることで、テストをスキャン対象のコードと適切に関連付けることができます。これにより、以下が可能になります。 +- スキャン結果を特定のコミットまたはブランチに関連付ける +- コードの変更にともなって検出事項がどのように変化するかを追跡する +- 2つのスキャンがコードの同一バージョンまたは異なるバージョンに対するものかを把握することで、重複排除を改善する +- どのコードがいつスキャンされたかを正確に示すことで、監査可能性を高める + +DefectDojoのAPIは、インポートまたは再インポート時にこれらの値を受け付け、スキャンインポートの一部として保存し、テストのインポート履歴に反映します。このメタデータは、コミットハッシュや、CI/CD実行に関連するリポジトリ情報の特定に利用できます。 + +#### サポートされているメタデータフィールド + +APIは、再インポート時に含めることができる、定義済みのメタデータフィールドのセットをサポートしています。具体的には以下のとおりです。 + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- `active / verified`フラグ + +これらのフィールドは、再インポート操作時にコンテキストメタデータを付加するための主要な手段です。 + +自動化されたパイプラインでは、最も一般的に指定されるメタデータには以下が含まれます。 +- build_id(CIジョブの識別子) +- commit_hash(ソースコード管理の参照情報) +- branch_tag(ブランチまたは環境のコンテキスト) +- tags(例: nightly、staging、production) + +これらのフィールドにより、手動の介入を必要とすることなく、スキャン間のトレーサビリティが確保されます。 + +メタデータは再インポートスキャンフォームから手動で更新することもできますが、ほとんどの自動化環境では`/api/v2/reimport-scan/`エンドポイントを直接呼び出すことでこれを処理します。この方法により、パイプラインは再インポート時にメタデータを自動的に付加できます。 + +##### メタデータを使用したAPI再インポート + +curl -X POST `"https:///api/v2/reimport-scan/"` \ + -H `"Authorization: Token "` \ + -F `"test=123"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` \ + -F `"tags=nightly,api-scan"` \ + -F `"version=1.4.2"` \ + -F `"build_id=jenkins-842"` \ + -F `"branch_tag=main"` \ + -F `"commit_hash=a1b2c3d4"` + +##### メタデータ、再インポート、およびスケジュールされたスキャン + +スキャンは、cronジョブなどによってトリガーされる定期的な間隔で実行されるようスケジュールすることもできます。スケジュールされたスキャンはリポジトリの活動と結び付いていないため、スクリプト自体が明示的に注入しない限り、コミットハッシュやブランチ名といったメタデータは意味を持ちません。それでも、単一のテスト内でセキュリティ体制の継続的な記録を保持したい場合には、再インポートを使用することが依然として有用な場合があります。 diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.de.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.de.md new file mode 100644 index 00000000000..a7d32100da2 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.de.md @@ -0,0 +1,186 @@ +--- +title: Assets +description: Assets in DefectDojo Pro verstehen +audience: pro +weight: 2 +--- + +Organisationen → **ASSETS** → Engagements → Tests → Befunde + +## Überblick + +**Assets** stehen im Mittelpunkt der Organisation der Sicherheitsarbeit innerhalb der Objekthierarchie von DefectDojo. Assets repräsentieren jedes Projekt, Programm, jede Software oder jeden physischen Vermögenswert, den Ihr Sicherheitsteam testet, und bündeln die gesamte Sicherheitsarbeit und Testhistorie im Zusammenhang mit dem jeweiligen Testziel. Beispiele für Assets sind unter anderem: +- Software-Releases +- Software von Drittanbietern +- Virtuelle Maschinen oder Assets in der Produktion +- Eine einzelne Anwendung +- Ein Microservice +- Eine API +- Eine SaaS-Plattform +- Eine mobile App +- Ein internes System +- Ein Geschäftsservice +- Eine kundenorientierte Plattform +- Eine Cloud-Umgebung oder ein Infrastrukturbereich + +Im Allgemeinen sollte ein Asset das „Ding“ repräsentieren, dessen Sicherheitslage Sie im Zeitverlauf nachverfolgen möchten. Dazu gehören die zugehörige Testhistorie, Befunde, Metriken, Zuständigkeiten, Integrationen und Behebungs-Workflows im Zusammenhang mit diesem „Ding“. + +### Asset-Beispiele + +Assets können je nach den Anforderungen Ihrer Organisation noch feiner granuliert werden. Beispielsweise könnten Sie in folgenden Szenarien separate DefectDojo-Assets erstellen: + +- „ExampleAsset“ hat eine Windows-Version, eine Mac-Version und eine Cloud-Version +- „ExampleAsset 1.0“ verwendet völlig andere Softwarekomponenten als „ExampleAsset 2.0“, und beide Versionen werden von Ihrem Unternehmen aktiv unterstützt. +- Das Team, das an „ExampleAsset Version A“ arbeitet, unterscheidet sich von dem Asset-Team, das an „ExampleAsset Version B“ arbeitet, und benötigt infolgedessen andere Sicherheitsberechtigungen. + +Sie können diese Varianten zwar auch als Engagements innerhalb eines einzelnen Assets abbilden, RBAC kann jedoch nur auf Ebene von Assets oder Organisationen festgelegt werden, was den Zugriff der Benutzer auf das passende Engagement (sowie die Tests und Befunde innerhalb dieser Engagements) einschränken kann, wenn sie so organisiert sind. Weitere Informationen zu RBAC und Berechtigungen in DefectDojo finden Sie [hier](/admin/user_management/about_perms_and_roles/). + +## Asset-Daten + +Assets enthalten immer die folgenden Komponenten: + +- **Organisation** +- **Eindeutiger Name** +- **Beschreibung** +- **SLA-Konfiguration** +- **Priorisierungs-Engine** + +Optionale Asset-Metadaten umfassen: + +- **Tags** +- **Geschäftskritikalität** +- **Benutzerdatensätze** (d. h. die geschätzte Anzahl der Benutzerdatensätze im Asset) +- **Umsatz** +- **Personalinformationen** (z. B. Asset-Manager, Team-Manager, technischer Ansprechpartner usw.) +- **Vorschriften** (z. B. HIPAA, GLBA, OPPA usw.) +- **Plattform** (z. B. API, Desktop, IoT, Mobil, Web usw.) +- **Lebenszyklus** (z. B. Aufbau, Produktion, Außerbetriebnahme usw.) +- **Herkunft** (z. B. Drittanbieter-Bibliothek, Gekauft, Open Source usw.) + +Diese Metadaten verbessern das Filtern, Berichten und Priorisieren in Ihrem gesamten Sicherheitsprogramm. Noch wichtiger ist jedoch, dass Assets auch alle Engagements, Tests und Befunde enthalten, die mit den Testaktivitäten rund um dieses Asset zusammenhängen. Alle Befunde aus Tests werden letztlich auf Asset-Ebene zusammengeführt, was langfristiges Tracking, Trendanalysen und Berichte ermöglicht. + +## Zugriff auf Assets + +Assets sind über die Seitenleiste zugänglich. Das Untermenü bietet Zugriff auf die [Asset-Hierarchie](/asset_modelling/engagements_tests/pro__assets/#asset-nesting) und Alle Assets sowie die Möglichkeit, ein neues Asset zu erstellen. + +![image](images/assets_ss1.png) + +### Berechtigungen + +Auf Assets können rollenbasierte Zugriffskontrollregeln (RBAC) angewendet werden, die die Möglichkeit der Teammitglieder einschränken, sie anzuzeigen und mit ihnen zu interagieren. + +Berechtigungen werden nach unten vererbt, das heißt, der Zugriff auf ein Asset gewährt automatisch Zugriff auf alle darin enthaltenen Objekte (z. B. Engagements, Tests und Befunde). + +Weitere Informationen zu Benutzerrollen finden Sie in unserem Artikel [Einführung in Rollen](/admin/user_management/set_user_permissions/#introduction-to-permission-types). + +## Asset-Ansicht + +Asset-Ansichten enthalten eine Vielzahl von Tabellen und Diagrammen, mit denen sich der Status eines Assets auf einen Blick erfassen lässt. Dazu gehören: + +- **Schweregrad offener Befunde** + - Eine Liste der offenen Befunde innerhalb des Assets, gruppiert nach Schweregrad +- **Asset-Übersicht** + - Eine Aufschlüsselung verschiedener Merkmale des Assets, einschließlich Beschreibung, Komponenten, Kontakte, [Benutzergruppen](/admin/user_management/create_user_group/ +), Mitglieder, Technologien und Vorschriften. + - Technologien: next.js, vue.js, npm v.1.2.3, Django, nginx, Hugo +- **Metadaten** + - Einschließlich übergeordneter und untergeordneter Assets, Organisation, Geschäftskritikalität, Umsatz und weiterer Details aus den Einstellungen des Assets. +- **Service Level Agreement nach Schweregrad** + - Wendet die SLA-Konfiguration des Assets aus den Einstellungen auf die Befunde innerhalb des Assets an. +- **Aufschlüsselung des Befund-Schweregrads** + - Ein Diagramm der Befunde innerhalb des Assets, organisiert nach Schweregrad. +- **Befundverteilung** + - Eine Aufschlüsselung der Befunde innerhalb des Assets, organisiert nach Status (z. B. Aktiv, Behoben, Statisch und Dynamisch) +- **Alle Engagements** + - Eine Liste der im Asset enthaltenen Engagements. + +## Arbeiten mit Assets + +### Assets erstellen + +Es gibt zwei Möglichkeiten, Assets zu erstellen: + +- Über die Option **Neues Asset** im Seitenmenü +- Über die Schaltfläche **Neues Asset** oben in der Liste „Alle Assets“ + +## Assets bearbeiten + +Assets können bearbeitet werden, indem Sie im Zahnrad-Menü oben rechts in der Asset-Ansicht auf **Asset bearbeiten** klicken. Auf dasselbe Menü können Sie auch über das ⋮-Kebab-Menü links neben dem Asset in der Ansicht „Alle Assets“ zugreifen. + +Alle daraufhin bearbeitbaren Felder stehen auch bei der Erstellung des Assets zur Verfügung. + +![image](images/assets_ss2.png) + +### Assets löschen + +Um ein Asset zu löschen, wählen Sie **Asset löschen** in den Einstellungen des Assets aus. Diese Aktion kann nicht rückgängig gemacht werden. Assets können nicht geschlossen und später wieder geöffnet werden. + +Beim Löschen eines Assets werden außerdem folgende Elemente gelöscht: +- Alle im Asset enthaltenen Engagements und Tests +- Der gesamte zugehörige Sicherheitsverlauf, einschließlich Befunde und Integrationen +- Alle verknüpften Jira-Epics +- Alle Notizen und Datei-Uploads im Zusammenhang mit den Engagements und Tests des Assets + +## Asset-Grenzen + +### Deduplizierung + +Assets sind „abgeschottet“ und interagieren nicht mit anderen Assets. Die intelligenten Funktionen von DefectDojo, wie zum Beispiel die Deduplizierung, gelten nur im Kontext eines einzelnen Assets. Befunde aus unterschiedlichen Assets werden nicht automatisch dedupliziert. + +### Berichte und Metriken + +Die meisten Berichte und Metriken aggregieren Daten auf Asset-Ebene, wodurch Assets die primäre Einheit für die Messung und Nachverfolgung von Risiken darstellen. + +Infolgedessen werden viele wichtige Kennzahlen pro Asset berechnet, darunter: + +- Gesamtzahl der Befunde (nach Schweregrad oder Status) +- Mittlere Behebungszeit (MTTR) +- SLA-Einhaltungs- und Verletzungsraten +- Risikotrends im Zeitverlauf + +Das bedeutet, dass die Struktur der Assets die Genauigkeit und den Nutzen von Berichten direkt beeinflusst. Wenn beispielsweise mehrere nicht zusammenhängende Systeme unter einem einzigen Asset zusammengefasst werden, kann dies die Risikotransparenz verringern, während eine zu feingranulare Asset-Struktur die Berichterstattung fragmentieren und die Erkennung übergreifender Trends erschweren kann. + +### Connectors + +In DefectDojo Pro werden Connectors verschiedenen Assets zugeordnet, wodurch sie zum primären Integrationspunkt zwischen DefectDojo und Ihrem umfassenderen Sicherheits-Ökosystem werden. + +Sobald ein Connector mit einem Asset verknüpft wurde, importiert er Scan-Ergebnisse und erstellt oder aktualisiert Engagements, Tests und Befunde innerhalb dieses Assets. + +Weitere Informationen zu Connectors finden Sie [hier](/connectors/upstream/about/#main-content). + +### CI/CD-Pipelines + +CI/CD-Pipelines automatisieren den Import von Scan-Ergebnissen. Unabhängig von der Integrationsmethode muss jeder Scan-Import einem Asset zugeordnet sein, wodurch das Asset zum Ankerpunkt für pipeline-gesteuerte Sicherheitsdaten wird. + +Wenn eine Pipeline Scan-Ergebnisse übermittelt, muss sie entweder: + +- Ein bestehendes Asset angeben (und optional ein Engagement), oder +- So konfiguriert sein, dass Ergebnisse konsistent dem richtigen Asset zugeordnet werden + +Alle importierten Befunde übernehmen den Kontext des Assets, einschließlich Zuständigkeit, Berechtigungen, Priorität-/Risikokonfiguration und Berichtsumfang. + +In der Praxis sollten Assets so definiert werden, dass sie widerspiegeln, wie Systeme innerhalb von CI/CD aufgebaut und bereitgestellt werden, um sicherzustellen, dass Sicherheitsergebnisse konsistent der richtigen Anwendung oder dem richtigen Service zugeordnet werden. + +### SLAs, Priorität und Risiko + +In DefectDojo Pro übernehmen Befunde ihre SLA-Ziele, Priorität und ihr Risiko von dem Asset, das sie enthält. Asset-Metadaten (z. B. Geschäftskritikalität, Umsatz usw.) werden verwendet, um Prioritäts- und Risikowerte automatisch zu berechnen. + +Das bedeutet, dass dieselbe Schwachstelle je nachdem, ob sie ein internes Entwicklungssystem oder ein Produktions-Asset betrifft, das kritische Geschäftsabläufe unterstützt, eine unterschiedliche Prioritäts- oder Risikobewertung erhalten kann. + +### Jira-/Downstream-Connector-Beziehungen + +Assets können direkt mit [Jira](/connectors/downstream/pro__jira_guide/#main-content)- oder [Integrators](/connectors/downstream/downstream_toolreference/#main-content)-Instanzen (z. B. GitHub, GitLab, ServiceNow usw.) verknüpft werden, die die Befunde des Assets nach außen in externe Ticketing-/Work-Management-Systeme übertragen. + +Da Befunde Risiko, Priorität und Zuständigkeit von ihrem übergeordneten Asset übernehmen, bestimmt das Asset effektiv den Behebungskontext, der in Jira-Tickets und Downstream-Connector-Workflows einfließt. + +Wichtig ist außerdem, dass Assets der wichtigste bestimmende Faktor für die SLA-Eigenschaften eines Befunds sind. Der SLA eines Befunds hängt daher von der SLA-Konfiguration seines übergeordneten Assets ab. Weitere Informationen zu SLA-Konfigurationen finden Sie [hier](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas). + +## Asset-Verschachtelung + +DefectDojo unterstützt eine übergeordnet-untergeordnet-Beziehung zwischen zwei Assets innerhalb derselben Organisation. Dies kann bei der Erstellung des Assets oder in dessen Einstellungen konfiguriert werden. + +Sie können die Struktur der Assets in DefectDojo visualisieren und Beziehungen mithilfe der Option **Asset-Hierarchie** in der Seitenleiste ändern. + +Nachdem Sie die zu visualisierenden Assets in der entsprechenden Tabelle ausgewählt haben, klicken Sie auf **Asset-Hierarchie anzeigen**, um ein Flussdiagramm der Beziehung zwischen den gewählten Assets zu erstellen, sofern vorhanden. + +Weitere Informationen zu den Auswirkungen der Asset-Verschachtelung auf Deduplizierung, RBAC und weitere Details sowie Beispielanwendungsfälle finden Sie [hier](/asset_modelling/pro_hierarchy/asset_hierarchy/#asset-nesting-examples). diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.es.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.es.md new file mode 100644 index 00000000000..b81d5b69115 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.es.md @@ -0,0 +1,186 @@ +--- +title: Activos +description: Cómo entender los Activos en DefectDojo Pro +audience: pro +weight: 2 +--- + +Organizaciones → **ACTIVOS** → Compromisos → Tests → Hallazgos + +## Resumen + +Los **Activos** se ubican en el centro de cómo se organiza el trabajo de seguridad dentro de la jerarquía de objetos de DefectDojo. Los Activos representan cualquier proyecto, programa, software o activo físico que su equipo de seguridad esté probando, y albergan todo el trabajo de seguridad y el historial de pruebas relacionado con el objetivo de las pruebas. Algunos ejemplos de Activos pueden incluir: +- Versiones de software +- Software de terceros +- Máquinas virtuales o activos en producción +- Una única aplicación +- Un microservicio +- Una API +- Una plataforma SaaS +- Una aplicación móvil +- Un sistema interno +- Un servicio de negocio +- Una plataforma orientada al cliente +- Un entorno de nube o dominio de infraestructura + +En general, un Activo debe representar la “cosa” cuya postura de seguridad se desea rastrear a lo largo del tiempo. Esto incluye el historial de pruebas asociado, los Hallazgos, las métricas, la propiedad, las integraciones y los flujos de trabajo de remediación relacionados con esa “cosa”. + +### Ejemplos de Activos + +Los Activos pueden volverse aún más granulares según las necesidades de su organización. Por ejemplo, puede considerar crear Activos de DefectDojo independientes en los siguientes escenarios: + +- “ExampleAsset” tiene una versión para Windows, una versión para Mac y una versión en la nube +- “ExampleAsset 1.0” utiliza componentes de software completamente distintos de “ExampleAsset 2.0”, y ambas versiones cuentan con soporte activo por parte de su empresa. +- El equipo asignado para trabajar en “ExampleAsset version A” es distinto del equipo de Activo asignado para trabajar en “ExampleAsset version B”, y por ello necesita tener asignados permisos de seguridad diferentes. + +Aunque también puede optar por representar estas variaciones como Compromisos dentro de un único Activo, el RBAC solo se puede configurar a nivel de Activos u Organizaciones, lo que puede limitar el acceso de los usuarios al Compromiso adecuado (así como a los Tests y Hallazgos dentro de esos Compromisos) si se organizan de esa manera. Para obtener más información sobre RBAC y permisos en DefectDojo, haga clic [aquí](/admin/user_management/about_perms_and_roles/). + +## Datos del Activo + +Los Activos siempre incluirán los siguientes componentes: + +- **Organización** +- **Nombre único** +- **Descripción** +- **Configuración de SLA** +- **Motor de priorización** + +Los metadatos opcionales del Activo incluyen: + +- **Etiquetas** +- **Criticidad de negocio** +- **Registros de usuario** (es decir, el número estimado de registros de usuario en el Activo) +- **Ingresos** +- **Información del personal** (por ejemplo, Asset Manager, Team Manager, Technical Contact, etc.) +- **Regulaciones** (por ejemplo, HIPAA, GLBA, OPPA, etc.) +- **Plataforma** (por ejemplo, API, Desktop, IoT, Mobile, Web, etc.) +- **Ciclo de vida** (por ejemplo, Construction, Production, Retirement, etc.) +- **Origen** (por ejemplo, Third-Party Library, Purchased, Open Source, etc.) + +Estos metadatos mejoran el filtrado, la generación de informes y la priorización en todo su programa de seguridad, pero lo más importante es que los Activos también contienen todos los Compromisos, Tests y Hallazgos relacionados con los esfuerzos de prueba en torno a ese Activo. Todos los Hallazgos de los Tests terminan consolidándose a nivel de Activo, lo que permite el seguimiento a largo plazo, el análisis de tendencias y la generación de informes. + +## Acceso a los Activos + +Se puede acceder a los Activos desde la barra lateral. El submenú brinda acceso a [Asset Hierarchy](/asset_modelling/engagements_tests/pro__assets/#asset-nesting) y a All Assets, además de la opción de crear un nuevo Activo. + +![image](images/assets_ss1.png) + +### Permisos + +A los Activos se les pueden aplicar reglas de Control de Acceso Basado en Roles (RBAC), que limitan la capacidad de los miembros del equipo para verlos e interactuar con ellos. + +Los permisos se propagan en cascada hacia abajo, lo que significa que el acceso a un Activo otorga automáticamente acceso a todos los objetos dentro de ese Activo (por ejemplo, Compromisos, Tests y Hallazgos). + +Para obtener más información sobre los roles de usuario, consulte nuestro artículo [Introduction To Roles](/admin/user_management/set_user_permissions/#introduction-to-permission-types). + +## Vista del Activo + +Las vistas de Activo contienen diversas tablas y gráficos para interpretar el estado de un Activo de un vistazo. Esto incluye: + +- **Open Finding Severity** + - Una lista de los Hallazgos abiertos dentro del Activo, agrupados por severidad +- **Asset Overview** + - Un desglose de varias características del Activo, incluyendo Descripción, Componentes, Contactos, [Grupos de Usuarios](/admin/user_management/create_user_group/ +), Miembros, Tecnologías y Regulaciones. + - Tecnologías: next.js, vue.js, npm v.1.2.3, Django, nginx, Hugo +- **Metadata** + - Incluyendo Activos principales y secundarios, Organización, criticidad de negocio, ingresos y otros detalles agregados desde la configuración del Activo. +- **Service Level Agreement by Severity** + - Aplica la configuración de SLA del Activo definida en la configuración a los Hallazgos dentro del Activo. +- **Finding Severity Breakdown** + - Un gráfico de los Hallazgos dentro del Activo, organizado por severidad. +- **Finding Distribution** + - Un desglose de los Hallazgos dentro del Activo, organizado por estado (por ejemplo, Activo, Mitigado, Estático y Dinámico) +- **All Engagements** + - Una lista de los Compromisos contenidos en el Activo. + +## Trabajar con Activos + +### Crear Activos + +Existen dos maneras de crear Activos: + +- Desde la opción **New Asset** en el menú lateral +- Desde el botón **New Asset** en la parte superior de la lista All Assets + +## Editar Activos + +Los Activos se pueden editar haciendo clic en **Edit Asset** desde el menú de engranaje en la parte superior derecha de la vista del Activo. También se puede acceder al mismo menú haciendo clic en el menú de tres puntos (⋮) situado a la izquierda del Activo en la vista All Assets. + +Todos los campos que se pueden editar posteriormente también están disponibles al crear el Activo. + +![image](images/assets_ss2.png) + +### Eliminar Activos + +Para eliminar un Activo, seleccione **Delete Asset** en la configuración del Activo. Esta acción no se puede deshacer. Los Activos no se pueden cerrar y volver a abrir posteriormente. + +Eliminar un Activo también eliminará lo siguiente: +- Cualquier Compromiso y Test contenido dentro del Activo +- Todo el historial de seguridad asociado, incluidos los Hallazgos y las integraciones +- Cualquier Epic de Jira vinculado +- Todas las notas y archivos cargados asociados con los Compromisos y Tests del Activo + +## Límites del Activo + +### Deduplicación + +Los Activos están “aislados” y no interactúan con otros Activos. Las Smart Features de DefectDojo, como la Deduplicación, solo se aplican dentro del contexto de un único Activo. Los Hallazgos de diferentes Activos no se deduplicarán automáticamente. + +### Informes y métricas + +La mayoría de los informes y métricas agregan datos a nivel de Activo, lo que convierte a los Activos en la unidad principal para medir y realizar seguimiento del riesgo. + +Como resultado, muchas métricas clave se calculan por Activo, entre ellas: + +- Número total de Hallazgos (por severidad o estado) +- Tiempo medio de remediación (MTTR) +- Tasas de cumplimiento e incumplimiento de SLA +- Tendencias de riesgo a lo largo del tiempo + +Esto significa que la forma en que se estructuran los Activos repercutirá directamente en la precisión y utilidad de los informes. Por ejemplo, agrupar varios sistemas no relacionados bajo un único Activo puede oscurecer la visibilidad del riesgo, mientras que unas estructuras de Activos demasiado granulares pueden fragmentar los informes, dificultando la identificación de tendencias más amplias. + +### Connectors + +En DefectDojo Pro, los Conectores se asignan a diferentes Activos en DefectDojo Pro, lo que los convierte en el punto de integración principal entre DefectDojo y su ecosistema de seguridad más amplio. + +Una vez que se ha vinculado un Conector a un Activo, este importará los resultados de escaneo y creará o actualizará Compromisos, Tests y Hallazgos dentro de ese Activo. + +Para obtener más información sobre los Conectores, haga clic [aquí](/connectors/upstream/about/#main-content). + +### Pipelines de CI/CD + +Los pipelines de CI/CD automatizan la importación de resultados de escaneo. Independientemente del método de integración, todas las importaciones de escaneo deben asociarse con un Activo, lo que convierte al Activo en el punto de anclaje de los datos de seguridad impulsados por pipelines. + +Cuando un pipeline envía resultados de escaneo, debe hacer una de las siguientes cosas: + +- Especificar un Activo existente (y opcionalmente un Compromiso), o +- Estar configurado de manera que los resultados se asignen sistemáticamente al Activo correcto + +Todos los Hallazgos importados heredarán el contexto del Activo, incluidos la propiedad, los permisos, la configuración de prioridad/riesgo y el alcance de los informes. + +En la práctica, los Activos deben definirse de manera que reflejen cómo se construyen y despliegan los sistemas dentro de CI/CD, para garantizar que los resultados de seguridad se asocien sistemáticamente con la aplicación o el servicio correctos. + +### SLA, prioridad y riesgo + +En DefectDojo Pro, los Hallazgos heredan sus objetivos de SLA, Prioridad y Riesgo del Activo que los contiene. Los metadatos del Activo (por ejemplo, criticidad de negocio, ingresos, etc.) se utilizan para calcular automáticamente los valores de Prioridad y Riesgo. + +Esto significa que la misma vulnerabilidad puede recibir una puntuación de Prioridad o Riesgo diferente según afecte a un sistema interno de desarrollo o a un activo de producción que respalde operaciones de negocio críticas. + +### Relaciones con Jira / Downstream Connector + +Los Activos se pueden asignar directamente a instancias de [Jira](/connectors/downstream/pro__jira_guide/#main-content) o de [Integrators](/connectors/downstream/downstream_toolreference/#main-content) (por ejemplo, GitHub, GitLab, ServiceNow, etc.), que envían los Hallazgos del Activo hacia sistemas externos de tickets/gestión de trabajo. + +Dado que los Hallazgos heredan el riesgo, la prioridad y la propiedad de su Activo principal, el Activo determina de forma efectiva el contexto de remediación que fluye hacia los tickets de Jira y los flujos de trabajo de Downstream Connector. + +Es importante destacar que los Activos también son el factor determinante principal de las características de SLA de un Hallazgo. Por lo tanto, el SLA de un Hallazgo depende de la configuración de SLA de su Activo principal. Puede encontrar más información sobre las configuraciones de SLA [aquí](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas). + +## Anidamiento de Activos + +DefectDojo admite relaciones de tipo padre-hijo entre dos Activos dentro de la misma Organización. Esto se puede configurar durante la creación del Activo o en la configuración del Activo. + +Puede visualizar la estructura de los Activos en DefectDojo y cambiar las relaciones mediante la opción **Asset Hierarchy** en la barra lateral. + +Después de seleccionar los Activos que desea visualizar en la tabla correspondiente, haga clic en **View Asset Hierarchy** para generar un diagrama de flujo de la relación entre los Activos elegidos, si la hubiera. + +Puede encontrar más información sobre el efecto de anidar Activos en la deduplicación, el RBAC y otros detalles, así como ejemplos de casos de uso, [aquí](/asset_modelling/pro_hierarchy/asset_hierarchy/#asset-nesting-examples). diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.fr.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.fr.md new file mode 100644 index 00000000000..70f0cac93eb --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.fr.md @@ -0,0 +1,186 @@ +--- +title: Actifs +description: Comprendre les Actifs dans DefectDojo Pro +audience: pro +weight: 2 +--- + +Organisations → **ACTIFS** → Engagements → Tests → Constatations + +## Aperçu + +**Les Actifs** se situent au centre de l'organisation du travail de sécurité au sein de la hiérarchie des objets de DefectDojo. Les Actifs représentent tout projet, programme, logiciel ou actif physique testé par votre équipe de sécurité, et hébergent l'ensemble du travail de sécurité et de l'historique de tests relatifs à l'objectif de test. Voici des exemples d'Actifs : +- Versions logicielles +- Logiciels tiers +- Machines virtuelles ou actifs en production +- Une application unique +- Un microservice +- Une API +- Une plateforme SaaS +- Une application mobile +- Un système interne +- Un service métier +- Une plateforme destinée aux clients +- Un environnement cloud ou un domaine d'infrastructure + +En général, un Actif doit représenter la « chose » dont vous souhaitez suivre la posture de sécurité dans le temps. Cela inclut l'historique de tests associé, les Constatations, les métriques, la propriété, les intégrations et les flux de remédiation liés à cette « chose ». + +### Exemples d'Actifs + +Les Actifs peuvent devenir encore plus granulaires selon les besoins de votre organisation. Par exemple, vous pouvez envisager de créer des Actifs DefectDojo distincts dans les scénarios suivants : + +- « ExampleAsset » possède une version Windows, une version Mac et une version Cloud +- « ExampleAsset 1.0 » utilise des composants logiciels complètement différents de « ExampleAsset 2.0 », et les deux versions sont activement maintenues par votre entreprise. +- L'équipe chargée de travailler sur « ExampleAsset version A » est différente de l'équipe chargée de l'Actif « ExampleAsset version B », et doit par conséquent se voir attribuer des permissions de sécurité différentes. + +Bien que vous puissiez également choisir de représenter ces variations sous forme d'Engagements au sein d'un seul Actif, le RBAC ne peut être défini qu'au niveau des Actifs ou des Organisations, ce qui peut limiter l'accès des utilisateurs à l'Engagement approprié (ainsi qu'aux Tests et Constatations au sein de ces Engagements) s'ils sont organisés de cette façon. Pour plus d'informations sur le RBAC et les permissions dans DefectDojo, cliquez [ici](/admin/user_management/about_perms_and_roles/). + +## Données de l'Actif + +Les Actifs incluent toujours les composants suivants : + +- **Organisation** +- **Nom unique** +- **Description** +- **Configuration SLA** +- **Moteur de priorisation** + +Les métadonnées optionnelles de l'Actif incluent : + +- **Étiquettes** +- **Criticité métier** +- **Enregistrements utilisateur** (c'est-à-dire le nombre estimé d'enregistrements utilisateur dans l'Actif) +- **Chiffre d'affaires** +- **Informations sur le personnel** (par ex., Responsable de l'Actif, Responsable d'équipe, Contact technique, etc.) +- **Réglementations** (par ex., HIPAA, GLBA, OPPA, etc.) +- **Plateforme** (par ex., API, Desktop, IoT, Mobile, Web, etc.) +- **Cycle de vie** (par ex., Construction, Production, Retrait, etc.) +- **Origine** (par ex., Bibliothèque tierce, Achetée, Open Source, etc.) + +Ces métadonnées améliorent le filtrage, le reporting et la priorisation au sein de votre programme de sécurité, mais surtout, les Actifs contiennent également tous les Engagements, Tests et Constatations liés aux efforts de test entourant cet Actif. Toutes les Constatations issues des Tests remontent finalement au niveau de l'Actif, permettant un suivi à long terme, une analyse des tendances et un reporting. + +## Accéder aux Actifs + +Les Actifs sont accessibles depuis la barre latérale. Le sous-menu donne accès à la [Hiérarchie des Actifs](/asset_modelling/engagements_tests/pro__assets/#asset-nesting) et à Tous les Actifs, ainsi qu'à l'option de créer un nouvel Actif. + +![image](images/assets_ss1.png) + +### Permissions + +Des règles de contrôle d'accès basé sur les rôles (RBAC) peuvent être appliquées aux Actifs, ce qui limite la capacité des membres de l'équipe à les consulter et à interagir avec eux. + +Les permissions se propagent vers le bas, ce qui signifie que l'accès à un Actif accorde automatiquement l'accès à tous les objets qu'il contient (par ex., Engagements, Tests et Constatations). + +Pour plus d'informations sur les rôles utilisateur, consultez notre article [Introduction aux rôles](/admin/user_management/set_user_permissions/#introduction-to-permission-types). + +## Vue Actif + +Les vues Actif contiennent divers tableaux et graphiques permettant d'interpréter l'état d'un Actif d'un coup d'œil. Cela inclut : + +- **Sévérité des Constatations ouvertes** + - Une liste des Constatations ouvertes au sein de l'Actif, regroupées par sévérité +- **Aperçu de l'Actif** + - Une répartition des différentes caractéristiques de l'Actif, notamment Description, Composants, Contacts, [Groupes d'utilisateurs](/admin/user_management/create_user_group/ +), Membres, Technologies et Réglementations. + - Technologies : next.js, vue.js, npm v.1.2.3, Django, nginx, Hugo +- **Métadonnées** + - Y compris les Actifs parents et enfants, l'Organisation, la criticité métier, le chiffre d'affaires et d'autres détails ajoutés depuis les paramètres de l'Actif. +- **Accord de niveau de service par sévérité** + - Applique la configuration SLA de l'Actif définie dans les paramètres aux Constatations au sein de l'Actif. +- **Répartition des Constatations par sévérité** + - Un graphique des Constatations au sein de l'Actif, organisé par sévérité. +- **Distribution des Constatations** + - Une répartition des Constatations au sein de l'Actif, organisée par statut (par ex., Actif, Atténué, Statique et Dynamique) +- **Tous les Engagements** + - Une liste des Engagements contenus dans l'Actif. + +## Utiliser les Actifs + +### Créer des Actifs + +Il existe deux façons de créer des Actifs : + +- Depuis l'option **Nouvel Actif** dans le menu latéral +- Depuis le bouton **Nouvel Actif** en haut de la liste Tous les Actifs + +## Modifier des Actifs + +Les Actifs peuvent être modifiés en cliquant sur **Modifier l'Actif** dans le menu représenté par une roue dentée, en haut à droite de la vue de l'Actif. Ce même menu est également accessible en cliquant sur le menu kebab ⋮ à gauche de l'Actif dans la vue Tous les Actifs. + +Tous les champs modifiables qui en découlent sont également disponibles lors de la création de l'Actif. + +![image](images/assets_ss2.png) + +### Supprimer des Actifs + +La suppression d'un Actif s'effectue en sélectionnant **Supprimer l'Actif** dans les paramètres de l'Actif. Cette action est irréversible. Les Actifs ne peuvent pas être fermés puis rouverts ultérieurement. + +La suppression d'un Actif entraînera également la suppression des éléments suivants : +- Tous les Engagements et Tests contenus dans l'Actif +- Tout l'historique de sécurité associé, y compris les Constatations et les intégrations +- Toutes les Epics Jira liées +- Toutes les notes et tous les fichiers téléversés associés aux Engagements et Tests de l'Actif + +## Frontières de l'Actif + +### Déduplication + +Les Actifs sont « cloisonnés » et n'interagissent pas avec d'autres Actifs. Les fonctionnalités intelligentes de DefectDojo, telles que la Déduplication, ne s'appliquent que dans le contexte d'un seul Actif. Les Constatations réparties sur différents Actifs ne seront pas automatiquement dédupliquées. + +### Reporting et métriques + +La plupart des rapports et métriques agrègent les données au niveau de l'Actif, faisant des Actifs l'unité principale de mesure et de suivi du risque. + +Par conséquent, de nombreuses métriques clés sont calculées par Actif, notamment : + +- Nombre total de Constatations (par sévérité ou statut) +- Délai moyen de remédiation (MTTR) +- Taux de conformité et de dépassement des SLA +- Évolution du risque dans le temps + +Cela signifie que la façon dont les Actifs sont structurés aura un impact direct sur la précision et l'utilité des rapports. Par exemple, regrouper plusieurs systèmes sans lien sous un seul Actif peut masquer la visibilité du risque, tandis que des structures d'Actifs trop granulaires peuvent fragmenter le reporting, rendant difficile l'identification de tendances plus larges. + +### Connecteurs + +Dans DefectDojo Pro, les Connecteurs sont associés à différents Actifs, ce qui en fait le principal point d'intégration entre DefectDojo et votre écosystème de sécurité plus large. + +Une fois qu'un Connecteur a été rattaché à un Actif, il importera les résultats de scan et créera ou mettra à jour des Engagements, Tests et Constatations au sein de cet Actif. + +Pour plus d'informations sur les Connecteurs, cliquez [ici](/connectors/upstream/about/#main-content). + +### Pipelines CI/CD + +Les pipelines CI/CD automatisent l'import des résultats de scan. Quelle que soit la méthode d'intégration, tous les imports de scan doivent être associés à un Actif, faisant de l'Actif le point d'ancrage des données de sécurité pilotées par pipeline. + +Lorsqu'un pipeline soumet des résultats de scan, il doit soit : + +- Spécifier un Actif existant (et éventuellement un Engagement), soit +- Être configuré de manière à toujours associer les résultats à l'Actif correct + +Toutes les Constatations importées hériteront du contexte de l'Actif, y compris la propriété, les permissions, la configuration de priorité/risque et le périmètre de reporting. + +En pratique, les Actifs doivent être définis de manière à refléter la façon dont les systèmes sont construits et déployés dans le cadre du CI/CD, afin de garantir que les résultats de sécurité soient systématiquement associés à l'application ou au service correct. + +### SLA, priorité et risque + +Dans DefectDojo Pro, les Constatations héritent de leurs objectifs SLA, de leur Priorité et de leur Risque de l'Actif qui les contient. Les métadonnées de l'Actif (par ex., criticité métier, chiffre d'affaires, etc.) sont utilisées pour calculer automatiquement les valeurs de Priorité et de Risque. + +Cela signifie qu'une même vulnérabilité peut recevoir un score de Priorité ou de Risque différent selon qu'elle affecte un système de développement interne ou un actif de production prenant en charge des opérations métier critiques. + +### Relations Jira / Connecteur en aval + +Les Actifs peuvent être associés directement à des instances [Jira](/connectors/downstream/pro__jira_guide/#main-content) ou d'[Intégrateurs](/connectors/downstream/downstream_toolreference/#main-content) (par ex. GitHub, GitLab, ServiceNow, etc.), qui poussent les Constatations de l'Actif vers l'extérieur, dans des systèmes externes de gestion de tickets/travail. + +Étant donné que les Constatations héritent du risque, de la priorité et de la propriété de leur Actif parent, l'Actif détermine effectivement le contexte de remédiation qui alimente les tickets Jira et les flux de travail des Connecteurs en aval. + +Il est important de noter que les Actifs constituent également le principal facteur déterminant des caractéristiques SLA d'une Constatation. Ainsi, le SLA d'une Constatation dépend de la configuration SLA de son Actif parent. Plus d'informations sur les configurations SLA sont disponibles [ici](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas). + +## Imbrication des Actifs + +DefectDojo prend en charge une relation parent-enfant entre deux Actifs au sein d'une même Organisation. Cela peut être configuré lors de la création de l'Actif ou dans les paramètres de l'Actif. + +Vous pouvez visualiser la structure des Actifs dans DefectDojo et modifier les relations à l'aide de l'option **Hiérarchie des Actifs** dans la barre latérale. + +Après avoir sélectionné les Actifs à visualiser dans le tableau correspondant, cliquez sur **Voir la hiérarchie des Actifs** pour générer un organigramme des relations entre les Actifs choisis, le cas échéant. + +Plus d'informations sur l'effet de l'imbrication des Actifs sur la déduplication, le RBAC et d'autres détails, ainsi que des exemples de cas d'usage, sont disponibles [ici](/asset_modelling/pro_hierarchy/asset_hierarchy/#asset-nesting-examples). diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.ja.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.ja.md new file mode 100644 index 00000000000..8227c790f3b --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.ja.md @@ -0,0 +1,186 @@ +--- +title: アセット +description: DefectDojo Proにおけるアセットの理解 +audience: pro +weight: 2 +--- + +組織 → **アセット** → エンゲージメント → テスト → 検出事項 + +## 概要 + +**アセット**は、DefectDojoのオブジェクト階層内でセキュリティ業務がどのように編成されるかにおいて、中心的な役割を果たします。アセットは、セキュリティチームがテストを行う対象となるあらゆるプロジェクト、プログラム、ソフトウェア、または物理的な資産を表し、そのテスト目標に関連するすべてのセキュリティ業務とテスト履歴を格納します。アセットの例には、以下のようなものがあります。 +- ソフトウェアリリース +- サードパーティ製ソフトウェア +- 本番環境の仮想マシンまたは資産 +- 単一のアプリケーション +- マイクロサービス +- API +- SaaSプラットフォーム +- モバイルアプリ +- 内部システム +- ビジネスサービス +- 顧客向けプラットフォーム +- クラウド環境またはインフラストラクチャドメイン + +一般的に、アセットはセキュリティ体制を継続的に追跡したい対象、つまり「モノ」を表すべきです。これには、その「モノ」に関連するテスト履歴、検出事項、メトリクス、所有権、インテグレーション、修復ワークフローが含まれます。 + +### アセットの例 + +アセットは、組織のニーズに応じて、さらに細かい粒度にすることも可能です。たとえば、以下のようなシナリオでは、DefectDojoのアセットを分けて作成することを検討するとよいでしょう。 + +- 「ExampleAsset」にWindows版、Mac版、クラウド版がある場合 +- 「ExampleAsset 1.0」と「ExampleAsset 2.0」で使用しているソフトウェアコンポーネントが全く異なり、両方のバージョンが自社によって現在もサポートされている場合 +- 「ExampleAsset version A」の担当チームと「ExampleAsset version B」の担当チームが異なり、その結果として異なるセキュリティ権限を割り当てる必要がある場合 + +これらのバリエーションを単一のアセット内のエンゲージメントとして表すことも可能ですが、RBACはアセットまたは組織のレベルでしか設定できないため、そのように構成した場合、ユーザーが適切なエンゲージメント(およびそのエンゲージメント内のテストや検出事項)にアクセスできる範囲が制限される可能性があります。DefectDojoにおけるRBACと権限の詳細については、[こちら](/admin/user_management/about_perms_and_roles/)をクリックしてください。 + +## アセットのデータ + +アセットには常に以下の要素が含まれます。 + +- **組織** +- **一意の名前** +- **説明** +- **SLA設定** +- **優先順位付けエンジン** + +オプションのアセットメタデータには以下が含まれます。 + +- **タグ** +- **ビジネスクリティカリティ** +- **ユーザーレコード**(アセット内の推定ユーザーレコード数) +- **収益** +- **担当者情報**(アセットマネージャー、チームマネージャー、技術担当者など) +- **規制**(HIPAA、GLBA、OPPAなど) +- **プラットフォーム**(API、デスクトップ、IoT、モバイル、Webなど) +- **ライフサイクル**(構築中、本番稼働中、廃止など) +- **由来**(サードパーティ製ライブラリ、購入品、オープンソースなど) + +これらのメタデータは、セキュリティプログラム全体にわたるフィルタリング、レポート、優先順位付けを改善しますが、最も重要な点として、アセットにはそのアセットを取り巻くテスト活動に関連するすべてのエンゲージメント、テスト、検出事項も含まれます。テストから得られたすべての検出事項は最終的にアセットレベルに集約され、長期的な追跡、傾向分析、レポート作成が可能になります。 + +## アセットへのアクセス + +アセットにはサイドバーからアクセスできます。サブメニューからは、[アセット階層](/asset_modelling/engagements_tests/pro__assets/#asset-nesting)や全アセット一覧にアクセスできるほか、新しいアセットを作成するオプションも利用できます。 + +![image](images/assets_ss1.png) + +### 権限 + +アセットには、ロールベースアクセス制御(RBAC)のルールを適用でき、チームメンバーがアセットを閲覧・操作できる範囲を制限できます。 + +権限は下位に継承されるため、あるアセットへのアクセス権を持つと、そのアセット内のすべてのオブジェクト(エンゲージメント、テスト、検出事項など)へのアクセス権が自動的に付与されます。 + +ユーザーロールの詳細については、[ロールの概要](/admin/user_management/set_user_permissions/#introduction-to-permission-types)の記事を参照してください。 + +## アセットビュー + +アセットビューには、アセットの状態を一目で把握できるよう、さまざまな表やグラフが含まれています。具体的には以下のとおりです。 + +- **未対応検出事項の深刻度** + - アセット内の未対応の検出事項を深刻度別にグループ化した一覧 +- **アセットの概要** + - 説明、コンポーネント、連絡先、[ユーザーグループ](/admin/user_management/create_user_group/ +)、メンバー、テクノロジー、規制など、アセットのさまざまな要素の内訳 + - テクノロジー: next.js、vue.js、npm v.1.2.3、Django、nginx、Hugo +- **メタデータ** + - 親アセットおよび子アセット、組織、ビジネスクリティカリティ、収益など、アセットの設定から追加されたその他の詳細を含む +- **深刻度別のサービスレベルアグリーメント** + - アセットの設定にあるSLA設定を、アセット内の検出事項に適用する +- **検出事項の深刻度別内訳** + - アセット内の検出事項を深刻度別に整理したグラフ +- **検出事項の分布** + - アセット内の検出事項をステータス別(アクティブ、緩和済み、静的、動的など)に整理した内訳 +- **全エンゲージメント** + - アセット内に含まれるエンゲージメントの一覧 + +## アセットの操作 + +### アセットの作成 + +アセットを作成する方法は2つあります。 + +- サイドメニューの**新規アセット**オプションから +- 全アセット一覧の上部にある**新規アセット**ボタンから + +## アセットの編集 + +アセットは、アセットビューの右上にある歯車メニューから**アセットを編集**をクリックすることで編集できます。同じメニューには、全アセットビューでアセットの左側にある⋮(縦三点)メニューをクリックしてもアクセスできます。 + +編集可能な各フィールドは、アセットの作成時にも同様に利用できます。 + +![image](images/assets_ss2.png) + +### アセットの削除 + +アセットは、アセットの設定から**アセットを削除**を選択することで削除できます。この操作は元に戻せません。アセットは後で終了して再開することはできません。 + +アセットを削除すると、以下も削除されます。 +- アセット内に含まれるすべてのエンゲージメントおよびテスト +- 検出事項やインテグレーションを含む、関連するすべてのセキュリティ履歴 +- リンクされているすべてのJira Epic +- アセットのエンゲージメントおよびテストに関連するすべてのメモおよびアップロードファイル + +## アセットの境界 + +### 重複排除 + +アセットは互いに「隔離」されており、他のアセットと相互作用することはありません。重複排除などのDefectDojoのスマート機能は、単一のアセット内でのみ適用されます。異なるアセットにまたがる検出事項が自動的に重複排除されることはありません。 + +### レポートとメトリクス + +ほとんどのレポートおよびメトリクスはアセットレベルでデータを集計するため、アセットはリスクを測定・追跡するための主要な単位となります。 + +その結果、多くの主要なメトリクスがアセットごとに算出されます。具体的には以下が含まれます。 + +- 検出事項の総数(深刻度またはステータス別) +- 平均修復時間(MTTR) +- SLA遵守率および違反率 +- 経時的なリスクの傾向 + +つまり、アセットをどのように構造化するかが、レポートの正確性と有用性に直接影響するということです。たとえば、関連性のない複数のシステムを1つのアセットにまとめると、リスクの可視性が損なわれる可能性がある一方、アセットの構造を過度に細分化すると、レポートが断片化し、全体的な傾向を把握しにくくなる可能性があります。 + +### コネクター + +DefectDojo Proでは、コネクターがDefectDojo Pro内の各アセットにマッピングされ、DefectDojoと広範なセキュリティエコシステムとの間の主要な統合ポイントとなります。 + +コネクターがアセットに接続されると、スキャン結果をインポートし、そのアセット内のエンゲージメント、テスト、検出事項を作成または更新します。 + +コネクターの詳細については、[こちら](/connectors/upstream/about/#main-content)をクリックしてください。 + +### CI/CDパイプライン + +CI/CDパイプラインは、スキャン結果のインポートを自動化します。統合方法にかかわらず、すべてのスキャンインポートはアセットに関連付けられる必要があり、アセットがパイプライン主導のセキュリティデータの基点となります。 + +パイプラインがスキャン結果を送信する際は、以下のいずれかを行う必要があります。 + +- 既存のアセット(および任意でエンゲージメント)を指定する +- 結果が正しいアセットに一貫してマッピングされるように構成する + +インポートされたすべての検出事項は、所有権、権限、優先度/リスク設定、レポート範囲など、アセットのコンテキストを継承します。 + +実際には、セキュリティ結果が正しいアプリケーションまたはサービスに一貫して関連付けられるよう、CI/CD内でシステムがどのように構築・デプロイされるかを反映してアセットを定義する必要があります。 + +### SLA、優先度、リスク + +DefectDojo Proでは、検出事項はそれを含むアセットからSLA目標、優先度、リスクを継承します。アセットのメタデータ(ビジネスクリティカリティ、収益など)は、優先度とリスクの値を自動的に算出するために使用されます。 + +つまり、同じ脆弱性であっても、それが内部の開発システムに影響するのか、重要な業務を支える本番アセットに影響するのかによって、異なる優先度やリスクスコアが付与される場合があります。 + +### Jira/ダウンストリームコネクターとの関係 + +アセットは、[Jira](/connectors/downstream/pro__jira_guide/#main-content)や[インテグレーター](/connectors/downstream/downstream_toolreference/#main-content)のインスタンス(GitHub、GitLab、ServiceNowなど)に直接マッピングでき、アセットの検出事項を外部のチケット/作業管理システムに送信できます。 + +検出事項は親アセットからリスク、優先度、所有権を継承するため、実質的にアセットが、Jiraチケットやダウンストリームコネクターのワークフローに流れ込む修復コンテキストを決定することになります。 + +重要な点として、アセットは検出事項のSLA特性を決定する主要な要因でもあります。そのため、検出事項のSLAは、その親アセットのSLA設定によって決まります。SLA設定の詳細については、[こちら](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas)を参照してください。 + +## アセットのネスト + +DefectDojoは、同一組織内にある2つのアセット間の親子関係をサポートしています。これは、アセットの作成時、またはアセットの設定内で構成できます。 + +サイドバーの**アセット階層**オプションを使用すると、DefectDojo内のアセットの構造を可視化したり、関係性を変更したりできます。 + +対応する表から可視化したいアセットを選択した後、**アセット階層を表示**をクリックすると、選択したアセット間の関係性(存在する場合)を示すフローチャートが生成されます。 + +アセットのネストが重複排除やRBACなどに与える影響の詳細や、その他の詳細、活用事例については、[こちら](/asset_modelling/pro_hierarchy/asset_hierarchy/#asset-nesting-examples)を参照してください。 diff --git a/docs/content/asset_modelling/engagements_tests/PRO__calendar.de.md b/docs/content/asset_modelling/engagements_tests/PRO__calendar.de.md new file mode 100644 index 00000000000..a24a1300a6e --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__calendar.de.md @@ -0,0 +1,62 @@ +--- +title: Kalender +description: So verwenden Sie den Kalender in DefectDojo Pro +audience: pro +weight: 9 +--- + +DefectDojo verfügt über einen integrierten Kalender, mit dem Sie alle früheren und aktiven Engagements und Tests in Ihrer Organisation verfolgen können. Sobald ein Benutzer ein neues Engagement oder einen neuen Test erstellt und Start- und Enddatum festlegt, wird automatisch ein entsprechender Eintrag im Kalender angelegt. + +### Startseite + +Die Kalenderseite enthält oben Filter und darunter einen Monatskalender. Mit den Filtern legen Sie fest, welche Ergebnisse im Kalender erscheinen, und zwar anhand von: +- Engagement und/oder Test +- Start- und Enddatum +- Engagement-Status (z. B. Abgeschlossen, In Bearbeitung, Angehalten usw.) +- Engagement-/Testleitung (d. h. wem ist das Engagement bzw. der Test zugewiesen?) +- Engagement-Typ (z. B. Interactive oder CI/CD) +- Testtyp (z. B. Pen Test, Acunetix Scan, Tenable Scan usw.) + +![image](images/calendar1.png) + +Nach dem Filtern können die Ergebnisse als ICS-Datei exportiert und weitergegeben werden. + +Wichtig: Der Kalender zeigt nur Engagements und Tests, auf die der Benutzer, der den Kalender ansieht, Zugriff hat. Engagements und Tests, für die der Benutzer keine Anzeigeberechtigung besitzt, werden nicht dargestellt. + +## Funktionen + +### Monatsansicht + +Der Monatskalender zeigt pro Tag fünf Einträge in der Vorschau. Weitere Einträge dieses Tages bleiben verborgen, bis in der Zelle des jeweiligen Datums auf **„+ [X] Ereignisse“** geklickt wird. Nach dem Klick wechselt der Kalender von der Monatsansicht zur Tagesansicht. + +Ein Klick auf einen Eintrag für einen Test oder ein Engagement öffnet ein Dialogfenster mit zusätzlichen Informationen zu diesem Eintrag, darunter: +- Start- und Enddatum +- Test- oder Engagement-Typ +- Leitung +- Status +- Asset +- Engagement +- Test + +Von dort aus können das Asset, das Engagement oder der Test über einen Hyperlink aufgerufen werden. + +### Tagesansicht + +In der Tagesansicht erscheinen alle derzeit aktiven Engagements und Tests in chronologisch absteigender Reihenfolge (d. h. ein neu erstelltes Engagement oder ein neuer Test steht am Ende der Einträge dieses Tages). Engagements werden in Blau dargestellt, Tests in Orange. + +Sofern im jeweiligen Engagement bzw. Test festgelegt, enthält der Titel jedes Eintrags im Tageskalender Folgendes: +- Status +- Produkt +- Engagement +- Test +- Zugewiesene Person + +#### Pfeile + +Die Pfeile links und rechts an jedem Eintrag zeigen an, ob der jeweilige Test oder das jeweilige Engagement auch am vorherigen und/oder folgenden Tag vorhanden ist. + +Ein Test, der am selben Tag erstellt wurde, an dem er betrachtet wird, hat beispielsweise keine Pfeile auf der linken Seite, weil dieser Test am Tag davor noch nicht existierte. Umgekehrt hat ein Test, der am selben Tag endet, an dem er betrachtet wird, keine Pfeile auf der rechten Seite, weil der Eintrag am folgenden Tag nicht mehr existiert. + +Da beispielsweise das letzte Engagement im Screenshot unten (**In Bearbeitung** Example Product A ▶ **Sample Engagement** (Nicht zugewiesen)) am Tag seiner Erstellung betrachtet wird und das geplante Enddatum auf den folgenden Tag gesetzt wurde, sind weder links noch rechts Pfeile vorhanden. + +![image](images/calendar2.png) diff --git a/docs/content/asset_modelling/engagements_tests/PRO__calendar.es.md b/docs/content/asset_modelling/engagements_tests/PRO__calendar.es.md new file mode 100644 index 00000000000..2da74c3ea09 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__calendar.es.md @@ -0,0 +1,62 @@ +--- +title: Calendario +description: Cómo usar el Calendario en DefectDojo Pro +audience: pro +weight: 9 +--- + +DefectDojo incluye un Calendario integrado para que pueda hacer seguimiento de todos los Compromisos y Tests anteriores y activos dentro de su organización. Cada vez que un Usuario crea un nuevo Compromiso o Test y establece las fechas de inicio y fin, se agregará automáticamente una entrada correspondiente al Calendario. + +### Página de inicio + +La página del Calendario incluye filtros en la parte superior y un calendario mensual debajo. Los filtros pueden ajustar qué resultados aparecen en el calendario según: +- Compromiso y/o Test +- Fecha de inicio y fin +- Estado del Compromiso (por ejemplo, Completado, En curso, En espera, etc.) +- Responsable del Compromiso/Test (es decir, ¿a quién está asignado el Compromiso/Test?) +- Tipo de Compromiso (por ejemplo, Interactivo o CI/CD) +- Tipo de Test (por ejemplo, Pen Test, Acunetix Scan, Tenable Scan, etc.) + +![image](images/calendar1.png) + +Una vez filtrados, los resultados se pueden exportar y compartir como un archivo ICS. + +Es importante destacar que el Calendario solo mostrará los Compromisos y Tests a los que tenga acceso el Usuario que está viendo el calendario. No mostrará los Compromisos y Tests que el Usuario no tenga permiso para ver. + +## Funcionalidades + +### Vista mensual + +El calendario mensual mostrará una vista previa de cinco entradas por día. Las entradas adicionales que ocurran ese día quedarán ocultas a menos que se haga clic en **"+ [X] events"** dentro de la celda de una fecha determinada. Al hacer clic, el calendario pasará de una vista mensual a una vista diaria. + +Al hacer clic en una entrada de un Test o Compromiso, se abrirá una ventana modal con información adicional sobre esa entrada, entre ellas: +- Fecha de inicio y fin +- Tipo de Test o Compromiso +- Responsable +- Estado +- Activo +- Compromiso +- Test + +Desde allí, se puede acceder al Activo, Compromiso o Test mediante un hipervínculo. + +### Vista diaria + +En la vista diaria, todos los Compromisos y Tests actualmente activos aparecerán en orden cronológico descendente (es decir, un Compromiso o Test recién creado se ubicará en la parte inferior de la entrada de ese día). Los Compromisos aparecen en azul, mientras que los Tests aparecen en naranja. + +Si se configura dentro del Compromiso/Test correspondiente, el título de cada entrada en el calendario diario incluirá lo siguiente: +- Estado +- Producto +- Compromiso +- Test +- Asignado + +#### Flechas + +Las flechas a la izquierda y a la derecha de cada entrada indican si ese Test o Compromiso en particular está presente el día anterior y/o el día siguiente. + +Por ejemplo, un Test que se creó el mismo día en que se está visualizando no tendrá flechas a la izquierda porque ese Test no existía el día anterior. Por el contrario, un Test que finaliza el mismo día en que se está visualizando no tendrá flechas a la derecha porque la entrada no existirá al día siguiente. + +Por ejemplo, dado que el último Compromiso en la captura de pantalla a continuación (**In Progress** Example Product A ▶ **Sample Engagement** (Unassigned)) se está visualizando el día en que fue creado, y la Fecha de finalización prevista se estableció para el día siguiente, no aparecen flechas ni a la izquierda ni a la derecha. + +![image](images/calendar2.png) diff --git a/docs/content/asset_modelling/engagements_tests/PRO__calendar.fr.md b/docs/content/asset_modelling/engagements_tests/PRO__calendar.fr.md new file mode 100644 index 00000000000..845ae34b8c3 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__calendar.fr.md @@ -0,0 +1,62 @@ +--- +title: Calendrier +description: Comment utiliser le calendrier dans DefectDojo Pro +audience: pro +weight: 9 +--- + +DefectDojo propose un calendrier intégré qui vous permet de suivre tous les Engagements et Tests antérieurs et actifs au sein de votre organisation. Chaque fois qu'un Utilisateur crée un nouvel Engagement ou Test et définit les dates de début et de fin, une entrée correspondante est automatiquement ajoutée au calendrier. + +### Page d'accueil + +La page Calendrier comprend des filtres en haut et un calendrier mensuel en dessous. Les filtres permettent d'ajuster les résultats qui apparaissent dans le calendrier en fonction des critères suivants : +- Engagement et/ou Test +- Date de début et de fin +- Statut de l'Engagement (par exemple, Terminé, En cours, En attente, etc.) +- Responsable de l'Engagement/Test (c'est-à-dire, à qui l'Engagement/Test est-il assigné ?) +- Type d'Engagement (par exemple, Interactif ou CI/CD) +- Type de Test (par exemple, Pen Test, Acunetix Scan, Tenable Scan, etc.) + +![image](images/calendar1.png) + +Une fois filtrés, les résultats peuvent être exportés et partagés sous forme de fichier ICS. + +Il est important de noter que le calendrier n'affichera que les Engagements et Tests auxquels l'Utilisateur consultant le calendrier a accès. Il n'affichera pas les Engagements et Tests que l'Utilisateur n'est pas autorisé à consulter. + +## Fonctionnalités + +### Vue mensuelle + +Le calendrier mensuel affiche un aperçu de cinq entrées par jour. Les entrées supplémentaires survenant ce jour-là resteront masquées, sauf si vous cliquez sur **« + [X] événements »** dans la cellule de la date concernée. Une fois cliqué, le calendrier passe d'une vue mensuelle à une vue journalière. + +Cliquer sur une entrée de Test ou d'Engagement ouvre une fenêtre modale contenant des informations supplémentaires sur cette entrée, notamment : +- Date de début et de fin +- Type de Test ou d'Engagement +- Responsable +- Statut +- Actif +- Engagement +- Test + +À partir de là, il est possible d'accéder à l'Actif, à l'Engagement ou au Test via un lien hypertexte. + +### Vue journalière + +Dans la vue journalière, tous les Engagements et Tests actuellement actifs apparaissent par ordre chronologique décroissant (c'est-à-dire qu'un Engagement ou Test nouvellement créé se trouvera en bas de la liste des entrées de ce jour). Les Engagements apparaissent en bleu, tandis que les Tests apparaissent en orange. + +Si ces informations sont définies dans l'Engagement/Test concerné, le titre de chaque entrée du calendrier journalier inclura les éléments suivants : +- Statut +- Produit +- Engagement +- Test +- Assigné + +#### Flèches + +Les flèches situées à gauche et à droite de chaque entrée indiquent si ce Test ou cet Engagement en particulier est présent la veille et/ou le lendemain. + +Par exemple, un Test créé le jour même où il est consulté n'aura pas de flèche à gauche, car ce Test n'existait pas la veille. À l'inverse, un Test se terminant le jour où il est consulté n'aura pas de flèche à droite, car l'entrée n'existera pas le lendemain. + +Par exemple, comme le dernier Engagement de la capture d'écran ci-dessous (**En cours** Example Product A ▶ **Sample Engagement** (Non assigné)) est consulté le jour de sa création, et que la date de fin cible a été fixée au lendemain, aucune flèche n'apparaît ni à gauche ni à droite. + +![image](images/calendar2.png) diff --git a/docs/content/asset_modelling/engagements_tests/PRO__calendar.ja.md b/docs/content/asset_modelling/engagements_tests/PRO__calendar.ja.md new file mode 100644 index 00000000000..abf7812995c --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__calendar.ja.md @@ -0,0 +1,62 @@ +--- +title: カレンダー +description: DefectDojo Proでのカレンダーの使い方 +audience: pro +weight: 9 +--- + +DefectDojoには、組織内のすべての過去および進行中のエンゲージメントとテストを追跡できる、組み込みのカレンダー機能が備わっています。ユーザーが新しいエンゲージメントまたはテストを作成し、開始日と終了日を設定するたびに、対応するエントリが自動的にカレンダーに追加されます。 + +### ランディングページ + +カレンダーページの上部にはフィルターがあり、下部には月間カレンダーが表示されます。フィルターを使用すると、以下の条件に基づいてカレンダーに表示する結果を調整できます。 +- エンゲージメントおよび/またはテスト +- 開始日と終了日 +- エンゲージメントのステータス(例:完了、進行中、保留中など) +- エンゲージメント/テストのリード(つまり、エンゲージメント/テストが誰に割り当てられているか) +- エンゲージメントタイプ(例:インタラクティブまたはCI/CD) +- テストタイプ(例:ペネトレーションテスト、Acunetixスキャン、Tenableスキャンなど) + +![image](images/calendar1.png) + +フィルター処理後、結果はICSファイルとしてエクスポートおよび共有できます。 + +重要な点として、カレンダーには、それを閲覧しているユーザーがアクセス権を持つエンゲージメントとテストのみが表示されます。ユーザーが閲覧権限を持たないエンゲージメントとテストは表示されません。 + +## 機能 + +### 月間表示 + +月間カレンダーでは、各日につき5件のエントリがプレビューされます。その日に発生した追加のエントリは、特定の日付のセル内で**"+ [X] events"**をクリックしない限り非表示のままです。クリックすると、カレンダーは月間表示から日次表示に切り替わります。 + +テストまたはエンゲージメントのエントリをクリックすると、そのエントリに関する追加情報を含むポップアップモーダルが開きます。内容は以下の通りです。 +- 開始日と終了日 +- テストまたはエンゲージメントのタイプ +- リード +- ステータス +- アセット +- エンゲージメント +- テスト + +そこから、アセット、エンゲージメント、またはテストにハイパーリンクでアクセスできます。 + +### 日次表示 + +日次表示では、現在アクティブなすべてのエンゲージメントとテストが時系列の降順で表示されます(つまり、新しく作成されたエンゲージメントまたはテストは、その日のエントリの一番下に表示されます)。エンゲージメントは青色で、テストはオレンジ色で表示されます。 + +該当するエンゲージメント/テスト内で設定されている場合、日次カレンダーの各エントリのタイトルには以下が含まれます。 +- ステータス +- 製品 +- エンゲージメント +- テスト +- 担当者 + +#### 矢印 + +各エントリの左右にある矢印は、その特定のテストまたはエンゲージメントが前日および/または翌日にも存在するかどうかを示します。 + +例えば、閲覧している当日に作成されたテストには、前日にはそのテストが存在しなかったため、左側に矢印は表示されません。逆に、閲覧している当日に終了するテストには、翌日にはそのエントリが存在しないため、右側に矢印は表示されません。 + +例えば、以下のスクリーンショットの最後のエンゲージメント(**進行中** Example Product A ▶ **Sample Engagement**(未割り当て))は、作成された当日に閲覧されており、目標終了日が翌日に設定されているため、左右どちらにも矢印は表示されていません。 + +![image](images/calendar2.png) diff --git a/docs/content/asset_modelling/engagements_tests/PRO__engagements.de.md b/docs/content/asset_modelling/engagements_tests/PRO__engagements.de.md new file mode 100644 index 00000000000..bb7aba2aee6 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__engagements.de.md @@ -0,0 +1,193 @@ +--- +title: Engagements +description: Engagements in DefectDojo Pro verstehen +audience: pro +weight: 3 +--- + +Organizations → Assets → **ENGAGEMENTS** → Tests → Findings + +## Übersicht + +In der Asset-Hierarchie von DefectDojo sind Engagements zeit- oder pipelinegebundene Container, die Gruppen zusammengehöriger Tests innerhalb eines bestimmten Assets darstellen. Wenn Sie eine geplante Testaktivität vorgesehen haben, egal ob routinemäßig oder einmalig, bietet Ihnen ein Engagement einen Ort, an dem Sie alle zugehörigen Ergebnisse speichern können. + +Beispiele für Engagements sind: +- Einmalige Penetrationstests +- Wiederkehrende monatliche oder vierteljährliche Scans +- Bug-Bounty-Prüfzeiträume +- CI/CD-Pipeline-Läufe (für Teams, die jede Pipeline als eigenes Engagement betrachten) +- Code-Release-Zyklen (z. B. „Sicherheitsüberprüfung für Release v4.2“) + +### Engagement-Typen + +DefectDojo unterstützt zwei Engagement-Typen: **Interactive** und **CI/CD**. Diese Typen bestimmen, wie Tests in der Regel erstellt werden und wie Scan-Ergebnisse importiert werden. + +Ein Interactive Engagement wird in der Regel von einem Ingenieur durchgeführt. Interactive Engagements konzentrieren sich darauf, eine Anwendung während der Laufzeit zu testen, sei es durch einen automatisierten Test, einen menschlichen Tester oder jede andere Aktivität, die mit der Anwendungsfunktionalität „interagiert“. + +Ein CI/CD Engagement dient der automatisierten Integration mit einer CI/CD-Pipeline. CI/CD Engagements sind dafür vorgesehen, Daten als automatisierte Aktion zu importieren, die durch einen Schritt im Release-Prozess ausgelöst wird. + +| **Kategorie** | **Interactive Engagements** | **CI/CD Engagements** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **Primärer Anwendungsfall** | Manuelle oder Ad-hoc-Sicherheitstests | Automatisierte, wiederkehrende Sicherheitstests innerhalb von Pipelines | +| **Dauer** | Zeitlich begrenzt und endlich | Potenziell unbegrenzte Dauer | +| **Häufigkeit** | Periodisch oder einmalig | Kontinuierlich oder pro Commit | +| **Ablauf** | Menschlicher Tester führt Tool aus → importiert Ergebnisse manuell | Pipeline führt Tool aus → überträgt Ergebnisse automatisch an DefectDojo | +| **Methode des Ergebnisimports** | Manueller Upload über UI oder CLI | API-gesteuerter Import per Automatisierung (z. B. CLI, Connectors, Cron-Jobs, Pipeline-Skripte) | +| **Typischer Testtyp** | Penetrationstests, Red-Team-Übungen, manuelle Bewertungen | Statische Analyse, Dependency-Scanning, Container-Scanning | + +### Engagement-Daten + +Als Container, die Testaktivitäten organisieren, können Engagements eine Vielzahl von Daten speichern oder verfolgen: + +- Geplantes Start- und Enddatum +- Beschreibung und Hinweise zum Geltungsbereich +- Status (laufend, geplant, abgeschlossen usw.) +- Zuständiger / Verantwortlicher +- Zugehörige Tests (z. B. Scans, Penetrationstests, manuelle Tests usw.) +- Befunde und Befundtypen (z. B. aktiv, behoben, Risiko akzeptiert, Duplikat usw.) +- Bedrohungsmodelle oder Informationen zur Risikoakzeptanz +- Tags +- Dateien und Notizen +- Jira-Projekteinstellungen +- Umgebungsdetails (z. B. Staging vs. Produktion) +- Build-IDs (bei Anbindung an CI/CD) +- Historische Daten aus früheren Tests innerhalb des Engagements + +## Zugriff auf Engagements + +Engagements sind über die Seitenleiste zugänglich. Das Untermenü bietet Zugriff auf Active Engagements und All Engagements sowie die Möglichkeit, neue Engagements zu erstellen. + +![image](images/engagement_ss13.png) + +Alternativ können Engagements innerhalb eines Assets im Fenster am unteren Rand der Asset-Ansicht aufgerufen werden. + +![image](images/engagement_ss14.png) + +### Berechtigungen + +Engagements stehen in der Objekthierarchie unterhalb von Assets und oberhalb von Tests. Der Zugriff auf ein Asset gewährt daher automatisch Zugriff auf alle Engagements innerhalb dieses Assets. Engagements verfügen über keine eigenen Zugriffskontrolllisten. + +## Arbeiten mit Engagements + +### Engagements erstellen + +Bevor Sie ein Engagement erstellen können, müssen Sie zunächst [ein Asset erstellt haben](/asset_modelling/engagements_tests/pro__assets/#create-assets), das es enthält. + +Es gibt mehrere Möglichkeiten, ein Engagement zu erstellen: + +- Über das Engagements-Dropdown im Bereich „Manage“ der Seitenleiste + - Beim Ausfüllen des Formulars „New Engagement“ müssen Sie das Asset auswählen, dem das Engagement zugeordnet werden soll + +![image](images/engagement_ss1.png) + +- Über das Zahnradsymbol oben rechts in einer Asset-Ansicht + +![image](images/engagement_ss9.png) + +- Über die Schaltfläche „+ New Engagement“ in der Liste der Engagements innerhalb eines Assets + +![image](images/engagement_ss2.png) + +- Wenn Sie noch kein Engagement innerhalb eines Assets erstellt haben, können Sie dies auch beim Importieren eines Scans tun. + +![image](images/engagement_ss3.png) + +Für jedes Engagement müssen die folgenden Felder festgelegt werden: +- Typ (Interactive oder CI/CD) +- Ein eindeutiger Name +- Geplantes Start- und Enddatum + - Dies bestimmt, wie das Engagement im Kalenderbereich angezeigt wird +- Asset +- Status + +#### Engagement-Status + +Engagements können bei der Erstellung mit unterschiedlichen Status gekennzeichnet werden. Der Status kann anschließend auch in den Einstellungen des Engagements geändert werden. + +Ein Engagement kann einen der folgenden Status haben: +- Not Started +- Blocked +- Cancelled +- Completed +- In Progress +- On Hold +- Scheduled +- Waiting for Resource + +Wird der Status eines Engagements auf „Completed“ geändert, sind die meisten Schreibvorgänge (z. B. das Hinzufügen von Tests, das Importieren von Scans) nicht mehr verfügbar oder ausgeblendet. Andere Status wirken sich nicht wesentlich auf die Funktionalität des Engagements aus und dienen hauptsächlich der Filterung bzw. Information. + +### Engagements bearbeiten + +Engagements können bearbeitet werden, indem Sie im Zahnradmenü auf **Edit Engagement** klicken. Dasselbe Menü ist auch über das ⋮-Kebab-Menü links neben dem Asset in der Ansicht „All Assets“ zugänglich. + +Alle nachfolgend bearbeitbaren Felder stehen auch bei der Erstellung des Engagements zur Verfügung. + +![image](images/engagements_ss99.png) + +### Engagements kopieren + +Sie können Engagements ganz einfach duplizieren, indem Sie in den Einstellungen des Engagements „Copy Engagement“ auswählen. Dadurch wird innerhalb des übergeordneten Assets eine exakte Kopie des ursprünglichen Engagements erstellt, einschließlich der Metadaten, Tests und Befunde darin. + +### Engagements schließen + +Engagements werden geschlossen, indem Sie in den Einstellungen des Engagements **Close Engagement** auswählen. Nach dem Schließen wird der Status des Engagements auf „Completed“ geändert. Dennoch bleiben die meisten Schreibvorgänge (z. B. das Hinzufügen von Tests, das Importieren von Scans) weiterhin verfügbar. + +Das Schließen eines Engagements ändert nicht den Status der Befunde innerhalb der Tests des Engagements. Befunde bleiben gemäß ihrem eigenen Lebenszyklus offen, behoben oder als Risiko akzeptiert und bleiben weiterhin für die Anzeige und Berichterstellung zugänglich. + +Wenn das Engagement mit einem Jira Epic verknüpft ist (siehe **[Jira-Integration: Enable Engagement Epic Mapping](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**), löst das Schließen des Engagements eine asynchrone Aufgabe aus, die das zugehörige Jira Epic in Ihrem verbundenen Jira Space schließt. + +### Engagements erneut öffnen + +Wenn ein Engagement geschlossen ist, kann es erneut geöffnet werden, indem Sie in den Einstellungen **Reopen Engagement** auswählen. Dadurch wird das Engagement wieder aktiv und sein Status kehrt zu „In Progress“ zurück. + +### Abgelaufene Engagements + +Ein Engagement läuft ab, sobald das geplante Enddatum überschritten ist. + +Im Vergleich zum Schließen oder Löschen eines Engagements hat das Ablaufen eines Engagements keine direkten Auswirkungen auf dessen Funktionalität und dient in erster Linie als Überwachungs- bzw. Benachrichtigungsmechanismus. + +Nach Ablauf erscheint neben dem Engagement das Tag „Overdue“, dies schränkt jedoch keine der Funktionen des Engagements ein. Der Status des Engagements wird weiterhin als „In Progress“ angezeigt. + +Obwohl es standardmäßig nicht aktiviert ist, gibt es in den Systemeinstellungen eine Option, mit der ein Engagement automatisch geschlossen wird, nachdem es eine bestimmte Anzahl von Tagen abgelaufen ist. + +![image](images/engagement_ss15.png) + +### Engagements löschen + +Das Löschen eines Engagements erfolgt, indem Sie in den Einstellungen des Engagements **Delete Engagement** auswählen. Diese Aktion kann nicht rückgängig gemacht werden. + +Das Löschen eines Engagements löscht auch Folgendes: +Alle mit dem Engagement verknüpften Tests +Alle Befunde innerhalb dieser Tests +Alle verknüpften Jira-Epic-Zuordnungen (das Epic selbst bleibt in Jira erhalten, aber die Verknüpfung zwischen DefectDojo und Jira wird entfernt) +Alle Notizen und Datei-Uploads, die mit dem Engagement verknüpft sind + +Für Auditzwecke wird empfohlen, abgeschlossene Engagements zu schließen, anstatt sie zu löschen. + +| **Vorgang** | **Ergebnisse** | **Umkehrbar** | +|----------|---------|------------| +| **Schließen** | Wird als inaktiv markiert; Daten bleiben erhalten; kann erneut geöffnet werden | Ja (erneut öffnen) | +| **Ablaufen** | Nur visueller Hinweis; optionales automatisches Schließen; Benachrichtigungen | Entfällt | +| **Löschen** | Entfernt dauerhaft Engagement, Tests, Befunde, Notizen, Dateien und alle Jira-Epic-Zuordnungen (Epics bleiben in Jira erhalten) | Nein | + +## Jira-Integration + +Engagements können mit einem verbundenen Jira Space verknüpft werden, sodass Befunde innerhalb des Engagements als Issues an Jira übertragen werden können. Eine vollständige Anleitung zur Einrichtung von Jira finden Sie unter **[Connecting DefectDojo to Jira](/connectors/downstream/pro__jira_guide/)**. + +### Engagement-Epic-Zuordnung + +Wenn **Enable Engagement Epic Mapping** in den Jira-Einstellungen eines Produkts aktiviert ist, werden Engagements als Epics an Jira übertragen. Befunde innerhalb des Engagements werden als untergeordnete Issues unterhalb des Epics übertragen, wodurch die Hierarchie „Engagement → Findings“ von DefectDojo in der Struktur „Epic → Issue“ von Jira abgebildet wird. + +Weitere Informationen zu dieser Einstellung finden Sie unter **[Enable Engagement Epic Mapping](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**. + +### Jira-Einstellungen auf Engagement-Ebene + +Standardmäßig übernehmen Engagements ihre Jira-Einstellungen vom übergeordneten Asset (Product). Einzelne Engagements können diese Einstellungen jedoch überschreiben, um andere Jira-Konfigurationen zu verwenden. Die folgenden Einstellungen können pro Engagement angepasst werden: + +- **Project Key** — leitet Befunde an einen anderen Jira Space weiter +- **Issue Template** — verwendet eine andere Vorlage für Issues, die aus diesem Engagement erstellt werden +- **Custom Fields** — wendet andere Zuordnungen benutzerdefinierter Felder an +- **Jira Labels** — versieht Issues mit engagementspezifischen Labels +- **Default Assignee** — weist Issues einem anderen Teammitglied zu + +Diese Einstellungen sind über die Seite **Edit Engagement** zugänglich. Weitere Details finden Sie unter **[Engagement-Level Jira Settings](/connectors/downstream/pro__jira_guide/#engagement-level-jira-settings)**. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__engagements.es.md b/docs/content/asset_modelling/engagements_tests/PRO__engagements.es.md new file mode 100644 index 00000000000..e3ade11c3fd --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__engagements.es.md @@ -0,0 +1,193 @@ +--- +title: Compromisos +description: Comprender los Compromisos en DefectDojo Pro +audience: pro +weight: 3 +--- + +Organizaciones → Activos → **COMPROMISOS** → Tests → Hallazgos + +## Descripción general + +En la Jerarquía de Activos de DefectDojo, los Compromisos son contenedores delimitados por tiempo o por pipeline que representan grupos de Tests relacionados dentro de un Activo específico. Si tiene programado un esfuerzo de testing planificado, ya sea de forma rutinaria o puntual, un Compromiso le ofrece un lugar donde almacenar todos los resultados relacionados. + +Algunos ejemplos de Compromisos incluyen: +- Pruebas de penetración puntuales +- Escaneos mensuales o trimestrales recurrentes +- Períodos de revisión de bug bounty +- Ejecuciones de pipeline de CI/CD (para equipos que tratan cada pipeline como su propio Compromiso) +- Ciclos de lanzamiento de código (por ejemplo, "revisión de seguridad del lanzamiento v4.2") + +### Tipos de Compromiso + +DefectDojo admite dos tipos de Compromiso: **Interactivo** y **CI/CD**. Estos tipos determinan cómo se crean habitualmente los Tests y cómo se importan los resultados de los escaneos. + +Un Compromiso Interactivo suele ser ejecutado por un ingeniero. Los Compromisos Interactivos se centran en probar una aplicación mientras esta se está ejecutando, mediante un test automatizado, un tester humano o cualquier actividad que "interactúe" con la funcionalidad de la aplicación. + +Un Compromiso de CI/CD está pensado para la integración automatizada con un pipeline de CI/CD. Los Compromisos de CI/CD tienen como fin importar datos como una acción automatizada, activada por un paso del proceso de lanzamiento. + +| **Categoría** | **Compromisos Interactivos** | **Compromisos de CI/CD** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **Caso de uso principal** | Testing de seguridad manual o puntual | Testing de seguridad automatizado y recurrente dentro de pipelines | +| **Duración** | Delimitada en el tiempo y finita | Duración potencialmente infinita | +| **Frecuencia** | Periódica o puntual | Continua o por cada commit | +| **Flujo de trabajo** | El tester humano ejecuta la herramienta → importa los resultados manualmente | El pipeline ejecuta la herramienta → envía automáticamente los resultados a DefectDojo | +| **Método de importación de resultados** | Carga manual mediante la UI o la CLI | Importación mediante automatización basada en API (por ejemplo, CLI, conectores, cron jobs, scripts de pipeline) | +| **Tipo de testing habitual** | Pruebas de penetración, ejercicios de red team, evaluaciones manuales | Análisis estático, escaneo de dependencias, escaneo de contenedores | + +### Datos del Compromiso + +Como contenedores que organizan la actividad de testing, los Compromisos pueden almacenar o hacer seguimiento de diversos datos: + +- Fechas de inicio y fin previstas +- Descripción y notas de alcance +- Estado (en curso, planificado, completado, etc.) +- Persona asignada / Responsable +- Tests asociados (por ejemplo, escaneos, pruebas de penetración, tests manuales, etc.) +- Hallazgos y Tipos de Hallazgo (por ejemplo, activo, mitigado, riesgo aceptado, duplicado, etc.) +- Modelos de amenaza o información de aceptación de riesgo +- Etiquetas +- Archivos y notas +- Configuración del proyecto de Jira +- Detalles del entorno (por ejemplo, staging vs. producción) +- IDs de compilación (si está vinculado a CI/CD) +- Datos históricos de Tests anteriores dentro del Compromiso + +## Acceso a los Compromisos + +Se puede acceder a los Compromisos desde la barra lateral. El submenú brinda acceso a Compromisos Activos y Todos los Compromisos, además de la opción de crear nuevos Compromisos. + +![image](images/engagement_ss13.png) + +Como alternativa, se puede acceder a los Compromisos dentro de un Activo desde la ventana ubicada en la parte inferior de la vista del Activo. + +![image](images/engagement_ss14.png) + +### Permisos + +Los Compromisos se ubican debajo de los Activos y por encima de los Tests en la jerarquía de objetos. Por lo tanto, el acceso a un Activo otorga automáticamente acceso a todos los Compromisos dentro de ese Activo. Los Compromisos no cuentan con listas de control de acceso independientes. + +## Trabajar con Compromisos + +### Crear Compromisos + +Antes de crear un Compromiso, primero debe haber [creado un Activo](/asset_modelling/engagements_tests/pro__assets/#create-assets) que lo contenga. + +Existen varias formas de crear un Compromiso: + +- Desde el menú desplegable de Compromisos en la sección Gestionar de la barra lateral + - Deberá seleccionar el Activo al que se atribuirá el Compromiso al completar el formulario de nuevo Compromiso + +![image](images/engagement_ss1.png) + +- El ícono de engranaje ubicado en la esquina superior derecha de la vista de un Activo + +![image](images/engagement_ss9.png) + +- El botón "+ Nuevo Compromiso" que se encuentra en la lista de Compromisos dentro de un Activo + +![image](images/engagement_ss2.png) + +- Si aún no ha creado un Compromiso dentro de un Activo, puede hacerlo mientras importa un escaneo. + +![image](images/engagement_ss3.png) + +Todo Compromiso debe tener definidos los siguientes campos: +- Tipo (Interactivo o CI/CD) +- Un nombre único +- Fechas de inicio y fin previstas + - Esto determinará la aparición del Compromiso en la sección Calendario +- Activo +- Estado + +#### Estados del Compromiso + +Los Compromisos pueden etiquetarse con distintos estados al momento de su creación. El estado también se puede cambiar posteriormente en la configuración del Compromiso. + +Un Compromiso puede tener cualquiera de los siguientes estados: +- No iniciado +- Bloqueado +- Cancelado +- Completado +- En curso +- En espera +- Programado +- Esperando recurso + +Cambiar el estado de un Compromiso a "Completado" hará que la mayoría de las operaciones de escritura (por ejemplo, agregar tests, importar escaneos) queden no disponibles u ocultas. Los demás estados no afectan de manera sustancial la funcionalidad del Compromiso y cumplen principalmente fines de filtrado o informativos. + +### Editar Compromisos + +Los Compromisos se pueden editar haciendo clic en **Editar Compromiso** dentro del menú de engranaje. Se puede acceder al mismo menú haciendo clic en el menú de tres puntos ⋮ a la izquierda del Activo en la vista Todos los Activos. + +Todos los campos que se pueden editar a continuación también están disponibles al momento de crear el Compromiso. + +![image](images/engagements_ss99.png) + +### Copiar Compromisos + +Puede duplicar fácilmente los Compromisos seleccionando "Copiar Compromiso" dentro de la configuración del Compromiso. Esto creará una copia exacta del Compromiso original dentro del Activo principal, incluyendo los metadatos, Tests y Hallazgos que contiene. + +### Cerrar Compromisos + +Los Compromisos se cierran seleccionando **Cerrar Compromiso** dentro de la configuración del Compromiso. Una vez cerrado, el estado del Compromiso cambiará a "Completado". No obstante, la mayoría de las operaciones de escritura (por ejemplo, agregar tests, importar escaneos) seguirán estando disponibles. + +Cerrar un Compromiso no cambia el estado de los Hallazgos dentro de ninguno de los Tests del Compromiso. Los Hallazgos permanecen activos, mitigados o con riesgo aceptado según su propio ciclo de vida, y siguen estando accesibles para su visualización e inclusión en informes. + +Si el Compromiso está vinculado a una Épica de Jira (consulte **[Integración con Jira: Habilitar la asignación de Épicas a Compromisos](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**), cerrar el Compromiso activará una tarea asíncrona que cierra la Épica de Jira asociada en su Espacio de Jira conectado. + +### Reabrir Compromisos + +Si un Compromiso está cerrado, se puede reabrir seleccionando **Reabrir Compromiso** dentro de su configuración. Esto hará que el Compromiso vuelva a estar activo y su estado regrese a "En curso." + +### Compromisos vencidos + +Un Compromiso vence una vez que transcurre su fecha de finalización prevista. + +A diferencia de cerrar o eliminar un Compromiso, que un Compromiso venza no tiene un impacto directo en su funcionalidad, y sirve principalmente como un mecanismo de monitoreo/notificación. + +Una vez vencido, aparecerá una etiqueta "Vencido" junto al Compromiso, pero esto no restringirá ninguna de sus funcionalidades. El estado del Compromiso seguirá apareciendo como "En curso." + +Si bien no está habilitada de forma predeterminada, existe una opción dentro de la configuración del sistema para cerrar automáticamente un Compromiso una vez que ha estado vencido durante una cierta cantidad de días. + +![image](images/engagement_ss15.png) + +### Eliminar Compromisos + +Se puede eliminar un Compromiso seleccionando **Eliminar Compromiso** en la configuración del Compromiso. Esta acción no se puede deshacer. + +Eliminar un Compromiso también eliminará lo siguiente: +Cualquier Test asociado con el Compromiso +Todos los Hallazgos dentro de esos Tests +Cualquier asignación vinculada a una Épica de Jira (la Épica en sí permanecerá en Jira, pero se eliminará el vínculo entre DefectDojo y Jira) +Todas las notas y archivos cargados asociados con el Compromiso + +Para fines de auditoría, se recomienda cerrar los Compromisos completados en lugar de eliminarlos. + +| **Operación** | **Resultados** | **Reversible** | +|----------|---------|------------| +| **Cerrar** | Se marca como inactivo; los datos permanecen; se puede reabrir | Sí (reabrir) | +| **Vencer** | Solo advertencia visual; cierre automático opcional; notificaciones | N/D | +| **Eliminar** | Elimina de forma permanente el Compromiso, los Tests, los Hallazgos, las notas, los archivos y cualquier asignación de Épica de Jira (las Épicas permanecen en Jira) | No | + +## Integración con Jira + +Los Compromisos se pueden vincular a un Espacio de Jira conectado, lo que permite enviar los Hallazgos dentro del Compromiso a Jira como Issues. Para obtener una guía completa sobre la configuración de Jira, consulte **[Conectar DefectDojo con Jira](/connectors/downstream/pro__jira_guide/)**. + +### Asignación de Épicas a Compromisos + +Cuando la opción **Habilitar la asignación de Épicas a Compromisos** está marcada en la configuración de Jira de un Producto, los Compromisos se enviarán a Jira como Épicas. Los Hallazgos dentro del Compromiso se envían como Issues secundarios debajo de la Épica, reflejando la jerarquía de Compromiso → Hallazgos de DefectDojo en la estructura de Épica → Issue de Jira. + +Para obtener más información sobre esta configuración, consulte **[Habilitar la asignación de Épicas a Compromisos](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**. + +### Configuración de Jira a nivel de Compromiso + +De forma predeterminada, los Compromisos heredan su configuración de Jira del Activo (Producto) principal. Sin embargo, los Compromisos individuales pueden anular esta configuración para usar configuraciones de Jira diferentes. Los siguientes ajustes se pueden personalizar por Compromiso: + +- **Clave del proyecto** — envía los Hallazgos a un Espacio de Jira diferente +- **Plantilla de Issue** — usa una plantilla diferente para los Issues creados a partir de este Compromiso +- **Campos personalizados** — aplica asignaciones de campos personalizados diferentes +- **Etiquetas de Jira** — etiqueta los Issues con etiquetas específicas del Compromiso +- **Persona asignada predeterminada** — asigna los Issues a un miembro diferente del equipo + +Se puede acceder a esta configuración desde la página **Editar Compromiso**. Para obtener más detalles, consulte **[Configuración de Jira a nivel de Compromiso](/connectors/downstream/pro__jira_guide/#engagement-level-jira-settings)**. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__engagements.fr.md b/docs/content/asset_modelling/engagements_tests/PRO__engagements.fr.md new file mode 100644 index 00000000000..1f57dff9c22 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__engagements.fr.md @@ -0,0 +1,193 @@ +--- +title: Engagements +description: Comprendre les Engagements dans DefectDojo Pro +audience: pro +weight: 3 +--- + +Organisations → Actifs → **ENGAGEMENTS** → Tests → Constatations + +## Aperçu + +Dans la hiérarchie des Actifs de DefectDojo, les Engagements sont des conteneurs limités dans le temps ou liés à un pipeline, qui regroupent des Tests apparentés au sein d'un Actif donné. Si vous avez prévu un effort de test, qu'il soit ponctuel ou récurrent, un Engagement vous offre un endroit où stocker tous les résultats associés. + +Voici quelques exemples d'Engagements : +- Tests d'intrusion ponctuels +- Analyses mensuelles ou trimestrielles récurrentes +- Périodes d'évaluation de bug bounty +- Exécutions de pipeline CI/CD (pour les équipes qui traitent chaque pipeline comme un Engagement à part entière) +- Cycles de publication de code (par exemple, « revue de sécurité de la version v4.2 ») + +### Types d'Engagement + +DefectDojo prend en charge deux types d'Engagement : **Interactif** et **CI/CD**. Ces types déterminent la façon dont les Tests sont généralement créés et dont les résultats d'analyse sont importés. + +Un Engagement Interactif est généralement mené par un ingénieur. Les Engagements Interactifs se concentrent sur le test d'une application pendant son exécution, à l'aide d'un test automatisé, d'un testeur humain, ou de toute activité « interagissant » avec les fonctionnalités de l'application. + +Un Engagement CI/CD est destiné à une intégration automatisée avec un pipeline CI/CD. Les Engagements CI/CD sont conçus pour importer des données de manière automatisée, déclenchée par une étape du processus de publication. + +| **Catégorie** | **Engagements Interactifs** | **Engagements CI/CD** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **Cas d'usage principal** | Tests de sécurité manuels ou ponctuels | Tests de sécurité automatisés et récurrents au sein des pipelines | +| **Durée** | Limitée dans le temps et finie | Durée potentiellement infinie | +| **Fréquence** | Périodique ou ponctuelle | Continue ou par commit | +| **Flux de travail** | Un testeur humain exécute l'outil → importe manuellement les résultats | Le pipeline exécute l'outil → envoie automatiquement les résultats vers DefectDojo | +| **Méthode d'importation des résultats** | Téléversement manuel via l'interface utilisateur ou la CLI | Importation pilotée par API via automatisation (par exemple, CLI, connecteurs, tâches cron, scripts de pipeline) | +| **Type de test habituel** | Tests d'intrusion, exercices red team, évaluations manuelles | Analyse statique, analyse des dépendances, analyse de conteneurs | + +### Données de l'Engagement + +En tant que conteneurs organisant l'activité de test, les Engagements peuvent stocker ou suivre diverses données : + +- Dates de début et de fin cibles +- Description et notes de périmètre +- Statut (en cours, planifié, terminé, etc.) +- Assigné / Responsable +- Tests associés (par exemple, analyses, tests d'intrusion, tests manuels, etc.) +- Constatations et types de Constatations (par exemple, actif, atténué, risque accepté, doublon, etc.) +- Modèles de menace ou informations sur l'acceptation du risque +- Étiquettes +- Fichiers et notes +- Paramètres du projet Jira +- Détails de l'environnement (par exemple, staging ou production) +- ID de build (si lié à un pipeline CI/CD) +- Données historiques des Tests précédents au sein de l'Engagement + +## Accès aux Engagements + +Les Engagements sont accessibles depuis la barre latérale. Le sous-menu donne accès aux Engagements actifs et à tous les Engagements, ainsi qu'à l'option de création de nouveaux Engagements. + +![image](images/engagement_ss13.png) + +Autrement, les Engagements d'un Actif sont accessibles dans la fenêtre située en bas de la vue de l'Actif. + +![image](images/engagement_ss14.png) + +### Autorisations + +Les Engagements se situent sous les Actifs et au-dessus des Tests dans la hiérarchie des objets. Ainsi, l'accès à un Actif accorde automatiquement l'accès à tous les Engagements qu'il contient. Les Engagements ne disposent pas de listes de contrôle d'accès indépendantes. + +## Utilisation des Engagements + +### Créer des Engagements + +Avant de créer un Engagement, vous devez d'abord avoir [créé un Actif](/asset_modelling/engagements_tests/pro__assets/#create-assets) pour le contenir. + +Il existe plusieurs façons de créer un Engagement : + +- Depuis le menu déroulant Engagements de la section Gérer de la barre latérale + - Vous devrez sélectionner l'Actif auquel attribuer l'Engagement en remplissant le formulaire Nouvel Engagement + +![image](images/engagement_ss1.png) + +- L'icône d'engrenage située en haut à droite de la vue d'un Actif + +![image](images/engagement_ss9.png) + +- Le bouton « + Nouvel Engagement » situé dans la liste des Engagements d'un Actif + +![image](images/engagement_ss2.png) + +- Si vous n'avez pas encore créé d'Engagement au sein d'un Actif, vous pouvez le faire lors de l'importation d'une analyse. + +![image](images/engagement_ss3.png) + +Chaque Engagement doit avoir les champs suivants définis : +- Type (Interactif ou CI/CD) +- Un nom unique +- Dates de début et de fin cibles + - Cela déterminera l'apparition de l'Engagement dans la section Calendrier +- Actif +- Statut + +#### Statuts d'Engagement + +Les Engagements peuvent être associés à différents statuts lors de leur création. Le statut peut également être modifié ultérieurement dans les paramètres de l'Engagement. + +Un Engagement peut avoir l'un des statuts suivants : +- Non démarré +- Bloqué +- Annulé +- Terminé +- En cours +- En attente +- Planifié +- En attente de ressource + +Faire passer le statut d'un Engagement à « Terminé » entraînera l'indisponibilité ou le masquage de la plupart des opérations d'écriture (par exemple, l'ajout de tests, l'importation d'analyses). Les autres statuts n'affectent pas de manière significative le fonctionnement de l'Engagement et servent principalement à des fins de filtrage ou d'information. + +### Modifier des Engagements + +Les Engagements peuvent être modifiés en cliquant sur **Modifier l'Engagement** dans le menu d'engrenage. Ce même menu est également accessible en cliquant sur le menu kebab ⋮ à gauche de l'Actif dans la vue Tous les Actifs. + +Tous les champs pouvant être modifiés par la suite sont également disponibles lors de la création de l'Engagement. + +![image](images/engagements_ss99.png) + +### Copier des Engagements + +Vous pouvez facilement dupliquer des Engagements en sélectionnant « Copier l'Engagement » dans les paramètres de l'Engagement. Cela crée une copie exacte de l'Engagement d'origine au sein de l'Actif parent, y compris les métadonnées, les Tests et les Constatations qu'il contient. + +### Fermer des Engagements + +Les Engagements sont fermés en sélectionnant **Fermer l'Engagement** dans les paramètres de l'Engagement. Une fois fermé, le statut de l'Engagement passera à « Terminé ». Néanmoins, la plupart des opérations d'écriture (par exemple, l'ajout de tests, l'importation d'analyses) resteront disponibles. + +La fermeture d'un Engagement ne modifie pas le statut des Constatations au sein des Tests de l'Engagement. Les Constatations restent actives, atténuées ou acceptées comme risque selon leur propre cycle de vie, et demeurent accessibles pour consultation et création de rapports. + +Si l'Engagement est lié à une Epic Jira (voir **[Intégration Jira : activer le mappage Engagement-Epic](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**), la fermeture de l'Engagement déclenchera une tâche asynchrone qui fermera l'Epic Jira associée dans votre Espace Jira connecté. + +### Rouvrir des Engagements + +Si un Engagement est fermé, il peut être rouvert en sélectionnant **Rouvrir l'Engagement** dans ses paramètres. Cela réactivera l'Engagement et ramènera son statut à « En cours ». + +### Engagements expirés + +Un Engagement expire une fois sa date de fin cible dépassée. + +Contrairement à la fermeture ou à la suppression d'un Engagement, l'expiration d'un Engagement n'a aucun impact direct sur son fonctionnement et sert principalement de mécanisme de suivi et de notification. + +Une fois expiré, une étiquette « En retard » apparaîtra à côté de l'Engagement, mais cela ne restreindra aucune de ses fonctionnalités. Le statut de l'Engagement continuera d'apparaître comme « En cours ». + +Bien que cette option ne soit pas activée par défaut, les paramètres système permettent de fermer automatiquement un Engagement une fois qu'il est expiré depuis un certain nombre de jours. + +![image](images/engagement_ss15.png) + +### Supprimer des Engagements + +La suppression d'un Engagement s'effectue en sélectionnant **Supprimer l'Engagement** dans les paramètres de l'Engagement. Cette action est irréversible. + +La suppression d'un Engagement supprimera également les éléments suivants : +Tous les Tests associés à l'Engagement +Toutes les Constatations au sein de ces Tests +Tous les mappages d'Epic Jira liés (l'Epic elle-même restera dans Jira, mais le lien entre DefectDojo et Jira sera supprimé) +Toutes les notes et tous les fichiers téléversés associés à l'Engagement + +À des fins d'audit, il est recommandé de fermer les Engagements terminés plutôt que de les supprimer. + +| **Opération** | **Résultats** | **Réversible** | +|----------|---------|------------| +| **Fermer** | Marque comme inactif ; les données sont conservées ; peut être rouvert | Oui (réouverture) | +| **Expirer** | Avertissement visuel uniquement ; fermeture automatique facultative ; notifications | N/A | +| **Supprimer** | Supprime définitivement l'Engagement, les Tests, les Constatations, les notes, les fichiers et tous les mappages d'Epic Jira (les Epics restent dans Jira) | Non | + +## Intégration Jira + +Les Engagements peuvent être liés à un Espace Jira connecté, ce qui permet de transmettre à Jira les Constatations de l'Engagement sous forme d'Issues. Pour un guide complet de configuration de Jira, consultez **[Connexion de DefectDojo à Jira](/connectors/downstream/pro__jira_guide/)**. + +### Mappage Engagement-Epic + +Lorsque **Activer le mappage Engagement-Epic** est coché dans les paramètres Jira d'un Produit, les Engagements sont transmis à Jira sous forme d'Epics. Les Constatations de l'Engagement sont transmises sous forme d'Issues enfants rattachées à l'Epic, reproduisant ainsi la hiérarchie Engagement → Constatations de DefectDojo dans la structure Epic → Issue de Jira. + +Pour plus d'informations sur ce paramètre, consultez **[Activer le mappage Engagement-Epic](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**. + +### Paramètres Jira au niveau de l'Engagement + +Par défaut, les Engagements héritent des paramètres Jira de leur Actif parent (Produit). Cependant, chaque Engagement peut individuellement remplacer ces paramètres pour utiliser des configurations Jira différentes. Les paramètres suivants peuvent être personnalisés par Engagement : + +- **Clé de projet** — achemine les Constatations vers un autre Espace Jira +- **Modèle d'Issue** — utilise un modèle différent pour les Issues créées à partir de cet Engagement +- **Champs personnalisés** — applique des mappages de champs personnalisés différents +- **Étiquettes Jira** — associe aux Issues des étiquettes spécifiques à l'Engagement +- **Assigné par défaut** — attribue les Issues à un autre membre de l'équipe + +Ces paramètres sont accessibles depuis la page **Modifier l'Engagement**. Pour plus de détails, consultez **[Paramètres Jira au niveau de l'Engagement](/connectors/downstream/pro__jira_guide/#engagement-level-jira-settings)**. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__engagements.ja.md b/docs/content/asset_modelling/engagements_tests/PRO__engagements.ja.md new file mode 100644 index 00000000000..4c790a77fca --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__engagements.ja.md @@ -0,0 +1,193 @@ +--- +title: エンゲージメント +description: DefectDojo Proにおけるエンゲージメントの理解 +audience: pro +weight: 3 +--- + +組織 → アセット → **エンゲージメント** → テスト → 検出事項 + +## 概要 + +DefectDojoのアセット階層において、エンゲージメントは、特定のアセット内で関連するテストのグループを表す、期間またはパイプラインに紐づくコンテナです。定期的であれ一度限りであれ、計画されたテスト作業がある場合、エンゲージメントはその関連結果すべてを保存する場所を提供します。 + +エンゲージメントの例には以下が含まれます。 +- 単発のペネトレーションテスト +- 毎月または四半期ごとの定期スキャン +- バグバウンティのレビュー期間 +- CI/CDパイプラインの実行(各パイプラインを個別のエンゲージメントとして扱うチームの場合) +- コードリリースサイクル(例:「v4.2リリースセキュリティレビュー」) + +### エンゲージメントタイプ + +DefectDojoは、**インタラクティブ**と**CI/CD**という2つのエンゲージメントタイプをサポートしています。これらのタイプは、テストが通常どのように作成され、スキャン結果がどのようにインポートされるかを決定します。 + +インタラクティブエンゲージメントは、通常エンジニアによって実行されます。インタラクティブエンゲージメントは、自動テスト、人間のテスター、またはアプリケーションの機能と「インタラクト」する何らかの活動を使用して、実行中のアプリケーションをテストすることに焦点を当てています。 + +CI/CDエンゲージメントは、CI/CDパイプラインとの自動連携のためのものです。CI/CDエンゲージメントは、リリースプロセスのステップによってトリガーされる自動アクションとしてデータをインポートすることを目的としています。 + +| **カテゴリ** | **インタラクティブエンゲージメント** | **CI/CDエンゲージメント** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **主な用途** | 手動またはアドホックなセキュリティテスト | パイプライン内での自動化された定期的なセキュリティテスト | +| **期間** | 期間限定で有限 | 潜在的に無期限 | +| **頻度** | 定期的または単発 | 継続的またはコミットごと | +| **ワークフロー** | 人間のテスターがツールを実行 → 結果を手動でインポート | パイプラインがツールを実行 → 結果を自動的にDefectDojoにプッシュ | +| **結果のインポート方法** | UIまたはCLI経由での手動アップロード | 自動化によるAPI駆動のインポート(例:CLI、コネクタ、cronジョブ、パイプラインスクリプト) | +| **典型的なテストタイプ** | ペネトレーションテスト、レッドチーム演習、手動評価 | 静的解析、依存関係スキャン、コンテナスキャン | + +### エンゲージメントデータ + +テスト活動を整理するコンテナとして、エンゲージメントはさまざまなデータを保存または追跡できます。 + +- 目標開始日と終了日 +- 説明とスコープに関するメモ +- ステータス(進行中、計画済み、完了など) +- 担当者/リード +- 関連するテスト(例:スキャン、ペネトレーションテスト、手動テストなど) +- 検出事項と検出事項のタイプ(例:アクティブ、緩和済み、リスク受容済み、重複など) +- 脅威モデルまたはリスク受容情報 +- タグ +- ファイルとメモ +- Jiraプロジェクト設定 +- 環境の詳細(例:ステージング環境か本番環境か) +- ビルドID(CI/CDに連携している場合) +- エンゲージメント内の過去のテストの履歴データ + +## エンゲージメントへのアクセス + +エンゲージメントにはサイドバーからアクセスできます。サブメニューから、アクティブなエンゲージメントとすべてのエンゲージメントにアクセスできるほか、新しいエンゲージメントを作成するオプションも利用できます。 + +![image](images/engagement_ss13.png) + +別の方法として、アセット内のエンゲージメントには、アセットのビュー下部にあるウィンドウからアクセスすることもできます。 + +![image](images/engagement_ss14.png) + +### 権限 + +エンゲージメントは、オブジェクト階層においてアセットの下、テストの上に位置します。そのため、アセットへのアクセス権があれば、そのアセット内のすべてのエンゲージメントへのアクセス権が自動的に付与されます。エンゲージメントは独自のアクセス制御リストを持ちません。 + +## エンゲージメントの操作 + +### エンゲージメントの作成 + +エンゲージメントを作成する前に、まずそれを格納する[アセットを作成しておく](/asset_modelling/engagements_tests/pro__assets/#create-assets)必要があります。 + +エンゲージメントを作成する方法はいくつかあります。 + +- サイドバーのManageセクションにあるエンゲージメントのドロップダウンから + - New Engagementフォームに入力する際、エンゲージメントを紐づけるアセットを選択する必要があります + +![image](images/engagement_ss1.png) + +- アセットビューの右上隅にある歯車アイコンから + +![image](images/engagement_ss9.png) + +- アセット内のエンゲージメント一覧にある「+ New Engagement」ボタンから + +![image](images/engagement_ss2.png) + +- アセット内にまだエンゲージメントを作成していない場合は、スキャンのインポート中に作成することもできます。 + +![image](images/engagement_ss3.png) + +すべてのエンゲージメントには、以下のフィールドを定義する必要があります。 +- タイプ(インタラクティブまたはCI/CD) +- 一意の名前 +- 目標開始日と終了日 + - これにより、カレンダーセクションでのエンゲージメントの表示が決まります +- アセット +- ステータス + +#### エンゲージメントのステータス + +エンゲージメントには、作成時にさまざまなステータスを設定できます。ステータスは、エンゲージメントの設定から後で変更することもできます。 + +エンゲージメントには、以下のいずれかのステータスを設定できます。 +- 未開始 +- ブロック中 +- キャンセル済み +- 完了 +- 進行中 +- 保留中 +- 予定済み +- リソース待ち + +エンゲージメントのステータスを「完了」に変更すると、テストの追加やスキャンのインポートなど、ほとんどの書き込み操作が利用できなくなるか、非表示になります。それ以外のステータスは、エンゲージメントの機能に実質的な影響を与えず、主にフィルタリングや情報提供の目的で使用されます。 + +### エンゲージメントの編集 + +エンゲージメントは、歯車メニュー内の**Edit Engagement**をクリックすることで編集できます。同じメニューには、All Assetsビューでアセットの左側にある⋮ kebabメニューをクリックすることでもアクセスできます。 + +編集可能な以降のフィールドはすべて、エンゲージメントの作成時にも利用できます。 + +![image](images/engagements_ss99.png) + +### エンゲージメントのコピー + +エンゲージメントの設定内で「Copy Engagement」を選択することで、エンゲージメントを簡単に複製できます。これにより、メタデータ、テスト、およびその中の検出事項を含む、元のエンゲージメントの完全なコピーが親アセット内に作成されます。 + +### エンゲージメントのクローズ + +エンゲージメントは、エンゲージメントの設定内で**Close Engagement**を選択することでクローズされます。クローズすると、エンゲージメントのステータスは「完了」に変更されます。ただし、テストの追加やスキャンのインポートなど、ほとんどの書き込み操作は引き続き利用可能です。 + +エンゲージメントをクローズしても、そのエンゲージメント内のテストにおける検出事項のステータスは変更されません。検出事項は、それぞれのライフサイクルに従ってオープン、緩和済み、またはリスク受容済みのままとなり、閲覧やレポート作成のためにアクセス可能な状態を維持します。 + +エンゲージメントがJira Epicにリンクされている場合(**[Jira連携:エンゲージメントEpicマッピングの有効化](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**を参照)、エンゲージメントをクローズすると、連携先のJiraスペース内の関連するJira Epicをクローズする非同期タスクがトリガーされます。 + +### エンゲージメントの再オープン + +エンゲージメントがクローズされている場合、その設定内で**Reopen Engagement**を選択することで再オープンできます。これにより、エンゲージメントは再びアクティブになり、ステータスは「進行中」に戻ります。 + +### 期限切れのエンゲージメント + +エンゲージメントは、目標終了日を過ぎると期限切れになります。 + +エンゲージメントのクローズや削除と比較して、エンゲージメントの期限切れはその機能に直接的な影響を与えず、主に監視/通知の仕組みとして機能します。 + +期限切れになると、エンゲージメントの横に「Overdue」タグが表示されますが、エンゲージメントの機能が制限されることはありません。エンゲージメントのステータスは引き続き「進行中」として表示されます。 + +デフォルトでは有効になっていませんが、システム設定内には、エンゲージメントが一定日数期限切れになった時点で自動的にクローズするオプションがあります。 + +![image](images/engagement_ss15.png) + +### エンゲージメントの削除 + +エンゲージメントの削除は、エンゲージメントの設定から**Delete Engagement**を選択することで実行できます。この操作は取り消せません。 + +エンゲージメントを削除すると、以下も削除されます。 +エンゲージメントに関連付けられたすべてのテスト +それらのテスト内のすべての検出事項 +リンクされているJira Epicマッピング(Epic自体はJira上に残りますが、DefectDojoとJiraの間のリンクは削除されます) +エンゲージメントに関連付けられたすべてのメモとファイルアップロード + +監査目的のため、完了したエンゲージメントは削除するのではなく、クローズすることを推奨します。 + +| **操作** | **結果** | **元に戻せるか** | +|----------|---------|------------| +| **クローズ** | 非アクティブとしてマークされる。データは残る。再オープン可能 | はい(再オープン) | +| **期限切れ** | 視覚的な警告のみ。オプションで自動クローズ。通知あり | 該当なし | +| **削除** | エンゲージメント、テスト、検出事項、メモ、ファイル、およびJira Epicマッピングを完全に削除(EpicはJiraに残る) | いいえ | + +## Jira連携 + +エンゲージメントは連携先のJiraスペースにリンクでき、エンゲージメント内の検出事項をJiraにIssueとしてプッシュできるようになります。Jiraの設定に関する完全なガイドについては、**[DefectDojoとJiraの連携](/connectors/downstream/pro__jira_guide/)**を参照してください。 + +### エンゲージメントEpicマッピング + +製品のJira設定で**Enable Engagement Epic Mapping**がチェックされている場合、エンゲージメントはJiraにEpicとしてプッシュされます。エンゲージメント内の検出事項は、そのEpicの下に子Issueとしてプッシュされ、DefectDojoのエンゲージメント → 検出事項の階層構造が、JiraのEpic → Issue構造として再現されます。 + +この設定の詳細については、**[エンゲージメントEpicマッピングの有効化](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**を参照してください。 + +### エンゲージメントレベルのJira設定 + +デフォルトでは、エンゲージメントは親アセット(製品)からJira設定を継承します。ただし、個々のエンゲージメントでこれらの設定を上書きし、別のJira設定を使用することもできます。以下の設定はエンゲージメントごとにカスタマイズできます。 + +- **Project Key** — 検出事項を別のJiraスペースにルーティングします +- **Issue Template** — このエンゲージメントから作成されるIssueに別のテンプレートを使用します +- **Custom Fields** — 別のカスタムフィールドマッピングを適用します +- **Jira Labels** — エンゲージメント固有のラベルでIssueにタグ付けします +- **Default Assignee** — Issueを別のチームメンバーに割り当てます + +これらの設定には、**Edit Engagement**ページからアクセスできます。詳細については、**[エンゲージメントレベルのJira設定](/connectors/downstream/pro__jira_guide/#engagement-level-jira-settings)**を参照してください。 diff --git a/docs/content/asset_modelling/engagements_tests/PRO__findings.de.md b/docs/content/asset_modelling/engagements_tests/PRO__findings.de.md new file mode 100644 index 00000000000..e8c994fd77e --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__findings.de.md @@ -0,0 +1,275 @@ +--- +title: Befunde +description: Befunde in DefectDojo Pro verstehen +audience: pro +weight: 5 +--- + +Organisationen → Assets → Engagements → Tests → **BEFUNDE** + +## Überblick +**Befunde** stellen die unterste Ebene der Produkthierarchie dar, auf der einzelne Schwachstellen erfasst und verwaltet werden. Sie sind die zentrale Methode, mit der DefectDojo den Melde- und Behebungsprozess Ihrer Sicherheitstools standardisiert und steuert. Unabhängig davon, ob eine Schwachstelle in SonarQube, Acunetix oder dem individuellen Tool Ihres Teams gemeldet wurde, ermöglichen Ihnen Befunde, jede Schwachstelle auf dieselbe Weise zu verwalten. + +Beispiele für Befunde sind: +- **Cookie Not Marked as HttpOnly** +- **Out-of-Date Version (PHP)** +- **Out-of-Band Code Evaluation (PHP)** +- **Out-of-Date Version (MySQL)** +- **Backup Source Code Detected** +- **Blind Cross-Site Scripting** + +Neben der Speicherung der Schwachstellendaten und der Bereitstellung eines Rahmens für die Behebung erweitert DefectDojo Ihre Befunde auch auf folgende Weise: +- Automatisches Hinzufügen zugehöriger EPSS-Werte zu einem Befund, um die Ausnutzbarkeit zu beschreiben +- Automatisches Übersetzen der Schweregrad-Metrik eines Sicherheitstools in einen Schweregrad-Wert für jeden Befund, wodurch dem Befund gemäß der SLA-Konfiguration Ihres Assets eine SLA zugewiesen wird. Weitere Informationen zur SLA-Konfiguration finden Sie [hier](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas). + +Insgesamt sind Befunde so konzipiert, dass sie mit der Produkthierarchie zusammenarbeiten, um Ihre Bemühungen zu standardisieren und für jedes Asset eine einheitliche Methode anzuwenden. + +## Zugriff auf Befunde +Befunde sind über die Seitenleiste zugänglich. Das Untermenü bietet Zugriff auf Aktive und Behobene Befunde, Alle Befunde (unabhängig vom Status Offen oder Geschlossen), Befundgruppen, Befundvorlagen und den Workflow für neue Befunde. Einzelne Befunde sind auch innerhalb des Tests zugänglich, der sie enthält. + +[Risikoakzeptierte Befunde] (/triage_findings/findings_workflows/os__risk_acceptance/) sind über den Bereich **Risikoakzeptanzen** in der Seitenleiste zugänglich. + +![image](images/profindings_ss1.png) + +### Berechtigungen +Jeder Befund gehört zu einem Test, sodass DefectDojo nachvollziehen kann, welcher Scan oder welche Bewertung die Schwachstelle ursprünglich identifiziert hat. + +Da Befunde zu Tests gehören, wird der Zugriff auf Befunde durch den Zugriff eines Benutzers auf das Asset bestimmt, das den Test enthält. Tests verfügen nicht über eigene Zugriffskontrolllisten. + +## Befundansicht +Befundansichten enthalten verschiedene Tabellen, die dabei helfen, den Status eines Befunds auf einen Blick zu erfassen. + +### Befundübersicht +- **Beschreibung**: Die Beschreibung des Befunds (je nach Art des Befunds automatisch hinzugefügt oder manuell erstellt). +- **Behebung**: Vorgeschlagene Schritte zur Behebung. +- **Allgemeine Behebungsrichtlinie**: Die standardisierte Behebungsrichtlinie für den ausgewählten Befund. +Behebungsrichtlinien finden Sie in der Seitenleiste unter **Konfiguration** → **Behebungsrichtlinien** und können dort bearbeitet werden. +- **Auswirkung**: Mögliche Auswirkung, wenn der Befund nicht behoben wird. +- **Referenzen**: URL, die auf die spezifische Beschreibung des Befunds durch das Drittanbieter-Scan-Tool verweist. Referenzen können beispielsweise Links zu einem relevanten Eintrag in einem Befundkatalog oder zu einer einzelnen Advisory-URL sein. +- **Dateien**: Alle Dateien, die zur Kontextualisierung des Befunds hinzugefügt wurden. +- **Notizen**: Von Benutzern hinterlassene Notizen zum Befund. Wenn eine Notiz als Privat markiert wird, ist sie in keinem generierten Bericht enthalten, der den ausgewählten Befund einschließt. + +### Metadaten +- **ID**: Die eindeutige Befund-ID von DefectDojo. +- **Organisation, Asset, Engagement und Test**: Die übergeordneten Objekte des ausgewählten Befunds. +- **Status**: Der Status des Befunds (z. B. Aktiv, Verifiziert, Falsch-positiv, Duplikat, Außerhalb des Geltungsbereichs und In Fehlerprüfung). +- **Schweregrad**: Die Schweregradbewertung dieses Befunds, die automatisch angewendet wird. + - Wie oben erwähnt, übersetzt DefectDojo automatisch die Schweregrad-Metrik eines Sicherheitstools in einen Schweregrad-Wert für jeden Befund, wodurch dem Befund gemäß der SLA-Konfiguration Ihres Assets eine SLA zugewiesen wird. +- **Risiko**: Ein vierstufiges Einstufungssystem, das die Ausnutzbarkeit eines Befunds berücksichtigt und automatisch angewendet wird. + - Details dazu, wie Priorität, Risiko und SLAs berechnet werden, finden Sie [hier](/asset_modelling/pro_hierarchy/priority_sla/#main-content). Weitere Details zu den Definitionen von Befundstatus und Risikostufen finden Sie [hier](/triage_findings/findings_workflows/finding_status_definitions/). +- **Priorität**: Ein berechneter numerischer Rang, der auf alle Befunde angewendet wird und es Ihnen ermöglicht, Schwachstellen schnell im Kontext zu verstehen. +- **Alter**: Wie alt der ausgewählte Befund ist. +- **SLA**: Das Fälligkeitsdatum, bis zu dem der Befund behoben werden soll. +- **Typ**: Ob der Befund von einem statischen oder dynamischen Anwendungssicherheitstool erkannt wurde (Statisch, Dynamisch oder Statisch/Dynamisch). +- **Speicherort und Zeile**: Die Datei und Zeilennummer, in der der ausgewählte Befund gefunden wurde. +- **Komponentenname und -version**: Der Name und die Version der Komponente, in der der ausgewählte Befund gefunden wurde. +- **Entdeckungsdatum**: Das Datum, an dem der Befund entdeckt wurde. +- **Geplantes Behebungsdatum und -version**: Das Datum, an dem der Befund voraussichtlich behoben wird, sowie die Version der betroffenen Komponente, in der die Korrektur implementiert wird. +- **Dienst**: Verbundene Dienste (in sich geschlossene Funktionseinheiten innerhalb eines Assets), die vom ausgewählten Befund betroffen sind. Wenn dieses Feld ausgefüllt ist, wird es beim Deduplizierungsabgleich berücksichtigt (d. h. Befunde mit identischen Dienst-Feldern werden dedupliziert). +- **Melder**: Der Benutzer, der den Befund aufgedeckt hat. +- **CWE**: Die CWE-Schwachstellenklassifizierung des Befunds. Ein Befund kann **mehrere CWEs** tragen — eine primäre CWE sowie alle zusätzlichen CWEs, die vom meldenden Tool bereitgestellt wurden. Die primäre CWE wird für die klassische Deduplizierung und die Hash-Code-Berechnung verwendet; der vollständige CWE-Satz kann zusätzlich für den Abgleich über die mengenbasierten Hash-Code-Felder von Pro verwendet werden (siehe [Deduplizierungs-Tuning](/triage_findings/finding_deduplication/pro__deduplication_tuning/#set-based-hash-code-fields-vulnerability-ids-and-cwes)). + - Eine CWE beschreibt eine Schwachstellen*klasse* (zum Beispiel „SQL Injection"), keine konkrete Schwachstelleninstanz — dafür sind Schwachstellen-IDs da. +- **Schwachstellen-IDs**: Öffentlich anerkannte Schwachstellenkennungen, die mit dem Befund verknüpft sind, wie z. B. CVE, GHSA oder andere standardisierte Advisory-Referenzen. In DefectDojo Pro werden sie außerdem für EPSS- und KEV-Abfragen verwendet. + - Schwachstellen-IDs werden als eigenständige Datensätze gespeichert, sodass dieselbe CVE nur einmal erfasst und von jedem Befund gemeinsam genutzt wird, der auf sie verweist. Sie können sie — zusammen mit ihren EPSS- und KEV-Werten — im **Schwachstellen-Explorer** einsehen. Siehe [EPSS / KEV](/triage_findings/finding_scoring/epss_kev/#viewing-kevepss-in-the-vulnerability-explorer). +- **Eindeutige ID vom Tool**: Eine stabile Kennung, die vom Quelltool einer bestimmten Befundinstanz zugewiesen wird. Eindeutige IDs sollen bei wiederholten Scans konsistent bleiben, sodass das Tool denselben Befund im Laufe der Zeit wiedererkennen kann. + - Im Gegensatz zu Schwachstellen-IDs ist dieser Wert proprietär für das meldende Tool und keine öffentliche Schwachstellenreferenz. + - Beispiel: `finding-12345` +- **Schwachstellen-ID vom Tool**: Eine proprietäre Schwachstellen- oder Regelkennung, die vom Quelltool zugewiesen wird, um die Art der erkannten Schwachstelle zu beschreiben. + - Im Gegensatz zur eindeutigen ID vom Tool ist diese Kennung nicht für einen einzelnen Befund eindeutig und kann bei vielen Befunden auftreten, die derselben Erkennungsregel entsprechen. + - Im Gegensatz zu Schwachstellen-IDs sind diese Kennungen spezifisch für das meldende Tool und nicht öffentlich standardisiert. + - Beispiel: `semgrep.rule.lang.security.sql-injection` +- **EPSS-Score / Perzentil**: EPSS-Score und Perzentil für die CVE. +- **Bekannt ausgenutzt**: Ob bestätigt wurde, dass die Schwachstelle ausgenutzt wurde. +- **Ransomware eingesetzt**: Ob Ransomware bei der Ausnutzung der Schwachstelle beteiligt war. +- **KEV-Datum**: Das Datum, an dem der Befund dem KEV-Katalog hinzugefügt wurde. +- **Gefunden von**: Der Typ des Tools, das die Schwachstelle identifiziert hat. +- **CVSSv3- und CVSSv4-Vektor und -Score**: Der CVSS3- und CVSS4-Vektor und -Score des ausgewählten Befunds. +- **Integrator-Tickets**: Ticketnummern von Drittanbieter-Issue-Trackern, die mit dem Befund verknüpft sind. + +### Betroffene Endpunkte +Dieser Abschnitt enthält eine Tabelle der Endpunkte, die vom ausgewählten Befund betroffen sind, zusammen mit allen relevanten Metadaten. + +### Zusätzliche Details +- **Anfrage-/Antwort-Paare**: Eine Kopie der vom Client gesendeten Nachricht und der Antwort des Servers auf die Anfrage. +- **Schritte zur Reproduktion**: Schritte zur Reproduktion des Befunds. +- **Schweregrad-Begründung**: Schriftliche Beschreibung, warum dem Befund eine bestimmte Schweregradbewertung zugeordnet wurde. + +## Befunddaten +Befunde erfordern die folgenden Metadaten: +- **Name** +- **Datum** +- **Schweregrad** +- **Beschreibung** + +Zusätzlich zu den Metadaten, die den Tabellen in der Ansicht eines Befunds entsprechen, umfassen die optionalen Metadatenfelder: +- **Tags**: Alle Tags, die dem Befund hinzugefügt wurden. +- **Verantwortliche**: Die Gruppe von Benutzern, die für den ausgewählten Befund verantwortlich sein wird. +- **Push to Jira**: Überträgt den Befund zu Ticketzwecken an Jira. +- **Push to Integrator**: Überträgt den Befund an alle integrierten Drittanbieter-Issue-Tracker. +- **Risiko- und Prioritätseinstellungen**: Bietet die Möglichkeit, die automatische Berechnung von Risiko und Priorität des Befunds durch DefectDojo zu überschreiben. +- **Hinzuzufügende Endpunkte**: Betroffene Endpunkte, die vom ausgewählten Befund betroffen sein könnten und nicht in der vorstehenden Liste der Systeme/Endpunkte enthalten sind. +- **Fehlerprüfung angefordert von**: Erfasst, wer eine Fehlerprüfung für den betreffenden Mangel angefordert hat. +- **SAST-Quellobjekt, Zeilennummer und Dateipfad**: Quellobjekt, Zeilennummer und Dateipfad des Angriffsvektors. +- **SAST-Sink-Objekt**: Sink-Objekt des Angriffsvektors. +- **Anzahl der Vorkommen**: Anzahl der Vorkommen im Quelltool, wenn mehrere Schwachstellen gefunden und vom Scanner aggregiert wurden. +- **Veröffentlichungsdatum**: Das Datum, an dem die Schwachstelle veröffentlicht wurde. +- **Aufwandsschätzung**: Der Aufwand, der mit der Behebung des Befunds verbunden ist (z. B. Niedrig, Mittel oder Hoch). + +Welche Metadaten genau verfügbar sind, hängt vom Parser/Scanner ab, der den Befund aufgedeckt hat. Manche liefern nur grundlegende Informationen wie Titel und Schweregrad, während andere CVSS-Vektoren, betroffene Komponenten, Endpunkte, Anfrage-/Antwort-Paare und weitere scannerspezifische Metadaten enthalten. + +Diese Metadaten verbessern die Filterung, Berichterstellung und Priorisierung in Ihrem gesamten Sicherheitsprogramm und ermöglichen eine langfristige Nachverfolgung und Trendanalyse. Weitere Details und Beschreibungen der Metadaten finden Sie [hier](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page). + +### Deduplizierung +DefectDojo verfügt über Deduplizierungsfunktionen, die dabei helfen, Befunde zu identifizieren und zu verwalten, die dieselbe zugrunde liegende Schwachstelle darstellen. Beim Import von Scan-Ergebnissen aus einem oder mehreren Tools verwendet DefectDojo eine konfigurierbare Abgleichlogik, um Befunde zu identifizieren, die dieselbe Schwachstelle darstellen. + +Die Deduplizierung verhindert, dass dieselbe Schwachstelle mehrfach erscheint, wenn sie wiederholt von demselben oder verschiedenen Scannern entdeckt wird, sodass der Behebungsverlauf einem einzigen Befund zugeordnet bleibt. + +Weitere Informationen zur Deduplizierung finden Sie [hier](/triage_findings/finding_deduplication/about_deduplication/). + +### Reimport +Die Reimport-Funktion von DefectDojo ermöglicht die Aktualisierung von Befunden beim Import neuer Scan-Ergebnisse. Wird ein Scan reimportiert, vergleicht DefectDojo die eingehenden Ergebnisse mit bestehenden Befunden und aktualisiert übereinstimmende Datensätze, anstatt völlig neue zu erstellen. Dadurch bleiben wertvolle Kontextinformationen wie Statusänderungen, Behebungsverlauf, Kommentare und Zuständigkeitsinformationen erhalten, sodass ein durchgehender Verlauf des Lebenszyklus eines Befunds über mehrere Testzyklen hinweg entsteht. + +Weitere Informationen zur Reimport-Funktion finden Sie [hier](/import_data/import_intro/reimport/). + +### Risikoakzeptanzen +Risikoakzeptanzen sind ein besonderer Status, der auf Befunde angewendet werden kann, um die Entscheidung, sie anzuerkennen, ohne sie sofort zu beheben, formell zu dokumentieren und umzusetzen. + +Weitere Informationen zu Risikoakzeptanzen finden Sie [hier](/triage_findings/findings_workflows/pro__risk_acceptance/). + +### Status +Jeder in DefectDojo erstellte Befund verfügt über einen Status, der relevante Informationen vermittelt und Ihrem Team hilft, den Fortschritt bei der Behebung von Problemen zu verfolgen. + +Weitere Informationen zu Status finden Sie [hier](/triage_findings/findings_workflows/finding_status_definitions/). + +## Arbeiten mit Befunden + +### Befunde erstellen +Während die meisten Befunde automatisch durch Scan-Importe und Integrationen erzeugt werden, unterstützt DefectDojo auch die manuelle Erstellung von Befunden. Manuelle Befunde sind nützlich, um Schwachstellen und Sicherheitsbedenken zu erfassen, die durch Penetrationstests, Architekturüberprüfungen, Compliance-Bewertungen, Bug-Bounty-Programme, Beratereinsätze oder andere Aktivitäten identifiziert wurden, die keine Scanner-Ausgabe erzeugen. + +Befunde können manuell hinzugefügt werden, indem Sie entweder auf **Neuer Befund** im Bereich **Befunde** der Seitenleiste klicken oder **Befund hinzufügen** im Zahnradmenü des Tests auswählen, dem Sie den Befund hinzufügen möchten. + +### Befunde bearbeiten +Das ⋮-Kebab-Menü neben Befunden enthält die folgenden Funktionen: +- **Befund bearbeiten**: Bearbeitet den Befund. +- **Befund kopieren**: Erstellt eine Kopie des Befunds in einem anderen Test. Die Kopie kann in jedem Test innerhalb desselben Engagements gespeichert werden, für den Sie über Bearbeitungsrechte verfügen. Das Kopieren ist nützlich, wenn dieselbe Schwachstelle in mehr als einem Testkontext separat verfolgt werden muss. +- **Befund schließen**: Startet den Prozess zum Schließen des Befunds. +- **Überprüfung anfordern**: Startet den Peer-Review-Prozess und ändert den Status des Befunds in „In Überprüfung". Weitere Informationen zu Peer-Reviews finden Sie [hier](/triage_findings/findings_workflows/finding_status_definitions/#under-review). +- **Risikoakzeptanz hinzufügen**: Startet den Risikoakzeptanzprozess. Weitere Informationen finden Sie [hier](/triage_findings/findings_workflows/pro__risk_acceptance/). +- **Datei hinzufügen**: Startet den Prozess zum Hinzufügen einer Datei zum Befund (siehe Abschnitt unten). +- **Notiz hinzufügen**: Startet den Prozess zum Hinzufügen einer Notiz zum Befund. +- **Benutzerdefiniertes Feld hinzufügen**: Öffnet ein Pop-up, mit dem Sie ein benutzerdefiniertes Feld hinzufügen und definieren können, das auf den Befund angewendet wird. +- **Push to Jira**: Überträgt den Befund zu Ticketzwecken an Jira. +- **Push to Integrator**: Überträgt den Befund an alle integrierten Drittanbieter-Issue-Tracker. +- **Befund löschen**: Löscht den ausgewählten Befund. +- **Befundverlauf**: Zeigt den Verlauf des ausgewählten Befunds an. + +#### Dateien an Befunde anhängen +Sie können jedem Befund Dateien anhängen, um zusätzlichen Kontext bereitzustellen — zum Beispiel einen Screenshot einer Schwachstelle in Aktion oder ein Proof-of-Concept-Bild. + +Unterstützte Dateitypen sind unter anderem: + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +Um einem Befund eine Datei anzuhängen, klicken Sie entweder im ⋮-Kebab-Menü oder im Zahnradmenü des ausgewählten Befunds auf **Datei hinzufügen**. Geben Sie einen Titel für die Datei ein, wählen Sie die Datei von Ihrem Computer aus und klicken Sie auf **Absenden**. + +Die Datei erscheint anschließend im Abschnitt Dateien der Tabelle **Testübersicht** in der Ansicht des Befunds. + +#### Befunde in großen Mengen bearbeiten +Befunde können aus einer Befundliste heraus in großen Mengen bearbeitet werden, z. B. aus der über die Seitenleiste zugänglichen Tabelle Alle Befunde oder aus der Tabelle der Befunde innerhalb eines bestimmten Tests. + +Weitere Informationen zur Massenbearbeitung von Befunden finden Sie [hier](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings). + +### Befunde schließen +Sobald die Arbeit an einem Befund abgeschlossen ist, können Sie ihn manuell schließen, indem Sie im ⋮-Kebab-Menü oder im Zahnradmenü des Befunds auf **Befund schließen** klicken. Alternativ wird ein zuvor erfasster Befund automatisch geschlossen, wenn ein Scan erneut in DefectDojo importiert wird, der diesen Befund nicht mehr enthält. + +Wenn keine Befunde geschlossen werden sollen, können Sie dieses Verhalten im Formular Scan reimportieren deaktivieren: + +- Deaktivieren Sie das Kontrollkästchen Alte Befunde schließen, wenn Sie die Benutzeroberfläche verwenden +- Setzen Sie close_old_findings auf False, wenn Sie die API verwenden ​ + +### Befunde löschen +Das Löschen eines Befunds kann über das ⋮-Kebab-Menü oder das Zahnradmenü des Befunds erfolgen. Diese Aktion kann nicht rückgängig gemacht werden. + +Aus Audit-Gründen wird empfohlen, behobene Befunde zu schließen, anstatt sie zu löschen. + +## Befundgruppen +**Befundgruppen** ermöglichen es Ihnen, mehrere zusammengehörige Befunde für Triage, Berichterstellung und Koordination der Behebung als eine einzige logische Einheit zu behandeln. + +Ein Scan könnte beispielsweise 10 SQL-Injection-Befunde über verschiedene Endpunkte hinweg erzeugen. Anstatt jeden einzeln zu verwalten, können Sie sie zu einer einzigen Befundgruppe zusammenfassen, die das übergreifende SQL-Injection-Problem repräsentiert. + +Eine Befundgruppe ersetzt nicht die einzelnen Befunde. Jeder Befund existiert weiterhin mit seinem eigenen Schweregrad, Status, seinen Metadaten, Kommentaren und seinem Behebungsverlauf. Eine Befundgruppe bietet lediglich eine zusätzliche organisatorische Ebene über den darin enthaltenen Befunden. + +### Auf Befundgruppen zugreifen +Befundgruppen sind über die Seitenleiste zugänglich. Das Untermenü bietet Zugriff auf Offene und Geschlossene Befundgruppen sowie auf Alle Befundgruppen (unabhängig vom Status Offen). + +![image](images/profindings_ss1.png) + +### Befundgruppen erstellen +Befundgruppen können entweder manuell oder automatisch erstellt werden. + +Zu beachten ist, dass Befundgruppen nur aus den Befunden erstellt werden können, die in einem einzigen Test enthalten sind. Befunde aus unterschiedlichen Tests, Engagements oder Produkten können nicht derselben Befundgruppe hinzugefügt werden. + +#### Manuelle Befundgruppen +Um Befundgruppen-Aktionen manuell durchzuführen: +1. Navigieren Sie zu einer Liste von Befunden innerhalb eines Tests. +2. Wählen Sie die Befunde aus, die Sie einer Befundgruppe hinzufügen möchten, indem Sie das entsprechende Kontrollkästchen des Befunds anklicken. +3. Klicken Sie auf die Schaltfläche **Befundgruppe**, die oben in der Befundliste erscheint. +4. Klicken Sie auf die entsprechende Aktion, die Sie durchführen möchten. + - **Add to New Finding Group**: Erstellt eine neue Befundgruppe, die die ausgewählten Befunde enthält. + - **Add to Existing Finding Group**: Fügt die ausgewählten Befunde einer bereits vorhandenen Befundgruppe hinzu. + - **Remove from Finding Group**: Entfernt die ausgewählten Befunde aus allen Befundgruppen, denen sie zuvor angehörten. +5. Klicken Sie auf **Absenden**. + +Beachten Sie, dass die Gruppierung deaktiviert ist, sofern nicht jeder ausgewählte Befund bearbeitbar, ungruppiert und im selben Test ist. + +Beachten Sie außerdem, dass bei der Auswahl von Befunden aus der Liste Alle Befunde nur die Aktion möglich ist, die ausgewählten Befunde aus einer Befundgruppe zu entfernen. Das liegt daran, dass Befundgruppen, wie bereits erwähnt, nur aus den Befunden erstellt werden können, die in einem einzigen Test enthalten sind. + +#### Automatische Befundgruppen +Beim Import eines Scans kann die Funktion **Group By** im ausklappbaren Menü **Optional Fields** automatisch Befundgruppen basierend auf einer gewählten Gruppierungsmethode erstellen. Dies ist nützlich, wenn ein Scanner viele zusammengehörige Befunde erzeugt, die gemeinsam verwaltet werden sollten. + +Das dazugehörige Kontrollkästchen **Create Finding Groups for all Findings** erfüllt zwei Funktionen: +- **Aktiviert**: Erstellt für jeden importierten Befund eine Befundgruppe, auch wenn dieser Befund das einzige Mitglied der Gruppe ist. +- **Deaktiviert**: Erstellt Befundgruppen nur, wenn tatsächlich mehrere Befunde zusammen gruppiert werden können. + +![image](images/profindings_ss2.png) + +Wenn beim Import keine Option aus dem Dropdown-Menü Group By ausgewählt wird (z. B. **Finding Title** im obigen Screenshot usw.), erfolgt keine Gruppierung. + +Wenn das Gruppierungskriterium (z. B. Komponentenname, Schwachstellen-ID, Befundtitel usw.) im Befund nicht ausgefüllt ist, wird für ihn keine Gruppe erstellt und er wird auch keiner bestehenden Befundgruppe hinzugefügt. + +Wenn ein Scan importiert wird, der 10 nicht gruppierte Befunde aufdeckt, und derselbe Scan anschließend reimportiert wird, wobei die Befunde diesmal gruppiert werden, werden die ersten 10 Befunde nicht dieser Befundgruppe hinzugefügt (d. h., die Befundgruppe enthält nur die 10 Befunde aus dem Reimport, nicht die 10 Befunde aus dem ursprünglichen Import). + +## Befundvorlagen +**Befundvorlagen** ermöglichen es Benutzern, wiederverwendbare Vorlagen für häufig gemeldete Schwachstellen und Sicherheitsprobleme zu erstellen. Eine Vorlage kann standardisierte Informationen wie Titel, Beschreibung, Auswirkung, Schritte zur Reproduktion, Behebung, Referenzen und weitere Befund-Metadaten enthalten. + +Befundvorlagen sind besonders nützlich in Situationen, in denen Benutzer wiederholt manuelle Befunde erstellen müssen und die erneute Eingabe derselben unterstützenden Informationen jedes Mal vermeiden möchten. + +### Auf Befundvorlagen zugreifen +Befundvorlagen finden Sie im Untermenü Befunde in der Seitenleiste. + +![image](images/profindings_ss1.png) + +### Befundvorlagen erstellen +Befundvorlagen können erstellt werden, indem Sie oben links in der Ansicht Befundvorlagen auf die Schaltfläche **Neue Befundvorlage** klicken. + +Die daraufhin angezeigte Seite bietet einen Überblick über die Metadaten, die auf einen Befund angewendet werden, wenn eine Befundvorlage verwendet wird. + +### Befundvorlagen anwenden +Befundvorlagen unterscheiden sich zwischen OS DefectDojo und DefectDojo Pro. In Pro können Befundvorlagen nicht auf bereits vorhandene Befunde angewendet werden, und sie können auch nicht auf Grundlage bereits vorhandener Befunde erstellt werden. + +Sie können jedoch manuell einen Befund basierend auf einer Befundvorlage zu einem Test hinzufügen, entweder über das ⋮-Kebab-Menü neben dem Test in der Ansicht des übergeordneten Engagements oder über das Zahnradmenü in der Ansicht des Tests. + +![image](images/profindings_ss3.png) + +![image](images/profindings_ss4.png) + +## Berichterstellung +Mit dem Report-Builder von DefectDojo können Sie aus einer Reihe von Inhalts-Widgets einen benutzerdefinierten Bericht zusammenstellen, ihn ausführen und das Ergebnis exportieren (zum Beispiel durch Drucken als PDF). Benutzerdefinierte Berichte können die Befunde oder Endpunkte zusammenfassen, die Sie mit einem externen Publikum teilen möchten, und können Branding sowie Standardtexte enthalten. + +Weitere Informationen zum Report-Builder von DefectDojo finden Sie [hier](/metrics_reports/reports/report-builder/). + +### Befunde exportieren +Seiten, die eine Liste von Befunden oder eine Liste von Engagements anzeigen, verfügen oben links über eine CSV- und Excel-Exportoption. Bei Befunden gibt es außerdem die Möglichkeit eines Schnellexports, der einen neuen Tab mit Tabellen der Metadaten zu jedem Befund öffnet. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__findings.es.md b/docs/content/asset_modelling/engagements_tests/PRO__findings.es.md new file mode 100644 index 00000000000..f33abc9f6d5 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__findings.es.md @@ -0,0 +1,275 @@ +--- +title: Hallazgos +description: Cómo funcionan los Hallazgos en DefectDojo Pro +audience: pro +weight: 5 +--- + +Organizations → Activos → Compromisos → Tests → **HALLAZGOS** + +## Descripción general +Los **Hallazgos** representan el nivel más bajo de la Jerarquía de Productos, donde se rastrean y gestionan las vulnerabilidades individuales, y constituyen la forma principal en que DefectDojo estandariza y guía el proceso de generación de informes y remediación de sus herramientas de seguridad. Independientemente de si una vulnerabilidad fue reportada en SonarQube, Acunetix o la herramienta personalizada de su equipo, los Hallazgos le permiten gestionar cada vulnerabilidad de la misma manera. + +Ejemplos de Hallazgos incluyen: +- **Cookie no marcada como HttpOnly** +- **Versión desactualizada (PHP)** +- **Evaluación de código fuera de banda (PHP)** +- **Versión desactualizada (MySQL)** +- **Código fuente de respaldo detectado** +- **Cross-Site Scripting ciego** + +Además de almacenar los datos de la vulnerabilidad y proporcionar un marco de remediación, DefectDojo también mejora sus Hallazgos de las siguientes maneras: +- Agregar automáticamente las puntuaciones EPSS relacionadas a un Hallazgo para describir su explotabilidad +- Traducir automáticamente la métrica de severidad de una herramienta de seguridad en una puntuación de Severidad para cada Hallazgo, lo que otorga un SLA al Hallazgo según la configuración de SLA de su Activo. Para obtener más información sobre la configuración de SLA, haga clic [aquí](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas). + +En general, los Hallazgos están diseñados para funcionar junto con la Jerarquía de Productos, con el fin de estandarizar sus esfuerzos y aplicar un método coherente a cada Activo. + +## Acceso a los Hallazgos +Se puede acceder a los Hallazgos desde la barra lateral. El submenú brinda acceso a los Hallazgos Activos y Mitigados, a Todos los Hallazgos (independientemente de su estado Abierto o Cerrado), a los Grupos de Hallazgos, a las Plantillas de Hallazgos y al flujo de trabajo de Nuevo Hallazgo. También se puede acceder a los Hallazgos individuales desde dentro del Test que los contiene. + +[Hallazgos con Riesgo aceptado] (/triage_findings/findings_workflows/os__risk_acceptance/) son accesibles desde la sección **Risk Acceptances** de la barra lateral. + +![image](images/profindings_ss1.png) + +### Permisos +Cada Hallazgo pertenece a un Test, lo que permite a DefectDojo conservar qué análisis o evaluación identificó originalmente la vulnerabilidad. + +Dado que los Hallazgos pertenecen a Tests, el acceso a los Hallazgos está determinado por el acceso de un Usuario al Activo que contiene el Test. Los Tests no tienen listas de control de acceso independientes. + +## Vista de Hallazgos +Las vistas de Hallazgos contienen una variedad de tablas que ayudan a interpretar de un vistazo el estado de un Hallazgo. + +### Resumen del Hallazgo +- **Description**: La descripción del Hallazgo (agregada automáticamente según el tipo de Hallazgo, o creada manualmente). +- **Mitigation**: Pasos sugeridos para mitigar. +- **General Mitigation Policy**: La política de mitigación estandarizada para el Hallazgo seleccionado. +Las políticas de mitigación se pueden consultar y editar en la barra lateral, en **Configuration** → **Mitigation Policies**. +- **Impact**: El impacto potencial de dejar el Hallazgo sin resolver. +- **References**: URL para hacer referencia cruzada a la descripción específica del Hallazgo proporcionada por la herramienta de análisis de terceros. Por ejemplo, las Referencias podrían ser enlaces a una entrada relevante en un catálogo de Hallazgos, o una única URL de un aviso. +- **Files**: Cualquier archivo que se haya agregado para contextualizar el Hallazgo. +- **Notes**: Notas dejadas por los Usuarios relacionadas con el Hallazgo. Marcar una nota como Privada implica que no se incluirá en ningún informe generado que contenga el Hallazgo seleccionado. + +### Metadatos +- **ID**: El ID único del Hallazgo en DefectDojo. +- **Organization, Asset, Engagement, and Test**: Los objetos principales del Hallazgo seleccionado. +- **Status**: El estado del Hallazgo (por ejemplo, Activo, Verificado, Falso positivo, Duplicado, Fuera de alcance y En revisión de defecto). +- **Severity**: La calificación de severidad de ese Hallazgo, que se aplica automáticamente. + - Como se mencionó anteriormente, DefectDojo traduce automáticamente la métrica de severidad de una herramienta de seguridad en una puntuación de Severidad para cada Hallazgo, lo que otorga un SLA al Hallazgo según la configuración de SLA de su Activo. +- **Risk**: Un sistema de clasificación de 4 niveles que tiene en cuenta la explotabilidad de un Hallazgo y se aplica automáticamente. + - Puede encontrar detalles sobre cómo se calculan la prioridad, el riesgo y los SLA [aquí](/asset_modelling/pro_hierarchy/priority_sla/#main-content). Puede encontrar más detalles sobre las definiciones de estado y nivel de riesgo de los Hallazgos [aquí](/triage_findings/findings_workflows/finding_status_definitions/). +- **Priority**: Un rango numérico calculado que se aplica a todos los Hallazgos y que le permite comprender rápidamente las vulnerabilidades en su contexto. +- **Age**: Cuánto tiempo lleva abierto el Hallazgo seleccionado. +- **SLA**: La fecha límite en la que se espera que el Hallazgo esté resuelto. +- **Type**: Si el Hallazgo fue detectado por una herramienta de seguridad de aplicaciones estática o dinámica (Estático, Dinámico o Estático/Dinámico). +- **Location and Line**: El archivo y el número de línea en los que se encontró el Hallazgo seleccionado. +- **Component Name and Version**: El nombre y la versión del componente en el que se encontró el Hallazgo seleccionado. +- **Date Discovered**: La fecha en la que se descubrió el Hallazgo. +- **Planned Remediation Date and Version**: La fecha en la que está previsto remediar el Hallazgo, y la versión del componente afectado en la que se implementará la corrección. +- **Service**: Los Servicios conectados (partes autónomas de funcionalidad dentro de un Activo) que se ven afectados por el Hallazgo seleccionado. Cuando está completo, este campo se incluye en la coincidencia de deduplicación (es decir, los Hallazgos con campos de Servicio idénticos se deduplicarán). +- **Reporter**: El Usuario que reveló el Hallazgo. +- **CWE**: La clasificación de debilidad CWE del Hallazgo. Un Hallazgo puede tener **múltiples CWE** — un CWE principal, más cualquier CWE adicional proporcionado por la herramienta de reporte. El CWE principal es el que se utiliza para la deduplicación heredada y el cálculo del código hash; el conjunto completo de CWE también se puede utilizar para la coincidencia mediante los Campos de código hash basados en conjuntos de Pro (consulte [Deduplication Tuning](/triage_findings/finding_deduplication/pro__deduplication_tuning/#set-based-hash-code-fields-vulnerability-ids-and-cwes)). + - Un CWE describe una *clase* de debilidad (por ejemplo, "Inyección SQL"), no una instancia específica de vulnerabilidad — para eso están los ID de vulnerabilidad. +- **Vulnerability IDs**: Identificadores de vulnerabilidad reconocidos públicamente y asociados con el Hallazgo, como CVE, GHSA u otras referencias de asesorías estandarizadas. En DefectDojo Pro, también se utilizan para realizar búsquedas de EPSS y KEV. + - Los ID de vulnerabilidad se almacenan como registros de primera clase, por lo que el mismo CVE se rastrea una sola vez y es compartido por todos los Hallazgos que lo referencian. Puede revisarlos — junto con sus valores de EPSS y KEV — en el **Vulnerability Explorer**. Consulte [EPSS / KEV](/triage_findings/finding_scoring/epss_kev/#viewing-kevepss-in-the-vulnerability-explorer). +- **Unique ID From Tool**: Un identificador estable asignado por la herramienta de origen a una instancia específica de Hallazgo. Los ID únicos están diseñados para mantenerse consistentes a través de análisis repetidos, lo que permite que la herramienta reconozca el mismo Hallazgo a lo largo del tiempo. + - A diferencia de los ID de vulnerabilidad, este valor es propio de la herramienta de reporte y no es una referencia pública de vulnerabilidad. + - Ejemplo: `finding-12345` +- **Vulnerability ID From Tool**: Un identificador de vulnerabilidad o regla propio, asignado por la herramienta de origen para describir el tipo de vulnerabilidad detectada. + - A diferencia del ID único de la herramienta, este identificador no es exclusivo de un Hallazgo individual y puede aparecer en muchos Hallazgos que coincidan con la misma regla de detección. + - A diferencia de los ID de vulnerabilidad, estos identificadores son específicos de la herramienta de reporte y no están estandarizados públicamente. + - Ejemplo: `semgrep.rule.lang.security.sql-injection` +- **EPSS Score / Percentile**: Puntuación y percentil EPSS para el CVE. +- **Known Exploited**: Si existe confirmación de que la vulnerabilidad ha sido explotada. +- **Ransomware Used**: Si se utilizó ransomware en la explotación de la vulnerabilidad. +- **KEV Date**: La fecha en la que el Hallazgo se agregó al catálogo KEV. +- **Found By**: El tipo de herramienta que identificó la vulnerabilidad. +- **CVSSv3 and CVSSv4 Vector and Score**: El vector y la puntuación CVSS3 y CVSS4 del Hallazgo seleccionado. +- **Integrator Tickets**: Números de ticket de sistemas de seguimiento de incidencias de terceros asociados con el Hallazgo. + +### Endpoints vulnerables +Esta sección incluye una tabla de los Endpoints afectados por el Hallazgo seleccionado, junto con cualquier metadato relevante. + +### Detalles adicionales +- **Request/Response Pairs**: Una copia del mensaje enviado por el cliente y la respuesta del servidor a la solicitud. +- **Steps to Reproduce**: Pasos para reproducir el Hallazgo. +- **Severity Justification**: Descripción escrita de por qué se asoció una determinada calificación de Severidad al Hallazgo. + +## Datos de los Hallazgos +Los Hallazgos requieren los siguientes metadatos: +- **Name** +- **Date** +- **Severity** +- **Description** + +Además de los metadatos correspondientes a las tablas en la vista de un Hallazgo, los campos de metadatos opcionales incluyen: +- **Tags**: Cualquier etiqueta que se haya agregado al Hallazgo. +- **Owners**: El grupo de usuarios que será responsable del Hallazgo seleccionado. +- **Push to Jira**: Envía el Hallazgo a Jira con fines de creación de tickets. +- **Push to Integrator**: Envía el Hallazgo a cualquier sistema de seguimiento de incidencias de terceros integrado. +- **Risk and priority settings**: Ofrece la opción de anular el cálculo automático que hace DefectDojo del riesgo y la prioridad del Hallazgo. +- **Endpoints to add**: Endpoints vulnerables que pueden verse afectados por el Hallazgo seleccionado y que no están reflejados en la lista anterior de sistemas/endpoints. +- **Defect review requested by**: Registra quién solicitó una revisión de defecto para el fallo en cuestión. +- **SAST source object, line number, and file path**: Objeto de origen, número de línea y ruta de archivo del vector de ataque. +- **SAST sink object**: Objeto de destino del vector de ataque. +- **Number of occurrences**: Número de ocurrencias en la herramienta de origen cuando el escáner encontró y agregó varias vulnerabilidades. +- **Publish date**: La fecha en la que se publicó la vulnerabilidad. +- **Effort estimation**: El nivel de esfuerzo que implica corregir el Hallazgo (por ejemplo, Baja, Media o Alta). + +Los metadatos exactos disponibles dependerán del parser/escáner que reveló el Hallazgo. Algunos solo proporcionan información básica, como el título y la severidad, mientras que otros incluyen vectores CVSS, componentes vulnerables, endpoints, pares de solicitud/respuesta y otros metadatos específicos del escáner. + +Estos metadatos mejoran el filtrado, la generación de informes y la priorización en todo su programa de seguridad, lo que permite el seguimiento a largo plazo y el análisis de tendencias. Puede encontrar detalles adicionales y descripciones de metadatos [aquí](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page). + +### Deduplicación +DefectDojo incluye capacidades de deduplicación que ayudan a identificar y gestionar los Hallazgos que representan la misma vulnerabilidad subyacente. A medida que se importan los resultados de análisis desde una o más herramientas, DefectDojo utiliza una lógica de coincidencia configurable para identificar los Hallazgos que representan la misma vulnerabilidad. + +La deduplicación evita que la misma vulnerabilidad aparezca varias veces cuando es descubierta repetidamente por el mismo escáner o por escáneres distintos, lo que permite que el historial de remediación permanezca vinculado a un único Hallazgo. + +Puede encontrar más información sobre la deduplicación [aquí](/triage_findings/finding_deduplication/about_deduplication/). + +### Reimportación +La función de Reimportación de DefectDojo permite actualizar los Hallazgos a medida que se importan nuevos resultados de análisis. Cuando se reimporta un análisis, DefectDojo compara los resultados entrantes con los Hallazgos existentes y actualiza los registros coincidentes en lugar de crear otros completamente nuevos. Esto conserva contexto valioso, como cambios de estado, historial de remediación, comentarios e información de propiedad, proporcionando un registro continuo del ciclo de vida de un Hallazgo a través de múltiples ciclos de prueba. + +Puede encontrar más información sobre la función de Reimportación [aquí](/import_data/import_intro/reimport/). + +### Aceptaciones de riesgo +Las Aceptaciones de riesgo son un estado especial que se puede aplicar a los Hallazgos para documentar formalmente y operacionalizar la decisión de reconocerlos sin remediarlos de inmediato. + +Puede encontrar más información sobre las Aceptaciones de riesgo [aquí](/triage_findings/findings_workflows/pro__risk_acceptance/). + +### Estados +Cada Hallazgo creado en DefectDojo tiene un Estado que comunica información relevante y ayuda a su equipo a hacer seguimiento del progreso en la resolución de los problemas. + +Puede encontrar más información sobre los Estados [aquí](/triage_findings/findings_workflows/finding_status_definitions/). + +## Cómo trabajar con los Hallazgos + +### Creación de Hallazgos +Si bien la mayoría de los Hallazgos se generan automáticamente mediante importaciones de análisis e integraciones, DefectDojo también admite la creación manual de Hallazgos. Los Hallazgos manuales son útiles para rastrear vulnerabilidades y problemas de seguridad identificados mediante pruebas de penetración, revisiones de arquitectura, evaluaciones de cumplimiento, programas de recompensas por errores, compromisos con consultores, u otras actividades que no producen salida de un escáner. + +Los Hallazgos se pueden agregar manualmente haciendo clic en **New Finding** dentro de la sección **Findings** de la barra lateral, o seleccionando **Add Finding** dentro del menú de engranaje del Test al que desea agregar el Hallazgo. + +### Edición de Hallazgos +El menú kebab ⋮ junto a los Hallazgos contiene las siguientes funciones: +- **Edit Finding**: Edita el Hallazgo. +- **Copy Finding**: Crea una copia del Hallazgo en otro Test. La copia se puede guardar en cualquier Test dentro del mismo Compromiso para el que tenga permiso de edición. Copiar es útil cuando la misma vulnerabilidad debe rastrearse por separado en más de un contexto de Test. +- **Close Finding**: Inicia el proceso de cierre del Hallazgo. +- **Request Review**: Inicia el proceso de Revisión por pares y cambia el estado del Hallazgo a "Under Review." Puede encontrar más información sobre las Revisiones por pares [aquí](/triage_findings/findings_workflows/finding_status_definitions/#under-review). +- **Add Risk Acceptance**: Inicia el proceso de Aceptación de riesgo. Puede encontrar más información [aquí](/triage_findings/findings_workflows/pro__risk_acceptance/). +- **Add File**: Inicia el proceso para agregar un archivo al Hallazgo (consulte la sección a continuación). +- **Add Note**: Inicia el proceso para agregar una nota al Hallazgo. +- **Add Custom Field**: Abre una ventana emergente que le permite agregar y definir un campo personalizado para aplicar al Hallazgo. +- **Push to Jira**: Envía el Hallazgo a Jira con fines de creación de tickets. +- **Push to Integrator**: Envía el Hallazgo a cualquier sistema de seguimiento de incidencias de terceros integrado. +- **Delete Finding**: Elimina el Hallazgo seleccionado. +- **Finding History**: Muestra el historial del Hallazgo seleccionado. + +#### Adjuntar archivos a los Hallazgos +Puede adjuntar archivos a cualquier Hallazgo para proporcionar contexto adicional — por ejemplo, una captura de pantalla de una vulnerabilidad en acción o una imagen de prueba de concepto. + +Los tipos de archivo admitidos incluyen: + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +Para adjuntar un archivo a un Hallazgo, haga clic en **Add File** desde el menú kebab ⋮ o el menú de engranaje del Hallazgo seleccionado. Ingrese un Título para el archivo, elija el archivo desde su computadora y haga clic en **Submit**. + +El archivo aparecerá entonces en la sección Files de la tabla **Test Overview** dentro de la vista del Hallazgo. + +#### Edición masiva de Hallazgos +Los Hallazgos se pueden editar de forma masiva desde una Lista de Hallazgos, como la tabla de Todos los Hallazgos accesible desde la barra lateral, o desde la tabla de Hallazgos dentro de un Test específico. + +Puede encontrar más información sobre cómo editar Hallazgos de forma masiva [aquí](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings). + +### Cierre de Hallazgos +Una vez que el trabajo sobre un Hallazgo está completo, puede cerrarlo manualmente haciendo clic en **Close Finding** dentro del menú kebab ⋮ o el menú de engranaje del Hallazgo. Alternativamente, si se reimporta un análisis en DefectDojo que no contiene un Hallazgo previamente registrado, ese Hallazgo se cerrará automáticamente. + +Si no desea que se cierre ningún Hallazgo, puede deshabilitar este comportamiento en el formulario de Reimport Scan: + +- Desmarque la casilla Close Old Findings si utiliza la interfaz de usuario +- Establezca close_old_findings en False si utiliza la API ​ + +### Eliminación de Hallazgos +Se puede eliminar un Hallazgo desde el menú kebab ⋮ o el menú de engranaje del Hallazgo. Esta acción no se puede deshacer. + +Para fines de auditoría, se recomienda cerrar los Hallazgos remediados en lugar de eliminarlos. + +## Grupos de Hallazgos +Los **Grupos de Hallazgos** le permiten tratar varios Hallazgos relacionados como una única unidad lógica para la clasificación, la generación de informes y la coordinación de la remediación. + +Por ejemplo, un análisis podría producir 10 Hallazgos de inyección SQL en diferentes endpoints. En lugar de gestionar cada uno de forma independiente, puede agruparlos en un único Grupo de Hallazgos que represente el problema general de inyección SQL. + +Un Grupo de Hallazgos no reemplaza a los Hallazgos individuales. Cada Hallazgo sigue existiendo con su propia severidad, estado, metadatos, comentarios e historial de remediación. Un Grupo de Hallazgos simplemente proporciona una capa organizativa adicional sobre los Hallazgos que contiene. + +### Acceso a los Grupos de Hallazgos +Se puede acceder a los Grupos de Hallazgos desde la barra lateral. El submenú brinda acceso a los Grupos de Hallazgos Abiertos y Cerrados, así como a Todos los Grupos de Hallazgos (independientemente de su estado Abierto). + +![image](images/profindings_ss1.png) + +### Creación de Grupos de Hallazgos +Los Grupos de Hallazgos se pueden crear de forma manual o automática. + +Cabe destacar que los Grupos de Hallazgos solo se pueden crear a partir de los Hallazgos contenidos en un único Test. Los Hallazgos de diferentes Tests, Compromisos o Productos no se pueden agregar al mismo Grupo de Hallazgos. + +#### Grupos de Hallazgos manuales +Para realizar acciones de Grupo de Hallazgos de forma manual: +1. Navegue hasta una lista de Hallazgos dentro de un Test. +2. Seleccione el/los Hallazgo(s) que desea agregar a un Grupo de Hallazgos haciendo clic en la casilla correspondiente del Hallazgo. +3. Haga clic en el botón **Finding Group** que aparece en la parte superior de la lista de Hallazgos. +4. Haga clic en la acción correspondiente que desea completar. + - **Add to New Finding Group**: Crea un nuevo Grupo de Hallazgos que incluye los Hallazgos seleccionados. + - **Add to Existing Finding Group**: Agrega los Hallazgos seleccionados a un Grupo de Hallazgos preexistente. + - **Remove from Finding Group**: Elimina los Hallazgos seleccionados de cualquier Grupo de Hallazgos del que formaran parte anteriormente. +5. Haga clic en **Submit**. + +Tenga en cuenta que la agrupación estará deshabilitada a menos que todos los Hallazgos seleccionados sean editables, no estén agrupados y pertenezcan al mismo Test. + +Además, tenga en cuenta que la única acción posible al seleccionar Hallazgos desde la lista Todos los Hallazgos es eliminarlos de cualquier Grupo de Hallazgos. Esto se debe a que, como se mencionó, los Grupos de Hallazgos solo se pueden crear a partir de los Hallazgos contenidos en un único Test. + +#### Grupos de Hallazgos automáticos +Al importar un análisis, la función **Group By** dentro del menú desplegable **Optional Fields** puede crear automáticamente Grupos de Hallazgos según el método de agrupación elegido. Esto es útil cuando un escáner produce muchos Hallazgos relacionados que deben gestionarse juntos. + +La casilla adyacente **Create Finding Groups for all Findings** cumple dos funciones: +- **Checked**: Crea un Grupo de Hallazgos para cada Hallazgo importado, incluso si ese Hallazgo es el único miembro del grupo. +- **Unchecked**: Crea Grupos de Hallazgos solo cuando realmente hay varios Hallazgos para agrupar. + +![image](images/profindings_ss2.png) + +Si no se selecciona ninguna opción en el menú desplegable Group By durante la importación (por ejemplo, **Finding Title** en la captura de pantalla anterior, etc.), no se producirá ninguna agrupación. + +Si el criterio de agrupación (por ejemplo, nombre del componente, ID de vulnerabilidad, título del Hallazgo, etc.) no está completo en el Hallazgo, no se le creará un grupo ni se agregará a un Grupo de Hallazgos preexistente. + +Si se importa un análisis que revela 10 Hallazgos que no están agrupados, y luego se reimporta el mismo análisis y los Hallazgos quedan agrupados, los primeros 10 Hallazgos no se agregarán a ese Grupo de Hallazgos (es decir, el Grupo de Hallazgos incluirá únicamente los 10 Hallazgos de la reimportación, y no los 10 Hallazgos de la importación inicial). + +## Plantillas de Hallazgos +Las **Plantillas de Hallazgos** permiten a los Usuarios crear plantillas reutilizables para vulnerabilidades y problemas de seguridad reportados con frecuencia. Una plantilla puede incluir información estandarizada, como un título, descripción, impacto, pasos para reproducir, mitigación, referencias y otros metadatos del Hallazgo. + +Las Plantillas de Hallazgos son especialmente útiles en situaciones en las que los Usuarios necesitan crear Hallazgos manuales de forma repetida y desean evitar volver a ingresar la misma información de respaldo cada vez. + +### Acceso a las Plantillas de Hallazgos +Las Plantillas de Hallazgos se encuentran dentro del submenú Findings en la barra lateral. + +![image](images/profindings_ss1.png) + +### Creación de Plantillas de Hallazgos +Las Plantillas de Hallazgos se pueden crear haciendo clic en el botón **New Finding Template** en la parte superior izquierda de la vista de Plantillas de Hallazgos. + +La página siguiente ofrece un resumen de los metadatos que se aplicarán a un Hallazgo cuando se utilice una Plantilla de Hallazgo. + +### Aplicación de Plantillas de Hallazgos +Las Plantillas de Hallazgos difieren entre DefectDojo OS y DefectDojo Pro. En Pro, las Plantillas de Hallazgos no se pueden aplicar a Hallazgos preexistentes, ni se pueden crear a partir de Hallazgos preexistentes. + +Sin embargo, puede agregar manualmente un Hallazgo a un Test a partir de una Plantilla de Hallazgo, ya sea mediante el menú kebab ⋮ junto al Test en la vista del Compromiso principal, o mediante el menú de engranaje en la vista del Test. + +![image](images/profindings_ss3.png) + +![image](images/profindings_ss4.png) + +## Generación de informes +El generador de informes de DefectDojo le permite ensamblar un informe personalizado a partir de un conjunto de widgets de contenido, ejecutarlo y exportar el resultado (por ejemplo, imprimiéndolo en PDF). Los informes personalizados pueden resumir los Hallazgos o Endpoints que desea compartir con una audiencia externa, y pueden incluir elementos de marca y texto estándar. + +Puede encontrar más información sobre el Generador de informes de DefectDojo [aquí](/metrics_reports/reports/report-builder/). + +### Exportar Hallazgos +Las páginas que muestran una lista de Hallazgos o una lista de Compromisos tienen una opción de exportación a CSV y Excel en la parte superior izquierda. Para los Hallazgos, también existe la opción de realizar una Exportación rápida, que abrirá una nueva pestaña con tablas de metadatos correspondientes a cada Hallazgo. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__findings.fr.md b/docs/content/asset_modelling/engagements_tests/PRO__findings.fr.md new file mode 100644 index 00000000000..afcb957c5c5 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__findings.fr.md @@ -0,0 +1,275 @@ +--- +title: Constatations +description: Comprendre les Constatations dans DefectDojo Pro +audience: pro +weight: 5 +--- + +Organisations → Actifs → Engagements → Tests → **CONSTATATIONS** + +## Aperçu +**Les Constatations** représentent le niveau le plus bas de la hiérarchie des produits, où les vulnérabilités individuelles sont suivies et gérées, et constituent le principal moyen par lequel DefectDojo normalise et guide le processus de signalement et de remédiation de vos outils de sécurité. Qu'une vulnérabilité ait été signalée par SonarQube, Acunetix ou l'outil personnalisé de votre équipe, les Constatations vous permettent de gérer chaque vulnérabilité de la même manière. + +Exemples de Constatations : +- **Cookie non marqué comme HttpOnly** +- **Version obsolète (PHP)** +- **Évaluation de code hors bande (PHP)** +- **Version obsolète (MySQL)** +- **Code source de sauvegarde détecté** +- **Cross-Site Scripting aveugle** + +En plus de stocker les données de vulnérabilité et de fournir un cadre de remédiation, DefectDojo enrichit également vos Constatations des façons suivantes : +- Ajout automatique des scores EPSS associés à une Constatation pour décrire son exploitabilité +- Traduction automatique de la métrique de sévérité d'un outil de sécurité en un score de Sévérité pour chaque Constatation, ce qui confère un SLA à la Constatation selon la configuration SLA de votre Actif. Pour plus d'informations sur la configuration des SLA, cliquez [ici](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas). + +Dans l'ensemble, les Constatations sont conçues pour fonctionner avec la hiérarchie des produits afin de normaliser vos efforts et d'appliquer une méthode cohérente à chaque Actif. + +## Accès aux Constatations +Les Constatations sont accessibles depuis la barre latérale. Le sous-menu donne accès aux Constatations Actives et Atténuées, à Toutes les Constatations (quel que soit leur statut Ouvert ou Fermé), aux Groupes de constatations, aux Modèles de constatation, ainsi qu'au workflow de Nouvelle constatation. Les Constatations individuelles sont également accessibles depuis le Test qui les contient. + +[Constatations à risque accepté] (/triage_findings/findings_workflows/os__risk_acceptance/) sont accessibles depuis la section **Acceptations du risque** de la barre latérale. + +![image](images/profindings_ss1.png) + +### Autorisations +Chaque Constatation appartient à un Test, ce qui permet à DefectDojo de conserver la trace du scan ou de l'évaluation ayant initialement identifié la vulnérabilité. + +Comme les Constatations appartiennent à des Tests, l'accès aux Constatations est déterminé par l'accès d'un Utilisateur à l'Actif qui contient le Test. Les Tests ne disposent pas de listes de contrôle d'accès indépendantes. + +## Vue des Constatations +Les vues de Constatation contiennent divers tableaux permettant d'interpréter en un coup d'œil le statut d'une Constatation. + +### Aperçu de la Constatation +- **Description** : la description de la Constatation (ajoutée automatiquement selon le type de Constatation, ou créée manuellement). +- **Atténuation** : étapes suggérées pour atténuer le problème. +- **Politique d'atténuation générale** : la politique d'atténuation normalisée pour la Constatation sélectionnée. +Les politiques d'atténuation se trouvent et peuvent être modifiées dans la barre latérale, sous **Configuration** → **Politiques d'atténuation**. +- **Impact** : impact potentiel si la Constatation n'est pas résolue. +- **Références** : URL permettant de faire référence à la description spécifique de la Constatation fournie par l'outil de scan tiers. Par exemple, les Références peuvent être des liens vers une entrée pertinente d'un catalogue de Constatations, ou une URL d'avis unique. +- **Fichiers** : tout fichier ajouté pour contextualiser la Constatation. +- **Notes** : notes laissées par les Utilisateurs à propos de la Constatation. Marquer une note comme privée signifie qu'elle ne sera incluse dans aucun rapport généré comprenant la Constatation sélectionnée. + +### Métadonnées +- **ID** : l'identifiant unique de la Constatation dans DefectDojo. +- **Organisation, Actif, Engagement et Test** : les objets parents de la Constatation sélectionnée. +- **Statut** : le statut de la Constatation (par exemple, Actif, Vérifié, Faux positif, Doublon, Hors périmètre et En révision de défaut). +- **Sévérité** : la note de sévérité de cette Constatation, appliquée automatiquement. + - Comme mentionné plus haut, DefectDojo traduit automatiquement la métrique de sévérité d'un outil de sécurité en un score de Sévérité pour chaque Constatation, ce qui confère un SLA à la Constatation selon la configuration SLA de votre Actif. +- **Risque** : un système de classement à 4 niveaux qui prend en compte l'exploitabilité d'une Constatation et qui est appliqué automatiquement. + - Vous trouverez des détails sur le calcul de la priorité, du risque et des SLA [ici](/asset_modelling/pro_hierarchy/priority_sla/#main-content). Des détails supplémentaires sur les définitions du statut et du niveau de risque des Constatations sont disponibles [ici](/triage_findings/findings_workflows/finding_status_definitions/). +- **Priorité** : un rang numérique calculé, appliqué à toutes les Constatations, qui permet de comprendre rapidement les vulnérabilités dans leur contexte. +- **Ancienneté** : l'âge de la Constatation sélectionnée. +- **SLA** : la date d'échéance à laquelle la Constatation est censée être résolue. +- **Type** : indique si la Constatation a été détectée par un outil de sécurité applicative statique ou dynamique (Statique, Dynamique ou Statique/Dynamique). +- **Emplacement et ligne** : le fichier et le numéro de ligne où la Constatation sélectionnée a été trouvée. +- **Nom et version du composant** : le nom et la version du composant dans lequel la Constatation sélectionnée a été trouvée. +- **Date de découverte** : la date à laquelle la Constatation a été découverte. +- **Date et version de remédiation prévues** : la date à laquelle la remédiation de la Constatation est prévue, et la version du composant concerné dans laquelle le correctif sera implémenté. +- **Service** : les Services connectés (éléments fonctionnels autonomes au sein d'un Actif) affectés par la Constatation sélectionnée. Lorsqu'il est renseigné, ce champ est pris en compte dans la correspondance de déduplication (c'est-à-dire que les Constatations ayant des champs Service identiques seront dédupliquées). +- **Rapporteur** : l'Utilisateur ayant révélé la Constatation. +- **CWE** : la classification de la faiblesse CWE de la Constatation. Une Constatation peut porter **plusieurs CWE** — un CWE principal, ainsi que tout CWE supplémentaire fourni par l'outil de signalement. Le CWE principal est celui utilisé pour la déduplication historique et le calcul du hash code ; l'ensemble complet des CWE peut également être utilisé pour la correspondance via les champs de hash code basés sur des ensembles de Pro (voir [Réglage de la déduplication](/triage_findings/finding_deduplication/pro__deduplication_tuning/#set-based-hash-code-fields-vulnerability-ids-and-cwes)). + - Un CWE décrit une *classe* de faiblesse (par exemple, « Injection SQL »), et non une instance de vulnérabilité spécifique — c'est à cela que servent les Identifiants de vulnérabilité. +- **Identifiants de vulnérabilité** : identifiants de vulnérabilité publiquement reconnus associés à la Constatation, tels que CVE, GHSA ou d'autres références d'avis normalisées. Dans DefectDojo Pro, ils sont également utilisés pour effectuer des recherches EPSS et KEV. + - Les Identifiants de vulnérabilité sont stockés comme des enregistrements de premier ordre, de sorte qu'un même CVE est suivi une seule fois et partagé par toutes les Constatations qui y font référence. Vous pouvez les consulter — ainsi que leurs valeurs EPSS et KEV — dans l'**Explorateur de vulnérabilités**. Voir [EPSS / KEV](/triage_findings/finding_scoring/epss_kev/#viewing-kevepss-in-the-vulnerability-explorer). +- **ID unique de l'outil** : identifiant stable attribué par l'outil source à une instance spécifique de Constatation. Les ID uniques sont censés rester cohérents d'un scan à l'autre, ce qui permet à l'outil de reconnaître la même Constatation au fil du temps. + - Contrairement aux Identifiants de vulnérabilité, cette valeur est propre à l'outil de signalement et ne constitue pas une référence publique de vulnérabilité. + - Exemple : `finding-12345` +- **ID de vulnérabilité de l'outil** : identifiant propriétaire de vulnérabilité ou de règle attribué par l'outil source pour décrire le type de vulnérabilité détecté. + - Contrairement à l'ID unique de l'outil, cet identifiant n'est pas propre à une Constatation individuelle et peut apparaître sur de nombreuses Constatations correspondant à la même règle de détection. + - Contrairement aux Identifiants de vulnérabilité, ces identifiants sont spécifiques à l'outil de signalement et ne sont pas normalisés publiquement. + - Exemple : `semgrep.rule.lang.security.sql-injection` +- **Score EPSS / Percentile** : le score EPSS et le percentile du CVE. +- **Exploitation connue** : indique s'il existe une confirmation que la vulnérabilité a été exploitée. +- **Rançongiciel utilisé** : indique si un rançongiciel a été impliqué dans l'exploitation de la vulnérabilité. +- **Date KEV** : la date à laquelle la Constatation a été ajoutée au catalogue KEV. +- **Détecté par** : le type d'outil ayant identifié la vulnérabilité. +- **Vecteur et score CVSSv3 et CVSSv4** : le vecteur et le score CVSS3 et CVSS4 de la Constatation sélectionnée. +- **Tickets d'intégrateur** : numéros de tickets de systèmes de suivi des problèmes tiers associés à la Constatation. + +### Points de terminaison vulnérables +Cette section comprend un tableau des Points de terminaison affectés par la Constatation sélectionnée, ainsi que les métadonnées pertinentes. + +### Détails supplémentaires +- **Paires requête/réponse** : une copie du message envoyé par le client et de la réponse du serveur à la requête. +- **Étapes de reproduction** : les étapes permettant de reproduire la Constatation. +- **Justification de la sévérité** : description écrite expliquant pourquoi une certaine note de Sévérité a été associée à la Constatation. + +## Données des Constatations +Les Constatations nécessitent les métadonnées suivantes : +- **Nom** +- **Date** +- **Sévérité** +- **Description** + +En plus des métadonnées correspondant aux tableaux de la vue d'une Constatation, les champs de métadonnées optionnels comprennent : +- **Étiquettes** : toutes les étiquettes ajoutées à la Constatation. +- **Propriétaires** : le groupe d'utilisateurs responsable de la Constatation sélectionnée. +- **Envoyer vers Jira** : envoie la Constatation vers Jira à des fins de gestion des tickets. +- **Envoyer vers l'intégrateur** : envoie la Constatation vers tout système de suivi des problèmes tiers intégré. +- **Paramètres de risque et de priorité** : offre la possibilité de remplacer le calcul automatique du risque et de la priorité de la Constatation effectué par DefectDojo. +- **Points de terminaison à ajouter** : points de terminaison vulnérables susceptibles d'être affectés par la Constatation sélectionnée et qui ne figurent pas dans la liste précédente des systèmes/points de terminaison. +- **Révision de défaut demandée par** : enregistre qui a demandé une révision de défaut pour la faille en question. +- **Objet source SAST, numéro de ligne et chemin du fichier** : objet source, numéro de ligne et chemin du fichier du vecteur d'attaque. +- **Objet de destination SAST** : objet de destination (sink) du vecteur d'attaque. +- **Nombre d'occurrences** : nombre d'occurrences dans l'outil source lorsque plusieurs vulnérabilités ont été trouvées et regroupées par le scanner. +- **Date de publication** : la date à laquelle la vulnérabilité a été publiée. +- **Estimation de l'effort** : le niveau d'effort requis pour corriger la Constatation (par exemple, Faible, Moyenne ou Élevée). + +Les métadonnées exactement disponibles dépendent de l'analyseur/scanner ayant révélé la Constatation. Certains ne fournissent que des informations basiques telles que le titre et la sévérité, tandis que d'autres incluent des vecteurs CVSS, des composants vulnérables, des points de terminaison, des paires requête/réponse et d'autres métadonnées spécifiques au scanner. + +Ces métadonnées améliorent le filtrage, le reporting et la priorisation au sein de votre programme de sécurité, en permettant un suivi à long terme et une analyse des tendances. Des détails supplémentaires et des descriptions des métadonnées sont disponibles [ici](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page). + +### Déduplication +DefectDojo intègre des fonctionnalités de déduplication qui aident à identifier et à gérer les Constatations représentant une même vulnérabilité sous-jacente. Lorsque les résultats de scan sont importés depuis un ou plusieurs outils, DefectDojo utilise une logique de correspondance configurable pour identifier les Constatations représentant la même vulnérabilité. + +La déduplication empêche qu'une même vulnérabilité n'apparaisse plusieurs fois lorsqu'elle est découverte à répétition par le même scanner ou par des scanners différents, ce qui permet à l'historique de remédiation de rester rattaché à une seule Constatation. + +Vous trouverez plus d'informations sur la déduplication [ici](/triage_findings/finding_deduplication/about_deduplication/). + +### Réimportation +La fonction de réimportation de DefectDojo permet de mettre à jour les Constatations à mesure que de nouveaux résultats de scan sont importés. Lorsqu'un scan est réimporté, DefectDojo compare les résultats entrants aux Constatations existantes et met à jour les enregistrements correspondants au lieu d'en créer de nouveaux. Cela préserve un contexte précieux tel que les changements de statut, l'historique de remédiation, les commentaires et les informations de propriété, offrant ainsi un enregistrement continu du cycle de vie d'une Constatation à travers plusieurs cycles de test. + +Vous trouverez plus d'informations sur la fonction de réimportation [ici](/import_data/import_intro/reimport/). + +### Acceptations du risque +Les Acceptations du risque sont un statut spécial pouvant être appliqué aux Constatations afin de documenter formellement et de mettre en œuvre la décision de les reconnaître sans les corriger immédiatement. + +Vous trouverez plus d'informations sur les Acceptations du risque [ici](/triage_findings/findings_workflows/pro__risk_acceptance/). + +### Statuts +Chaque Constatation créée dans DefectDojo possède un Statut qui communique des informations pertinentes et aide votre équipe à suivre l'avancement de la résolution des problèmes. + +Vous trouverez plus d'informations sur les Statuts [ici](/triage_findings/findings_workflows/finding_status_definitions/). + +## Travailler avec les Constatations + +### Créer des Constatations +Bien que la plupart des Constatations soient générées automatiquement via les imports de scans et les intégrations, DefectDojo prend également en charge la création manuelle de Constatations. Les Constatations manuelles sont utiles pour suivre les vulnérabilités et les problèmes de sécurité identifiés lors de tests d'intrusion, de revues d'architecture, d'évaluations de conformité, de programmes de bug bounty, de missions de consultants, ou d'autres activités qui ne produisent pas de résultats de scanner. + +Les Constatations peuvent être ajoutées manuellement en cliquant sur **Nouvelle constatation** dans la section **Constatations** de la barre latérale, ou en sélectionnant **Ajouter une constatation** dans le menu d'engrenage du Test auquel vous souhaitez ajouter la Constatation. + +### Modifier des Constatations +Le menu kebab ⋮ situé à côté des Constatations contient les fonctions suivantes : +- **Modifier la constatation** : modifie la Constatation. +- **Copier la constatation** : crée une copie de la Constatation dans un autre Test. La copie peut être enregistrée dans n'importe quel Test du même Engagement pour lequel vous disposez des droits de modification. La copie est utile lorsque la même vulnérabilité doit être suivie séparément dans plusieurs contextes de Test. +- **Fermer la constatation** : lance le processus de fermeture de la Constatation. +- **Demander une révision** : lance le processus de révision par les pairs et fait passer le statut de la Constatation à « En révision ». Vous trouverez plus d'informations sur les révisions par les pairs [ici](/triage_findings/findings_workflows/finding_status_definitions/#under-review). +- **Ajouter une acceptation du risque** : lance le processus d'Acceptation du risque. Vous trouverez plus d'informations [ici](/triage_findings/findings_workflows/pro__risk_acceptance/). +- **Ajouter un fichier** : lance le processus d'ajout d'un fichier à la Constatation (voir la section ci-dessous). +- **Ajouter une note** : lance le processus d'ajout d'une note à la Constatation. +- **Ajouter un champ personnalisé** : ouvre une fenêtre contextuelle permettant d'ajouter et de définir un champ personnalisé à appliquer à la Constatation. +- **Envoyer vers Jira** : envoie la Constatation vers Jira à des fins de gestion des tickets. +- **Envoyer vers l'intégrateur** : envoie la Constatation vers tout système de suivi des problèmes tiers intégré. +- **Supprimer la constatation** : supprime la Constatation sélectionnée. +- **Historique de la constatation** : affiche l'historique de la Constatation sélectionnée. + +#### Joindre des fichiers aux Constatations +Vous pouvez joindre des fichiers à n'importe quelle Constatation pour fournir un contexte supplémentaire — par exemple, une capture d'écran d'une vulnérabilité en action ou une image de preuve de concept. + +Les types de fichiers pris en charge sont les suivants : + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +Pour joindre un fichier à une Constatation, cliquez sur **Ajouter un fichier** dans le menu kebab ⋮ ou dans le menu d'engrenage de la Constatation sélectionnée. Saisissez un Titre pour le fichier, choisissez le fichier sur votre ordinateur, puis cliquez sur **Envoyer**. + +Le fichier apparaîtra alors dans la section Fichiers du tableau **Aperçu du test** dans la vue de la Constatation. + +#### Modifier des Constatations en masse +Les Constatations peuvent être modifiées en masse depuis une liste de Constatations, comme le tableau Toutes les Constatations accessible depuis la barre latérale, ou depuis le tableau des Constatations d'un Test spécifique. + +Vous trouverez plus d'informations sur la modification en masse des Constatations [ici](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings). + +### Fermer des Constatations +Une fois le travail sur une Constatation terminé, vous pouvez la fermer manuellement en cliquant sur **Fermer la constatation** dans le menu kebab ⋮ ou le menu d'engrenage de la Constatation. Autrement, si un scan est réimporté dans DefectDojo sans qu'il ne contienne une Constatation précédemment enregistrée, cette dernière se fermera automatiquement. + +Si vous ne souhaitez qu'aucune Constatation ne soit fermée, vous pouvez désactiver ce comportement dans le formulaire de réimportation de scan : + +- Décochez la case Fermer les anciennes constatations si vous utilisez l'interface utilisateur +- Définissez close_old_findings sur False si vous utilisez l'API ​ + +### Supprimer des Constatations +La suppression d'une Constatation peut être effectuée depuis le menu kebab ⋮ ou le menu d'engrenage de la Constatation. Cette action est irréversible. + +À des fins d'audit, il est recommandé de fermer les Constatations corrigées plutôt que de les supprimer. + +## Groupes de constatations +**Les Groupes de constatations** vous permettent de traiter plusieurs Constatations liées entre elles comme une seule unité logique pour le triage, le reporting et la coordination de la remédiation. + +Par exemple, un scan peut produire 10 Constatations d'injection SQL réparties sur différents points de terminaison. Plutôt que de gérer chacune indépendamment, vous pouvez les regrouper au sein d'un seul Groupe de constatations représentant le problème d'injection SQL dans son ensemble. + +Un Groupe de constatations ne remplace pas les Constatations individuelles. Chaque Constatation continue d'exister avec sa propre sévérité, son propre statut, ses propres métadonnées, commentaires et historique de remédiation. Un Groupe de constatations fournit simplement une couche organisationnelle supplémentaire au-dessus des Constatations qu'il contient. + +### Accès aux Groupes de constatations +Les Groupes de constatations sont accessibles depuis la barre latérale. Le sous-menu donne accès aux Groupes de constatations Ouverts et Fermés, ainsi qu'à Tous les groupes de constatations (quel que soit leur statut Ouvert). + +![image](images/profindings_ss1.png) + +### Créer des Groupes de constatations +Les Groupes de constatations peuvent être créés manuellement ou automatiquement. + +Il est à noter que les Groupes de constatations ne peuvent être créés qu'à partir des Constatations contenues dans un seul Test. Les Constatations provenant de Tests, d'Engagements ou de Produits différents ne peuvent pas être ajoutées au même Groupe de constatations. + +#### Groupes de constatations manuels +Pour effectuer manuellement des actions de Groupe de constatations : +1. Accédez à une liste de Constatations au sein d'un Test. +2. Sélectionnez la ou les Constatations que vous souhaitez ajouter à un Groupe de constatations en cochant la case correspondante. +3. Cliquez sur le bouton **Groupe de constatations** qui apparaît en haut de la liste des Constatations. +4. Cliquez sur l'action correspondante que vous souhaitez effectuer. + - **Ajouter à un nouveau groupe de constatations** : crée un nouveau Groupe de constatations incluant les Constatations sélectionnées. + - **Ajouter à un groupe de constatations existant** : ajoute les Constatations sélectionnées à un Groupe de constatations préexistant. + - **Retirer du groupe de constatations** : retire les Constatations sélectionnées de tout Groupe de constatations dont elles faisaient précédemment partie. +5. Cliquez sur **Envoyer**. + +Notez que le regroupement sera désactivé à moins que chaque Constatation sélectionnée soit modifiable, non regroupée et appartienne au même Test. + +Par ailleurs, notez que la seule action possible lors de la sélection de Constatations depuis la liste Toutes les Constatations consiste à retirer les Constatations sélectionnées de tout Groupe de constatations. En effet, comme mentionné, les Groupes de constatations ne peuvent être créés qu'à partir des Constatations contenues dans un seul Test. + +#### Groupes de constatations automatiques +Lors de l'import d'un scan, la fonctionnalité **Regrouper par** du menu déroulant **Champs optionnels** peut créer automatiquement des Groupes de constatations selon une méthode de regroupement choisie. Cela est utile lorsqu'un scanner produit de nombreuses Constatations liées qui doivent être gérées ensemble. + +La case à cocher adjacente **Créer des groupes de constatations pour toutes les constatations** remplit deux fonctions : +- **Cochée** : crée un Groupe de constatations pour chaque Constatation importée, même si cette Constatation est l'unique membre du groupe. +- **Décochée** : ne crée des Groupes de constatations que lorsqu'il y a réellement plusieurs Constatations à regrouper. + +![image](images/profindings_ss2.png) + +Si aucune option n'est sélectionnée dans le menu déroulant Regrouper par lors de l'import (par exemple, **Titre de la constatation** dans la capture d'écran ci-dessus, etc.), aucun regroupement n'aura lieu. + +Si le critère de regroupement (par exemple, le nom du composant, l'identifiant de vulnérabilité, le titre de la Constatation, etc.) n'est pas renseigné dans la Constatation, aucun groupe ne sera créé pour elle et elle ne sera pas ajoutée à un Groupe de constatations préexistant. + +Si un scan est importé et révèle 10 Constatations qui ne sont pas regroupées, puis que ce même scan est réimporté avec un regroupement des Constatations, les 10 premières Constatations ne seront pas ajoutées à ce Groupe de constatations (c'est-à-dire que le Groupe de constatations n'inclura que les 10 Constatations issues de la réimportation, et non les 10 Constatations de l'import initial). + +## Modèles de constatation +**Les Modèles de constatation** permettent aux Utilisateurs de créer des modèles réutilisables pour les vulnérabilités et problèmes de sécurité fréquemment signalés. Un modèle peut inclure des informations normalisées telles qu'un titre, une description, un impact, des étapes de reproduction, une atténuation, des références et d'autres métadonnées de Constatation. + +Les Modèles de constatation sont particulièrement utiles lorsque les Utilisateurs doivent créer des Constatations manuelles de manière répétée et souhaitent éviter de ressaisir les mêmes informations à chaque fois. + +### Accès aux Modèles de constatation +Les Modèles de constatation se trouvent dans le sous-menu Constatations de la barre latérale. + +![image](images/profindings_ss1.png) + +### Créer des Modèles de constatation +Les Modèles de constatation peuvent être créés en cliquant sur le bouton **Nouveau modèle de constatation** en haut à gauche de la vue Modèles de constatation. + +La page qui s'affiche présente un aperçu des métadonnées qui seront appliquées à une Constatation lors de l'utilisation d'un Modèle de constatation. + +### Appliquer des Modèles de constatation +Les Modèles de constatation diffèrent entre DefectDojo OS et DefectDojo Pro. Dans Pro, les Modèles de constatation ne peuvent pas être appliqués à des Constatations préexistantes, et ils ne peuvent pas être créés à partir de Constatations préexistantes. + +Cependant, vous pouvez ajouter manuellement une Constatation à un Test à partir d'un Modèle de constatation, en utilisant soit le menu kebab ⋮ situé à côté du Test dans la vue de l'Engagement parent, soit le menu d'engrenage dans la vue du Test. + +![image](images/profindings_ss3.png) + +![image](images/profindings_ss4.png) + +## Reporting +Le générateur de rapports de DefectDojo vous permet d'assembler un rapport personnalisé à partir d'un ensemble de widgets de contenu, de l'exécuter et d'exporter le résultat (par exemple, en l'imprimant au format PDF). Les rapports personnalisés peuvent résumer les Constatations ou les Points de terminaison que vous souhaitez partager avec un public externe, et peuvent inclure une image de marque et du texte standard. + +Vous trouverez plus d'informations sur le Générateur de rapports de DefectDojo [ici](/metrics_reports/reports/report-builder/). + +### Exporter les Constatations +Les pages affichant une liste de Constatations ou une liste d'Engagements disposent d'une option d'export CSV et Excel en haut à gauche. Pour les Constatations, il existe également une option d'Export rapide, qui ouvre un nouvel onglet contenant des tableaux de métadonnées relatives à chaque Constatation. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__findings.ja.md b/docs/content/asset_modelling/engagements_tests/PRO__findings.ja.md new file mode 100644 index 00000000000..b7649c24787 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__findings.ja.md @@ -0,0 +1,275 @@ +--- +title: 検出事項 +description: DefectDojo Proにおける検出事項について +audience: pro +weight: 5 +--- + +組織 → アセット → エンゲージメント → テスト → **検出事項** + +## 概要 +**検出事項**は、個々の脆弱性が追跡・管理される製品階層の最下層に位置し、DefectDojoがセキュリティツールのレポートおよび修復プロセスを標準化し導くための主要な手段として機能します。脆弱性がSonarQube、Acunetix、またはチーム独自のツールのいずれで報告されたかに関わらず、検出事項によって同じ方法で各脆弱性を管理できます。 + +検出事項の例には以下のようなものがあります。 +- **Cookie に HttpOnly 属性が設定されていない** +- **バージョンが古い (PHP)** +- **帯域外コード評価 (PHP)** +- **バージョンが古い (MySQL)** +- **バックアップソースコードの検出** +- **ブラインドクロスサイトスクリプティング** + +脆弱性データを保存し、修復のためのフレームワークを提供することに加えて、DefectDojoは以下の方法で検出事項を強化します。 +- 悪用可能性を示す関連EPSSスコアを検出事項に自動的に追加します +- セキュリティツールの深刻度指標を各検出事項の深刻度スコアに自動的に変換し、アセットのSLA設定に応じて検出事項にSLAを付与します。SLA設定の詳細については、[こちら](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas)をクリックしてください。 + +全体として、検出事項は製品階層と連携して機能するように設計されており、取り組みを標準化し、各アセットに一貫した方法を適用します。 + +## 検出事項へのアクセス +検出事項にはサイドバーからアクセスできます。サブメニューからは、アクティブおよび緩和済みの検出事項、(オープンまたはクローズのステータスを問わない)すべての検出事項、検出事項グループ、検出事項テンプレート、新規検出事項の作成ワークフローにアクセスできます。個々の検出事項は、それを含むテストの中からもアクセスできます。 + +[リスク受容済みの検出事項] (/triage_findings/findings_workflows/os__risk_acceptance/)は、サイドバーの**リスク受容**セクションからアクセスできます。 + +![image](images/profindings_ss1.png) + +### 権限 +すべての検出事項はテストに属しており、これによりDefectDojoは、その脆弱性を最初に特定したスキャンまたは評価がどれであるかを保持できます。 + +検出事項はテストに属しているため、検出事項へのアクセス権は、そのテストを含むアセットに対するユーザーのアクセス権によって決まります。テストには独立したアクセス制御リストはありません。 + +## 検出事項ビュー +検出事項ビューには、検出事項のステータスを一目で把握できるよう、さまざまなテーブルが含まれています。 + +### 検出事項の概要 +- **説明**: 検出事項の説明(検出事項の種類に応じて自動的に追加されるか、手動で作成されます)。 +- **緩和策**: 推奨される緩和手順。 +- **一般緩和ポリシー**: 選択した検出事項に適用される標準化された緩和ポリシー。 +緩和ポリシーは、サイドバーの**設定** → **緩和ポリシー**で確認・編集できます。 +- **影響**: 検出事項が未解決のまま残された場合に想定される影響。 +- **参照**: サードパーティ製スキャンツールによる検出事項の具体的な説明を相互参照するためのURL。例えば、参照には検出事項カタログ内の該当項目へのリンクや、単一のアドバイザリURLが含まれることがあります。 +- **ファイル**: 検出事項に文脈情報を加えるために追加されたファイル。 +- **メモ**: 検出事項に関連してユーザーが残したメモ。メモを非公開としてマークすると、その検出事項を含む生成済みレポートには含まれなくなります。 + +### メタデータ +- **ID**: DefectDojoが割り当てる検出事項固有のID。 +- **組織、アセット、エンゲージメント、テスト**: 選択した検出事項の親オブジェクト。 +- **ステータス**: 検出事項のステータス(例: アクティブ、検証済み、誤検知、重複、対象外、不具合レビュー中など)。 +- **深刻度**: その検出事項に自動的に適用される深刻度評価。 + - 前述の通り、DefectDojoはセキュリティツールの深刻度指標を各検出事項の深刻度スコアに自動的に変換し、アセットのSLA設定に応じて検出事項にSLAを付与します。 +- **リスク**: 検出事項の悪用可能性を考慮した、自動的に適用される4段階のランキングシステム。 + - 優先度、リスク、SLAの計算方法の詳細は[こちら](/asset_modelling/pro_hierarchy/priority_sla/#main-content)をご覧ください。検出事項のステータスとリスクレベルの定義の詳細は[こちら](/triage_findings/findings_workflows/finding_status_definitions/)をご覧ください。 +- **優先度**: すべての検出事項に適用される計算済みの数値ランクで、脆弱性を文脈の中で素早く把握できるようにします。 +- **経過日数**: 選択した検出事項がどれくらい前のものかを示します。 +- **SLA**: 検出事項の解決が見込まれる期限日。 +- **種別**: 検出事項が静的または動的なアプリケーションセキュリティツールのいずれから検出されたか(Static、Dynamic、またはStatic/Dynamic)。 +- **場所と行**: 選択した検出事項が見つかったファイルと行番号。 +- **コンポーネント名とバージョン**: 選択した検出事項が見つかったコンポーネントの名前とバージョン。 +- **発見日**: 検出事項が発見された日付。 +- **修復予定日とバージョン**: 検出事項の修復が予定されている日付と、修正が実装される対象コンポーネントのバージョン。 +- **サービス**: 選択した検出事項の影響を受ける接続済みサービス(アセット内で完結した機能の単位)。この項目に値が入力されている場合、重複排除のマッチングに使用されます(つまり、サービスの項目が同一の検出事項同士は重複排除されます)。 +- **報告者**: 検出事項を発見したユーザー。 +- **CWE**: 検出事項のCWE脆弱性分類。1つの検出事項は**複数のCWE**を持つことができます—プライマリCWEに加えて、報告元ツールが提供した追加のCWEです。プライマリCWEはレガシーの重複排除およびハッシュコード計算に使用されるCWEであり、CWEの全セットはPro独自のセットベースのハッシュコードフィールドを通じたマッチングにも使用できます([重複排除の調整](/triage_findings/finding_deduplication/pro__deduplication_tuning/#set-based-hash-code-fields-vulnerability-ids-and-cwes)を参照)。 + - CWEは(例えば「SQLインジェクション」のような)脆弱性の*クラス*を表すものであり、個々の脆弱性インスタンスを表すものではありません—それを表すのが脆弱性IDです。 +- **脆弱性ID**: CVE、GHSA、その他の標準化されたアドバイザリ参照など、検出事項に関連付けられた公に認知されている脆弱性識別子。DefectDojo Proでは、EPSSおよびKEVのルックアップを行う際にも使用されます。 + - 脆弱性IDはファーストクラスのレコードとして保存されるため、同一のCVEは一度だけ追跡され、それを参照するすべての検出事項で共有されます。これらはEPSSおよびKEVの値とともに**脆弱性エクスプローラー**で確認できます。[EPSS / KEV](/triage_findings/finding_scoring/epss_kev/#viewing-kevepss-in-the-vulnerability-explorer)を参照してください。 +- **ツール固有の一意のID**: 特定の検出事項インスタンスに対して発生元ツールが割り当てる安定した識別子。一意のIDは、繰り返しのスキャンにわたって一貫性を保つことを意図しており、ツールが時間の経過とともに同一の検出事項を認識できるようにします。 + - 脆弱性IDとは異なり、この値は報告元ツールに固有のものであり、公開された脆弱性の参照ではありません。 + - 例: `finding-12345` +- **ツール固有の脆弱性ID**: 検出された脆弱性の種類を説明するために発生元ツールが割り当てる、独自の脆弱性またはルールの識別子。 + - ツール固有の一意のIDとは異なり、この識別子は個々の検出事項に固有ではなく、同じ検出ルールに一致する多くの検出事項に現れることがあります。 + - 脆弱性IDとは異なり、これらの識別子は報告元ツールに固有のものであり、公に標準化されたものではありません。 + - 例: `semgrep.rule.lang.security.sql-injection` +- **EPSSスコア/パーセンタイル**: CVEのEPSSスコアとパーセンタイル。 +- **既知の悪用**: 脆弱性が悪用されたことが確認されているかどうか。 +- **ランサムウェアの使用**: 脆弱性の悪用にランサムウェアが関与していたかどうか。 +- **KEV登録日**: 検出事項がKEVカタログに追加された日付。 +- **検出元**: 脆弱性を特定したツールの種類。 +- **CVSSv3およびCVSSv4のベクターとスコア**: 選択した検出事項のCVSS3およびCVSS4のベクターとスコア。 +- **インテグレーターチケット**: 検出事項に関連付けられたサードパーティ製課題管理システムのチケット番号。 + +### 脆弱なエンドポイント +このセクションには、選択した検出事項が影響を及ぼすエンドポイントのテーブルと、関連するメタデータが含まれます。 + +### 追加の詳細 +- **リクエスト/レスポンスペア**: クライアントから送信されたメッセージと、そのリクエストに対するサーバーの応答のコピー。 +- **再現手順**: 検出事項を再現するための手順。 +- **深刻度の根拠**: 特定の深刻度評価が検出事項に関連付けられた理由を記述したもの。 + +## 検出事項のデータ +検出事項には以下のメタデータが必須です。 +- **名前** +- **日付** +- **深刻度** +- **説明** + +検出事項ビューのテーブルに対応するメタデータに加え、以下の任意のメタデータ項目も指定できます。 +- **タグ**: 検出事項に追加されたタグ。 +- **担当者**: 選択した検出事項を担当するユーザーのグループ。 +- **Jiraへプッシュ**: チケット発行のために検出事項をJiraへプッシュします。 +- **インテグレーターへプッシュ**: 統合済みのサードパーティ製課題管理システムへ検出事項をプッシュします。 +- **リスクと優先度の設定**: DefectDojoによる検出事項のリスクと優先度の自動計算を上書きするオプションを提供します。 +- **追加するエンドポイント**: 上記のシステム/エンドポイントの一覧に反映されていない、選択した検出事項の影響を受ける可能性のある脆弱なエンドポイント。 +- **不具合レビュー依頼者**: 該当する不具合についてレビューを依頼した人物を記録します。 +- **SASTソースオブジェクト、行番号、ファイルパス**: 攻撃ベクターのソースオブジェクト、行番号、ファイルパス。 +- **SASTシンクオブジェクト**: 攻撃ベクターのシンクオブジェクト。 +- **発生件数**: スキャナーによって複数の脆弱性が検出・集約された際の、発生元ツールにおける発生件数。 +- **公開日**: 脆弱性が公開された日付。 +- **対応工数の見積もり**: 検出事項の修正にかかる作業量のレベル(例: 低、中、高)。 + +利用可能な具体的なメタデータは、検出事項を明らかにしたパーサー/スキャナーによって異なります。タイトルと深刻度といった基本情報のみを提供するものもあれば、CVSSベクター、脆弱なコンポーネント、エンドポイント、リクエスト/レスポンスペア、その他スキャナー固有のメタデータを含むものもあります。 + +このメタデータにより、セキュリティプログラム全体でのフィルタリング、レポート作成、優先順位付けが向上し、長期的な追跡とトレンド分析が可能になります。詳細およびメタデータの説明は[こちら](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page)をご覧ください。 + +### 重複排除 +DefectDojoには、同一の根本的な脆弱性を表す検出事項を特定・管理するための重複排除機能が備わっています。1つまたは複数のツールからスキャン結果がインポートされると、DefectDojoは設定可能なマッチングロジックを使用して、同一の脆弱性を表す検出事項を特定します。 + +重複排除により、同一または異なるスキャナーによって繰り返し発見された同一の脆弱性が複数回表示されることを防ぎ、修復履歴を1つの検出事項に紐付けたまま保持できます。 + +重複排除の詳細は[こちら](/triage_findings/finding_deduplication/about_deduplication/)をご覧ください。 + +### 再インポート +DefectDojoの再インポート機能により、新しいスキャン結果がインポートされる際に検出事項を更新できます。スキャンが再インポートされると、DefectDojoは受信した結果を既存の検出事項と比較し、まったく新しいレコードを作成するのではなく、一致するレコードを更新します。これにより、ステータスの変更、修復履歴、コメント、担当情報などの重要な文脈が保持され、複数のテストサイクルにわたる検出事項のライフサイクルの継続的な記録が提供されます。 + +再インポート機能の詳細は[こちら](/import_data/import_intro/reimport/)をご覧ください。 + +### リスク受容 +リスク受容は、検出事項を即座に修復せずに承認する決定を正式に文書化し運用するために、検出事項に適用できる特別なステータスです。 + +リスク受容の詳細は[こちら](/triage_findings/findings_workflows/pro__risk_acceptance/)をご覧ください。 + +### ステータス +DefectDojoで作成された各検出事項には、関連情報を伝え、チームが問題解決の進捗を追跡できるようにするステータスがあります。 + +ステータスの詳細は[こちら](/triage_findings/findings_workflows/finding_status_definitions/)をご覧ください。 + +## 検出事項の操作 + +### 検出事項の作成 +ほとんどの検出事項はスキャンのインポートや統合を通じて自動的に生成されますが、DefectDojoでは検出事項を手動で作成することもサポートしています。手動での検出事項作成は、ペネトレーションテスト、アーキテクチャレビュー、コンプライアンス評価、バグバウンティプログラム、コンサルタントによるエンゲージメントなど、スキャナーの出力を生成しない活動を通じて特定された脆弱性やセキュリティ上の懸念事項を追跡する際に役立ちます。 + +検出事項は、サイドバーの**検出事項**セクション内で**新規検出事項**をクリックするか、検出事項を追加したいテストの歯車メニュー内で**検出事項を追加**を選択することで、手動で追加できます。 + +### 検出事項の編集 +検出事項の横にある⋮ケバブメニューには、以下の機能があります。 +- **検出事項を編集**: 検出事項を編集します。 +- **検出事項をコピー**: 検出事項のコピーを別のテストに作成します。コピーは、編集権限を持つ同一エンゲージメント内の任意のテストに保存できます。コピー機能は、同一の脆弱性を複数のテストのコンテキストで個別に追跡する必要がある場合に役立ちます。 +- **検出事項をクローズ**: 検出事項をクローズするプロセスを開始します。 +- **レビューを依頼**: ピアレビューのプロセスを開始し、検出事項のステータスを「レビュー中」に変更します。ピアレビューの詳細は[こちら](/triage_findings/findings_workflows/finding_status_definitions/#under-review)をご覧ください。 +- **リスク受容を追加**: リスク受容のプロセスを開始します。詳細は[こちら](/triage_findings/findings_workflows/pro__risk_acceptance/)をご覧ください。 +- **ファイルを追加**: 検出事項にファイルを追加するプロセスを開始します(以下のセクションを参照)。 +- **メモを追加**: 検出事項にメモを追加するプロセスを開始します。 +- **カスタムフィールドを追加**: 検出事項に適用するカスタムフィールドを追加・定義できるポップアップを開始します。 +- **Jiraへプッシュ**: チケット発行のために検出事項をJiraへプッシュします。 +- **インテグレーターへプッシュ**: 統合済みのサードパーティ製課題管理システムへ検出事項をプッシュします。 +- **検出事項を削除**: 選択した検出事項を削除します。 +- **検出事項の履歴**: 選択した検出事項の履歴を表示します。 + +#### 検出事項へのファイルの添付 +どの検出事項にもファイルを添付して、追加の文脈情報を提供できます—例えば、脆弱性が実際に発生している様子のスクリーンショットや、概念実証(PoC)の画像などです。 + +サポートされているファイル形式は以下の通りです。 + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +検出事項にファイルを添付するには、選択した検出事項の⋮ケバブメニューまたは歯車メニューから**ファイルを追加**をクリックします。ファイルのタイトルを入力し、コンピューターからファイルを選択して、**送信**をクリックします。 + +ファイルは、検出事項ビュー内の**テスト概要**テーブルのファイルセクションに表示されます。 + +#### 検出事項の一括編集 +検出事項は、サイドバーからアクセスできるすべての検出事項のテーブルなどの検出事項リストや、特定のテスト内の検出事項のテーブルから一括編集できます。 + +検出事項の一括編集方法の詳細は[こちら](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings)をご覧ください。 + +### 検出事項のクローズ +検出事項に対する作業が完了したら、検出事項の⋮ケバブメニューまたは歯車メニュー内の**検出事項をクローズ**をクリックして手動でクローズできます。あるいは、以前に記録された検出事項を含まないスキャンがDefectDojoに再インポートされた場合、その以前に記録された検出事項は自動的にクローズされます。 + +検出事項をクローズしたくない場合は、再インポートスキャンフォームでこの動作を無効にできます。 + +- UIを使用している場合は、Close Old Findingsのチェックボックスをオフにします +- APIを使用している場合は、close_old_findingsをFalseに設定します ​ + +### 検出事項の削除 +検出事項の削除は、検出事項の⋮ケバブメニューまたは歯車メニューから行えます。この操作は元に戻せません。 + +監査の目的上、修復済みの検出事項は削除するのではなく、クローズすることが推奨されます。 + +## 検出事項グループ +**検出事項グループ**を使用すると、トリアージ、レポート作成、修復調整のために、複数の関連する検出事項を単一の論理的な単位として扱うことができます。 + +例えば、あるスキャンによって異なるエンドポイントにわたる10件のSQLインジェクションの検出事項が生成されることがあります。それぞれを個別に管理する代わりに、それらをより広範なSQLインジェクションの問題を表す単一の検出事項グループにまとめることができます。 + +検出事項グループは個々の検出事項を置き換えるものではありません。各検出事項は、それぞれ固有の深刻度、ステータス、メタデータ、コメント、修復履歴を保持したまま存在し続けます。検出事項グループは、含まれる検出事項の上に、単に追加の整理層を提供するだけです。 + +### 検出事項グループへのアクセス +検出事項グループにはサイドバーからアクセスできます。サブメニューからは、オープンおよびクローズの検出事項グループ、ならびに(オープン状態を問わない)すべての検出事項グループにアクセスできます。 + +![image](images/profindings_ss1.png) + +### 検出事項グループの作成 +検出事項グループは、手動または自動のいずれかで作成できます。 + +なお、検出事項グループは単一のテストに含まれる検出事項からのみ作成できます。異なるテスト、エンゲージメント、または製品にまたがる検出事項を同じ検出事項グループに追加することはできません。 + +#### 手動での検出事項グループ +検出事項グループの操作を手動で行うには: +1. テスト内の検出事項の一覧に移動します。 +2. 検出事項グループに追加したい検出事項に対応するチェックボックスをクリックして選択します。 +3. 検出事項リストの上部に表示される**検出事項グループ**ボタンをクリックします。 +4. 実行したい対応するアクションをクリックします。 + - **新しい検出事項グループに追加**: 選択した検出事項を含む新しい検出事項グループを作成します。 + - **既存の検出事項グループに追加**: 選択した検出事項を既存の検出事項グループに追加します。 + - **検出事項グループから削除**: 選択した検出事項を、それまで属していた検出事項グループから削除します。 +5. **送信**をクリックします。 + +選択したすべての検出事項が編集可能であり、未グループ化であり、かつ同じテストに含まれている場合にのみ、グループ化が有効になる点に注意してください。 + +さらに、すべての検出事項の一覧から検出事項を選択した場合に実行できる唯一のアクションは、選択した検出事項を検出事項グループから削除することです。これは前述の通り、検出事項グループが単一のテストに含まれる検出事項からのみ作成できるためです。 + +#### 自動での検出事項グループ +スキャンをインポートする際、折りたたみ可能な**オプションフィールド**メニュー内の**グループ化基準**機能を使用すると、選択したグループ化方法に基づいて検出事項グループを自動的に作成できます。これは、スキャナーが一緒に管理すべき多数の関連する検出事項を生成する場合に役立ちます。 + +隣接する**すべての検出事項に対して検出事項グループを作成する**チェックボックスは、2つの機能を果たします。 +- **チェックした場合**: インポートされたすべての検出事項に対して検出事項グループを作成します。たとえそのグループのメンバーがその検出事項のみであってもです。 +- **チェックしない場合**: 実際にグループ化すべき複数の検出事項が存在する場合にのみ、検出事項グループを作成します。 + +![image](images/profindings_ss2.png) + +インポート時にグループ化基準のドロップダウンメニューからオプションが選択されていない場合(例えば上記のスクリーンショットにある**検出事項タイトル**など)、グループ化は行われません。 + +グループ化基準(コンポーネント名、脆弱性ID、検出事項タイトルなど)が検出事項に設定されていない場合、その検出事項に対してグループが作成されたり、既存の検出事項グループに追加されたりすることはありません。 + +グループ化されていない10件の検出事項が明らかになるスキャンがインポートされ、その後同じスキャンが再インポートされて検出事項がグループ化された場合、最初の10件の検出事項はその検出事項グループには追加されません(つまり、検出事項グループには再インポート時の10件の検出事項のみが含まれ、初回インポート時の10件の検出事項は含まれません)。 + +## 検出事項テンプレート +**検出事項テンプレート**を使用すると、ユーザーはよく報告される脆弱性やセキュリティ上の問題に対する再利用可能なテンプレートを作成できます。テンプレートには、タイトル、説明、影響、再現手順、緩和策、参照、その他の検出事項メタデータなどの標準化された情報を含めることができます。 + +検出事項テンプレートは、ユーザーが手動での検出事項作成を繰り返し行う必要があり、毎回同じ補足情報を再入力することを避けたい状況で最も役立ちます。 + +### 検出事項テンプレートへのアクセス +検出事項テンプレートは、サイドバーの検出事項サブメニュー内にあります。 + +![image](images/profindings_ss1.png) + +### 検出事項テンプレートの作成 +検出事項テンプレートは、検出事項テンプレートビューの左上にある**新規検出事項テンプレート**ボタンをクリックすることで作成できます。 + +続くページには、検出事項テンプレートを使用した際に検出事項に適用されるメタデータの概要が表示されます。 + +### 検出事項テンプレートの適用 +検出事項テンプレートは、OS版DefectDojoとDefectDojo Proとで異なります。Proでは、検出事項テンプレートを既存の検出事項に適用することはできず、また既存の検出事項に基づいて作成することもできません。 + +ただし、親エンゲージメントのビュー内でテストの横にある⋮ケバブメニュー、またはテストのビュー内の歯車メニューを使用して、検出事項テンプレートに基づく検出事項をテストに手動で追加することができます。 + +![image](images/profindings_ss3.png) + +![image](images/profindings_ss4.png) + +## レポート作成 +DefectDojoのレポートビルダーを使用すると、一連のコンテンツウィジェットからカスタムレポートを組み立て、実行し、その結果をエクスポートできます(例えば、PDFとして印刷するなど)。カスタムレポートは、社外の対象者と共有したい検出事項やエンドポイントをまとめることができ、ブランディングや定型文を含めることもできます。 + +DefectDojoのレポートビルダーの詳細は[こちら](/metrics_reports/reports/report-builder/)をご覧ください。 + +### 検出事項のエクスポート +検出事項の一覧またはエンゲージメントの一覧を表示するページには、左上にCSVおよびExcelのエクスポートオプションがあります。検出事項の場合、クイックエクスポートを実行するオプションもあり、これを実行すると各検出事項に関するメタデータのテーブルを含む新しいタブが開きます。 diff --git a/docs/content/asset_modelling/engagements_tests/PRO__organizations.de.md b/docs/content/asset_modelling/engagements_tests/PRO__organizations.de.md new file mode 100644 index 00000000000..542d05c1037 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__organizations.de.md @@ -0,0 +1,140 @@ +--- +title: Organisationen +description: Organisationen in DefectDojo Pro verstehen +audience: pro +weight: 1 +--- + +**ORGANISATIONEN** → Assets → Engagements → Tests → Befunde + +## Überblick + +**Organisationen** stehen ganz oben in der Produkthierarchie von DefectDojo. Organisationen unterscheiden sich von den nachgeordneten Objekten der Hierarchie — Assets, Engagements, Tests und Befunden —, da sie keine technischen Scan-Ziele sind, sondern in erster Linie als organisatorische Abstraktionen dienen, die Ihre Sicherheitsbemühungen unterteilen nach: +- Geschäftsbereich +- Entwicklungsteam +- Sicherheitsteam +- Softwareanwendungen +- Übergeordneter Produktfamilie +- Kunde oder Tochtergesellschaft +- Berichtsstruktur +- usw. + +Das gemeinsame Thema der obigen Beispiele veranschaulicht den wesentlichen Nutzen von Organisationen: Sie sollten in der Regel stabile, langlebige Grenzen innerhalb Ihres Sicherheitsprogramms darstellen. + +## Organisationsdaten und -struktur + +Da Organisationen nicht direkt gescannt werden, ist der Name das einzige Pflichtfeld, das zu ihrer Erstellung erforderlich ist. Darüber hinaus fungieren sie als Container für Assets und deren nachgeordnete Engagements, Tests und Befunde. + +Überlegen Sie beim Erstellen einer Organisation, wie deren Struktur Ihre Berichterstellung beeinflussen wird. Benötigen Sie Organisationen in erster Linie, um die Teams abzubilden, die an den Projekten (Assets) arbeiten, welche die Organisationen enthalten werden? Oder würden Organisationen besser übergeordnete Projekte darstellen, die unterschiedliche Iterationen der darin enthaltenen Projekte (Assets) umfassen? + +Wenn Sie eine einzelne Organisation haben, die alle relevanten Informationen für einen bestimmten Geschäftsbereich oder ein bestimmtes Entwicklungsteam enthält, erleichtert deren Abbildung als Organisation eine reibungslosere Berichterstellung, anstatt einen Bericht aus verschiedenen Assets und Organisationen zusammenstellen zu müssen. + +Wenn ein bestimmtes Softwareprojekt viele verschiedene Bereitstellungen oder Versionen hat, kann es sich lohnen, eine einzelne Organisation zu erstellen, die den Umfang des gesamten Projekts abdeckt, wobei jede Version als einzelnes Asset existiert. In manchen Workflows werden Organisationen auch verwendet, um Phasen des Softwarelebenszyklus zu trennen: eine Organisation für „In Entwicklung", eine Organisation für „In Produktion" usw. +​ +Organisationen können verwendet werden, um für RBAC-Zwecke den Zugriff auf Tochtergesellschaften, erworbene Unternehmen oder andere regulierte Geschäftseinheiten festzulegen. In komplexen Unternehmen, in denen es viele einzigartige Projekte mit unterschiedlichen Zugriffsregeln gibt, sind Organisationen besonders relevant. + +Letztlich hängt die Entscheidung, wie Organisationen und Assets verwendet werden, davon ab, wie Sie Ihre individuelle Organisationsstruktur und die Anforderungen Ihres Sicherheitsteams am besten abbilden möchten. + +Nachfolgend finden Sie einige Beispielstrukturen, die Ihnen als Orientierung dienen, wie Sie Ihre Objekte entweder als Organisationen oder als Assets festlegen. + +- **Organisation**: Zahlungsabteilung + - Asset: Payments API - Production + - Asset: Payments API - Staging + - Asset: Billing Worker + +- **Organisation**: Softwareprodukt A + - Asset: Web Portal + - Asset: Mobile Backend + +Darüber hinaus dient die folgende Übersicht als Orientierungshilfe, ob etwas besser durch eine Organisation oder ein Asset dargestellt wird: + +| Organizations | Assets | +|--------------|--------| +| Geschäftseinheiten | Einzelne Anwendungen | +| Abteilungen | Bereitstellungen/Umgebungen | +| Sicherheitszuständigkeitsbereiche | Infrastrukturkomponenten | +| Produktfamilien | Spezifische Microservices | +| Portfolioebene-Berichterstattung | Scan-Ziele | +| Kunden | Spezifische Softwareversionen | + +Wie bereits erwähnt, kann Ihre Struktur je nach Ihren individuellen Sicherheitsanforderungen abweichen. + +## Zugriff auf Organisationen + +Organisationen sind über die Seitenleiste zugänglich. Das Untermenü bietet Zugriff auf Alle Organisationen sowie die Möglichkeit, eine neue Organisation zu erstellen. + +![image](images/org_ss1.png) + +## Organisationsansicht + +Die Ansicht einer Organisation enthält verschiedene Tabellen und Diagramme, um deren Status auf einen Blick zu erfassen. Dazu gehören: + +- **Beschreibung** +- **Commerce** + - Ob die Organisation als Kritisch oder Wichtig eingestuft wurde + - Die Kennzeichnung als Kritisch oder Wichtig dient ausschließlich Filterzwecken +- **Zugewiesene Mitglieder** (DefectDojo-Benutzer) +- **Zugewiesene Benutzergruppen** + - Benutzergruppen, die der Organisation zur Berechtigungssteuerung zugewiesen wurden. Weitere Informationen zu Benutzergruppen finden Sie [hier](/admin/user_management/create_user_group/). +- **Liste der Assets innerhalb der Organisation** + +## Arbeiten mit Organisationen + +### Organisationen erstellen + +Es gibt zwei Möglichkeiten, Organisationen zu erstellen: + +- Über die Option **Neue Organisation** im Seitenmenü +- Über die Schaltfläche **Neue Organisation** oben in der Liste Alle Organisationen + +### Organisationen bearbeiten + +Organisationen können bearbeitet werden, indem Sie im Zahnradmenü oben rechts in der Ansicht der Organisation auf **Organisation bearbeiten** klicken. Dasselbe Menü kann auch über das ⋮-Kebab-Menü links neben der Organisation in der Ansicht Alle Organisationen aufgerufen werden. + +Alle daraufhin bearbeitbaren Felder sind auch bereits beim Erstellen der Organisation verfügbar. + +### Organisationen löschen + +Das Löschen einer Organisation erfolgt, indem Sie in den Einstellungen der Organisation **Organisation löschen** auswählen. + +Da Organisationen ganz oben in der Hierarchie stehen, werden beim Löschen sämtlicher nachgeordneter Sicherheitsverlauf, Beziehungen und untergeordnete Objekte entfernt, wie zum Beispiel: +- Alle in der Organisation enthaltenen Assets, Engagements und Tests +- Der gesamte zugehörige Sicherheitsverlauf, einschließlich Befunde und Integrationen +- Alle verknüpften Jira-Epics +- Alle Notizen und Datei-Uploads, die mit den Assets, Engagements und Tests innerhalb dieser Organisation verknüpft sind + +Das Löschen einer Organisation kann nicht rückgängig gemacht werden. Wenn Sie eine Organisation „außer Betrieb nehmen" möchten, ohne die zugrunde liegenden Daten zu löschen (zum Beispiel, um alte Software-Testaufzeichnungen zu Auditzwecken zu erhalten), können Sie den Namen der Organisation ändern oder einen Tag hinzufügen, der anzeigt, dass sie sich in einem veralteten Zustand befindet. + +## Organisationen vs. Metadaten + +Organisationen sollen strukturelle Zuständigkeiten oder Berichtsgrenzen abbilden und keine leichtgewichtigen Klassifizierungen. Attribute wie Bereitstellungsstatus, interne Kennzeichnungen oder temporäre Workflow-Zustände lassen sich oft besser durch Tags oder Metadaten abbilden als durch separate Organisationen. + +## Organisationsgrenzen + +Organisationen legen sowohl Berichts- als auch Zugriffsgrenzen innerhalb von DefectDojo fest. Da Integrationen, RBAC-Berechtigungen, Zuständigkeiten, Metriken und Deduplizierungsmodelle häufig die Struktur der Organisationen übernehmen, hilft eine frühzeitig klar gestaltete Grenzziehung dabei, spätere Hierarchie-Wildwuchs und Fragmentierung der Berichterstattung zu vermeiden. + +### Befunde und Automatisierung + +Obwohl Integrationen in der Regel auf untergeordneten Objekten wie Assets, Engagements oder Befunden konfiguriert werden, legen Organisationen weiterhin die Zuständigkeits-, Berichts- und Zugriffsgrenzen fest, innerhalb derer diese Integrationen arbeiten. + +Berechtigungen kaskadieren nach unten, das heißt, der Zugriff auf eine Organisation gewährt automatisch Zugriff auf alle Objekte innerhalb dieser Organisation (z. B. Assets, Engagements, Tests und Befunde). + +Das RBAC-Modell von DefectDojo kann verwendet werden, um den Zugriff menschlicher Benutzer zu steuern, aber auch, um den Zugriff von API-Token auf bestimmte Organisationen zu beschränken. + +Weitere Informationen zu Benutzerrollen finden Sie in unserem Artikel [Einführung in die Berechtigungstypen](/admin/user_management/set_user_permissions/#introduction-to-permission-types). + +### Eigentümerschaft + +Als übergeordnete Objekte implizieren Organisationen auch die Zuständigkeit für die darin enthaltenen untergeordneten Objekte. SLA-Nachverfolgung, Behebungs-Workflows, Ticket-Routing und die allgemeine Governance funktionieren reibungsloser, wenn Organisationen so eingerichtet wurden, dass sie die dafür verantwortlichen Personen genau widerspiegeln. + +### Metriken/Berichterstellung + +Metrik-Dashboards, Kacheln und Ansichten können nach Organisation gefiltert werden, wodurch sie eine entscheidende Komponente dafür sind, wie Ihre Sicherheitsdaten berechnet, visualisiert und letztlich exportiert werden. + +Für Berichtszwecke ist es in der Regel einfacher, mehrere Organisationen in einem einzigen Dokument zusammenzufassen, als eine einzelne Organisation in separate Dokumente aufzuteilen. Wir empfehlen daher, Organisationen so granular einzurichten, wie es für die Berichte Ihres Teams sinnvoll ist. Es besteht beispielsweise keine Notwendigkeit, eine große Geschäftseinheit als Organisation abzubilden, wenn Sie hauptsächlich an einzelne Abteilungen innerhalb dieser Einheit berichten werden. + +Eine effektive Strukturierung Ihrer Organisationen entsprechend Ihren Berichtsanforderungen ist entscheidend für eine genaue Bewertung Ihrer Sicherheitslage. Weitere Informationen zu Metriken finden Sie [hier](/metrics_reports/pro_metrics/pro__overview/). + +### Deduplizierung + +Die Deduplizierung in DefectDojo erfolgt auf Asset-Ebene und wird von der übergeordneten Organisation nicht beeinflusst. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__organizations.es.md b/docs/content/asset_modelling/engagements_tests/PRO__organizations.es.md new file mode 100644 index 00000000000..b9aaaaeaef5 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__organizations.es.md @@ -0,0 +1,140 @@ +--- +title: Organizaciones +description: Comprender las Organizaciones en DefectDojo Pro +audience: pro +weight: 1 +--- + +**ORGANIZACIONES** → Activos → Compromisos → Tests → Hallazgos + +## Descripción general + +Las **Organizaciones** se ubican en la parte más alta de la jerarquía de productos de DefectDojo. Las Organizaciones se distinguen de los objetos descendentes de la jerarquía —Activos, Compromisos, Tests y Hallazgos— porque no son objetivos técnicos de análisis, sino que funcionan principalmente como abstracciones organizativas que compartimentan sus esfuerzos de seguridad según: +- Dominio de negocio +- Equipo de desarrollo +- Equipo de seguridad +- Aplicaciones de software +- Familia de productos general +- Cliente o subsidiaria +- Estructura de generación de informes +- etc. + +El hilo conductor de los ejemplos anteriores ilustra la utilidad esencial de las Organizaciones: en general, deben representar límites estables y duraderos dentro de su programa de seguridad. + +## Datos y estructura de la Organización + +Dado que las Organizaciones no se analizan directamente, el único campo obligatorio para crearlas es un nombre. Más allá de eso, funcionan como contenedores de Activos y de los Compromisos, Tests y Hallazgos que descienden de ellos. + +Al crear una Organización, considere cómo su estructura influirá en la generación de sus informes. ¿Necesita principalmente que las Organizaciones representen a los equipos que trabajan en los proyectos (Activos) que contendrán las Organizaciones? ¿O sería mejor que las Organizaciones representaran proyectos generales que contienen diferentes iteraciones de los proyectos (Activos) dentro de ellas? + +Si tiene una única Organización que contiene toda la información relevante para un dominio de negocio o equipo de desarrollo determinado, representarla como una Organización facilitará una generación de informes más fluida, en lugar de tener que reunir un informe a partir de varios Activos y Organizaciones. + +Si un proyecto de software en particular tiene muchas implementaciones o versiones distintas, puede valer la pena crear una única Organización que cubra el alcance de todo el proyecto y que cada versión exista como Activos individuales. En algunos flujos de trabajo, las Organizaciones también se pueden utilizar para separar las etapas del ciclo de vida del software: una Organización para “In Development”, otra Organización para “In Production”, etc. +​ +Las Organizaciones se pueden utilizar para determinar el acceso a subsidiarias, empresas adquiridas u otras unidades de negocio reguladas con fines de RBAC. En negocios complejos, donde existen muchos proyectos únicos con distintas reglas de acceso, las Organizaciones son particularmente relevantes. + +En última instancia, la decisión sobre cómo utilizar las Organizaciones y los Activos depende de cómo desee reflejar mejor su estructura organizativa particular y las necesidades de su equipo de seguridad. + +A continuación se presentan algunos ejemplos de estructuras que le ayudarán a decidir cómo designar sus objetos, ya sea como Organizaciones o como Activos. + +- **Organización**: División de Pagos + - Activo: API de Pagos - Producción + - Activo: API de Pagos - Staging + - Activo: Worker de Facturación + +- **Organización**: Producto de Software A + - Activo: Portal Web + - Activo: Backend Móvil + +Además, la siguiente es una guía ilustrativa sobre si algo se representa mejor como una Organización o como un Activo: + +| Organizations | Assets | +|--------------|--------| +| Unidades de negocio | Aplicaciones individuales | +| Departamentos | Implementaciones/entornos | +| Dominios de propiedad de seguridad | Componentes de infraestructura | +| Familias de productos | Microservicios específicos | +| Informes a nivel de portafolio | Objetivos de análisis | +| Clientes | Versiones específicas de software | + +Como se mencionó, su estructura puede variar según las necesidades particulares de seguridad de su organización. + +## Acceso a las Organizaciones + +Se puede acceder a las Organizaciones desde la barra lateral. El submenú brinda acceso a Todas las Organizaciones, así como la opción de crear una nueva Organización. + +![image](images/org_ss1.png) + +## Vista de la Organización + +La vista de una Organización contiene una variedad de tablas y gráficos para interpretar su estado de un vistazo. Esto incluye: + +- **Description** +- **Commerce** + - Si se ha determinado que la Organización es Crítica o Clave + - Marcar Crítica o Clave se utiliza únicamente con fines de filtrado +- **Assigned Members** (Usuarios de DefectDojo) +- **Assigned User Groups** + - Grupos de usuarios que se han asignado a la Organización para el control de permisos. Puede encontrar más información sobre los grupos de usuarios [aquí](/admin/user_management/create_user_group/). +- **List of Assets within the Organization** + +## Cómo trabajar con las Organizaciones + +### Crear Organizaciones + +Hay dos formas de crear Organizaciones: + +- Desde la opción **New Organization** en el menú lateral +- Desde el botón **New Organization** en la parte superior de la lista Todas las Organizaciones + +### Editar Organizaciones + +Las Organizaciones se pueden editar haciendo clic en **Edit Organization** dentro del menú de engranaje en la parte superior derecha de la vista de la Organización. También se puede acceder al mismo menú haciendo clic en el menú kebab ⋮ a la izquierda de la Organización en la vista Todas las Organizaciones. + +Todos los campos que se pueden editar posteriormente también están disponibles al crear la Organización. + +### Eliminar Organizaciones + +Se puede eliminar una Organización seleccionando **Delete Organization** desde la configuración de la Organización. + +Dado que las Organizaciones se ubican en la parte superior de la jerarquía, eliminarlas elimina todo el historial de seguridad, las relaciones y los objetos secundarios posteriores, tales como: +- Cualquier Activo, Compromiso y Test contenido dentro de la Organización +- Todo el historial de seguridad asociado, incluidos los Hallazgos e integraciones +- Cualquier Épica de Jira vinculada +- Todas las notas y archivos cargados asociados con los Activos, Compromisos y Tests dentro de esa Organización + +Eliminar una Organización no se puede deshacer. Si desea “dar de baja” una organización sin eliminar los datos subyacentes (por ejemplo, para conservar registros de pruebas de software heredado con fines de auditoría), puede cambiar el nombre de la Organización o agregar una Etiqueta que indique que se encuentra en un estado obsoleto. + +## Organizaciones frente a Metadatos + +Las Organizaciones están destinadas a representar la propiedad estructural o los límites de generación de informes, en lugar de clasificaciones livianas. Atributos como el estado de implementación, las etiquetas internas o los estados temporales de flujo de trabajo pueden representarse mejor mediante etiquetas o metadatos, en lugar de mediante Organizaciones separadas. + +## Límites de la Organización + +Las Organizaciones establecen tanto los límites de generación de informes como los de acceso dentro de DefectDojo. Dado que las integraciones, los permisos de RBAC, la propiedad, las métricas y los modelos de deduplicación suelen heredar la estructura de las Organizaciones, diseñar límites claros desde el principio ayuda a evitar una expansión descontrolada de la jerarquía y la fragmentación de los informes más adelante. + +### Hallazgos y automatización + +Aunque las integraciones normalmente se configuran en objetos de nivel inferior, como Activos, Compromisos o Hallazgos, las Organizaciones siguen definiendo los límites de propiedad, generación de informes y acceso dentro de los cuales operan esas integraciones. + +Los permisos se propagan en cascada hacia abajo, lo que significa que el acceso a una Organización otorga automáticamente acceso a todos los objetos dentro de esa Organización (por ejemplo, Activos, Compromisos, Tests y Hallazgos). + +El modelo de RBAC de DefectDojo se puede utilizar para controlar el acceso de usuarios humanos, pero también puede restringir el acceso de los tokens de API a Organizaciones particulares. + +Para obtener más información sobre los roles de usuario, consulte nuestro artículo [Introducción a los tipos de permisos](/admin/user_management/set_user_permissions/#introduction-to-permission-types). + +### Propiedad + +Como objetos de nivel superior, las Organizaciones también implican la propiedad sobre los objetos secundarios que contienen. El seguimiento de SLA, los flujos de trabajo de remediación, el enrutamiento de tickets y la gobernanza general fluyen con mayor fluidez cuando las Organizaciones se han configurado para reflejar con precisión a las personas responsables de ellas. + +### Métricas/Generación de informes + +Los paneles de métricas, los cuadros y las vistas se pueden filtrar por Organización, lo que los convierte en un componente crítico de cómo se calculan, visualizan y, en última instancia, se exportan sus datos de seguridad. + +Para fines de generación de informes, generalmente es más fácil combinar varias Organizaciones en un único documento que subdividir una única Organización en documentos separados. Por lo tanto, recomendamos configurar las Organizaciones con el nivel de granularidad que tenga sentido para los informes de su equipo. Por ejemplo, no es necesario representar una gran división de negocio como una Organización si principalmente va a generar informes para departamentos individuales dentro de esa división. + +Estructurar eficazmente sus Organizaciones para reflejar sus necesidades de generación de informes es fundamental para evaluar con precisión su postura de seguridad. Para obtener más información sobre Métricas, haga clic [aquí](/metrics_reports/pro_metrics/pro__overview/). + +### Deduplicación + +La deduplicación en DefectDojo ocurre a nivel de Activo, y no se ve afectada por la Organización principal. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__organizations.fr.md b/docs/content/asset_modelling/engagements_tests/PRO__organizations.fr.md new file mode 100644 index 00000000000..bd53353e88b --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__organizations.fr.md @@ -0,0 +1,140 @@ +--- +title: Organisations +description: Comprendre les Organisations dans DefectDojo Pro +audience: pro +weight: 1 +--- + +**ORGANISATIONS** → Actifs → Engagements → Tests → Constatations + +## Aperçu + +**Les Organisations** se situent tout en haut de la hiérarchie des produits de DefectDojo. Les Organisations se distinguent des objets descendants de la hiérarchie — Actifs, Engagements, Tests et Constatations — car elles ne constituent pas des cibles de scan techniques, mais servent avant tout d'abstractions organisationnelles permettant de compartimenter vos efforts de sécurité selon : +- Le domaine d'activité +- L'équipe de développement +- L'équipe de sécurité +- Les applications logicielles +- La famille de produits globale +- Le client ou la filiale +- La structure de reporting +- etc. + +Le fil conducteur des exemples ci-dessus illustre l'utilité essentielle des Organisations : elles doivent généralement représenter des frontières stables et durables au sein de votre programme de sécurité. + +## Données et structure des Organisations + +Comme les Organisations ne sont pas scannées directement, le seul champ obligatoire pour les créer est un nom. Au-delà de cela, elles servent de conteneurs pour les Actifs et leurs Engagements, Tests et Constatations descendants. + +Lors de la création d'une Organisation, réfléchissez à la manière dont sa structure influencera votre reporting. Avez-vous principalement besoin que les Organisations représentent les équipes travaillant sur les projets (Actifs) qu'elles contiendront ? Ou les Organisations représenteraient-elles mieux des projets globaux englobant différentes itérations des projets (Actifs) qu'ils contiennent ? + +Si vous disposez d'une seule Organisation regroupant toutes les informations pertinentes pour un domaine d'activité ou une équipe de développement donné, la représenter comme une Organisation facilitera un reporting plus fluide, plutôt que de devoir compiler un rapport à partir de divers Actifs et Organisations. + +Si un projet logiciel particulier comporte de nombreux déploiements ou versions distincts, il peut être pertinent de créer une seule Organisation couvrant l'ensemble du périmètre du projet, chaque version existant alors en tant qu'Actif individuel. Dans certains workflows, les Organisations peuvent également être utilisées pour séparer les étapes du cycle de vie logiciel : une Organisation pour « En développement », une Organisation pour « En production », etc. +​ +Les Organisations peuvent être utilisées pour déterminer l'accès aux filiales, aux entreprises acquises ou à d'autres unités commerciales réglementées à des fins de RBAC. Dans les entreprises complexes, où de nombreux projets uniques ont des règles d'accès différentes, les Organisations sont particulièrement pertinentes. + +En définitive, la décision quant à la manière d'utiliser les Organisations et les Actifs dépend de la façon dont vous souhaitez le mieux refléter votre structure organisationnelle unique et les besoins de votre équipe de sécurité. + +Voici quelques exemples de structures pour vous aider à déterminer si vos objets doivent être désignés comme des Organisations ou des Actifs. + +- **Organisation** : Division des paiements + - Actif : API de paiements - Production + - Actif : API de paiements - Staging + - Actif : Worker de facturation + +- **Organisation** : Produit logiciel A + - Actif : Portail Web + - Actif : Backend mobile + +En outre, voici un guide illustratif permettant de déterminer si un élément est mieux représenté par une Organisation ou par un Actif : + +| Organisations | Actifs | +|--------------|--------| +| Unités commerciales | Applications individuelles | +| Départements | Déploiements/environnements | +| Domaines de propriété de sécurité | Composants d'infrastructure | +| Familles de produits | Microservices spécifiques | +| Reporting au niveau du portefeuille | Cibles de scan | +| Clients | Versions logicielles spécifiques | + +Comme indiqué, votre structure peut varier selon les besoins de sécurité qui vous sont propres. + +## Accès aux Organisations + +Les Organisations sont accessibles depuis la barre latérale. Le sous-menu donne accès à Toutes les Organisations, ainsi qu'à l'option permettant de créer une nouvelle Organisation. + +![image](images/org_ss1.png) + +## Vue de l'Organisation + +La vue d'une Organisation contient divers tableaux et graphiques permettant d'interpréter son statut en un coup d'œil. Cela comprend : + +- **Description** +- **Commerce** + - Indique si l'Organisation a été déterminée comme Critique ou Clé + - Cocher Critique ou Clé est utilisé uniquement à des fins de filtrage +- **Membres assignés** (Utilisateurs DefectDojo) +- **Groupes d'utilisateurs assignés** + - Groupes d'utilisateurs assignés à l'Organisation pour le contrôle des permissions. Vous trouverez plus d'informations sur les groupes d'utilisateurs [ici](/admin/user_management/create_user_group/). +- **Liste des Actifs au sein de l'Organisation** + +## Travailler avec les Organisations + +### Créer des Organisations + +Il existe deux façons de créer des Organisations : + +- Depuis l'option **Nouvelle organisation** du menu latéral +- Depuis le bouton **Nouvelle organisation** en haut de la liste Toutes les Organisations + +### Modifier des Organisations + +Les Organisations peuvent être modifiées en cliquant sur **Modifier l'organisation** dans le menu d'engrenage en haut à droite de la vue de l'Organisation. Ce même menu est également accessible en cliquant sur le menu kebab ⋮ à gauche de l'Organisation dans la vue Toutes les Organisations. + +Tous les champs qui peuvent ensuite être modifiés sont également disponibles lors de la création de l'Organisation. + +### Supprimer des Organisations + +La suppression d'une Organisation peut être effectuée en sélectionnant **Supprimer l'organisation** dans les paramètres de l'Organisation. + +Comme les Organisations se situent au sommet de la hiérarchie, leur suppression entraîne la suppression de tout l'historique de sécurité en aval, des relations et des objets enfants, tels que : +- Tout Actif, Engagement et Test contenu dans l'Organisation +- Tout l'historique de sécurité associé, y compris les Constatations et les intégrations +- Tout Epic Jira lié +- Toutes les notes et tous les fichiers téléversés associés aux Actifs, Engagements et Tests au sein de cette Organisation + +La suppression d'une Organisation est irréversible. Si vous souhaitez « démanteler » une organisation sans supprimer les données sous-jacentes (par exemple, pour conserver des enregistrements de tests logiciels historiques à des fins d'audit), vous pouvez modifier le nom de l'Organisation ou ajouter une Étiquette indiquant qu'elle est dans un état obsolète. + +## Organisations et métadonnées + +Les Organisations sont destinées à représenter des frontières de propriété structurelle ou de reporting, plutôt que des classifications légères. Des attributs tels que le statut de déploiement, les libellés internes ou les états de workflow temporaires peuvent être mieux représentés par des étiquettes ou des métadonnées plutôt que par des Organisations distinctes. + +## Limites des Organisations + +Les Organisations établissent à la fois des limites de reporting et d'accès au sein de DefectDojo. Étant donné que les intégrations, les permissions RBAC, la propriété, les métriques et les modèles de déduplication héritent fréquemment de la structure des Organisations, définir des limites claires dès le départ permet d'éviter par la suite une prolifération de la hiérarchie et une fragmentation du reporting. + +### Constatations et automatisation + +Bien que les intégrations soient généralement configurées sur des objets de niveau inférieur tels que les Actifs, les Engagements ou les Constatations, les Organisations définissent néanmoins les limites de propriété, de reporting et d'accès au sein desquelles ces intégrations fonctionnent. + +Les permissions se propagent vers le bas, ce qui signifie que l'accès à une Organisation accorde automatiquement l'accès à tous les objets qu'elle contient (par exemple, les Actifs, Engagements, Tests et Constatations). + +Le modèle RBAC de DefectDojo peut être utilisé pour contrôler l'accès des utilisateurs humains, mais aussi pour restreindre l'accès des tokens API à des Organisations particulières. + +Pour plus d'informations sur les rôles utilisateur, consultez notre article [Introduction aux types de permissions](/admin/user_management/set_user_permissions/#introduction-to-permission-types). + +### Propriété + +En tant qu'objets de premier niveau, les Organisations impliquent également la propriété des objets enfants qu'elles contiennent. Le suivi des SLA, les workflows de remédiation, le routage des tickets et la gouvernance générale fonctionnent tous plus efficacement lorsque les Organisations ont été configurées pour refléter fidèlement les personnes qui en sont responsables. + +### Métriques/Reporting + +Les tableaux de bord de métriques, les tuiles et les vues peuvent être filtrés par Organisation, ce qui en fait un élément essentiel de la façon dont vos données de sécurité sont calculées, visualisées et finalement exportées. + +À des fins de reporting, il est généralement plus simple de combiner plusieurs Organisations en un seul document que de subdiviser une seule Organisation en plusieurs documents. Nous recommandons donc de configurer les Organisations au niveau de granularité le plus pertinent pour les rapports de votre équipe. Par exemple, il n'est pas nécessaire de représenter une grande division commerciale comme une Organisation si vous allez principalement produire des rapports pour les différents départements de cette division. + +Structurer efficacement vos Organisations pour refléter vos besoins de reporting est essentiel pour évaluer avec précision votre posture de sécurité. Pour plus d'informations sur les Métriques, cliquez [ici](/metrics_reports/pro_metrics/pro__overview/). + +### Déduplication + +La déduplication dans DefectDojo s'effectue au niveau de l'Actif et n'est pas affectée par l'Organisation parente. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__organizations.ja.md b/docs/content/asset_modelling/engagements_tests/PRO__organizations.ja.md new file mode 100644 index 00000000000..11444a2b429 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__organizations.ja.md @@ -0,0 +1,140 @@ +--- +title: 組織 +description: DefectDojo Proにおける組織について +audience: pro +weight: 1 +--- + +**組織** → アセット → エンゲージメント → テスト → 検出事項 + +## 概要 + +**組織**は、DefectDojoの製品階層の最上位に位置します。組織は、階層内で下位に位置するオブジェクト—アセット、エンゲージメント、テスト、検出事項—とは異なり、技術的なスキャン対象ではなく、主に以下のような観点でセキュリティ活動を区分けするための組織的な抽象概念として機能します。 +- 事業領域 +- 開発チーム +- セキュリティチーム +- ソフトウェアアプリケーション +- 包括的な製品ファミリー +- 顧客または子会社 +- レポート体制 +- など + +上記の例に共通するテーマは、組織の本質的な有用性を示しています。すなわち、組織は一般的に、セキュリティプログラム内で安定した長期的な境界を表すべきだということです。 + +## 組織のデータと構造 + +組織は直接スキャンされる対象ではないため、作成に必要な必須項目は名前のみです。それ以外では、組織はアセットおよびその下位にあるエンゲージメント、テスト、検出事項を格納するコンテナとして機能します。 + +組織を作成する際は、その構造がレポート作成にどのように影響するかを考慮してください。組織に、その組織が含むプロジェクト(アセット)に取り組むチームを表現させたいのか。それとも、組織にその中に含まれるプロジェクト(アセット)のさまざまなバージョンを包含する、より包括的なプロジェクトを表現させる方が適しているのか。 + +特定の事業領域や開発チームに関連するすべての情報を含む単一の組織がある場合、それを1つの組織として表現することで、さまざまなアセットや組織からレポートをまとめ上げる必要がなくなり、よりスムーズなレポート作成が可能になります。 + +特定のソフトウェアプロジェクトに多数の異なるデプロイやバージョンがある場合、そのプロジェクト全体のスコープをカバーする単一の組織を作成し、各バージョンを個別のアセットとして存在させる方が良い場合もあります。ワークフローによっては、ソフトウェアのライフサイクルの段階を区別するために組織を使用することもあります。例えば、「開発中」用の組織と「本番稼働中」用の組織を分けるといった具合です。 +​ +組織は、RBAC(ロールベースアクセス制御)の目的で、子会社、買収した企業、その他の規制対象事業単位へのアクセスを決定するために使用できます。異なるアクセスルールを持つ独自のプロジェクトが多数存在する複雑な事業においては、組織の設計が特に重要になります。 + +最終的に、組織とアセットをどのように使い分けるかは、自社独自の組織構造とセキュリティチームのニーズをどのように反映させたいかによって決まります。 + +以下に、オブジェクトを組織とアセットのどちらに指定するかを判断する際の参考となる、いくつかの構造例を示します。 + +- **組織**: 決済部門 + - アセット: 決済API - 本番環境 + - アセット: 決済API - ステージング環境 + - アセット: 請求ワーカー + +- **組織**: ソフトウェア製品A + - アセット: Webポータル + - アセット: モバイルバックエンド + +さらに、あるものを組織とアセットのどちらで表現するのが適切かを示す参考ガイドは以下の通りです。 + +| Organizations | Assets | +|--------------|--------| +| 事業単位 | 個々のアプリケーション | +| 部門 | デプロイ/環境 | +| セキュリティ所有領域 | インフラストラクチャコンポーネント | +| 製品ファミリー | 特定のマイクロサービス | +| ポートフォリオレベルのレポート | スキャン対象 | +| 顧客 | 特定のソフトウェアバージョン | + +前述の通り、構造は自社独自のセキュリティニーズによって異なる場合があります。 + +## 組織へのアクセス + +組織にはサイドバーからアクセスできます。サブメニューからは、すべての組織へのアクセスに加え、新しい組織を作成するオプションも利用できます。 + +![image](images/org_ss1.png) + +## 組織ビュー + +組織のビューには、そのステータスを一目で把握できるよう、さまざまなテーブルとチャートが含まれています。これには以下が含まれます。 + +- **説明** +- **コマース** + - 組織がCriticalまたはKeyに指定されているかどうか + - CriticalまたはKeyのチェックは、フィルタリング目的でのみ使用されます +- **割り当てられたメンバー** (DefectDojoユーザー) +- **割り当てられたユーザーグループ** + - 権限制御のために組織に割り当てられたユーザーグループ。ユーザーグループの詳細は[こちら](/admin/user_management/create_user_group/)をご覧ください。 +- **組織内のアセットの一覧** + +## 組織の操作 + +### 組織の作成 + +組織を作成する方法は2通りあります。 + +- サイドメニューの**新規組織**オプションから +- すべての組織の一覧の上部にある**新規組織**ボタンから + +### 組織の編集 + +組織は、組織ビューの右上にある歯車メニューから**組織を編集**をクリックすることで編集できます。同じメニューには、すべての組織のビューで組織の左側にある⋮ケバブメニューをクリックすることでもアクセスできます。 + +編集可能なすべての項目は、組織の作成時にも利用できます。 + +### 組織の削除 + +組織の削除は、組織の設定から**組織を削除**を選択することで行えます。 + +組織は階層の最上位に位置するため、組織を削除すると、以下のような下位のセキュリティ履歴、関係性、および子オブジェクトがすべて削除されます。 +- その組織に含まれるすべてのアセット、エンゲージメント、テスト +- 検出事項や統合を含む、関連するすべてのセキュリティ履歴 +- リンクされたすべてのJiraエピック +- その組織内のアセット、エンゲージメント、テストに関連付けられたすべてのメモとファイルアップロード + +組織の削除は元に戻せません。基盤となるデータを削除せずに組織を「廃止」したい場合(例えば、監査目的でレガシーなソフトウェアテストの記録を保持したい場合)は、組織の名前を変更するか、非推奨状態であることを示すタグを追加することができます。 + +## 組織とメタデータ + +組織は、軽量な分類ではなく、構造的な所有権やレポート境界を表すことを意図しています。デプロイステータス、内部ラベル、一時的なワークフロー状態などの属性は、個別の組織としてではなく、タグやメタデータを通じて表現する方が適切な場合があります。 + +## 組織の境界 + +組織は、DefectDojo内でレポートとアクセスの両方の境界を確立します。統合、RBAC権限、所有権、メトリクス、重複排除モデルは組織の構造を継承することが多いため、早い段階で明確な境界を設計しておくことで、後になって階層が肥大化したりレポートが断片化したりすることを避けられます。 + +### 検出事項と自動化 + +統合は通常、アセット、エンゲージメント、検出事項などの下位のオブジェクトで設定されますが、それらの統合が動作する範囲となる所有権、レポート、アクセスの境界を定めるのは、依然として組織です。 + +権限は下位に向かって連鎖するため、組織へのアクセス権を持つと、その組織内のすべてのオブジェクト(アセット、エンゲージメント、テスト、検出事項など)へのアクセス権が自動的に付与されます。 + +DefectDojoのRBACモデルは、人間のユーザーのアクセスを制御するために使用できるだけでなく、APIトークンの特定の組織へのアクセスを制限するためにも使用できます。 + +ユーザーロールの詳細については、[権限タイプの概要](/admin/user_management/set_user_permissions/#introduction-to-permission-types)の記事をご覧ください。 + +### 所有権 + +最上位のオブジェクトとして、組織はその中の子オブジェクトに対する所有権も意味します。組織がその責任者を正確に反映するように設定されていると、SLAの追跡、修復ワークフロー、チケットのルーティング、全般的なガバナンスがよりスムーズに機能します。 + +### メトリクス/レポート + +メトリクスダッシュボード、タイル、ビューは組織ごとにフィルタリングできるため、セキュリティデータがどのように計算、可視化され、最終的にエクスポートされるかを左右する重要な要素となります。 + +レポート作成の観点では、一般的に、単一の組織を複数の文書に分割するよりも、複数の組織を1つの文書にまとめる方が容易です。そのため、チームのレポートにとって意味のある粒度で組織を設定することを推奨します。例えば、主にその事業部門内の個々の部門に対してレポートを作成する予定であれば、大きな事業部門全体を1つの組織として表現する必要はありません。 + +レポートのニーズを反映するように組織を効果的に構造化することは、セキュリティ体制を正確に評価する上で非常に重要です。メトリクスの詳細については、[こちら](/metrics_reports/pro_metrics/pro__overview/)をクリックしてください。 + +### 重複排除 + +DefectDojoにおける重複排除はアセットレベルで行われ、親組織の影響を受けません。 diff --git a/docs/content/asset_modelling/engagements_tests/PRO__tests.de.md b/docs/content/asset_modelling/engagements_tests/PRO__tests.de.md new file mode 100644 index 00000000000..d5985891830 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__tests.de.md @@ -0,0 +1,285 @@ +--- +title: Tests +description: Tests in DefectDojo Pro verstehen +audience: pro +weight: 4 +--- + +Organizations → Assets → Engagements → **TESTS** → Findings + +## Übersicht + +Ein Test ist ein Container für eine oder mehrere Scan-Ausführungen, mit denen Schwachstellen in einem Asset aufgedeckt werden. Tests sind die letzte, granularste Komponente der Objekthierarchie von DefectDojo. Sie dienen als Container für die Befunde, die aus der Ausführung eines Sicherheitstools oder einer manuellen Bewertung resultieren, und liefern zugleich den Kontext, in dem diese Befunde gefunden wurden (z. B. welches Tool sie gemeldet hat, wann dieses Tool zuletzt ausgeführt wurde usw.). + +Beispiele für Tests sind: +- Static Application Security Testing +- Dynamic Application Security Testing +- Software Composition Analysis +- Container-Sicherheitsscans +- Infrastruktur- / Netzwerkscans +- Manuelle Penetrationstests +- CI/CD-Pipeline-Scans + +### Testtypen + +Es gibt mehrere Möglichkeiten, Tests in DefectDojo zu erstellen, darunter **herstellerspezifische Parser** (z. B. Burp, OWASP ZAP, Acunetix, Invicti), **Generic Findings Import**, **Universal Parser** und **Connectors**. + +Je nach Konfiguration und Deduplizierungsstrategie können diese Methoden neue Tests erstellen oder Befunde in bestehende Tests reimportieren. + +Auch wenn sich die Methoden vor allem darin unterscheiden, wie Scan-Daten geparst und aufgenommen werden, führen sie letztlich alle dazu, dass Befunde einem Test zugeordnet werden. + +#### Parser + +**Parser** sind Komponenten, die bestimmte Scan-Ausgabeformate (z. B. XML, JSON, CSV) verarbeiten und in das interne Finding-Modell von DefectDojo überführen. Beim Import von Scan-Ergebnissen verwendet DefectDojo den ausgewählten Parser, um Befunde zu extrahieren und sie einem neu erstellten oder bestehenden Test zuzuordnen. + +#### Generic Findings Import + +Wenn für ein bestimmtes Tool kein nativer Parser existiert, können Sie mit [**Generic Findings Import**](/supported_tools/parsers/generic_findings_import) Findings unabhängig von der ursprünglichen Quelle über ein standardisiertes JSON- oder CSV-Schema importieren. + +DefectDojo parst die bereitgestellten Daten, erstellt einen neuen Test (oder importiert in einen bestehenden) und ordnet die Befunde zu. Basierend auf dem optionalen Feld `type` im Bericht wird außerdem ein entsprechender Test-Typ erstellt: Wird `type` weggelassen (oder entspricht es dem Scan-Typ), lautet der Test-Typ „Generic Findings Import“; wird `type` angegeben, wird daraus „`{type}` Scan (Generic Findings Import)“ (ein `type`, der bereits auf das Suffix „(Generic Findings Import)“ endet, wird unverändert übernommen). + +#### Universal Parser + +Mit [**Universal Parser**](/supported_tools/parsers/universal_parser) können Benutzer festlegen, wie beliebige Eingabedaten auf das Finding-Modell von DefectDojo abgebildet werden. Nach der Konfiguration des Parsers und dem Hochladen der Scan-Daten wendet DefectDojo die Mapping-Regeln an, um Befunde zu extrahieren, erstellt einen Test (oder aktualisiert einen bestehenden) und ordnet diesem Test die Befunde zu. + +#### Connectors + +Mit [**Connectors**](/connectors/upstream/about/) können Schwachstellendaten aus externen Tools automatisch per API-Aufrufe abgerufen und organisiert werden. Nach der Konfiguration ruft ein Connector Scan-Ergebnisse ab, parst die Daten und erstellt je nach Konfiguration neue Tests oder aktualisiert bestehende Tests. Die Befunde werden anschließend dem entsprechenden Test zugeordnet. + +#### Vergleich der Mechanismen zur Testerstellung + +| | **Native Parser** | **Generic Findings Import** | **Universal Parser (Pro)** | **Connectors** | +|----------|---------------|------------------------|------------------------|------------| +| **Primärer Zweck** | Ausgaben unterstützter Tools aufnehmen | Nicht unterstützte/benutzerdefinierte Daten über festes Schema aufnehmen | Beliebige Formate über konfigurierbare Mappings aufnehmen | Externe Systeme kontinuierlich synchronisieren | +| **Eingabeformat** | Tool-spezifisch (z. B. ZAP XML, SARIF) | Striktes JSON/CSV-Schema | Beliebig (JSON, XML usw.) | Externe API-Antworten | +| **Wer übernimmt die Normalisierung** | DefectDojo (integrierter Parser) | Benutzer (muss dem Schema entsprechen) | DefectDojo (über Parser-Konfiguration) | Externes Tool + DefectDojo | +| **Auslöser der Testerstellung** | Manueller Upload oder API-Import | Manueller Upload oder API-Import | Manueller Upload oder API-Import | Automatisierte Synchronisierung (geplant oder ereignisgesteuert) | +| **Test-Typ** | Vordefiniert (z. B. „ZAP Scan“) | Automatisch erstellter Typ „Generic“ | Aus der Parser-Konfiguration abgeleitet | Abhängig vom Connector / zugrunde liegenden Parser | +| **Einrichtungsaufwand** | Gering | Moderat (Datentransformation erforderlich) | Hoch (Parser-Konfiguration) | Moderat–hoch (Integrationseinrichtung) | +| **Flexibilität** | Gering (nur unterstützte Tools) | Mittel | Hoch | Mittel–hoch | +| **Automatisierungsgrad** | Gering–moderat | Gering–moderat | Gering–moderat | Hoch | +| **Typischer Anwendungsfall** | Standard-Scanner (SAST, DAST, SCA) | Eigene Skripte, nicht unterstützte Tools | Komplexe/benutzerdefinierte Formate im großen Maßstab | CI/CD-, SCM- oder Plattformintegrationen | + +Unabhängig von der Ingestion-Methode werden alle Scan-Daten in DefectDojo letztlich als Befunde dargestellt, die einem Test zugeordnet sind, der als Einheit für Ausführung und Lifecycle-Tracking dient. + +### Testdaten + +Tests speichern eine Vielzahl von Metadaten, die dabei helfen, verschiedene Bestandteile jedes Testvorgangs zu dokumentieren, wie zum Beispiel: +- Testtitel / -name +- Testtyp +- Testbeschreibung / Notizen +- Start- und Enddatum +- Die Umgebung, in der der Test ausgeführt wurde (z. B. Development, Staging, Pre-Production, Production usw.) +- Version / Branch / Build-ID / Commit-Hash +- API-Scan-Konfiguration +- Mit dem Test verknüpftes Personal +- Zusätzliche Dateien, die für spätere Audits oder Reimporte verwendet werden können +- Das übergeordnete Engagement, Asset und die Organisation +- Import- und Reimport-Verlauf + +Jeder Test führt einen Importverlauf, in dem alle mit dem Test verknüpften Scan-Importe und -Reimporte erfasst werden. Jeder Verlaufseintrag enthält Metadaten wie Scan-Datum, Version, Branch, Commit-Hash und Build-ID. + +Dieser Verlauf ermöglicht Nachvollziehbarkeit über mehrere Scan-Ausführungen innerhalb desselben Tests hinweg. + +### Berechtigungen + +Mehrere Tests können innerhalb eines einzigen Engagements gespeichert werden, und Engagements werden innerhalb von Assets gespeichert. Der Zugriff auf ein Asset gewährt daher automatisch Zugriff auf alle Tests (und Engagements) innerhalb dieses Assets. Tests verfügen über keine eigenen Zugriffskontrolllisten. + +## Zugriff auf Tests + +Auf Tests kann von verschiedenen Bereichen der DefectDojo-Benutzeroberfläche aus zugegriffen werden. + +- Die Seitenleiste + +![image](images/tests_ss13.png) + +- Innerhalb eines Engagements + +![image](images/tests_ss14.png) + +- Die obere Leiste eines Assets + +![image](images/tests_ss15.png) + +- Die Metadatentabelle in der Ansicht eines Befunds + +![image](images/tests_ss16.png) + +## Arbeiten mit Tests + +### Tests erstellen + +Tests können automatisch erstellt werden, wenn Scan-Daten direkt in ein Engagement importiert werden, wodurch ein neuer Test mit den Scan-Daten entsteht. Tests können auch im Vorgriff auf die Planung zukünftiger Engagements erstellt werden oder für manuell eingegebene Sicherheitsbefunde, die nachverfolgt und behoben werden müssen. + +#### Manuelle Workflows + +Um einen Test zu erstellen, muss zunächst ein Engagement vorhanden sein, das ihn enthält, sowie ein Asset, das dieses Engagement enthält. Danach gibt es mehrere Möglichkeiten, einen Test zu erstellen: + +- In der Seitenleiste, unter Tests im Unterbereich **Manage** + - Beim Ausfüllen des Formulars „New Test“ müssen Sie das bereits vorhandene Engagement auswählen, dem der Test zugeordnet werden soll. + +![image](images/tests_ss1.png) + +- Das Einstellungs-Dropdown oben rechts in einer Asset-Ansicht + - **Import Scan** erstellt automatisch einen Test, sobald dem Formular „Import Scan“ eine Scan-Datei hinzugefügt wurde. Sie haben die Möglichkeit, den Test entweder einem bereits vorhandenen Engagement zuzuordnen oder ein neues Engagement zu erstellen und zu benennen, das den neuen Test enthält. + - Beim Ausfüllen des Formulars „Import Scan“ können Sie Metadaten wie Version, Branch-Tag, Commit-Hash und Build-ID hinzufügen. Diese werden im Abschnitt „Import History“ der Testansicht angezeigt. + +![image](images/tests_ss2.png) + +- Das Einstellungs-Dropdown oben rechts in einer Engagement-Ansicht + - **Import Scan** folgt demselben Workflow wie bei Assets, platziert das Testobjekt jedoch automatisch innerhalb des Engagements, in dem Sie auf Import Scan geklickt haben. + - **Add Test** erstellt ein Testobjekt, erfordert jedoch nicht, dass dem Test selbst ein Scan hochgeladen wird. Das ist nützlich im Vorgriff auf die Planung zukünftiger Tests oder für manuell eingegebene Sicherheitsbefunde, die nachverfolgt und behoben werden müssen. + +![image](images/tests_ss3.png) + +Wenn Sie Add Test auswählen und später die Ergebnisse eines Scans manuell in einen Test importieren möchten, können Sie dies tun, indem Sie den Test öffnen und in dessen Einstellungen auf die Schaltfläche Reimport Findings oder in der Befunde-Tabelle auf die Schaltfläche Reimport Scan klicken. + +![image](images/tests_ss21.png) + +#### Automatisierte Workflows + +In automatisierten Workflows können Tests programmatisch als Teil des Scan-Importprozesses erstellt werden, sodass Pipelines Ergebnisse hochladen können, ohne dass vorab manuell ein Test erstellt werden muss. + +Bei der Verwendung der API oder CLI zum Importieren von Scan-Ergebnissen kann automatisch ein neuer Test erstellt werden, indem ein `engagement` statt eines `test` angegeben wird. + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +Angesichts des Obigen wird ein neuer Test unter dem angegebenen Engagement erstellt, und die Scan-Ergebnisse werden diesem Test zugeordnet. + +Wird stattdessen eine `test`-ID angegeben, werden die Scan-Ergebnisse einem bestehenden Test hinzugefügt, was in Reimport-Workflows üblich ist. + +##### CLI + +Bei Verwendung der DefectDojo-CLI wird dieses Verhalten automatisch anhand der angegebenen Argumente gesteuert. + +defectdojo-cli import \ + --engagement-id 45 \ + --scan-type `"ZAP Scan"` \ +GOog --file report.xml + +Angesichts des Obigen erstellt die Angabe einer `engagement-id` einen neuen Test, während die Angabe einer `test-id` einen bestehenden Test wiederverwendet und Scan-Ergebnisse in diesen Test reimportiert. + +Weitere Details zu den erforderlichen Flags finden Sie unter [DefectDojo-CLI](/import_data/pro/specialized_import/external_tools/#defectdojo-cli). + +### Tests bearbeiten + +Tests können bearbeitet werden, indem Sie im Zahnrad-Menü auf **Edit Test** klicken. Alle daraufhin bearbeitbaren Felder stehen auch bei der Erstellung des Tests zur Verfügung. + +### Tests löschen + +Ein Test kann gelöscht werden, indem Sie in den Einstellungen des Tests **Delete Test** auswählen. Diese Aktion kann nicht rückgängig gemacht werden. + +Beim Löschen eines Tests werden auch alle darin enthaltenen Befunde gelöscht. + +### Scan-Ergebnisse reimportieren (UI) + +Um einem bestehenden Test neue Daten hinzuzufügen, öffnen Sie den betreffenden Test und klicken Sie in dessen Einstellungen auf die Schaltfläche Reimport Findings oder in der Befunde-Tabelle auf die Schaltfläche Reimport Scan. + +![image](images/tests_ss21.png) + +Beim Ausfüllen des Formulars „Reimport Scan“ haben Sie die Möglichkeit, Metadaten für den reimportierten Scan zu aktualisieren, darunter Version, Branch-Tag, Commit-Hash und Build-ID. Diese Änderungen werden im Abschnitt „Import History“ der Testansicht angezeigt, der auch die entsprechenden Metadaten früherer Scan-Importe enthält. + +Im folgenden Screenshot beispielsweise wurden Branch-Tag, Build-ID, Commit-Hash und Version zwischen dem ursprünglichen Import und dem anschließenden Reimport alle manuell aktualisiert. + +![image](images/tests_ss23.png) + +Um die Metadaten des zuletzt reimportierten Scans zu bearbeiten, klicken Sie auf das Zahnrad-Symbol oben rechts in einer Engagement-Ansicht und wählen Sie „Edit Test“. Es können nur die Metadaten des letzten Imports bearbeitet werden. + +### Scan-Ergebnisse reimportieren (API/CLI) + +Wenn Tests über eine CI/CD-Pipeline erstellt oder aktualisiert werden, können Sie Metadaten aus dem Pipeline-Lauf einbeziehen, damit Tests korrekt mit dem gescannten Code verknüpft werden können. Dadurch können Sie: +- Scan-Ergebnisse mit einem bestimmten Commit oder Branch verknüpfen. +- Nachverfolgen, wie sich Befunde im Zuge von Codeänderungen entwickeln. +- Die Deduplizierung verbessern, indem Sie nachvollziehen, wann sich zwei Scans auf dieselbe oder unterschiedliche Codeversionen beziehen. +- Die Auditierbarkeit unterstützen, indem genau gezeigt wird, welcher Code wann gescannt wurde. + +Die CLI und API von DefectDojo akzeptieren diese Werte während des Imports oder Reimports, sodass sie als Teil des Scan-Imports gespeichert und im Importverlauf des Tests angezeigt werden. Diese Metadaten können verwendet werden, um Commit-Hashes oder alles, was mit relevanten Repository-Informationen zu einem CI/CD-Lauf zusammenhängt, zu identifizieren. + +#### Unterstützte Metadatenfelder + +Die API und CLI unterstützen einen definierten Satz von Metadatenfeldern, die beim Reimport angegeben werden können. Dazu gehören: + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- `active / verified`-Flags + +Diese Felder stellen den primären Mechanismus dar, um bei einem Reimport-Vorgang kontextbezogene Metadaten anzuhängen. + +In automatisierten Pipelines gehören zu den am häufigsten angegebenen Metadaten: +- `build_id` (CI-Job-Kennung) +- `commit_hash` (Versionskontroll-Referenz) +- `branch_tag` (Branch- oder Umgebungskontext) +- `tags` (z. B. `nightly`, `staging`, `production`) + +Diese Felder ermöglichen Nachvollziehbarkeit über mehrere Scans hinweg, ohne dass ein manueller Eingriff erforderlich ist. + +Obwohl Metadaten manuell über das Formular „Reimport Scan“ aktualisiert werden können, erledigen die meisten automatisierten Umgebungen dies, indem sie den Endpunkt `/api/v2/reimport-scan/` direkt aufrufen oder die DefectDojo-CLI (`defectdojo-cli reimport`) als Teil des Build-Prozesses verwenden. Dieser Ansatz ermöglicht es der Pipeline, beim Reimport automatisch Metadaten anzuhängen. + +##### API-Reimport mit Metadaten + +curl -X POST `"https:///api/v2/reimport-scan/"` \ + -H `"Authorization: Token "` \ + -F `"test=123"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` \ + -F `"tags=nightly,api-scan"` \ + -F `"version=1.4.2"` \ + -F `"build_id=jenkins-842"` \ + -F `"branch_tag=main"` \ + -F `"commit_hash=a1b2c3d4"` + +##### CLI-Reimport mit Metadaten + +defectdojo-cli import \ + --test-id 123 \ + --scan-type "ZAP Scan" \ + --file report.xml \ + --tag nightly \ + --tag api \ + --build-id jenkins-842 \ + --branch main \ + --commit a1b2c3d4 + +Die CLI wird direkt auf denselben API-Endpunkt abgebildet und unterstützt denselben Satz von Metadatenfeldern. + +Bei der Arbeit mit Metadaten während des Reimports sind einige Einschränkungen zu beachten: +- Die API/CLI unterstützt nur vordefinierte Parameter. Benutzerdefinierte Schlüssel-Wert-Metadaten können beim Reimport nicht hinzugefügt werden +- Zusätzliche Metadaten können je nach Scan-Typ und Parser aus der Scan-Datei selbst extrahiert werden. +- Beim Reimport angegebene Metadaten wirken sich nicht in gleicher Weise als direktes Update auf das Testobjekt aus wie manuelle Änderungen in der UI. + +##### Metadaten, Reimport und geplante Scans + +Scans können auch so geplant werden, dass sie in routinemäßigen Intervallen ausgeführt werden, etwa durch Cron-Jobs ausgelöst. Geplante Scans sind nicht an Repository-Aktivität gebunden, weshalb Metadaten wie Commit-Hashes oder Branch-Namen irrelevant sind, sofern sie nicht explizit vom Skript selbst eingefügt werden. Dennoch kann die Verwendung von Reimport sinnvoll sein, wenn Sie einen fortlaufenden Datensatz Ihrer Sicherheitslage innerhalb eines einzigen Tests führen möchten. + +## Reimport und Deduplizierung + +Das Reimportieren von Scans innerhalb von Tests ist grundlegend für eine effektive Deduplizierung. Wenn Scan-Ergebnisse in denselben Test reimportiert werden: + +- Bestehende Befunde können aktualisiert werden +- Doppelte Befunde können unterdrückt werden +- Neue Befunde können erstellt werden, wenn keine Übereinstimmung gefunden wird + +Dieses Verhalten hängt von den konfigurierten Deduplizierungsregeln und dem Scan-Typ ab. + +Das Erstellen eines neuen Tests anstelle des Reimports in einen bestehenden kann dazu führen, dass doppelte Befunde erstellt statt aktualisiert werden. + +### Reimport vs. Import + +Reimport wird typischerweise verwendet, wenn: + +- Wiederkehrende Scans gegen dasselbe Ziel ausgeführt werden +- Nachverfolgt wird, wie sich Befunde im Zeitverlauf entwickeln +- Eine kontinuierliche Sicht auf die Sicherheitslage der Anwendung aufrechterhalten wird + +Im Gegensatz dazu eignet sich Import (das Erstellen eines neuen Tests) besser für einmalige oder unabhängige Scan-Ausführungen. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__tests.es.md b/docs/content/asset_modelling/engagements_tests/PRO__tests.es.md new file mode 100644 index 00000000000..eed8c77fd5b --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__tests.es.md @@ -0,0 +1,285 @@ +--- +title: Tests +description: Cómo funcionan los Tests en DefectDojo Pro +audience: pro +weight: 4 +--- + +Organizaciones → Activos → Compromisos → **TESTS** → Hallazgos + +## Resumen + +Un Test es un contenedor para una o más ejecuciones de escaneo, que se utilizan para descubrir fallos en un Activo. Los Tests son el componente final y más granular de la jerarquía de objetos de DefectDojo, y sirven como contenedor de los Hallazgos que resultan de la ejecución de una herramienta de seguridad o de una evaluación manual, añadiendo además el contexto en el que se encontraron dichos Hallazgos (es decir, qué herramienta los reportó, cuándo se ejecutó esa herramienta por última vez, etc.). + +Ejemplos de Tests incluyen: +- Pruebas Estáticas de Seguridad de Aplicaciones +- Pruebas Dinámicas de Seguridad de Aplicaciones +- Análisis de Composición de Software +- Escaneos de Seguridad de Contenedores +- Escaneos de Infraestructura / Red +- Pruebas de Penetración Manuales +- Escaneos de Pipeline de CI/CD + +### Tipos de Test + +Existen varias formas de crear Tests en DefectDojo, incluidos los **parsers específicos de proveedor** (por ejemplo, Burp, OWASP ZAP, Acunetix, Invicti), **Generic Findings Import**, **Universal Parser** y **Connectors**. + +Estos métodos pueden crear nuevos Tests o reimportar Hallazgos en Tests existentes, según la configuración y la estrategia de deduplicación. + +Aunque cada método difiere principalmente en la forma en que se analizan e ingieren los datos de escaneo, todos terminan asociando Hallazgos a un Test. + +#### Parsers + +**Parsers** son componentes que procesan formatos específicos de salida de escaneo (por ejemplo, XML, JSON, CSV) y los asignan al modelo interno de Hallazgos de DefectDojo. Cuando se importan resultados de escaneo, DefectDojo utiliza el parser seleccionado para extraer los Hallazgos y adjuntarlos a un Test nuevo o existente. + +#### Generic Findings Import + +Cuando no existe un parser nativo para una herramienta determinada, [**Generic Findings Import**](/supported_tools/parsers/generic_findings_import) le permite importar hallazgos utilizando un esquema JSON o CSV estandarizado, sin importar el origen. + +DefectDojo analiza los datos proporcionados, crea un nuevo Test (o los importa en uno existente) y adjunta los Hallazgos. También se crea un Test Type correspondiente según el campo opcional `type` del informe: cuando se omite `type` (o es igual al tipo de escaneo) el Test Type es “Generic Findings Import”; cuando se proporciona `type`, se convierte en “`{type}` Scan (Generic Findings Import)” (un `type` que ya termina con el sufijo “(Generic Findings Import)” se utiliza tal cual). + +#### Universal Parser + +[**Universal Parser**](/supported_tools/parsers/universal_parser) permite a los usuarios definir cómo se asignan los datos de entrada arbitrarios al modelo de Hallazgos de DefectDojo. Después de configurar el parser y cargar los datos de escaneo, DefectDojo aplica las reglas de asignación para extraer los Hallazgos, crea un Test (o actualiza uno existente) y asocia los Hallazgos con ese Test. + +#### Connectors + +Los [**Connectors**](/connectors/upstream/about/) pueden utilizarse para ingerir y organizar automáticamente datos de vulnerabilidades de herramientas externas mediante llamadas a la API. Una vez configurado, un Connector obtiene los resultados del escaneo, analiza los datos y crea nuevos Tests o actualiza los existentes según su configuración. Los Hallazgos se adjuntan luego al Test correspondiente. + +#### Comparación de mecanismos de creación de Test + +| | **Parsers nativos** | **Generic Findings Import** | **Universal Parser (Pro)** | **Connectors** | +|----------|---------------|------------------------|------------------------|------------| +| **Propósito principal** | Ingerir salidas de herramientas compatibles | Ingerir datos no compatibles/personalizados mediante un esquema fijo | Ingerir formatos arbitrarios mediante asignaciones configurables | Sincronizar continuamente sistemas externos | +| **Formato de entrada** | Específico de la herramienta (por ejemplo, ZAP XML, SARIF) | Esquema JSON/CSV estricto | Arbitrario (JSON, XML, etc.) | Respuestas de API externas | +| **Quién gestiona la normalización** | DefectDojo (parser integrado) | Usuario (debe ajustarse al esquema) | DefectDojo (mediante configuración del parser) | Herramienta externa + DefectDojo | +| **Disparador de creación del Test** | Carga manual o importación por API | Carga manual o importación por API | Carga manual o importación por API | Sincronización automatizada (programada o basada en eventos) | +| **Test Type** | Predefinido (por ejemplo, “ZAP Scan”) | Tipo “Generic” creado automáticamente | Derivado de la configuración del parser | Depende del connector / parser subyacente | +| **Esfuerzo de configuración** | Bajo | Moderado (requiere transformación de datos) | Alto (configuración del parser) | Moderado–Alto (configuración de la integración) | +| **Flexibilidad** | Baja (solo herramientas compatibles) | Media | Alta | Media–Alta | +| **Nivel de automatización** | Bajo–Moderado | Bajo–Moderado | Bajo–Moderado | Alto | +| **Caso de uso típico** | Escáneres estándar (SAST, DAST, SCA) | Scripts personalizados, herramientas no compatibles | Formatos complejos/personalizados a gran escala | Integraciones de CI/CD, SCM o de plataforma | + +Independientemente del método de ingesta, todos los datos de escaneo en DefectDojo terminan representándose como Hallazgos adjuntos a un Test, que sirve como unidad de ejecución y seguimiento del ciclo de vida. + +### Datos del Test + +Los Tests almacenan una variedad de metadatos que ayudan a documentar distintos componentes de cada esfuerzo de testing, tales como: +- Título / nombre del Test +- Tipo de Test +- Descripción / notas del Test +- Fecha de inicio y fin +- El Entorno en el que se ejecutó el Test (por ejemplo, Development, Staging, Pre-Production, Production, etc.) +- Versión / Branch / Build ID / Commit Hash +- Configuración de escaneo por API +- Personal asociado al Test +- Archivos adicionales que se pueden utilizar para auditorías o reimportaciones posteriores +- El Compromiso, Activo y Organización superiores +- Historial de importación y reimportación + +Cada Test mantiene un historial de importación, que registra todas las importaciones y reimportaciones de escaneo asociadas con el Test. Cada elemento del historial incluye metadatos como la fecha de escaneo, la versión, el branch, el commit hash y el build ID. + +Este historial proporciona trazabilidad a través de múltiples ejecuciones de escaneo dentro del mismo Test. + +### Permisos + +Varios Tests pueden almacenarse dentro de un mismo Compromiso, y los Compromisos se almacenan dentro de los Activos. Por lo tanto, el acceso a un Activo otorga automáticamente acceso a todos los Tests (y Compromisos) dentro de ese Activo. Los Tests no tienen listas de control de acceso independientes. + +## Acceso a los Tests + +Se puede acceder a los Tests desde varias secciones de la interfaz de DefectDojo. + +- La barra lateral + +![image](images/tests_ss13.png) + +- Dentro de un Compromiso + +![image](images/tests_ss14.png) + +- La barra superior de un Activo + +![image](images/tests_ss15.png) + +- La tabla de metadatos dentro de la vista de un Hallazgo + +![image](images/tests_ss16.png) + +## Trabajar con Tests + +### Crear Tests + +Los Tests pueden crearse automáticamente cuando los datos de escaneo se importan directamente en un Compromiso, lo que da como resultado un nuevo Test que contiene los datos del escaneo. Los Tests también pueden crearse anticipándose a la planificación de futuros Compromisos, o para hallazgos de seguridad ingresados manualmente que requieran seguimiento y remediación. + +#### Flujos de trabajo manuales + +Para crear un Test, primero debe crearse un Compromiso que lo contenga, así como un Activo que contenga a ese Compromiso. Después, existen varias formas de crear un Test: + +- En la barra lateral, en Tests dentro de la subsección **Manage** + - Deberá seleccionar el Compromiso preexistente al que se atribuirá el Test al completar el formulario New Test. + +![image](images/tests_ss1.png) + +- El menú desplegable de configuración en la esquina superior derecha de la vista de un Activo + - **Import Scan** creará automáticamente un Test una vez que se haya añadido un archivo de escaneo al formulario Import Scan. Tendrá la opción de atribuir el Test a un Compromiso preexistente o de crear y nombrar un nuevo Compromiso que contenga el nuevo Test. + - Al completar el formulario Import Scan, puede agregar metadatos como la versión, el branch tag, el commit hash y el build ID. Esto se reflejará en la sección Import History de la vista del Test. + +![image](images/tests_ss2.png) + +- El menú desplegable de configuración en la parte superior derecha de la vista de un Compromiso + - **Import Scan** seguirá el mismo flujo de trabajo que en los Activos, pero colocará automáticamente el objeto Test dentro del Compromiso en el que hizo clic en Import Scan. + - **Add Test** creará un objeto Test, pero no requiere que se cargue un escaneo en el propio Test, lo cual es útil para anticiparse a la planificación de futuros Tests o para hallazgos de seguridad ingresados manualmente que requieran seguimiento y remediación. + +![image](images/tests_ss3.png) + +Si selecciona Add Test y más adelante desea importar manualmente los resultados de un escaneo a un Test, puede hacerlo abriendo el Test y haciendo clic en el botón Reimport Findings en la configuración del Test, o en el botón Reimport Scan de la tabla de Hallazgos. + +![image](images/tests_ss21.png) + +#### Flujos de trabajo automatizados + +En los flujos de trabajo automatizados, los Tests pueden crearse mediante programación como parte del proceso de importación de escaneo, lo que permite que los pipelines carguen resultados sin necesidad de crear un Test manualmente de antemano. + +Al usar la API o la CLI para importar resultados de escaneo, se puede crear un nuevo Test automáticamente proporcionando un `engagement` en lugar de un `test`. + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +Dado lo anterior, se crea un nuevo Test bajo el Compromiso especificado, y los resultados del escaneo se adjuntan a ese Test. + +Si en su lugar se proporciona un ID de `test`, los resultados del escaneo se agregarán a un Test existente, lo cual es común en los flujos de trabajo de reimportación. + +##### CLI + +Con la CLI de DefectDojo, este comportamiento se gestiona automáticamente según los argumentos proporcionados. + +defectdojo-cli import \ + --engagement-id 45 \ + --scan-type `"ZAP Scan"` \ +GOog --file report.xml + +Dado lo anterior, proporcionar un `engagement-id` crea un nuevo Test, y proporcionar un `test-id` reutiliza un Test existente y reimporta los resultados del escaneo en ese Test. + +Consulte [DefectDojo-CLI](/import_data/pro/specialized_import/external_tools/#defectdojo-cli) para obtener más detalles sobre los flags requeridos. + +### Editar Tests + +Los Tests se pueden editar haciendo clic en **Edit Test** dentro del menú de engranaje. Todos los campos que se pueden editar a continuación también están disponibles al crear el Test. + +### Eliminar Tests + +Para eliminar un Test, seleccione **Delete Test** en la configuración del Test. Esta acción no se puede deshacer. + +Eliminar un Test también eliminará todos los Hallazgos contenidos en ese Test. + +### Reimportar resultados de escaneo (UI) + +Para agregar nuevos datos a un Test existente, abra el Test al que desea agregar los nuevos datos y haga clic en el botón Reimport Findings en la configuración del Test, o en el botón Reimport Scan en la tabla de Hallazgos. + +![image](images/tests_ss21.png) + +Al completar el formulario Reimport Scan, tendrá la opción de actualizar los metadatos del escaneo que se está reimportando, incluidos la versión, el branch tag, el commit hash y el build ID. Estos cambios se reflejan en la sección Import History de la vista del Test, que también incluirá los mismos metadatos de importaciones de escaneo anteriores. + +Por ejemplo, en la captura de pantalla a continuación, el branch tag, el build ID, el commit hash y la versión se actualizaron manualmente entre la importación inicial y la reimportación posterior. + +![image](images/tests_ss23.png) + +Para editar los metadatos del escaneo reimportado más recientemente, haga clic en el ícono de engranaje ubicado en la esquina superior derecha de la vista del Compromiso y seleccione “Edit Test”. Solo se pueden editar los metadatos de la importación más reciente. + +### Reimportar resultados de escaneo (API/CLI) + +Cuando los Tests se crean o actualizan a través de un pipeline de CI/CD, puede incluir metadatos de la ejecución del pipeline para que los Tests queden correctamente vinculados al código que escanearon. Esto le permite: +- Asociar los resultados del escaneo con un commit o branch específico. +- Realizar seguimiento de cómo evolucionan los Hallazgos a través de los cambios de código. +- Mejorar la Deduplicación al comprender cuándo dos escaneos corresponden a la misma versión del código o a versiones diferentes. +- Facilitar la auditabilidad mostrando exactamente qué código se escaneó y cuándo. + +La CLI y la API de DefectDojo aceptan estos valores durante la importación o reimportación para que puedan almacenarse como parte de la importación del escaneo y reflejarse en el historial de importación del Test. Estos metadatos se pueden usar para identificar commit hashes o cualquier información relevante del repositorio asociada con una ejecución de CI/CD. + +#### Campos de metadatos admitidos + +La API y la CLI admiten un conjunto definido de campos de metadatos que se pueden incluir durante la reimportación. Estos incluyen: + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- Indicadores `active / verified` + +Estos campos representan el mecanismo principal para adjuntar metadatos contextuales durante una operación de reimportación. + +En los pipelines automatizados, los metadatos suministrados con mayor frecuencia incluyen: +- `build_id` (identificador del job de CI) +- `commit_hash` (referencia de control de versiones) +- `branch_tag` (contexto de branch o entorno) +- `tags` (por ejemplo, `nightly`, `staging`, `production`) + +Estos campos proporcionan trazabilidad entre escaneos sin requerir intervención manual. + +Aunque los metadatos se pueden actualizar manualmente a través del formulario Reimport Scan, la mayoría de los entornos automatizados gestionan esto llamando directamente al endpoint `/api/v2/reimport-scan/` o usando la CLI de DefectDojo (`defectdojo-cli reimport`) como parte del proceso de build. Este enfoque permite que el pipeline adjunte automáticamente los metadatos al reimportar. + +##### Reimportación por API con metadatos + +curl -X POST `"https:///api/v2/reimport-scan/"` \ + -H `"Authorization: Token "` \ + -F `"test=123"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` \ + -F `"tags=nightly,api-scan"` \ + -F `"version=1.4.2"` \ + -F `"build_id=jenkins-842"` \ + -F `"branch_tag=main"` \ + -F `"commit_hash=a1b2c3d4"` + +##### Reimportación por CLI con metadatos + +defectdojo-cli import \ + --test-id 123 \ + --scan-type "ZAP Scan" \ + --file report.xml \ + --tag nightly \ + --tag api \ + --build-id jenkins-842 \ + --branch main \ + --commit a1b2c3d4 + +La CLI se mapea directamente al mismo endpoint de la API y admite el mismo conjunto de campos de metadatos. + +Existen algunas limitaciones a tener en cuenta al trabajar con metadatos durante la reimportación: +- La API/CLI solo admite parámetros predefinidos. No se pueden agregar metadatos personalizados de clave-valor durante la reimportación +- Es posible que se extraigan metadatos adicionales del propio archivo de escaneo, según el tipo de escaneo y el parser. +- Los metadatos proporcionados durante la reimportación no se comportan como una actualización directa del objeto Test, a diferencia de las ediciones manuales en la interfaz. + +##### Metadatos, reimportación y escaneos programados + +Los escaneos también pueden programarse para ejecutarse a intervalos rutinarios, como los activados por cron jobs. Los escaneos programados no están vinculados a la actividad del repositorio, lo que hace que metadatos como los commit hashes o los nombres de branch sean irrelevantes a menos que el propio script los inyecte explícitamente. Aun así, usar la reimportación puede seguir siendo útil si prefiere mantener un registro continuo de su postura de seguridad dentro de un mismo Test. + +## Reimportación y Deduplicación + +Reimportar escaneos dentro de los Tests es fundamental para una deduplicación efectiva. Cuando los resultados de escaneo se reimportan en el mismo Test: + +- Los Hallazgos existentes pueden actualizarse +- Los Hallazgos duplicados pueden suprimirse +- Se pueden crear nuevos Hallazgos si no se encuentra ninguna coincidencia + +Este comportamiento depende de las reglas de deduplicación configuradas y del tipo de escaneo. + +Crear un nuevo Test en lugar de reimportar en uno existente puede provocar que se creen Hallazgos duplicados en vez de actualizarse. + +### Reimportación vs. Importación + +La reimportación se utiliza normalmente cuando: + +- Se ejecutan escaneos recurrentes contra el mismo objetivo +- Se realiza seguimiento de cómo evolucionan los Hallazgos con el tiempo +- Se mantiene una vista continua de la postura de seguridad de la aplicación + +Por el contrario, importar (crear un nuevo Test) es más apropiado para ejecuciones de escaneo únicas o independientes. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__tests.fr.md b/docs/content/asset_modelling/engagements_tests/PRO__tests.fr.md new file mode 100644 index 00000000000..3b00bf0ea0c --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__tests.fr.md @@ -0,0 +1,285 @@ +--- +title: Tests +description: Comprendre les Tests dans DefectDojo Pro +audience: pro +weight: 4 +--- + +Organisations → Actifs → Engagements → **TESTS** → Constatations + +## Aperçu + +Un Test est un conteneur pour une ou plusieurs exécutions de scan, utilisées pour découvrir des failles dans un Actif. Les Tests constituent le composant final et le plus granulaire de la hiérarchie d'objets de DefectDojo : ils servent de conteneur pour les Constatations résultant de l'exécution d'un outil de sécurité ou d'une évaluation manuelle, tout en ajoutant le contexte dans lequel ces Constatations ont été trouvées (c'est-à-dire quel outil les a signalées, quand cet outil a été exécuté pour la dernière fois, etc.). + +Exemples de Tests : +- Tests statiques de sécurité des applications +- Tests dynamiques de sécurité des applications +- Analyse de composition logicielle +- Analyses de sécurité des conteneurs +- Analyses d'infrastructure / réseau +- Tests d'intrusion manuels +- Analyses de pipeline CI/CD + +### Types de Test + +Il existe plusieurs façons de créer des Tests dans DefectDojo, notamment les **analyseurs spécifiques à un éditeur** (par ex. Burp, OWASP ZAP, Acunetix, Invicti), **Generic Findings Import**, **Universal Parser**, et **Connectors**. + +Ces méthodes peuvent créer de nouveaux Tests ou réimporter des Constatations dans des Tests existants, selon la configuration et la stratégie de déduplication. + +Bien que chaque méthode diffère principalement par la façon dont les données de scan sont analysées et ingérées, elles aboutissent toutes à l'association de Constatations à un Test. + +#### Analyseurs + +Les **analyseurs** sont des composants qui traitent des formats de sortie de scan spécifiques (par ex. XML, JSON, CSV) et les font correspondre au modèle interne de Constatation de DefectDojo. Lorsque des résultats de scan sont importés, DefectDojo utilise l'analyseur sélectionné pour extraire les Constatations et les rattacher à un Test nouvellement créé ou existant. + +#### Generic Findings Import + +Lorsqu'aucun analyseur natif n'existe pour un outil donné, [**Generic Findings Import**](/supported_tools/parsers/generic_findings_import) permet d'importer des constatations à l'aide d'un schéma JSON ou CSV standardisé, quelle que soit la source d'origine. + +DefectDojo analyse les données fournies, crée un nouveau Test (ou importe dans un Test existant) et y rattache les Constatations. Un Type de Test correspondant est également créé en fonction du champ optionnel `type` du rapport : lorsque `type` est omis (ou égal au type de scan), le Type de Test est « Generic Findings Import » ; lorsque `type` est fourni, il devient « `{type}` Scan (Generic Findings Import) » (un `type` se terminant déjà par le suffixe « (Generic Findings Import) » est utilisé tel quel). + +#### Universal Parser + +[**Universal Parser**](/supported_tools/parsers/universal_parser) permet aux utilisateurs de définir comment des données d'entrée arbitraires sont associées au modèle de Constatation de DefectDojo. Après avoir configuré l'analyseur et importé les données de scan, DefectDojo applique les règles de correspondance pour extraire les Constatations, crée un Test (ou en met à jour un existant), et associe les Constatations à ce Test. + +#### Connectors + +Les [**Connectors**](/connectors/upstream/about/) peuvent être utilisés pour ingérer et organiser automatiquement les données de vulnérabilité provenant d'outils externes via des appels API. Une fois configuré, un Connector récupère les résultats de scan, analyse les données, et crée de nouveaux Tests ou met à jour des Tests existants selon sa configuration. Les Constatations sont ensuite rattachées au Test correspondant. + +#### Comparaison des mécanismes de création de Test + +| | **Analyseurs natifs** | **Generic Findings Import** | **Universal Parser (Pro)** | **Connectors** | +|----------|---------------|------------------------|------------------------|------------| +| **Objectif principal** | Ingérer les sorties d'outils pris en charge | Ingérer des données non prises en charge/personnalisées via un schéma fixe | Ingérer des formats arbitraires via des correspondances configurables | Synchroniser en continu des systèmes externes | +| **Format d'entrée** | Spécifique à l'outil (par ex. ZAP XML, SARIF) | Schéma JSON/CSV strict | Arbitraire (JSON, XML, etc.) | Réponses d'API externes | +| **Qui gère la normalisation** | DefectDojo (analyseur intégré) | Utilisateur (doit se conformer au schéma) | DefectDojo (via la configuration de l'analyseur) | Outil externe + DefectDojo | +| **Déclencheur de création de Test** | Import manuel ou via l'API | Import manuel ou via l'API | Import manuel ou via l'API | Synchronisation automatisée (planifiée ou événementielle) | +| **Type de Test** | Prédéfini (par ex. « ZAP Scan ») | Type « Generic » créé automatiquement | Dérivé de la configuration de l'analyseur | Dépend du connecteur / de l'analyseur sous-jacent | +| **Effort de configuration** | Faible | Modéré (transformation des données requise) | Élevé (configuration de l'analyseur) | Modéré à élevé (configuration de l'intégration) | +| **Flexibilité** | Faible (outils pris en charge uniquement) | Moyenne | Élevée | Moyenne à élevée | +| **Niveau d'automatisation** | Faible à modéré | Faible à modéré | Faible à modéré | Élevé | +| **Cas d'usage typique** | Scanners standards (SAST, DAST, SCA) | Scripts personnalisés, outils non pris en charge | Formats complexes/personnalisés à grande échelle | Intégrations CI/CD, SCM ou plateforme | + +Quelle que soit la méthode d'ingestion, toutes les données de scan dans DefectDojo sont finalement représentées sous forme de Constatations rattachées à un Test, qui sert d'unité d'exécution et de suivi du cycle de vie. + +### Données de Test + +Les Tests stockent diverses métadonnées qui aident à documenter les différents composants de chaque effort de test, telles que : +- Titre / nom du Test +- Type de Test +- Description / notes du Test +- Dates de début et de fin +- L'Environnement dans lequel le Test a été exécuté (par ex. Développement, Pré-production, Production, etc.) +- Version / Branche / ID de build / Hash de commit +- Configuration de scan API +- Personnel associé au Test +- Fichiers supplémentaires pouvant être utilisés pour des audits ultérieurs ou des réimports +- L'Engagement, l'Actif et l'Organisation parents +- Historique d'import et de réimport + +Chaque Test conserve un historique d'import, qui enregistre tous les imports et réimports de scan associés au Test. Chaque élément de l'historique inclut des métadonnées telles que la date du scan, la version, la branche, le hash de commit et l'ID de build. + +Cet historique assure la traçabilité entre plusieurs exécutions de scan au sein d'un même Test. + +### Permissions + +Plusieurs Tests peuvent être stockés au sein d'un même Engagement, et les Engagements sont stockés au sein des Actifs. Ainsi, l'accès à un Actif accorde automatiquement l'accès à tous les Tests (et Engagements) de cet Actif. Les Tests n'ont pas de listes de contrôle d'accès indépendantes. + +## Accéder aux Tests + +Les Tests sont accessibles depuis différentes sections de l'interface DefectDojo. + +- La barre latérale + +![image](images/tests_ss13.png) + +- Au sein d'un Engagement + +![image](images/tests_ss14.png) + +- La barre supérieure d'un Actif + +![image](images/tests_ss15.png) + +- Le tableau des métadonnées dans la vue d'une Constatation + +![image](images/tests_ss16.png) + +## Utilisation des Tests + +### Créer des Tests + +Les Tests peuvent être créés automatiquement lorsque des données de scan sont importées directement dans un Engagement, ce qui donne lieu à un nouveau Test contenant les données de scan. Les Tests peuvent également être créés en prévision d'Engagements futurs, ou pour des constatations de sécurité saisies manuellement nécessitant un suivi et une remédiation. + +#### Flux de travail manuels + +Pour créer un Test, un Engagement doit être créé pour le contenir, ainsi qu'un Actif pour contenir cet Engagement. Ensuite, il existe plusieurs façons de créer un Test : + +- Dans la barre latérale, sous Tests dans la sous-section **Manage** + - Vous devrez sélectionner l'Engagement préexistant auquel attribuer le Test lors de la saisie du formulaire de nouveau Test. + +![image](images/tests_ss1.png) + +- Le menu déroulant des paramètres en haut à droite d'une vue d'Actif + - **Import Scan** créera automatiquement un Test une fois qu'un fichier de scan aura été ajouté au formulaire Import Scan. Vous aurez la possibilité d'attribuer le Test à un Engagement préexistant ou de créer et nommer un nouvel Engagement pour contenir le nouveau Test. + - En remplissant le formulaire Import Scan, vous pouvez ajouter des métadonnées telles que la version, l'étiquette de branche, le hash de commit et l'ID de build. Cela se reflétera dans la section Historique d'import de la vue du Test. + +![image](images/tests_ss2.png) + +- Le menu déroulant des paramètres en haut à droite d'une vue d'Engagement + - **Import Scan** suit le même flux de travail que pour les Actifs, mais placera automatiquement l'objet Test dans l'Engagement depuis lequel vous avez cliqué sur Import Scan. + - **Add Test** crée un objet Test sans exiger qu'un scan soit importé dans le Test lui-même, ce qui est utile en prévision de Tests futurs ou pour des constatations de sécurité saisies manuellement nécessitant un suivi et une remédiation. + +![image](images/tests_ss3.png) + +Si vous sélectionnez Add Test et que vous souhaitez ultérieurement importer manuellement les résultats d'un scan dans un Test, vous pouvez le faire en ouvrant le Test et en cliquant sur le bouton Reimport Findings dans les paramètres du Test, ou sur le bouton Reimport Scan dans le tableau des Constatations. + +![image](images/tests_ss21.png) + +#### Flux de travail automatisés + +Dans les flux de travail automatisés, les Tests peuvent être créés de manière programmatique dans le cadre du processus d'import de scan, ce qui permet aux pipelines de téléverser des résultats sans qu'un Test doive être créé manuellement au préalable. + +Lors de l'utilisation de l'API ou de la CLI pour importer des résultats de scan, un nouveau Test peut être créé automatiquement en fournissant un `engagement` plutôt qu'un `test`. + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +Dans l'exemple ci-dessus, un nouveau Test est créé sous l'Engagement spécifié, et les résultats de scan y sont rattachés. + +Si un ID de `test` est fourni à la place, les résultats de scan seront ajoutés à un Test existant, ce qui est courant dans les flux de réimport. + +##### CLI + +En utilisant la CLI DefectDojo, ce comportement est géré automatiquement en fonction des arguments fournis. + +defectdojo-cli import \ + --engagement-id 45 \ + --scan-type `"ZAP Scan"` \ +GOog --file report.xml + +Dans l'exemple ci-dessus, fournir un `engagement-id` crée un nouveau Test, et fournir un `test-id` réutilise un Test existant et y réimporte les résultats de scan. + +Voir [DefectDojo-CLI](/import_data/pro/specialized_import/external_tools/#defectdojo-cli) pour plus de détails sur les indicateurs requis. + +### Modifier des Tests + +Les Tests peuvent être modifiés en cliquant sur **Edit Test** dans le menu à engrenage. Tous les champs modifiables qui en découlent sont également disponibles lors de la création du Test. + +### Supprimer des Tests + +La suppression d'un Test s'effectue en sélectionnant **Delete Test** dans les paramètres du Test. Cette action est irréversible. + +La suppression d'un Test supprimera également toutes les Constatations qu'il contient. + +### Réimporter les résultats de scan (UI) + +Pour ajouter de nouvelles données à un Test existant, ouvrez le Test auquel vous ajoutez de nouvelles données et cliquez sur le bouton Reimport Findings dans les paramètres du Test, ou sur le bouton Reimport Scan dans le tableau des Constatations. + +![image](images/tests_ss21.png) + +En remplissant le formulaire Reimport Scan, vous pourrez mettre à jour les métadonnées du scan réimporté, notamment la version, l'étiquette de branche, le hash de commit et l'ID de build. Ces modifications se reflètent dans la section Historique d'import de la vue du Test, qui inclura également les mêmes métadonnées des imports précédents. + +Par exemple, dans la capture d'écran ci-dessous, l'étiquette de branche, l'ID de build, le hash de commit et la version ont tous été mis à jour manuellement entre l'import initial et le réimport suivant. + +![image](images/tests_ss23.png) + +Pour modifier les métadonnées du scan réimporté le plus récemment, cliquez sur l'icône en forme d'engrenage située en haut à droite d'une vue d'Engagement et sélectionnez « Edit Test ». Seules les métadonnées de l'import le plus récent peuvent être modifiées. + +### Réimporter les résultats de scan (API/CLI) + +Lorsque des Tests sont créés ou mis à jour via un pipeline CI/CD, vous pouvez inclure des métadonnées provenant de l'exécution du pipeline afin que les Tests puissent être correctement liés au code analysé. Cela vous permet de : +- Associer les résultats de scan à un commit ou une branche spécifique. +- Suivre l'évolution des Constatations au fil des modifications du code. +- Améliorer la Déduplication en comprenant quand deux scans s'appliquent à la même version du code, ou à des versions différentes. +- Faciliter l'auditabilité en montrant précisément quel code a été analysé, et quand. + +La CLI et l'API de DefectDojo acceptent ces valeurs lors de l'import ou du réimport afin qu'elles puissent être stockées dans le cadre de l'import du scan et reflétées dans l'historique d'import du Test. Ces métadonnées peuvent être utilisées pour identifier des hashs de commit ou toute information de dépôt associée à une exécution CI/CD. + +#### Champs de métadonnées pris en charge + +L'API et la CLI prennent en charge un ensemble défini de champs de métadonnées pouvant être inclus lors du réimport. Ceux-ci comprennent : + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- les indicateurs `active / verified` + +Ces champs représentent le mécanisme principal pour rattacher des métadonnées contextuelles lors d'une opération de réimport. + +Dans les pipelines automatisés, les métadonnées les plus couramment fournies sont : +- `build_id` (identifiant du job CI) +- `commit_hash` (référence de contrôle de source) +- `branch_tag` (contexte de branche ou d'environnement) +- `tags` (par ex. `nightly`, `staging`, `production`) + +Ces champs assurent la traçabilité entre les scans sans nécessiter d'intervention manuelle. + +Bien que les métadonnées puissent être mises à jour manuellement via le formulaire Reimport Scan, la plupart des environnements automatisés géreront cela en appelant directement le point de terminaison `/api/v2/reimport-scan/` ou en utilisant la CLI DefectDojo (`defectdojo-cli reimport`) dans le cadre du processus de build. Cette approche permet au pipeline de rattacher automatiquement les métadonnées lors du réimport. + +##### Réimport via l'API avec métadonnées + +curl -X POST `"https:///api/v2/reimport-scan/"` \ + -H `"Authorization: Token "` \ + -F `"test=123"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` \ + -F `"tags=nightly,api-scan"` \ + -F `"version=1.4.2"` \ + -F `"build_id=jenkins-842"` \ + -F `"branch_tag=main"` \ + -F `"commit_hash=a1b2c3d4"` + +##### Réimport via la CLI avec métadonnées + +defectdojo-cli import \ + --test-id 123 \ + --scan-type "ZAP Scan" \ + --file report.xml \ + --tag nightly \ + --tag api \ + --build-id jenkins-842 \ + --branch main \ + --commit a1b2c3d4 + +La CLI correspond directement au même point de terminaison de l'API et prend en charge le même ensemble de champs de métadonnées. + +Il existe quelques limitations à connaître lors de l'utilisation des métadonnées pendant le réimport : +- L'API/CLI ne prend en charge que des paramètres prédéfinis. Des métadonnées personnalisées sous forme de clé-valeur ne peuvent pas être ajoutées lors du réimport +- Des métadonnées supplémentaires peuvent être extraites du fichier de scan lui-même, selon le type de scan et l'analyseur. +- Les métadonnées fournies lors du réimport ne se comportent pas comme une mise à jour directe de l'objet Test, contrairement aux modifications manuelles effectuées dans l'interface. + +##### Métadonnées, réimport et scans planifiés + +Les scans peuvent également être planifiés pour s'exécuter à intervalles réguliers, par exemple déclenchés par des tâches cron. Les scans planifiés ne sont pas liés à l'activité du dépôt, ce qui rend des métadonnées comme les hashs de commit ou les noms de branche non pertinentes, sauf si elles sont explicitement injectées par le script lui-même. Néanmoins, l'utilisation du réimport peut rester utile si vous préférez conserver un historique glissant de votre posture de sécurité au sein d'un même Test. + +## Réimport et déduplication + +Le réimport des scans au sein des Tests est fondamental pour une déduplication efficace. Lorsque des résultats de scan sont réimportés dans le même Test : + +- Des Constatations existantes peuvent être mises à jour +- Des Constatations en double peuvent être supprimées +- De nouvelles Constatations peuvent être créées si aucune correspondance n'est trouvée + +Ce comportement dépend des règles de déduplication configurées et du type de scan. + +Créer un nouveau Test au lieu de réimporter dans un Test existant peut entraîner la création de Constatations en double plutôt que leur mise à jour. + +### Réimport vs. Import + +Le réimport est généralement utilisé lorsque : + +- Des scans récurrents sont exécutés contre la même cible +- Vous suivez l'évolution des Constatations dans le temps +- Vous maintenez une vue continue de la posture de sécurité de l'application + +En revanche, l'import (création d'un nouveau Test) est plus approprié pour des exécutions de scan ponctuelles ou indépendantes. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__tests.ja.md b/docs/content/asset_modelling/engagements_tests/PRO__tests.ja.md new file mode 100644 index 00000000000..32f6109e14a --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__tests.ja.md @@ -0,0 +1,285 @@ +--- +title: テスト +description: DefectDojo Proにおけるテストの理解 +audience: pro +weight: 4 +--- + +Organizations → Assets → Engagements → **TESTS** → Findings + +## 概要 + +テストとは、アセット内の欠陥を発見するために実行される1回以上のスキャン実行を格納するコンテナです。テストはDefectDojoのオブジェクト階層の中で最も末端かつ最も細かい単位であり、セキュリティツールの実行や手動評価の結果として得られる検出事項を格納するコンテナであると同時に、そうした検出事項がどのような文脈で発見されたか(どのツールが報告したか、そのツールが最後に実行されたのはいつかなど)という情報も付加します。 + +テストの例としては、以下のようなものが挙げられます。 +- 静的アプリケーションセキュリティテスト +- 動的アプリケーションセキュリティテスト +- ソフトウェア構成分析 +- コンテナセキュリティスキャン +- インフラストラクチャ/ネットワークスキャン +- 手動での侵入テスト +- CI/CDパイプラインスキャン + +### テストタイプ + +DefectDojoでテストを作成する方法はいくつかあり、**ベンダー固有のパーサー**(Burp、OWASP ZAP、Acunetix、Invictiなど)、**Generic Findings Import**、**Universal Parser**、**Connectors**が含まれます。 + +これらの方法は、設定や重複排除の戦略に応じて、新しいテストを作成することも、既存のテストに検出事項を再インポートすることもできます。 + +それぞれの方法はスキャンデータの解析と取り込み方が主に異なりますが、最終的にはいずれも検出事項がテストに関連付けられる結果となります。 + +#### パーサー + +**パーサー**とは、特定のスキャン出力形式(XML、JSON、CSVなど)を処理し、DefectDojo内部の検出事項モデルにマッピングするコンポーネントです。スキャン結果がインポートされると、DefectDojoは選択されたパーサーを使用して検出事項を抽出し、新規作成または既存のテストに関連付けます。 + +#### Generic Findings Import + +特定のツール用のネイティブパーサーが存在しない場合、[**Generic Findings Import**](/supported_tools/parsers/generic_findings_import)を使用すると、元のソースにかかわらず標準化されたJSONまたはCSVスキーマを使って検出事項をインポートできます。 + +DefectDojoは提供されたデータを解析し、新しいテストを作成する(または既存のテストにインポートする)とともに、検出事項を関連付けます。レポートの任意項目である`type`フィールドに基づいて、対応するテストタイプも作成されます。`type`が省略されている場合(またはスキャンタイプと同じ場合)、テストタイプは「Generic Findings Import」になります。`type`が指定されている場合は「`{type}` Scan (Generic Findings Import)」という形式になります(すでに「(Generic Findings Import)」というサフィックスで終わっている`type`はそのまま使用されます)。 + +#### Universal Parser + +[**Universal Parser**](/supported_tools/parsers/universal_parser)を使用すると、任意の入力データをDefectDojoの検出事項モデルにどのようにマッピングするかをユーザーが定義できます。パーサーを設定してスキャンデータをアップロードすると、DefectDojoはマッピングルールを適用して検出事項を抽出し、テストを作成(または既存のテストを更新)し、そのテストに検出事項を関連付けます。 + +#### Connectors + +[**Connectors**](/connectors/upstream/about/)を使用すると、外部ツールからの脆弱性データをAPI呼び出しによって自動的に取り込み、整理できます。設定が完了すると、コネクタはスキャン結果を取得し、データを解析して、その設定に応じて新しいテストを作成するか既存のテストを更新します。その後、検出事項が対応するテストに関連付けられます。 + +#### テスト作成メカニズムの比較 + +| | **Native Parsers** | **Generic Findings Import** | **Universal Parser (Pro)** | **Connectors** | +|----------|---------------|------------------------|------------------------|------------| +| **主な目的** | サポート対象ツールの出力を取り込む | 固定スキーマを使って未サポート/独自データを取り込む | 設定可能なマッピングで任意の形式を取り込む | 外部システムを継続的に同期する | +| **入力形式** | ツール固有(ZAP XML、SARIFなど) | 厳密なJSON/CSVスキーマ | 任意(JSON、XMLなど) | 外部APIレスポンス | +| **正規化を行う主体** | DefectDojo(組み込みパーサー) | ユーザー(スキーマに準拠する必要あり) | DefectDojo(パーサー設定経由) | 外部ツール + DefectDojo | +| **テスト作成のトリガー** | 手動アップロードまたはAPIインポート | 手動アップロードまたはAPIインポート | 手動アップロードまたはAPIインポート | 自動同期(スケジュールまたはイベント駆動) | +| **テストタイプ** | 事前定義済み(例: "ZAP Scan") | 自動作成される「Generic」タイプ | パーサー設定から導出 | コネクタ/基盤となるパーサーに依存 | +| **セットアップの手間** | 低 | 中程度(データ変換が必要) | 高(パーサー設定) | 中〜高(連携設定) | +| **柔軟性** | 低(サポート対象ツールのみ) | 中 | 高 | 中〜高 | +| **自動化レベル** | 低〜中 | 低〜中 | 低〜中 | 高 | +| **典型的なユースケース** | 標準的なスキャナー(SAST、DAST、SCA) | カスタムスクリプト、未サポートツール | 大規模な複雑/独自形式 | CI/CD、SCM、プラットフォーム連携 | + +取り込み方法にかかわらず、DefectDojo内のすべてのスキャンデータは最終的にテストに関連付けられた検出事項として表現され、テストが実行単位およびライフサイクル追跡の単位として機能します。 + +### テストデータ + +テストは、各テスト実施のさまざまな要素を記録するのに役立つ多様なメタデータを保持します。例えば以下のようなものです。 +- テストのタイトル/名前 +- テストタイプ +- テストの説明/メモ +- 開始日と終了日 +- テストが実行された環境(Development、Staging、Pre-Production、Productionなど) +- バージョン/ブランチ/ビルドID/コミットハッシュ +- APIスキャン設定 +- テストに関連する担当者 +- 後の監査や再インポートに使用できる追加ファイル +- 親となるエンゲージメント、アセット、組織 +- インポートおよび再インポートの履歴 + +各テストはインポート履歴を保持しており、そのテストに関連するすべてのスキャンのインポートと再インポートが記録されます。各履歴項目には、スキャン日、バージョン、ブランチ、コミットハッシュ、ビルドIDなどのメタデータが含まれます。 + +この履歴により、同一テスト内での複数回のスキャン実行にわたるトレーサビリティが確保されます。 + +### 権限 + +1つのエンゲージメント内には複数のテストを格納でき、エンゲージメントはアセット内に格納されます。そのため、アセットへのアクセス権があれば、そのアセット内のすべてのテスト(およびエンゲージメント)へのアクセスが自動的に許可されます。テストは独自のアクセス制御リストを持ちません。 + +## テストへのアクセス + +テストはDefectDojoのUIのさまざまなセクションからアクセスできます。 + +- サイドバー + +![image](images/tests_ss13.png) + +- エンゲージメント内 + +![image](images/tests_ss14.png) + +- アセットの上部バー + +![image](images/tests_ss15.png) + +- 検出事項ビュー内のメタデータテーブル + +![image](images/tests_ss16.png) + +## テストの操作 + +### テストの作成 + +スキャンデータがエンゲージメントに直接インポートされると、そのスキャンデータを含む新しいテストが自動的に作成されます。また、今後のエンゲージメントを計画する目的や、追跡・修復が必要な手動入力のセキュリティ検出事項のために、あらかじめテストを作成しておくこともできます。 + +#### 手動ワークフロー + +テストを作成するには、それを格納するエンゲージメントと、そのエンゲージメントを格納するアセットが必要です。その後、テストを作成する方法はいくつかあります。 + +- サイドバーの**Manage**サブセクション内のTestsから + - New Testフォームを入力する際に、そのテストを紐付ける既存のエンゲージメントを選択する必要があります。 + +![image](images/tests_ss1.png) + +- アセットビュー右上の設定ドロップダウンから + - **Import Scan**では、Import Scanフォームにスキャンファイルが追加されると自動的にテストが作成されます。そのテストを既存のエンゲージメントに紐付けるか、新しいエンゲージメントを作成・命名して新しいテストを格納するかを選択できます。 + - Import Scanフォームの入力時に、バージョン、ブランチタグ、コミットハッシュ、ビルドIDなどのメタデータを追加できます。これはテストビューのImport Historyセクションに反映されます。 + +![image](images/tests_ss2.png) + +- エンゲージメントビュー右上の設定ドロップダウンから + - **Import Scan**はアセットの場合と同じワークフローに従いますが、Import Scanをクリックしたエンゲージメント内に自動的にテストオブジェクトが配置されます。 + - **Add Test**はテストオブジェクトを作成しますが、そのテスト自体にスキャンをアップロードすることは必須ではありません。これは、今後のテストを計画する目的や、追跡・修復が必要な手動入力のセキュリティ検出事項に有用です。 + +![image](images/tests_ss3.png) + +Add Testを選択し、後でスキャン結果を手動でテストにインポートしたい場合は、テストを開いてテストの設定内のReimport Findingsボタン、または検出事項テーブル内のReimport Scanボタンをクリックすることで実行できます。 + +![image](images/tests_ss21.png) + +#### 自動化されたワークフロー + +自動化されたワークフローでは、スキャンのインポート処理の一部としてプログラム的にテストを作成できるため、パイプラインは事前に手動でテストを作成することなく結果をアップロードできます。 + +APIまたはCLIを使ってスキャン結果をインポートする際、`test`の代わりに`engagement`を指定することで、新しいテストを自動的に作成できます。 + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +上記の場合、指定されたエンゲージメントの下に新しいテストが作成され、スキャン結果がそのテストに関連付けられます。 + +代わりに`test` IDが指定された場合、スキャン結果は既存のテストに追加されます。これは再インポートのワークフローでよく見られるパターンです。 + +##### CLI + +DefectDojo CLIを使用する場合、この動作は指定された引数に基づいて自動的に処理されます。 + +defectdojo-cli import \ + --engagement-id 45 \ + --scan-type `"ZAP Scan"` \ +GOog --file report.xml + +上記の場合、`engagement-id`を指定すると新しいテストが作成され、`test-id`を指定すると既存のテストが再利用され、そのテストにスキャン結果が再インポートされます。 + +必須フラグの詳細については、[DefectDojo-CLI](/import_data/pro/specialized_import/external_tools/#defectdojo-cli)を参照してください。 + +### テストの編集 + +テストは、歯車メニューから**Edit Test**をクリックすることで編集できます。編集可能なフィールドはすべて、テスト作成時にも利用できます。 + +### テストの削除 + +テストの削除は、テストの設定から**Delete Test**を選択することで行えます。この操作は元に戻せません。 + +テストを削除すると、そのテストに含まれるすべての検出事項も削除されます。 + +### スキャン結果の再インポート(UI) + +既存のテストに新しいデータを追加するには、追加先のテストを開いて、テストの設定内のReimport Findingsボタン、または検出事項テーブル内のReimport Scanボタンをクリックします。 + +![image](images/tests_ss21.png) + +Reimport Scanフォームの入力時には、再インポートするスキャンのメタデータ(バージョン、ブランチタグ、コミットハッシュ、ビルドIDなど)を更新するオプションがあります。これらの変更はテストビューのImport Historyセクションに反映され、以前のスキャンインポート時の同様のメタデータも併せて表示されます。 + +例えば下のスクリーンショットでは、最初のインポートとその後の再インポートの間に、ブランチタグ、ビルドID、コミットハッシュ、バージョンがすべて手動で更新されています。 + +![image](images/tests_ss23.png) + +直近に再インポートされたスキャンのメタデータを編集するには、エンゲージメントビュー右上にある歯車アイコンをクリックし、「Edit Test」を選択します。編集できるのは直近のインポートのメタデータのみです。 + +### スキャン結果の再インポート(API/CLI) + +CI/CDパイプラインを通じてテストが作成または更新される場合、パイプライン実行時のメタデータを含めることで、テストをスキャン対象のコードに適切に紐付けることができます。これにより、以下のようなことが可能になります。 +- スキャン結果を特定のコミットやブランチに関連付ける。 +- コードの変更に伴って検出事項がどのように推移するかを追跡する。 +- 2つのスキャンが同じバージョンのコードに対するものか、異なるバージョンのものかを把握することで重複排除を改善する。 +- どのコードがいつスキャンされたかを正確に示すことで、監査可能性をサポートする。 + +DefectDojoのCLIとAPIは、インポートまたは再インポート時にこれらの値を受け付けます。これによりスキャンインポートの一部として保存され、テストのインポート履歴に反映されます。このメタデータは、コミットハッシュや、CI/CD実行に関連するリポジトリ情報を特定するために使用できます。 + +#### サポートされているメタデータフィールド + +APIとCLIは、再インポート時に含めることができる定義済みのメタデータフィールドをサポートしています。以下の通りです。 + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- `active / verified`フラグ + +これらのフィールドは、再インポート操作時に文脈的なメタデータを付与するための主要な仕組みです。 + +自動化されたパイプラインでは、最もよく指定されるメタデータは以下の通りです。 +- `build_id`(CIジョブの識別子) +- `commit_hash`(ソース管理の参照情報) +- `branch_tag`(ブランチまたは環境のコンテキスト) +- `tags`(`nightly`、`staging`、`production`など) + +これらのフィールドにより、手動での介入を必要とせずにスキャン間のトレーサビリティが確保されます。 + +メタデータはReimport Scanフォームから手動で更新することもできますが、ほとんどの自動化された環境では、ビルドプロセスの一部として`/api/v2/reimport-scan/`エンドポイントを直接呼び出すか、DefectDojo CLI(`defectdojo-cli reimport`)を使用してこれを処理します。この方法により、パイプラインは再インポート時にメタデータを自動的に付与できます。 + +##### メタデータを伴うAPI再インポート + +curl -X POST `"https:///api/v2/reimport-scan/"` \ + -H `"Authorization: Token "` \ + -F `"test=123"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` \ + -F `"tags=nightly,api-scan"` \ + -F `"version=1.4.2"` \ + -F `"build_id=jenkins-842"` \ + -F `"branch_tag=main"` \ + -F `"commit_hash=a1b2c3d4"` + +##### メタデータを伴うCLI再インポート + +defectdojo-cli import \ + --test-id 123 \ + --scan-type "ZAP Scan" \ + --file report.xml \ + --tag nightly \ + --tag api \ + --build-id jenkins-842 \ + --branch main \ + --commit a1b2c3d4 + +CLIは同じAPIエンドポイントに直接マッピングされ、同じメタデータフィールドのセットをサポートします。 + +再インポート時にメタデータを扱う際には、いくつか注意すべき制約があります。 +- APIおよびCLIは事前定義されたパラメータのみをサポートします。再インポート時にカスタムのキーバリュー形式のメタデータを追加することはできません。 +- スキャンタイプやパーサーによっては、スキャンファイル自体から追加のメタデータが抽出される場合があります。 +- 再インポート時に指定されたメタデータは、UI上での手動編集のようにテストオブジェクトへ直接反映されるわけではありません。 + +##### メタデータ、再インポート、スケジュールスキャン + +スキャンは、cronジョブなどによって定期的な間隔で実行されるようスケジュールすることもできます。スケジュールされたスキャンはリポジトリの活動に紐付いていないため、スクリプト自体が明示的に付与しない限り、コミットハッシュやブランチ名などのメタデータは意味を持ちません。とはいえ、単一のテスト内でセキュリティ体制の継続的な記録を維持したい場合は、再インポートを使用することが依然として有用です。 + +## 再インポートと重複排除 + +テスト内でスキャンを再インポートすることは、効果的な重複排除の基本です。スキャン結果が同じテストに再インポートされると、次のようになります。 + +- 既存の検出事項が更新される場合があります +- 重複する検出事項が抑制される場合があります +- 一致するものが見つからない場合は新しい検出事項が作成されます + +この動作は、設定された重複排除ルールとスキャンタイプに依存します。 + +既存のテストに再インポートする代わりに新しいテストを作成すると、検出事項が更新されるのではなく重複して作成される可能性があります。 + +### 再インポートとインポートの違い + +再インポートは、主に次のような場合に使用されます。 + +- 同一のターゲットに対して繰り返しスキャンを実行する場合 +- 検出事項が時間の経過とともにどのように変化するかを追跡する場合 +- アプリケーションのセキュリティ体制を継続的に把握する場合 + +一方、インポート(新しいテストの作成)は、一度限り、または独立したスキャン実行に適しています。 diff --git a/docs/content/asset_modelling/engagements_tests/_index.de.md b/docs/content/asset_modelling/engagements_tests/_index.de.md new file mode 100644 index 00000000000..6e112349bf4 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/_index.de.md @@ -0,0 +1,8 @@ +--- +title: Engagements & Tests +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/asset_modelling/engagements_tests/_index.es.md b/docs/content/asset_modelling/engagements_tests/_index.es.md new file mode 100644 index 00000000000..37e02013809 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/_index.es.md @@ -0,0 +1,8 @@ +--- +title: Compromisos y Tests +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/asset_modelling/engagements_tests/_index.fr.md b/docs/content/asset_modelling/engagements_tests/_index.fr.md new file mode 100644 index 00000000000..6e112349bf4 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/_index.fr.md @@ -0,0 +1,8 @@ +--- +title: Engagements & Tests +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/asset_modelling/engagements_tests/_index.ja.md b/docs/content/asset_modelling/engagements_tests/_index.ja.md new file mode 100644 index 00000000000..4962d12f9ea --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/_index.ja.md @@ -0,0 +1,8 @@ +--- +title: エンゲージメントとテスト +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/asset_modelling/locations/PRO__locations_overview.de.md b/docs/content/asset_modelling/locations/PRO__locations_overview.de.md new file mode 100644 index 00000000000..1cf990e0756 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__locations_overview.de.md @@ -0,0 +1,80 @@ +--- +title: Übersicht über Standorte +description: Was Standorte sind und warum sie Endpunkte ersetzen +audience: pro +weight: 1 +--- + +**Standorte** sind ein neues Asset-Modellierungs-Tool in DefectDojo Pro. Sie ersetzen das bisherige **Endpunkte**-Modell und übernehmen die früheren **Komponenten**-Daten (Bibliotheken), wodurch DefectDojo über eine einzige, polymorphe Möglichkeit verfügt, zu beschreiben, *wo* sich ein Befund befindet — sei es eine URL, eine Software-Abhängigkeit aus einer **SBOM** oder, zukünftig, eine **Cloud-Ressourcen-ID**, ein **Container-Image** oder ein **Code-Repository**. + +Standorte müssen auf Ihrer Instanz aktiviert werden, bevor Sie sie nutzen können. Sie können Standorte selbst über die [Seite Feature Flags](/admin/feature_flags/pro__feature_flags/) aktivieren — eine Support-Anfrage ist nicht erforderlich. Beachten Sie, dass Standorte nach der Aktivierung nicht wieder deaktiviert werden können. + +## Warum Endpunkte ersetzen? + +Das ursprüngliche Endpunkte-Modell war auf URLs und IP-Adressen ausgelegt — es enthielt Webanwendungsfelder wie `protocol`, `host`, `port`, `path` sowie eine feste Statustabelle, die eng an Befunde gekoppelt war. Daraus ergaben sich drei Probleme: + +1. **Begrenzte Genauigkeit.** Endpunkte konnten Nicht-URL-Assets wie Drittanbieter-Bibliotheken, Container-Images oder Cloud-Ressourcen nicht sauber beschreiben, obwohl Scanner zunehmend Befunde zu genau solchen Dingen erzeugen. +2. **Performance-Obergrenze.** Die Endpoint_Status-Zeilen pro Befund und das URL-förmige Schema skalierten bei großen Kundenvolumen nicht gut. +3. **Komponenten waren zweitrangig.** Software-Bibliotheken existierten nur als denormalisierte Felder an einem Befund, sodass eine Bibliothek nicht unabhängig von einer Schwachstelle existieren konnte — was ein echtes SBOM-Management unmöglich machte. + +Standorte beheben alle drei Probleme, indem sie ein **Basis-`Location`-Objekt** mit einem typisierten Payload sowie dedizierte **Subtypen** für jede Asset-Form einführen: + +- **URL-Standorte** — das funktionale Äquivalent der alten Endpunkte, mit denselben Feldern protocol/host/port/path/query/fragment. +- **Abhängigkeits-Standorte** — Software-Bibliotheken, identifiziert durch [Package URL (pURL)](https://github.com/package-url/purl-spec), zur Modellierung von SBOM-Inhalten. +- **[Quellcode-Standorte](/asset_modelling/locations/pro__source_code_locations/)** — wo sich ein Befund einer statischen Analyse im Quellcode befindet, identifiziert durch Dateipfad und Zeilennummer. Scan-verwaltet und die Grundlage für die [Verfolgung von Befunden, wenn sich ihr Code verschiebt](/triage_findings/finding_deduplication/pro__location_drift_matching/). + +Zu den zukünftigen, in Erwägung gezogenen Standort-Typen zählen Cloud-Provider-Ressourcen-IDs (AWS ARN, Azure Resource ID, GCP Full Resource Name) sowie Container-Images (registry/repository:tag und SHA256-Fingerabdrücke). + +## Kernkonzepte + +### Standorte und Subtypen + +Ein **Standort** ist das gemeinsame übergeordnete Objekt. Er enthält: + +- Einen `Location Type` (z. B. `"url"`, `"dependency"`) +- Eine kanonische `Location Value`-Zeichenkette, die für Anzeige, Suche und Deduplizierung verwendet wird +- `Tags` sowie von dem übergeordneten Asset geerbte Tags +- Metadaten (benutzerdefinierte Schlüssel-/Wert-Paare) + +Ein **Subtyp** (URL oder Abhängigkeit) enthält die strukturierten Felder, die für diese Art von Standort spezifisch sind. URLs und Abhängigkeiten existieren stets zusammen mit einem übergeordneten Location-Objekt; der `Location Value` des Subtyps wird aus dessen strukturierten Feldern generiert. + +### Referenzen + +Standorte werden nicht direkt an Produkte oder Befunde angehängt. Stattdessen verknüpfen sie zwei **Referenz**-Objekte: + +- **Asset-Referenzen** — Beziehungen, die der Standort zu Assets hat (z. B. gehört `libFoo` zu Asset 6 und wird von Asset 9 verwendet). Jede Referenz trägt einen Status (`Active` oder `Mitigated`) sowie optional eine **Beziehung** („Verwendet von“ oder „Gehört zu“). +- **Befund-Referenzen** — Beziehungen, die der Standort zu Befunden hat. Jede Referenz trägt einen umfangreicheren Status (`Active`, `Mitigated`, `False Positive`, `Risk Accepted`, `Out of Scope`) sowie den Prüfer und den Prüfzeitpunkt. + +Diese Trennung ermöglicht es, dass eine Bibliothek auf einem Produkt existieren kann, *ohne* einen Befund zu benötigen — eine Fähigkeit, die im alten Komponenten-Modell fehlte. + +### Automatische Zuordnung beim Import + +Wenn ein Parser einen Befund erzeugt, der auf eine URL oder eine Bibliothek verweist, geht der Importer wie folgt vor: + +1. Er sucht nach einem vorhandenen Standort, der der URL oder pURL entspricht; existiert keiner, wird einer erstellt. +2. Er erstellt eine Befund-Referenz, die den Befund mit dem Status `Active` mit dem Standort verknüpft. +3. Er erstellt (oder verwendet erneut) eine Asset-Referenz, damit der Standort auch am übergeordneten Asset existiert. + +Bestehende Parser wurden aktualisiert, um Standort-Daten auszugeben, wenn das Feature-Flag aktiviert ist, und auf das alte Endpunkt-Modell zurückzugreifen, wenn es deaktiviert ist. Nach der Aktivierung von Standorten ist keine erneute Konfiguration erforderlich — der nächste Import wird automatisch über die Standorte-Pipeline geleitet. + +## Was im MVP enthalten ist + +| Funktion | Status | +| --- | --- | +| Grundlegende Modelle `Location`, `URL`, `Dependency` | Veröffentlicht | +| REST-API für Standorte und Referenzen | Veröffentlicht (schreibgeschütztes `Location`, vollständiges CRUD für Referenzen) | +| Kompatibilitäts-Shim für die Endpunkt-API (nur Lesezugriff) | Veröffentlicht | +| Einseitiger Migrationsbefehl Endpunkt → URL | Veröffentlicht | +| Parser-Aktualisierungen (URLs und Abhängigkeiten) | Für die wichtigsten Parser veröffentlicht | +| SBOM-Upload (CycloneDX, SPDX v2/v3) | Veröffentlicht über `/api/v2/sbom-import/` | +| Pro-UI für Standorte, URLs, Abhängigkeiten | Veröffentlicht | +| pURL-Suche/-Filter | Veröffentlicht | +| Lizenz-Tracking für Abhängigkeiten | Teilweise (Feld `license_expression`) | +| SWID-Tag-SBOM-Format | Nicht im MVP enthalten | + +## Wie geht es weiter + +- **Funktion aktivieren** — wenden Sie sich an [support@defectdojo.com](mailto:support@defectdojo.com), um Standorte für Ihre Instanz zu aktivieren. +- **Migration von Endpunkten** — siehe [Migration von Endpunkten](../pro__migrating_from_endpoints), um zu erfahren, was bei der Migration erhalten bleibt und wie sich die alte Endpunkt-API danach verhält. +- **Tägliche URL-Workflows** — siehe [Arbeiten mit URLs](../pro__working_with_urls). +- **SBOMs und Abhängigkeiten** — siehe [Arbeiten mit SBOMs](../pro__working_with_sboms). diff --git a/docs/content/asset_modelling/locations/PRO__locations_overview.es.md b/docs/content/asset_modelling/locations/PRO__locations_overview.es.md new file mode 100644 index 00000000000..dec4e16f034 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__locations_overview.es.md @@ -0,0 +1,80 @@ +--- +title: Descripción general de Ubicaciones +description: Qué son las Ubicaciones y por qué reemplazan a los Endpoints +audience: pro +weight: 1 +--- + +Las **Ubicaciones** son una nueva herramienta de modelado de activos en DefectDojo Pro. Reemplazan al modelo heredado de **Endpoints** y absorben los datos previos de **Componentes** (bibliotecas), lo que le da a DefectDojo una única forma polimórfica de describir *dónde* vive un Hallazgo — ya sea una URL, una dependencia de software proveniente de un **SBOM** o, en el futuro, un **ID de recurso en la nube**, una **imagen de contenedor** o un **repositorio de código**. + +Las Ubicaciones deben habilitarse en su instancia antes de poder usarlas. Puede activarlas usted mismo desde la [página de Feature Flags](/admin/feature_flags/pro__feature_flags/) — no se requiere una solicitud de Soporte. Tenga en cuenta que las Ubicaciones no se pueden desactivar una vez habilitadas. + +## ¿Por qué reemplazar los Endpoints? + +El modelo original de Endpoints se construyó en torno a URL y direcciones IP — incluía campos de aplicación web como `protocol`, `host`, `port`, `path`, y una tabla de estado fija fuertemente acoplada a los Hallazgos. De esto se derivaron tres problemas: + +1. **Fidelidad limitada.** Los Endpoints no podían describir con claridad activos que no fueran URL, como bibliotecas de terceros, imágenes de contenedor o recursos en la nube, aunque los escáneres producen cada vez más hallazgos sobre esos elementos. +2. **Límite de rendimiento.** Las filas de Endpoint_Status por Hallazgo y el esquema con forma de URL no escalaban bien con grandes volúmenes de clientes. +3. **Los Componentes eran de segunda clase.** Las bibliotecas de software existían únicamente como campos desnormalizados en un Hallazgo, por lo que una biblioteca no podía existir independientemente de una vulnerabilidad — lo que hacía imposible una gestión real de SBOM. + +Las Ubicaciones resuelven los tres problemas al introducir un **objeto `Location` base** con una carga tipada, además de **subtipos** dedicados para cada forma de activo: + +- **Ubicaciones de URL** — equivalente funcional de los antiguos Endpoints, con los mismos campos protocol/host/port/path/query/fragment. +- **Ubicaciones de dependencia** — bibliotecas de software identificadas mediante [Package URL (pURL)](https://github.com/package-url/purl-spec), utilizadas para modelar el contenido de un SBOM. +- **[Ubicaciones de código fuente](/asset_modelling/locations/pro__source_code_locations/)** — dónde vive en el código fuente un hallazgo de análisis estático, identificado por ruta de archivo y número de línea. Gestionadas por el escaneo, y la base para [el seguimiento de hallazgos a medida que su código se mueve](/triage_findings/finding_deduplication/pro__location_drift_matching/). + +Entre los futuros tipos de Ubicación en consideración se incluyen los ID de recursos de proveedores en la nube (AWS ARN, Azure Resource ID, GCP Full Resource Name) e imágenes de contenedor (registry/repository:tag y huellas SHA256). + +## Conceptos clave + +### Ubicaciones y subtipos + +Una **Ubicación** es el padre compartido. Contiene: + +- Un `Location Type` (p. ej. `"url"`, `"dependency"`) +- Una cadena `Location Value` canónica utilizada para mostrar, buscar y deduplicar +- `Tags` y etiquetas heredadas del Activo padre +- Metadatos (pares clave/valor personalizados) + +Un **subtipo** (URL o Dependency) contiene los campos estructurados específicos de ese tipo de ubicación. Las URL y las Dependencies siempre existen junto a un objeto Location padre; el `Location Value` del subtipo se genera a partir de sus campos estructurados. + +### Referencias + +Las Ubicaciones no están adjuntas directamente a Productos o Hallazgos. En cambio, dos objetos **Reference** las vinculan: + +- **Asset References** — relaciones que la Ubicación tiene con los Activos (p. ej., `libFoo` es *propiedad de* Asset 6, *usada por* Asset 9). Cada referencia tiene un estado (`Active` o `Mitigated`) y una **relación** opcional ("Used By" u "Owned By"). +- **Finding References** — relaciones que la Ubicación tiene con los Hallazgos. Cada referencia tiene un estado más detallado (`Active`, `Mitigated`, `False Positive`, `Risk Accepted`, `Out of Scope`) además del auditor y el momento de la auditoría. + +Esta separación es lo que permite que una biblioteca exista en un Producto *sin* necesitar un Hallazgo — una capacidad ausente en el antiguo modelo de Componentes. + +### Asociación automática en el momento de la importación + +Cuando un parser produce un Hallazgo que hace referencia a una URL o biblioteca, el importador: + +1. Busca una Ubicación existente que coincida con la URL o el pURL; si no existe ninguna, crea una. +2. Crea una Finding Reference que vincula el Hallazgo con la Ubicación con estado `Active`. +3. Crea (o reutiliza) una Asset Reference para que la Ubicación también exista en el Activo padre. + +Los parsers existentes se han actualizado para emitir datos de Ubicación cuando el feature flag está activado, y para recurrir al modelo heredado de Endpoint cuando está desactivado. No se necesita ninguna reconfiguración cuando las Ubicaciones están habilitadas — la próxima importación se enrutará automáticamente a través del pipeline de Ubicaciones. + +## Qué incluye el MVP + +| Capability | Status | +| --- | --- | +| Modelos base `Location`, `URL`, `Dependency` | Disponible | +| API REST para Locations y References | Disponible (`Location` de solo lectura, CRUD completo en References) | +| Shim de compatibilidad de lectura de la API de Endpoint | Disponible | +| Comando de migración unidireccional de Endpoint a URL | Disponible | +| Actualizaciones de parsers (URL y dependencias) | Disponible para los principales parsers | +| Carga de SBOM (CycloneDX, SPDX v2/v3) | Disponible mediante `/api/v2/sbom-import/` | +| Pro UI para Locations, URLs, Dependencies | Disponible | +| Búsqueda/filtro por pURL | Disponible | +| Seguimiento de licencias en dependencias | Parcial (campo `license_expression`) | +| Formato de SBOM SWID Tag | No incluido en el MVP | + +## Próximos pasos + +- **Habilite la función** — comuníquese con [support@defectdojo.com](mailto:support@defectdojo.com) para activar las Ubicaciones en su instancia. +- **Migre desde Endpoints** — consulte [Migración desde Endpoints](../pro__migrating_from_endpoints) para saber qué preserva la migración y cómo se comporta después la API heredada de Endpoint. +- **Flujos de trabajo diarios de URL** — consulte [Trabajar con URLs](../pro__working_with_urls). +- **SBOM y dependencias** — consulte [Trabajar con SBOMs](../pro__working_with_sboms). diff --git a/docs/content/asset_modelling/locations/PRO__locations_overview.fr.md b/docs/content/asset_modelling/locations/PRO__locations_overview.fr.md new file mode 100644 index 00000000000..a4412b9e462 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__locations_overview.fr.md @@ -0,0 +1,81 @@ +--- +title: Vue d'ensemble des emplacements +description: Ce que sont les emplacements et pourquoi ils remplacent les points de + terminaison +audience: pro +weight: 1 +--- + +Les **emplacements** (Locations) sont un nouvel outil de modélisation des actifs dans DefectDojo Pro. Ils remplacent l'ancien modèle **Endpoints** et absorbent les anciennes données de **Composants** (bibliothèques), offrant à DefectDojo une manière unique et polymorphe de décrire *où* vit une Constatation — qu'il s'agisse d'une URL, d'une dépendance logicielle issue d'un **SBOM**, ou, à l'avenir, d'un **identifiant de ressource cloud**, d'une **image de conteneur** ou d'un **dépôt de code**. + +Les emplacements doivent être activés sur votre instance avant de pouvoir être utilisés. Vous pouvez les activer vous-même depuis la [page des indicateurs de fonctionnalités](/admin/feature_flags/pro__feature_flags/) — aucune demande auprès du support n'est nécessaire. Notez que les emplacements ne peuvent pas être désactivés une fois activés. + +## Pourquoi remplacer les Endpoints ? + +Le modèle Endpoints d'origine était construit autour des URL et des adresses IP — il comportait des champs propres aux applications web comme `protocol`, `host`, `port`, `path`, ainsi qu'une table de statut fixe étroitement couplée aux Constatations. Trois problèmes en découlaient : + +1. **Fidélité limitée.** Les Endpoints ne pouvaient pas décrire proprement des actifs non-URL tels que les bibliothèques tierces, les images de conteneurs ou les ressources cloud, alors même que les scanners produisent de plus en plus de constatations à ce sujet. +2. **Plafond de performance.** Les lignes Endpoint_Status par Constatation et le schéma en forme d'URL ne montaient pas bien en charge pour les gros volumes clients. +3. **Les composants étaient de seconde classe.** Les bibliothèques logicielles n'existaient que comme des champs dénormalisés sur une Constatation, si bien qu'une bibliothèque ne pouvait pas exister indépendamment d'une vulnérabilité — rendant impossible une véritable gestion des SBOM. + +Les emplacements corrigent ces trois problèmes en introduisant un **objet de base `Location`** doté d'une charge utile typée, ainsi que des **sous-types** dédiés pour chaque forme d'actif : + +- **Emplacements URL** — équivalent fonctionnel des anciens Endpoints, avec les mêmes champs protocole/hôte/port/chemin/requête/fragment. +- **Emplacements de dépendance** — bibliothèques logicielles identifiées par [Package URL (pURL)](https://github.com/package-url/purl-spec), utilisées pour modéliser le contenu des SBOM. +- **[Emplacements de code source](/asset_modelling/locations/pro__source_code_locations/)** — l'endroit où vit dans le code source une constatation d'analyse statique, identifié par un chemin de fichier et un numéro de ligne. Géré par le scan, et le socle permettant de [suivre les constatations lorsque leur code se déplace](/triage_findings/finding_deduplication/pro__location_drift_matching/). + +Parmi les futurs types d'emplacements envisagés figurent les identifiants de ressources des fournisseurs cloud (AWS ARN, Azure Resource ID, GCP Full Resource Name) et les images de conteneurs (registry/repository:tag et empreintes SHA256). + +## Concepts clés + +### Emplacements et sous-types + +Un **Location** est le parent commun. Il porte : + +- Un `Location Type` (par ex. `"url"`, `"dependency"`) +- Une chaîne `Location Value` canonique utilisée pour l'affichage, la recherche et la déduplication +- Des `Tags` et des étiquettes héritées de l'Actif parent +- Des métadonnées (paires clé/valeur personnalisées) + +Un **sous-type** (URL ou Dependency) contient les champs structurés propres à ce type d'emplacement. Les URL et les Dependencies vivent toujours aux côtés d'un objet Location parent ; le `Location Value` du sous-type est généré à partir de ses champs structurés. + +### Références + +Les emplacements ne sont pas directement rattachés aux Produits ou aux Constatations. Deux objets **Reference** les relient à la place : + +- **Asset References** — les relations que l'emplacement entretient avec les Actifs (par ex. `libFoo` est *possédée par* l'Actif 6, *utilisée par* l'Actif 9). Chaque référence porte un statut (`Active` ou `Mitigated`) et une **relation** optionnelle (« Used By » ou « Owned By »). +- **Finding References** — les relations que l'emplacement entretient avec les Constatations. Chaque référence porte un statut plus riche (`Active`, `Mitigated`, `False Positive`, `Risk Accepted`, `Out of Scope`), ainsi que l'auditeur et l'heure de l'audit. + +Cette séparation est ce qui permet à une bibliothèque d'exister sur un Produit *sans* qu'une Constatation soit nécessaire — une capacité absente de l'ancien modèle de Composants. + +### Association automatique lors de l'importation + +Lorsqu'un parseur produit une Constatation référençant une URL ou une bibliothèque, l'importateur : + +1. Recherche un emplacement existant correspondant à l'URL ou au pURL ; s'il n'en existe aucun, il en crée un. +2. Crée une Finding Reference reliant la Constatation à l'emplacement avec le statut `Active`. +3. Crée (ou réutilise) une Asset Reference afin que l'emplacement vive également sur l'Actif parent. + +Les parseurs existants ont été mis à jour pour émettre des données d'emplacement lorsque l'indicateur de fonctionnalité est activé, et pour revenir à l'ancien modèle Endpoint lorsqu'il est désactivé. Aucune reconfiguration n'est nécessaire une fois les emplacements activés — la prochaine importation passera automatiquement par le pipeline des emplacements. + +## Contenu du MVP + +| Fonctionnalité | État | +| --- | --- | +| Modèles de base `Location`, `URL`, `Dependency` | Livré | +| API REST pour les emplacements et les références | Livré (`Location` en lecture seule, CRUD complet sur les références) | +| Compatibilité en lecture avec l'ancienne API Endpoint | Livré | +| Commande de migration Endpoint → URL (à sens unique) | Livré | +| Mises à jour des parseurs (URL et dépendances) | Livré pour les principaux parseurs | +| Import de SBOM (CycloneDX, SPDX v2/v3) | Livré via `/api/v2/sbom-import/` | +| Interface Pro pour les emplacements, URL et dépendances | Livré | +| Recherche/filtre par pURL | Livré | +| Suivi des licences sur les dépendances | Partiel (champ `license_expression`) | +| Format SBOM SWID Tag | Absent du MVP | + +## Prochaines étapes + +- **Activer la fonctionnalité** — contactez [support@defectdojo.com](mailto:support@defectdojo.com) pour activer les emplacements sur votre instance. +- **Migrer depuis les Endpoints** — voir [Migrating from Endpoints](../pro__migrating_from_endpoints) pour savoir ce que la migration préserve, et comment se comporte ensuite l'ancienne API Endpoint. +- **Flux de travail quotidiens sur les URL** — voir [Working with URLs](../pro__working_with_urls). +- **SBOM et dépendances** — voir [Working with SBOMs](../pro__working_with_sboms). diff --git a/docs/content/asset_modelling/locations/PRO__locations_overview.ja.md b/docs/content/asset_modelling/locations/PRO__locations_overview.ja.md new file mode 100644 index 00000000000..eb265aac6ef --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__locations_overview.ja.md @@ -0,0 +1,80 @@ +--- +title: ロケーションの概要 +description: ロケーションとは何か、そしてなぜエンドポイントに代わるのか +audience: pro +weight: 1 +--- + +**ロケーション**は、DefectDojo Proにおける新しいアセットモデリングツールです。従来の**エンドポイント**モデルを置き換え、それまでの**コンポーネント**(ライブラリ)データを統合することで、検出事項がどこに存在するか — URLであれ、**SBOM**由来のソフトウェア依存関係であれ、あるいは将来的には**クラウドリソースID**、**コンテナイメージ**、**コードリポジトリ**であれ — を記述するための、単一の多態的な方法をDefectDojoにもたらします。 + +ロケーションを使用するには、事前にインスタンスで有効化しておく必要があります。[フィーチャーフラグページ](/admin/feature_flags/pro__feature_flags/)からご自身でロケーションを有効にでき、サポートへの依頼は不要です。ロケーションは一度有効にすると、再度無効に戻すことはできない点に注意してください。 + +## なぜエンドポイントを置き換えるのか? + +従来のエンドポイントモデルはURLとIPアドレスを中心に構築されており、`protocol`、`host`、`port`、`path`といったWebアプリ向けのフィールドと、検出事項と密結合した固定のステータステーブルを備えていました。これには3つの問題がありました。 + +1. **忠実度の限界。** エンドポイントは、サードパーティライブラリ、コンテナイメージ、クラウドリソースなど、URL以外のアセットをきれいに記述することができませんでした。スキャナーがこうした対象に関する検出事項をますます多く生成するようになっているにもかかわらずです。 +2. **パフォーマンスの上限。** 検出事項ごとのEndpoint_Statusレコードと、URL形式のスキーマは、大規模な顧客ボリュームにおいてうまくスケールしませんでした。 +3. **コンポーネントは二級市民でした。** ソフトウェアライブラリは検出事項上の非正規化フィールドとしてのみ存在していたため、ライブラリが脆弱性から独立して存在することができず、真のSBOM管理が不可能でした。 + +ロケーションは、型付きペイロードを持つ**基本の`Location`オブジェクト**と、各アセット形状に対応する専用の**サブタイプ**を導入することで、これら3つの問題をすべて解決します。 + +- **URLロケーション** — 従来のエンドポイントと機能的に同等で、同じprotocol/host/port/path/query/fragmentフィールドを持ちます。 +- **依存関係ロケーション** — [Package URL(pURL)](https://github.com/package-url/purl-spec)によって識別されるソフトウェアライブラリで、SBOMの内容をモデル化するために使用されます。 +- **[ソースコードロケーション](/asset_modelling/locations/pro__source_code_locations/)** — 静的解析による検出事項がソースコード内のどこに存在するかを、ファイルパスと行番号によって識別します。スキャンによって管理され、[コードの移動に伴う検出事項の追跡](/triage_findings/finding_deduplication/pro__location_drift_matching/)の基盤となります。 + +今後検討されているロケーションタイプには、クラウドプロバイダーのリソースID(AWS ARN、Azureリソース ID、GCPフルリソース名)やコンテナイメージ(registry/repository:tagおよびSHA256フィンガープリント)が含まれます。 + +## 主要な概念 + +### ロケーションとサブタイプ + +**ロケーション**は共有される親要素です。以下を保持します。 + +- `Location Type`(例:`"url"`、`"dependency"`) +- 表示、検索、重複排除に使用される正規の`Location Value`文字列 +- `Tags`および親アセットから継承されたタグ +- メタデータ(カスタムのキー/値ペア) + +**サブタイプ**(URLまたは依存関係)は、その種類のロケーションに固有の構造化されたフィールドを保持します。URLと依存関係は常に親のロケーションオブジェクトとともに存在し、サブタイプの`Location Value`はその構造化フィールドから生成されます。 + +### 参照 + +ロケーションは製品や検出事項に直接紐づけられるわけではありません。代わりに、2種類の**参照**オブジェクトがそれらをリンクします。 + +- **アセット参照** — ロケーションがアセットに対して持つ関係(例:`libFoo`はアセット6に*所有され*、アセット9に*使用される*)。各参照はステータス(`Active`または`Mitigated`)と任意の**関係**(「使用元」または「所有元」)を持ちます。 +- **検出事項参照** — ロケーションが検出事項に対して持つ関係。各参照は、より詳細なステータス(`Active`、`Mitigated`、`False Positive`、`Risk Accepted`、`Out of Scope`)に加え、監査者と監査日時を持ちます。 + +この分離により、ライブラリは検出事項を必要とせずに製品上に存在できるようになります。これは従来のコンポーネントモデルにはできなかったことです。 + +### インポート時の自動関連付け + +パーサーがURLまたはライブラリを参照する検出事項を生成すると、インポーターは以下を行います。 + +1. URLまたはpURLに一致する既存のロケーションを検索します。存在しない場合は新規に作成します。 +2. 検出事項をステータス`Active`でロケーションにリンクする検出事項参照を作成します。 +3. アセット参照を作成(または再利用)し、ロケーションが親アセット上にも存在するようにします。 + +既存のパーサーは、フィーチャーフラグが有効な場合にロケーションデータを出力し、無効な場合は従来のエンドポイントモデルにフォールバックするよう更新されています。ロケーションを有効にしても再設定は不要です。次回のインポートから自動的にロケーションパイプラインを経由します。 + +## MVPに含まれるもの + +| Capability | Status | +| --- | --- | +| 基盤となる`Location`、`URL`、`Dependency`モデル | 提供済み | +| ロケーションおよび参照用のREST API | 提供済み(`Location`は読み取り専用、参照は完全なCRUDに対応) | +| エンドポイントAPIとの読み取り互換シム | 提供済み | +| エンドポイント → URLの一方向移行コマンド | 提供済み | +| パーサーの更新(URLおよび依存関係) | 主要なパーサーで提供済み | +| SBOMアップロード(CycloneDX、SPDX v2/v3) | `/api/v2/sbom-import/`経由で提供済み | +| ロケーション、URL、依存関係向けのPro UI | 提供済み | +| pURLの検索/フィルタリング | 提供済み | +| 依存関係のライセンス追跡 | 部分的(`license_expression`フィールド) | +| SWID TagのSBOM形式 | MVP未対応 | + +## 次のステップ + +- **機能を有効にする** — インスタンスでロケーションを有効にするには、[support@defectdojo.com](mailto:support@defectdojo.com)までご連絡ください。 +- **エンドポイントからの移行** — 移行によって何が保持されるか、また移行後に従来のエンドポイントAPIがどのように動作するかについては、[エンドポイントからの移行](../pro__migrating_from_endpoints)を参照してください。 +- **日常のURLワークフロー** — [URLの操作](../pro__working_with_urls)を参照してください。 +- **SBOMと依存関係** — [SBOMの操作](../pro__working_with_sboms)を参照してください。 diff --git a/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.de.md b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.de.md new file mode 100644 index 00000000000..af0b2416ccc --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.de.md @@ -0,0 +1,70 @@ +--- +title: Migration von Endpoints +description: Was passiert, wenn Sie vorhandene Endpoint-Daten zu Locations migrieren +audience: pro +weight: 3 +--- + +Wenn Sie Locations auf einer bestehenden DefectDojo-Pro-Instanz aktivieren, müssen die bereits als Endpoints gespeicherten Daten in das neue Locations-Modell übernommen werden. Diese Seite beschreibt die Migration, was dabei erhalten bleibt, und wie sich die veraltete Endpoint-API nach der Migration verhält. + +Beachten Sie, dass die Migration **einseitig** ist. Es gibt keinen automatisierten Rollback-Pfad, der Endpoints aus Locations wiederherstellt. + +## Was die Migration bewirkt + +Für jeden bestehenden Endpoint führt die Migration Folgendes durch: + +1. **Erstellt eine URL-Location** (oder verwendet eine bestehende weiter) anhand der Felder `protocol`, `userinfo`, `host`, `port`, `path`, `query` und `fragment` des Endpoints. Die neue URL wird automatisch einem übergeordneten `Location`-Objekt zugeordnet. +2. **Überträgt Tags.** Jeder Tag am Endpoint wird der Tag-Menge der Location hinzugefügt. +3. **Überträgt Metadaten.** Jede an den Endpoint angehängte `DojoMeta`-Zeile wird auf die neue Location umgeleitet. +4. **Erstellt eine `LocationProductReference`**, damit die URL unter dem richtigen Asset (Produkt) erscheint. +5. **Erstellt eine `LocationFindingReference` für jeden `Endpoint_Status`**: + + | Endpoint_Status-Flag | Resultierender Location-Status | + | --- | --- | + | `risk_accepted=True` | **Risiko akzeptiert** | + | `false_positive=True` | **Falsch-positiv** | + | `out_of_scope=True` | **Außerhalb des Geltungsbereichs** | + | `mitigated=True` | **Behoben** | + | (keine der oben genannten) | **Aktiv** | + + Die Zuordnung ist reihenfolgeabhängig: Das *erste* zutreffende Flag gewinnt. Dadurch werden die alten Mehrfach-Flag-Kombinationen bewusst auf den einen kanonischen Status reduziert, den Locations verwenden. + + +## Was die Migration nicht bewirkt + +- Sie erstellt **keine** Dependency-Locations. SBOM- und Bibliotheksdaten existierten nie als Endpoints, daher gibt es für die Migration nichts zu konvertieren. Um Dependencies zu befüllen, laden Sie SBOMs hoch (siehe [Working with SBOMs](../pro__working_with_sboms)) oder führen Sie Scans erneut mit Parsern aus, die Dependency-Daten liefern. +- Sie löscht **nicht** die ursprünglichen Endpoint- oder Endpoint_Status-Zeilen. Diese bleiben in der Datenbank erhalten, um die schreibgeschützte veraltete API zu unterstützen. Sie werden von der neuen Benutzeroberfläche oder von Imports nach Aktivierung des Features nicht mehr verwendet. + +## Endpoint-API nach der Migration + +Sobald Locations aktiviert ist, wechselt die veraltete Endpoint-API in einen **Lese-Kompatibilitätsmodus**, der bestehende Automatisierungen ohne Codeänderungen weiterlaufen lässt — allerdings nur für Lesezugriffe. + +### Was weiterhin funktioniert + +- `GET /api/v2/endpoints/` — Liefert Zeilen, die *wie* Endpoints aussehen, tatsächlich aber aus Location-Product-Reference-Zeilen in Verbindung mit URL-Locations projiziert werden. Die bekannten Felder (`protocol`, `host`, `port`, `path`, `query`, `fragment`, `tags`, `product`, `active_finding_count`) sind alle vorhanden. +- `GET /api/v2/endpoints/{id}/` — Der Abruf eines einzelnen Endpoints funktioniert auf dieselbe Weise. Die `id` ist die ursprüngliche Endpoint-ID und bleibt durch die Migration über das Asset-Reference-Mapping erhalten. +- `GET /api/v2/endpoint_status/` und `GET /api/v2/endpoint_status/{id}/` — Liefert Zeilen, die aus `LocationFindingReference` projiziert werden. Die veralteten booleschen Felder `mitigated`, `false_positive`, `out_of_scope` und `risk_accepted` werden rekonstruiert. +- Das Filtern nach `protocol`, `host`, `port`, `path`, `query`, `fragment`, `product` und `tag(s)` funktioniert weiterhin. +- Die Aktion `generate_report` für einzelne Endpoints funktioniert weiterhin. + +### Was 403 zurückgibt + +- `POST`, `PUT`, `PATCH` und `DELETE` auf `/api/v2/endpoints/` und `/api/v2/endpoint_status/` liefern alle `HTTP 403` mit folgendem Inhalt zurück: + + > Writes to this endpoint are deprecated when V3_FEATURE_LOCATIONS is enabled + + Clients, die Endpoint-Daten schreiben, müssen auf die neuen Reference-Endpunkte (`POST /api/v2/location_findings/`, `POST /api/v2/location_products/`) und auf den URL-Endpunkt (`POST /api/v2/urls/`) umsteigen. + +### Verhaltensunterschiede, auf die Sie achten sollten + +Einige Dinge verhalten sich anders als bei der ursprünglichen Endpoint-API: + +- **Ein einzelner Status statt Flags.** Locations haben jeweils nur einen Status. Wenn Ihr Code davon ausging, dass ein Befund bei einem Endpoint_Status gleichzeitig *sowohl* `mitigated=True` *als auch* `false_positive=True` sein kann, lässt sich das nicht mehr abbilden — die Migration wählt das Flag mit der höchsten Priorität (Reihenfolge siehe Tabelle oben). +- **Feld `endpoint` bei Endpoint_Status.** Das veraltete Feld `endpoint` wird durch Nachschlagen der passenden Asset Reference rekonstruiert. In seltenen Fällen, in denen das Asset eines Befunds nicht mehr mit den Asset-Referenzen seiner Location übereinstimmt, kann dieses Feld null sein. +- **Paginierung und Sortierung.** Verfügbare Sortierfelder im Lese-Kompatibilitäts-Shim sind `host`, `product`, `id` und `active_finding_count`. Wenn Ihr Client nach einem anderen Feld sortiert, wechseln Sie zu einem dieser Felder oder zu den neuen Locations-Endpunkten. + +## Tags und Metadaten + +Auf Endpoints angewendete Tags werden zu Tags am Location-Objekt (nicht am URL-Subtyp). Tag-basierte Filter in der veralteten API funktionieren weiterhin. + +Endpoint-Metadaten werden während der Migration auf die Location umgeleitet. Bestehende Automatisierungen, die Metadaten über `/api/v2/endpoint_meta/` lesen, sollten weiterhin funktionieren; neue Metadaten sollten über die Location-Endpunkte geschrieben werden. diff --git a/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.es.md b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.es.md new file mode 100644 index 00000000000..2253a84f229 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.es.md @@ -0,0 +1,70 @@ +--- +title: Migración desde Endpoints +description: Qué sucede cuando se migran los datos existentes de Endpoint a Locations +audience: pro +weight: 3 +--- + +Cuando habilita Locations en una instancia existente de DefectDojo Pro, los datos ya almacenados como Endpoints deben trasladarse al nuevo modelo de Locations. Esta página describe la migración, qué conserva y cómo se comporta la API heredada de Endpoint una vez ejecutada la migración. + +Tenga en cuenta que la migración es **unidireccional**. No existe una ruta de reversión automatizada que vuelva a crear Endpoints a partir de Locations. + +## Qué hace la migración + +Para cada Endpoint existente, la migración hará lo siguiente: + +1. **Crea una URL Location** (o reutiliza una existente) usando los campos `protocol`, `userinfo`, `host`, `port`, `path`, `query` y `fragment` del Endpoint. La nueva URL se adjunta automáticamente a un objeto `Location` padre. +2. **Traslada las etiquetas.** Cada etiqueta del Endpoint se añade al conjunto de etiquetas de la Location. +3. **Traslada los metadatos.** Cada fila `DojoMeta` adjunta al Endpoint se redirige hacia la nueva Location. +4. **Crea una `LocationProductReference`** para que la URL aparezca bajo el Asset (Product) correcto. +5. **Crea una `LocationFindingReference` para cada `Endpoint_Status`**: + + | Indicador de Endpoint_Status | Estado resultante de la Location | + | --- | --- | + | `risk_accepted=True` | **Riesgo aceptado** | + | `false_positive=True` | **Falso positivo** | + | `out_of_scope=True` | **Fuera de alcance** | + | `mitigated=True` | **Mitigado** | + | (ninguno de los anteriores) | **Activo** | + + El mapeo depende del orden: gana el *primer* indicador que coincida. Esto reduce intencionalmente las antiguas combinaciones de múltiples indicadores a un único estado canónico que usan las Locations. + + +## Qué no hace la migración + +- **No** crea Dependency Locations. Los datos de SBOM y de bibliotecas nunca existieron como Endpoints, por lo que no hay nada que la migración pueda convertir. Para poblar las Dependencies, cargue SBOMs (consulte [Working with SBOMs](../pro__working_with_sboms)) o vuelva a ejecutar los escaneos con parsers que generen datos de dependencias. +- **No** elimina las filas originales de Endpoint o Endpoint_Status. Permanecen en la base de datos para respaldar la API heredada de solo lectura. La nueva interfaz de usuario ni las importaciones las utilizan una vez habilitada la función. + +## API de Endpoint después de la migración + +Una vez habilitado Locations, la API heredada de Endpoint entra en un modo de **compatibilidad de lectura** diseñado para que las automatizaciones existentes sigan funcionando sin cambios de código, pero solo para el tráfico de lectura. + +### Qué sigue funcionando + +- `GET /api/v2/endpoints/` — Devuelve filas que *parecen* Endpoints, pero en realidad se proyectan a partir de filas de Location Product Reference combinadas con URL Locations. Los campos habituales (`protocol`, `host`, `port`, `path`, `query`, `fragment`, `tags`, `product`, `active_finding_count`) están todos presentes. +- `GET /api/v2/endpoints/{id}/` — La recuperación de un único Endpoint funciona de la misma manera. El `id` es el ID original del Endpoint y se conserva a través de la migración mediante el mapeo de Asset Reference. +- `GET /api/v2/endpoint_status/` y `GET /api/v2/endpoint_status/{id}/` — Devuelven filas proyectadas a partir de `LocationFindingReference`. Los campos booleanos heredados `mitigated`, `false_positive`, `out_of_scope` y `risk_accepted` se reconstruyen. +- El filtrado por `protocol`, `host`, `port`, `path`, `query`, `fragment`, `product` y `tag(s)` sigue funcionando. +- La acción `generate_report` en Endpoints individuales sigue funcionando. + +### Qué devuelve 403 + +- `POST`, `PUT`, `PATCH` y `DELETE` en `/api/v2/endpoints/` y `/api/v2/endpoint_status/` devuelven todos `HTTP 403` con el cuerpo: + + > Writes to this endpoint are deprecated when V3_FEATURE_LOCATIONS is enabled + + Los clientes que escriben datos de Endpoint deben migrar a los nuevos endpoints de Reference (`POST /api/v2/location_findings/`, `POST /api/v2/location_products/`) y al endpoint de URL (`POST /api/v2/urls/`). + +### Diferencias de comportamiento a tener en cuenta + +Algunas cosas se comportan de forma diferente respecto a la API original de Endpoint: + +- **Un único estado en lugar de indicadores.** Las Locations tienen un solo estado a la vez. Si su código dependía de que un Hallazgo fuera *a la vez* `mitigated=True` *y* `false_positive=True` simultáneamente en un Endpoint_Status, eso ya no se puede representar: la migración elige el indicador de mayor prioridad (el orden que se muestra en la tabla anterior). +- **Campo `endpoint` en Endpoint_Status.** El campo heredado `endpoint` se reconstruye buscando el Asset Reference correspondiente. En casos excepcionales en los que el Asset de un Hallazgo ya no coincide con los Asset References de su Location, este campo puede ser nulo. +- **Paginación y ordenación.** Los campos de ordenación disponibles en la capa de compatibilidad de lectura son `host`, `product`, `id` y `active_finding_count`. Si su cliente ordena por otro campo, cambie a uno de estos o migre a los nuevos endpoints de Locations. + +## Etiquetas y metadatos + +Las etiquetas aplicadas a los Endpoints se convierten en etiquetas del objeto Location (no del subtipo URL). Los filtros basados en etiquetas de la API heredada siguen coincidiendo. + +Los metadatos del Endpoint se redirigen hacia la Location durante la migración. Las automatizaciones existentes que leen metadatos a través de `/api/v2/endpoint_meta/` deberían seguir funcionando; los metadatos nuevos deben escribirse a través de los endpoints de Location. diff --git a/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.fr.md b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.fr.md new file mode 100644 index 00000000000..c9b676f5aff --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.fr.md @@ -0,0 +1,71 @@ +--- +title: Migration depuis les Points de terminaison +description: Ce qui se passe lorsque vous migrez des données de Points de terminaison + existantes vers les Emplacements +audience: pro +weight: 3 +--- + +Lorsque vous activez les Emplacements sur une instance DefectDojo Pro existante, les données déjà stockées sous forme de Points de terminaison doivent être reportées dans le nouveau modèle d'Emplacements. Cette page décrit la migration, ce qu'elle préserve, et comment se comporte l'API Endpoint héritée une fois la migration exécutée. + +Notez que la migration est **à sens unique**. Il n'existe aucun chemin de restauration automatisé qui recrée des Points de terminaison à partir des Emplacements. + +## Ce que fait la migration + +Pour chaque Point de terminaison existant, la migration va : + +1. **Créer un Emplacement URL** (ou réutiliser un existant) en utilisant les champs `protocol`, `userinfo`, `host`, `port`, `path`, `query` et `fragment` du Point de terminaison. La nouvelle URL est automatiquement rattachée à un objet `Location` parent. +2. **Reporter les étiquettes.** Chaque étiquette du Point de terminaison est ajoutée à l'ensemble d'étiquettes de l'Emplacement. +3. **Reporter les métadonnées.** Chaque ligne `DojoMeta` rattachée au Point de terminaison est repointée vers le nouvel Emplacement. +4. **Créer une `LocationProductReference`** afin que l'URL apparaisse sous le bon Actif (Produit). +5. **Créer une `LocationFindingReference` pour chaque `Endpoint_Status`** : + + | Indicateur Endpoint_Status | Statut d'Emplacement résultant | + | --- | --- | + | `risk_accepted=True` | **Risque accepté** | + | `false_positive=True` | **Faux positif** | + | `out_of_scope=True` | **Hors périmètre** | + | `mitigated=True` | **Atténué** | + | (aucun des cas ci-dessus) | **Actif** | + + Le mappage est sensible à l'ordre : le *premier* indicateur correspondant l'emporte. Cela réduit intentionnellement les anciennes combinaisons multi-indicateurs à l'unique statut canonique utilisé par les Emplacements. + + +## Ce que la migration ne fait pas + +- Elle ne crée **pas** d'Emplacements de dépendance. Les données de SBOM et de bibliothèques n'ont jamais existé sous forme de Points de terminaison ; il n'y a donc rien à convertir. Pour peupler les Dépendances, importez des SBOM (voir [Utilisation des SBOM](../pro__working_with_sboms)) ou relancez des analyses avec des parseurs qui produisent des données de dépendance. +- Elle ne supprime **pas** les lignes Endpoint ou Endpoint_Status d'origine. Elles restent dans la base de données pour alimenter l'API héritée en lecture seule. Elles ne sont pas utilisées par la nouvelle interface ni par les imports une fois la fonctionnalité activée. + +## API Endpoint après la migration + +Une fois les Emplacements activés, l'API Endpoint héritée passe dans un mode de **compatibilité en lecture** conçu pour que les automatisations existantes continuent de fonctionner sans modification de code — mais uniquement pour le trafic en lecture. + +### Ce qui fonctionne toujours + +- `GET /api/v2/endpoints/` — Renvoie des lignes qui *ressemblent* à des Points de terminaison mais qui sont en réalité projetées à partir de lignes Location Product Reference jointes à des Emplacements URL. Les champs familiers (`protocol`, `host`, `port`, `path`, `query`, `fragment`, `tags`, `product`, `active_finding_count`) sont tous présents. +- `GET /api/v2/endpoints/{id}/` — La récupération d'un Point de terminaison unique fonctionne de la même manière. L'`id` est l'identifiant Endpoint d'origine et est préservé pendant la migration via le mappage Asset Reference. +- `GET /api/v2/endpoint_status/` et `GET /api/v2/endpoint_status/{id}/` — Renvoient des lignes projetées à partir de `LocationFindingReference`. Les champs booléens hérités `mitigated`, `false_positive`, `out_of_scope` et `risk_accepted` sont reconstruits. +- Le filtrage par `protocol`, `host`, `port`, `path`, `query`, `fragment`, `product` et `tag(s)` continue de fonctionner. +- L'action `generate_report` sur les Points de terminaison individuels continue de fonctionner. + +### Ce qui renvoie 403 + +- `POST`, `PUT`, `PATCH` et `DELETE` sur `/api/v2/endpoints/` et `/api/v2/endpoint_status/` renvoient tous `HTTP 403` avec le corps suivant : + + > Writes to this endpoint are deprecated when V3_FEATURE_LOCATIONS is enabled + + Les clients qui écrivent des données Endpoint doivent migrer vers les nouveaux points de terminaison Reference (`POST /api/v2/location_findings/`, `POST /api/v2/location_products/`) et vers le point de terminaison URL (`POST /api/v2/urls/`). + +### Différences de comportement à surveiller + +Certains éléments se comportent différemment de l'API Endpoint d'origine : + +- **Un seul statut au lieu d'indicateurs.** Les Emplacements n'ont qu'un seul statut à la fois. Si votre code s'appuyait sur une Constatation étant *à la fois* `mitigated=True` *et* `false_positive=True` simultanément sur un Endpoint_Status, cela n'est plus représentable — la migration retient l'indicateur de priorité la plus élevée (l'ordre indiqué dans le tableau ci-dessus). +- **Champ `endpoint` sur Endpoint_Status.** Le champ hérité `endpoint` est reconstruit en recherchant l'Asset Reference correspondante. Dans de rares cas où l'Actif d'une Constatation ne correspond plus aux références d'Actif de son Emplacement, ce champ peut être nul. +- **Pagination et tri.** Les champs de tri disponibles sur la couche de compatibilité en lecture sont `host`, `product`, `id` et `active_finding_count`. Si votre client trie sur un autre champ, passez à l'un de ceux-ci ou migrez vers les nouveaux points de terminaison Emplacements. + +## Étiquettes et métadonnées + +Les étiquettes appliquées aux Points de terminaison deviennent des étiquettes sur l'objet Emplacement (et non sur le sous-type URL). Les filtres basés sur les étiquettes dans l'API héritée continuent de fonctionner. + +Les métadonnées des Points de terminaison sont repointées vers l'Emplacement pendant la migration. Les automatisations existantes qui lisent les métadonnées via `/api/v2/endpoint_meta/` devraient continuer de fonctionner ; les nouvelles métadonnées doivent être écrites via les points de terminaison Emplacements. diff --git a/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.ja.md b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.ja.md new file mode 100644 index 00000000000..d515659135f --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.ja.md @@ -0,0 +1,70 @@ +--- +title: エンドポイントからの移行 +description: 既存のエンドポイントデータをロケーションに移行するとどうなるか +audience: pro +weight: 3 +--- + +既存のDefectDojo Proインスタンスでロケーションを有効にすると、すでにエンドポイントとして保存されているデータを新しいロケーションモデルに引き継ぐ必要があります。このページでは、移行の内容、保持される情報、そして移行実行後にレガシーエンドポイントAPIがどのように動作するかについて説明します。 + +移行は**一方向**である点に注意してください。ロケーションからエンドポイントを再作成する自動ロールバック手段はありません。 + +## 移行が行うこと + +既存の各エンドポイントに対して、移行では以下が行われます。 + +1. エンドポイントの `protocol`、`userinfo`、`host`、`port`、`path`、`query`、`fragment` の各フィールドを使用して**URLロケーションを作成**(または既存のものを再利用)します。新しいURLは自動的に親の `Location` オブジェクトに紐付けられます。 +2. **タグを引き継ぎます。** エンドポイントに付与されているすべてのタグが、ロケーションのタグセットに追加されます。 +3. **メタデータを引き継ぎます。** エンドポイントに紐付いている各 `DojoMeta` 行は、新しいロケーションを指すように再設定されます。 +4. URLが正しいアセット(製品)の下に表示されるよう、**`LocationProductReference` を作成**します。 +5. **`Endpoint_Status` ごとに `LocationFindingReference` を作成**します。 + + | Endpoint_Status フラグ | 結果として得られるロケーションステータス | + | --- | --- | + | `risk_accepted=True` | **リスク受容済み** | + | `false_positive=True` | **誤検知** | + | `out_of_scope=True` | **対象外** | + | `mitigated=True` | **緩和済み** | + | (上記のいずれにも該当しない場合) | **アクティブ** | + + このマッピングは順序に依存します。*最初に*一致したフラグが優先されます。これは、従来の複数フラグの組み合わせを、ロケーションが使用する単一の正規ステータスに意図的に集約するためです。 + + +## 移行が行わないこと + +- 依存関係ロケーションを作成することは**ありません**。SBOMおよびライブラリデータはこれまでエンドポイントとして存在したことがないため、移行が変換すべき対象がありません。依存関係を取り込むには、SBOMをアップロードするか([SBOMの利用](../pro__working_with_sboms)を参照)、依存関係データを出力するパーサーでスキャンを再実行してください。 +- 元のエンドポイントおよびEndpoint_Statusの行を削除することも**ありません**。これらはデータベースに残り、読み取り専用のレガシーAPIを支えます。この機能が有効になった後は、新しいUIやインポート処理では使用されません。 + +## 移行後のエンドポイントAPI + +ロケーションが有効になると、レガシーエンドポイントAPIは**読み取り互換**モードに入ります。これは、コードを変更することなく既存の自動化を動作させ続けるために設計されていますが、対象は読み取りトラフィックのみです。 + +### 引き続き動作するもの + +- `GET /api/v2/endpoints/` — エンドポイントの*ように見える*行を返しますが、実際にはURLロケーションと結合したLocation Product Referenceの行から投影されたものです。おなじみのフィールド(`protocol`、`host`、`port`、`path`、`query`、`fragment`、`tags`、`product`、`active_finding_count`)はすべて存在します。 +- `GET /api/v2/endpoints/{id}/` — 単一エンドポイントの取得も同様に動作します。`id` は元のエンドポイントIDであり、Asset Referenceのマッピングを通じて移行後も保持されます。 +- `GET /api/v2/endpoint_status/` および `GET /api/v2/endpoint_status/{id}/` — `LocationFindingReference` から投影された行を返します。レガシーの `mitigated`、`false_positive`、`out_of_scope`、`risk_accepted` の各ブールフィールドが再構築されます。 +- `protocol`、`host`、`port`、`path`、`query`、`fragment`、`product`、`tag(s)` によるフィルタリングは引き続き機能します。 +- 個々のエンドポイントに対する `generate_report` アクションは引き続き機能します。 + +### 403が返されるもの + +- `/api/v2/endpoints/` および `/api/v2/endpoint_status/` に対する `POST`、`PUT`、`PATCH`、`DELETE` は、すべて次の本文とともに `HTTP 403` を返します。 + + > Writes to this endpoint are deprecated when V3_FEATURE_LOCATIONS is enabled + + エンドポイントデータを書き込むクライアントは、新しいReferenceエンドポイント(`POST /api/v2/location_findings/`、`POST /api/v2/location_products/`)およびURLエンドポイント(`POST /api/v2/urls/`)に移行する必要があります。 + +### 注意すべき挙動の違い + +元のエンドポイントAPIとはいくつかの点で動作が異なります。 + +- **フラグではなく単一ステータス。** ロケーションは一度に1つのステータスしか持ちません。検出事項がEndpoint_Status上で `mitigated=True` と `false_positive=True` を*同時に*持つことに依存したコードがある場合、それはもはや表現できません。移行では、優先度が最も高いフラグ(上記の表に示した順序)が選択されます。 +- **Endpoint_Statusの `endpoint` フィールド。** レガシーの `endpoint` フィールドは、一致するAsset Referenceを検索することで再構築されます。まれに検出事項のアセットがそのロケーションのAsset Referenceと一致しなくなっている場合、このフィールドはnullになることがあります。 +- **ページネーションと並べ替え。** 読み取り互換シムで利用可能な並べ替えフィールドは `host`、`product`、`id`、`active_finding_count` です。クライアントが他のフィールドで並べ替えを行っている場合は、これらのいずれかに切り替えるか、新しいロケーションエンドポイントに移行してください。 + +## タグとメタデータ + +エンドポイントに付与されたタグは、(URLサブタイプではなく)ロケーションオブジェクトのタグになります。レガシーAPIにおけるタグベースのフィルタは引き続き一致します。 + +エンドポイントのメタデータは、移行時にロケーションを指すように再設定されます。`/api/v2/endpoint_meta/` 経由でメタデータを読み取る既存の自動化は引き続き動作するはずです。新しいメタデータは、ロケーションエンドポイントを通じて書き込んでください。 diff --git a/docs/content/asset_modelling/locations/PRO__source_code_locations.de.md b/docs/content/asset_modelling/locations/PRO__source_code_locations.de.md new file mode 100644 index 00000000000..47cafe9d8ea --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__source_code_locations.de.md @@ -0,0 +1,46 @@ +--- +title: Quellcode-Locations +description: Code-Locations modellieren, wo sich ein Befund einer statischen Analyse + im Quellcode befindet, und zeichnen dessen Bewegungsverlauf im Zuge der Codeentwicklung + auf +weight: 6 +audience: pro +--- + +**Source Code Locations** erweitern das Locations-Modell auf die statische Analyse: Neben URLs (DAST) und Dependencies (SCA) beschreibt eine **Code**-Location, wo ein SAST-Befund im Quellcode liegt — identifiziert anhand von **Dateipfad und Zeilennummer**. + +> Quellcode-Locations erfordern das Feature Locations (Beta). Um Locations auf Ihrer Instanz zu aktivieren, wenden Sie sich an [support@defectdojo.com](mailto:support@defectdojo.com). + +## Was sie modellieren + +Jeder statische Befund, der einen Dateipfad meldet, erhält eine Code-Location. Der kanonische Wert der Location ist `path/to/file.py:42` (oder nur der Dateipfad, wenn das Tool keine Zeile meldet). Wie alle Locations sind Code-Locations gemeinsam genutzte Objekte: Zwei Befunde an derselben Datei und Zeile verweisen auf dieselbe Location, die pro Befund und pro Asset jeweils eigene Referenzstatus führt. + +Code-Locations werden **scan-verwaltet**: Sie werden durch Imports und Reimports erstellt und aktualisiert, nicht manuell. Es gibt keine Aktion „Neue Source Code Location" — der Scanner ist die maßgebliche Quelle dafür, wo Code-Befunde liegen. + +## Wo Sie sie finden + +- **All Source Code** in der Seitenleiste listet jede Code-Location der Instanz auf, mit denselben Filter- und Tagging-Möglichkeiten wie bei URLs und Dependencies. +- **View Source Code** im Locations-Menü eines Assets grenzt die Liste auf ein einzelnes Asset ein. +- Die Seite eines Befunds zeigt seine aktuelle Code-Location und, wenn sich der Befund verschoben hat, seinen **Location-Verlauf**. + +## Verschiebungsverlauf + +Quellcode ändert sich ständig: Commits verschieben Zeilennummern, Refactorings benennen Dateien um. Wenn [Location Drift Matching](/triage_findings/finding_deduplication/pro__location_drift_matching/) für ein Tool aktiviert ist, behält ein Befund, der sich verschiebt, seine Identität, und seine Code-Location-Referenzen zeichnen den Verlauf auf: + +- Die Referenz des Befunds auf die **alte** Location erhält den Status **Behoben** und wird mit Angaben dazu versehen, *wohin sich der Befund verschoben hat* und *warum die Zuordnung getroffen wurde* (nächstgelegene Zeile, Datenfluss, Dateiumbenennung ...). +- Eine Referenz auf die **neue** Location wird erstellt und bleibt aktiv. + +Das Ergebnis ist eine durchsuchbare Ablösekette — „dieser Befund lag bei `auth.py:42`, dann bei `auth.py:57`, dann bei `session.py:31`" — dargestellt als Zeitleiste auf der Befundseite. Derselbe Verlaufsmechanismus deckt auch URL-Verschiebungen und Versionssprünge bei Dependencies ab, sodass sich alle drei Location-Typen eine gemeinsame Zeitleisten-Oberfläche teilen. + +Der Verlauf wird ab dem Zeitpunkt erfasst, an dem Locations auf der Instanz aktiviert wird. Befunde, die sich davor verschoben haben, behalten ihre aktuelle Location; frühere Sprünge wurden angewendet, aber nicht aufgezeichnet. Für Instanzen mit jahrelanger Historie vor Einführung des Features kann der [Befehl zur Konsolidierung von Churn](/triage_findings/finding_deduplication/pro__location_drift_matching/#consolidating-historical-churn) Verläufe rekonstruieren und dabei historische Schließen-und-Neuanlegen-Ketten zusammenführen. + +## Statuskorrektheit + +Die Referenzstatus von Code-Locations werden bei **jedem** Abgleichsalgorithmus durch Reimport korrekt gehalten, unabhängig davon, ob Drift Matching aktiviert ist: + +- Die aktuelle Code-Referenz eines abgeglichenen Befunds wird bei jedem Reimport synchronisiert, sodass ein verschobener Befund seine alte Referenz nicht dauerhaft aktiv hinterlässt. +- Dieselbe von der Einstellung unabhängige Synchronisierung gilt für Dependency-Referenzen: Wenn sich die Paketversion eines SCA-Befunds ändert, wird die Referenz der alten Version auf Behoben gesetzt, anstatt neben der neuen weiterhin aktiv zu bleiben. + +## Zusammenhang mit Befundfeldern + +Die eigenen Felder `file_path` / `line` des Befunds bleiben die maßgeblichen Skalarwerte (sie sind es, was Filter, Hashes und die API offenlegen); die Code-Location ist die gemeinsam genutzte, referenzgezählte Sicht auf dieselbe Koordinate. Der Reimport aktualisiert die Skalarwerte anhand des neuesten Scans, und die Location-Logik leitet die Locations daraus ab — die beiden können nicht auseinanderdriften. diff --git a/docs/content/asset_modelling/locations/PRO__source_code_locations.es.md b/docs/content/asset_modelling/locations/PRO__source_code_locations.es.md new file mode 100644 index 00000000000..b9fe92ac182 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__source_code_locations.es.md @@ -0,0 +1,46 @@ +--- +title: Ubicaciones de código fuente +description: Las ubicaciones de código modelan dónde vive en el código fuente un hallazgo + de análisis estático, y registran su historial de movimiento a medida que el código + evoluciona +weight: 6 +audience: pro +--- + +Las **Source Code Locations** amplían el modelo de Locations al análisis estático: junto con las URLs (DAST) y las Dependencies (SCA), una ubicación de tipo **Code** describe dónde vive en el código fuente un hallazgo SAST, identificada por su **ruta de archivo y número de línea**. + +> Source Code Locations requiere la función Locations (Beta). Para habilitar Locations en su instancia, comuníquese con [support@defectdojo.com](mailto:support@defectdojo.com). + +## Qué modelan + +Todo hallazgo estático que reporte una ruta de archivo obtiene una ubicación de tipo Code. El valor canónico de la ubicación es `path/to/file.py:42` (o solo la ruta del archivo cuando la herramienta no reporta una línea). Como todas las Locations, las ubicaciones de código son objetos compartidos: dos Hallazgos en el mismo archivo y línea hacen referencia a la misma ubicación, y esta lleva estados de referencia por Hallazgo y por Asset. + +Las ubicaciones de código están **gestionadas por el escaneo**: se crean y actualizan mediante importaciones y reimportaciones, no manualmente. No existe una acción "New Source Code Location": el escáner es la fuente de verdad de dónde viven los Hallazgos de código. + +## Dónde encontrarlas + +- **All Source Code** en la barra lateral enumera todas las ubicaciones de código de la instancia, con el mismo filtrado y etiquetado que las URLs y las Dependencies. +- **View Source Code** en el menú de Locations de un Asset limita la lista a ese Asset. +- La página de un Hallazgo muestra su ubicación de código actual y, cuando el Hallazgo se ha movido, su **historial de ubicación**. + +## Historial de movimiento + +El código fuente se mueve constantemente: los commits desplazan los números de línea, las refactorizaciones renombran archivos. Cuando [Location Drift Matching](/triage_findings/finding_deduplication/pro__location_drift_matching/) está habilitado para una herramienta, un Hallazgo que se mueve conserva su identidad, y sus referencias de ubicación de código registran el rastro: + +- La referencia del Hallazgo a la ubicación **anterior** se mitiga y se marca con *a dónde se movió el Hallazgo* y *por qué se hizo la coincidencia* (línea más cercana, flujo de datos, cambio de nombre de archivo...). +- Se crea una referencia a la **nueva** ubicación, que permanece activa. + +El resultado es una cadena de sustitución navegable — "este Hallazgo vivía en `auth.py:42`, luego en `auth.py:57`, luego en `session.py:31`" — que se representa como una línea de tiempo en la página del Hallazgo. El mismo mecanismo de historial cubre los movimientos de URL y los incrementos de versión de dependencias, de modo que los tres tipos de ubicación comparten una única interfaz de línea de tiempo. + +El historial se registra desde el momento en que Locations se habilita en la instancia. Los Hallazgos que se movieron antes de ese momento conservan su ubicación actual: los saltos pasados se aplicaron pero no se registraron. Para instancias con años de historial previo a la función, el [comando de consolidación de churn](/triage_findings/finding_deduplication/pro__location_drift_matching/#consolidating-historical-churn) puede reconstruir los rastros mientras fusiona las antiguas cadenas de cierre y recreación. + +## Corrección de estados + +Los estados de referencia de las ubicaciones de código se mantienen fieles a la realidad mediante la reimportación en **todos** los algoritmos de coincidencia, esté o no habilitado el drift matching: + +- La referencia de código actual de un Hallazgo coincidente se sincroniza en cada reimportación, de modo que un Hallazgo que se movió no deja su referencia anterior activa para siempre. +- La misma sincronización, independiente del interruptor de la función, se aplica a las referencias de dependencias: cuando la versión del paquete de un Hallazgo de SCA cambia, la referencia de la versión anterior se mitiga en lugar de permanecer activa junto a la nueva. + +## Relación con los campos del Hallazgo + +Los propios campos `file_path` / `line` del Hallazgo siguen siendo los valores escalares autorizados (son los que exponen los filtros, los hashes y la API); la Code Location es la vista compartida y con conteo de referencias de esa misma coordenada. La reimportación actualiza los valores escalares a partir del último escaneo y el mecanismo de ubicaciones deriva las ubicaciones a partir de ellos: los dos no pueden desalinearse. diff --git a/docs/content/asset_modelling/locations/PRO__source_code_locations.fr.md b/docs/content/asset_modelling/locations/PRO__source_code_locations.fr.md new file mode 100644 index 00000000000..ac6937c182a --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__source_code_locations.fr.md @@ -0,0 +1,46 @@ +--- +title: Emplacements de code source +description: Les emplacements de code modélisent l'endroit où vit une constatation + d'analyse statique dans le code source, et enregistrent son historique de déplacement + à mesure que le code évolue +weight: 6 +audience: pro +--- + +**Les Emplacements de code source** étendent le modèle d'Emplacements à l'analyse statique : aux côtés des URL (DAST) et des Dépendances (SCA), un emplacement de type **Code** décrit où vit une constatation SAST dans le code source — identifiée par son **chemin de fichier et son numéro de ligne**. + +> Les Emplacements de code source nécessitent la fonctionnalité Emplacements (Bêta). Pour activer les Emplacements sur votre instance, contactez [support@defectdojo.com](mailto:support@defectdojo.com). + +## Ce qu'ils modélisent + +Chaque constatation statique qui signale un chemin de fichier obtient un emplacement de type Code. La valeur canonique de l'emplacement est `path/to/file.py:42` (ou simplement le chemin de fichier lorsque l'outil ne signale aucune ligne). Comme tous les Emplacements, les emplacements de code sont des objets partagés : deux constatations situées au même fichier et à la même ligne référencent le même emplacement, et l'emplacement porte des statuts de référence par constatation et par actif. + +Les emplacements de code sont **gérés par les analyses** : ils sont créés et mis à jour par les imports et réimports, pas manuellement. Il n'existe pas d'action « Nouvel emplacement de code source » — le scanner fait autorité quant à l'endroit où vivent les constatations de code. + +## Où les trouver + +- **Tout le code source** dans la barre latérale répertorie chaque emplacement de code de l'instance, avec le même filtrage et le même étiquetage que les URL et les Dépendances. +- **Afficher le code source** dans le menu Emplacements d'un Actif restreint la liste à cet actif. +- La page d'une constatation affiche son emplacement de code actuel et, lorsque la constatation a été déplacée, son **historique d'emplacement**. + +## Historique de déplacement + +Le code source se déplace en permanence : les commits décalent les numéros de ligne, les refactorisations renomment les fichiers. Lorsque le [Rapprochement par dérive d'emplacement](/triage_findings/finding_deduplication/pro__location_drift_matching/) est activé pour un outil, une constatation qui se déplace conserve son identité, et ses références d'emplacement de code enregistrent la trace : + +- La référence de la constatation vers l'**ancien** emplacement est marquée comme atténuée et estampillée avec *où la constatation s'est déplacée* et *pourquoi la correspondance a été établie* (ligne la plus proche, flux de données, renommage de fichier...). +- Une référence vers le **nouvel** emplacement est créée et reste active. + +Le résultat est une chaîne de succession consultable — « cette constatation vivait à `auth.py:42`, puis à `auth.py:57`, puis à `session.py:31` » — représentée sous forme de chronologie sur la page de la constatation. Le même mécanisme d'historique couvre les déplacements d'URL et les montées de version de dépendances, de sorte que les trois types d'emplacements partagent une seule interface de chronologie. + +L'historique est enregistré à partir du moment où les Emplacements sont activés sur l'instance. Les constatations qui se sont déplacées avant cela conservent leur emplacement actuel ; les déplacements passés ont été appliqués mais non enregistrés. Pour les instances disposant de plusieurs années d'historique antérieur à la fonctionnalité, la [commande de consolidation du churn](/triage_findings/finding_deduplication/pro__location_drift_matching/#consolidating-historical-churn) peut reconstituer les traces tout en fusionnant les anciennes chaînes de fermeture-recréation. + +## Exactitude des statuts + +Les statuts de référence des emplacements de code sont maintenus exacts par le réimport, quel que soit l'algorithme de correspondance utilisé, que le rapprochement par dérive soit activé ou non : + +- La référence de code actuelle d'une constatation appariée est synchronisée à chaque réimport, de sorte qu'une constatation déplacée ne laisse pas son ancienne référence active indéfiniment. +- La même synchronisation, indépendante de ce réglage, s'applique aux références de dépendance : lorsque la version du paquet d'une constatation SCA change, la référence de l'ancienne version est atténuée plutôt que de rester active aux côtés de la nouvelle. + +## Relation avec les champs de la constatation + +Les propres champs `file_path` / `line` de la constatation restent les valeurs scalaires faisant autorité (ce sont elles qu'exposent les filtres, les hachages et l'API) ; l'emplacement de code est la vue partagée et comptabilisée par référence de cette même coordonnée. Le réimport actualise les scalaires à partir de la dernière analyse, et le mécanisme d'emplacement en dérive les emplacements — les deux ne peuvent pas diverger. diff --git a/docs/content/asset_modelling/locations/PRO__source_code_locations.ja.md b/docs/content/asset_modelling/locations/PRO__source_code_locations.ja.md new file mode 100644 index 00000000000..cd7ab0c9f49 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__source_code_locations.ja.md @@ -0,0 +1,44 @@ +--- +title: ソースコードロケーション +description: コードロケーションは静的解析の検出事項がソースコード内のどこに存在するかをモデル化し、コードの変化に伴う移動履歴を記録します +weight: 6 +audience: pro +--- + +**ソースコードロケーション**は、ロケーションモデルを静的解析にまで拡張します。URL(DAST)や依存関係(SCA)と並んで、**コード**ロケーションは、SASTの検出事項がソースコード内のどこに存在するかを**ファイルパスと行番号**によって示します。 + +> ソースコードロケーションを利用するには、ロケーション機能(ベータ版)が必要です。お使いのインスタンスでロケーションを有効にするには、[support@defectdojo.com](mailto:support@defectdojo.com) までご連絡ください。 + +## モデル化する対象 + +ファイルパスを報告するすべての静的解析の検出事項には、コードロケーションが割り当てられます。ロケーションの正規値は `path/to/file.py:42` です(ツールが行番号を報告しない場合はファイルパスのみになります)。他のすべてのロケーションと同様、コードロケーションは共有オブジェクトです。同じファイル・行にある2つの検出事項は同じロケーションを参照し、そのロケーションは検出事項ごと・アセットごとの参照ステータスを保持します。 + +コードロケーションは**スキャン管理**されます。手動ではなく、インポートおよび再インポートによって作成・更新されます。「新しいソースコードロケーション」という操作は存在しません。コードの検出事項がどこに存在するかについては、スキャナーが唯一の正しい情報源です。 + +## 確認できる場所 + +- サイドバーの**すべてのソースコード**には、インスタンス内のすべてのコードロケーションが、URLや依存関係と同じフィルタリングおよびタグ付け機能とともに一覧表示されます。 +- アセットのロケーションメニューにある**ソースコードを表示**を使うと、一覧を1つのアセットに絞り込めます。 +- 検出事項のページには、現在のコードロケーションと、検出事項が移動している場合はその**ロケーション履歴**が表示されます。 + +## 移動履歴 + +ソースコードは絶えず変化します。コミットによって行番号がずれ、リファクタリングによってファイル名が変わります。あるツールで[ロケーションドリフトマッチング](/triage_findings/finding_deduplication/pro__location_drift_matching/)が有効になっている場合、移動した検出事項もその同一性を保持し、コードロケーションの参照がその経路を記録します。 + +- 検出事項の**旧**ロケーションへの参照は緩和済みとなり、*検出事項がどこへ移動したか*と*なぜその対応付けが行われたか*(最も近い行、データフロー、ファイル名変更など)が記録されます。 +- **新しい**ロケーションへの参照が作成され、アクティブなまま維持されます。 + +その結果、閲覧可能な履歴の連鎖ができあがります。「この検出事項は `auth.py:42` にあり、次に `auth.py:57`、そして `session.py:31` に移った」といった具合に、検出事項のページ上でタイムラインとして表示されます。同じ履歴の仕組みはURLの移動や依存関係のバージョンアップにも及ぶため、3種類すべてのロケーションが1つのタイムラインUIを共有します。 + +履歴は、インスタンスでロケーションが有効化された時点から記録されます。それ以前に移動した検出事項は現在のロケーションを保持しますが、過去の移動は適用されただけで記録はされていません。この機能が導入される前の履歴が何年分もあるインスタンスでは、[チャーン統合コマンド](/triage_findings/finding_deduplication/pro__location_drift_matching/#consolidating-historical-churn)を使うことで、過去のクローズ・再作成の連鎖を統合しながら経路を再構築できます。 + +## ステータスの正確性 + +コードロケーション参照のステータスは、ドリフトマッチングの有効・無効にかかわらず、**すべての**マッチングアルゴリズムにおいて再インポート時に正しく保たれます。 + +- マッチした検出事項の現在のコード参照は、再インポートのたびに同期されるため、移動した検出事項の旧参照が永久にアクティブなまま残ることはありません。 +- 同じくトグルに依存しない同期は、依存関係の参照にも適用されます。SCAの検出事項のパッケージバージョンが上がった場合、旧バージョンの参照は新しいバージョンと並んでアクティブなまま残るのではなく、緩和済みになります。 + +## 検出事項フィールドとの関係 + +検出事項自体が持つ `file_path` / `line` フィールドは、引き続き正となるスカラー値です(フィルタ、ハッシュ、APIが公開するのはこれらです)。コードロケーションは、その同じ座標を共有し参照カウントする形で表現したものです。再インポートは最新のスキャンからスカラー値を更新し、ロケーションの仕組みはそこからロケーションを導出するため、両者がずれることはありません。 diff --git a/docs/content/asset_modelling/locations/PRO__working_with_sboms.de.md b/docs/content/asset_modelling/locations/PRO__working_with_sboms.de.md new file mode 100644 index 00000000000..a81aa4a9e7c --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_sboms.de.md @@ -0,0 +1,107 @@ +--- +title: Arbeiten mit SBOMs +description: Software-Abhängigkeiten und SBOMs als Locations verwalten +audience: pro +weight: 5 +--- + +DefectDojo Pro modelliert Software-Bibliotheken als **Dependency-Locations**. Eine Dependency ist ein Location-Subtyp, der durch eine [Package URL (pURL)](https://github.com/package-url/purl-spec) identifiziert wird und ein einzelnes Bibliotheks- oder Paket-Objekt darstellen soll — `org.apache.logging.log4j:log4j-core@2.17.0`, `pypi/django@5.0.2`, `npm/react@18.2.0` und so weiter. + +Dependencies ersetzen das bisherige **Components**-Modell, das nur an Befunde angehängt war. Mit Locations können Bibliotheken unabhängig von einer Schwachstelle existieren — Sie können ein SBOM zu einem Asset hochladen und Befunde dann automatisch an die Dependencies anhängen lassen, auf die sie sich beziehen, sobald Scans eintreffen. + +## Was eine Dependency enthält + +Jede Dependency wird eindeutig durch eine pURL identifiziert, die in atomare Felder zerlegt wird, nach denen Sie suchen und filtern können: + +| Feld | Bedeutung | Beispiel | +| --- | --- | --- | +| `purl_type` | Bibliotheks-Ökosystem | `npm`, `pypi`, `maven`, `cargo`, `nuget`, `gem` | +| `namespace` | Anbieter oder Organisation | `org.apache.logging` | +| `name` | Bibliotheksname | `log4j-core` | +| `version` | Konkrete Version | `2.17.0` | +| `qualifiers` *(optional)* | Implementierungsdetails | `arch=amd64` | +| `subpath` *(optional)* | Pfad innerhalb eines Archivs oder Monorepos | `src/lib/foo` | +| `artifact_hashes` *(optional)* | Fingerabdrücke | SHA256-Summen | +| `license_expression` *(optional)* | SPDX-Lizenzausdruck | `Apache-2.0`, `MIT` | +| `file_path` *(optional)* | Wo die Bibliothek im Projekt gefunden wurde | `package-lock.json` | + +Diese atomare Zerlegung macht die pURL-basierte Suche nützlich: Sie können fragen *„alle `pypi`-Pakete im Namespace `django` in Version 4.x"*, und DefectDojo kann das beantworten, ohne eine Freitext-Zeichenkette zu parsen. + +## Owned-By vs. Used-By + +Wenn eine Dependency mit einem Asset verknüpft ist, trägt die Asset Reference eine optionale **Beziehung**, die beschreibt, *wie* die Bibliothek zum Asset gehört: + +- **`owned_by`** — *„diese Bibliothek gehört zu diesem Asset"*. Verwenden Sie dies für Eigenentwicklungen (First-Party-Bibliotheken), die ein Asset veröffentlicht oder pflegt. +- **`used_by`** — *„diese Bibliothek wird von diesem Asset verwendet"*. Verwenden Sie dies für Drittanbieter-Abhängigkeiten, die ein Asset nutzt. + +Dieselbe Bibliothek kann für ein Asset `owned_by` und für mehrere andere `used_by` sein — genau die Beziehung, die Sie benötigen, um bei der Schwachstellen-Triage die Frage *„wer nutzt das Paket, das mein Team veröffentlicht?"* zu beantworten. + +## Hochladen eines SBOMs + +Um Dependencies in großem Umfang zu befüllen, laden Sie eine SBOM-Datei zu einem Produkt hoch. Der Endpunkt lautet: + +``` +POST /api/v2/sbom-import/ +``` + +| Feld | Beschreibung | +| --- | --- | +| `product` | Die ID des Ziel-Produkts (Asset) | +| `file` | Die SBOM-Datei | +| `scan_type` | Das SBOM-Format — siehe unterstützte Formate unten | +| `replace` *(optional)* | Wenn `true`, werden veraltete Produkt-Zuordnungen ohne bestehende Finding-Referenz entfernt. Standard: `false` (kumulativ) | + +Der Importer parst die Datei, extrahiert `Dependency`-Datensätze, dedupliziert sie gegen bestehende Locations (bei Bedarf werden neue erstellt) und erstellt Asset References, die jede Dependency mit dem Produkt verknüpfen. Die Pro-Benutzeroberfläche bietet denselben Upload-Ablauf — siehe die Aktion **Upload SBOM** im Locations-Tab eines Produkts. + +### Unterstützte Formate + +Das MVP enthält Parser für die beiden dominanten SBOM-Formate: + +- **CycloneDX** — JSON und XML +- **SPDX** — JSON (v2 und v3), XML und Tag-Value + +Das SWID-Tag-Format wird noch nicht unterstützt. + +### Replace vs. Append + +Standardmäßig sind wiederholte Uploads **additiv**: Dependencies, die auf dem Asset bereits vorhanden sind, bleiben erhalten, neue werden hinzugefügt, und nichts wird entfernt. Das entspricht dem typischen Workflow für inkrementelle SBOM-Aktualisierungen. + +Setzen Sie `replace=true`, um zu bereinigen. Ist der Replace-Modus aktiv, entfernt der Importer nach einem erfolgreichen Import Produkt-Zuordnungen, die im neuen SBOM nicht enthalten waren **und** aktuell nicht von einem aktiven Befund referenziert werden. Referenzen, die mit aktiven Befunden verknüpft sind, bleiben auch im Replace-Modus erhalten, sodass Sie den Schwachstellenkontext nicht verlieren, nur weil ein neues SBOM ein Paket auslässt. + +## Befunde, die auf Bibliotheken verweisen + +Wenn ein Parser eine an eine Bibliothek gebundene Schwachstelle einliest — zum Beispiel ein SCA-Tool, das `CVE-2021-44228` gegen `log4j-core@2.14.1` meldet —, führt der Importer Folgendes aus: + +1. Sucht anhand der pURL nach einer bestehenden Dependency-Location oder erstellt eine neue. +2. Erstellt eine `LocationFindingReference`, die den Befund mit dem Status **Aktiv** mit der Dependency verknüpft. +3. Erstellt eine `LocationProductReference`, damit die Dependency auch beim übergeordneten Produkt erscheint, falls noch nicht geschehen. + +Da Befunde und SBOM-Uploads dieselben zugrunde liegenden Dependency-Objekte gemeinsam nutzen, wird ein Befund, der *vor* einem SBOM-Upload eingelesen wurde, rückwirkend in der SBOM-Ansicht sichtbar, und umgekehrt. + +## REST-API + +| Aufgabe | Endpunkt | +| --- | --- | +| Ein SBOM hochladen | `POST /api/v2/sbom-import/` | +| Dependencies auflisten | `GET /api/v2/dependencies/` | +| Eine Dependency manuell erstellen | `POST /api/v2/dependencies/` | +| Dependency-Locations auflisten | `GET /api/v2/location/?location_type=dependency` | +| Eine Dependency mit einem Befund verknüpfen | `POST /api/v2/location_findings/` | +| Eine Dependency mit einem Produkt verknüpfen (mit `owned_by` / `used_by`) | `POST /api/v2/location_products/` | + +Filter für `/api/v2/dependencies/` umfassen die pURL-Komponentenfelder, Tags sowie die Sortierung nach `name`, `version` und der Anzahl aktiver Befunde. + +## In der Pro-Benutzeroberfläche + +Wenn Locations aktiviert ist, bietet die Navigation: + +- **Locations / Dependencies** — Globale Liste aller Dependencies der Instanz, mit pURL-Filtern. +- **Locations on a Product/Asset** — Asset-bezogene Ansicht, die sowohl URLs als auch Dependencies zeigt, mit der Aktion **Upload SBOM** im Dependencies-Tab. +- **New Dependency** — Formular zum Erstellen einer einzelnen Bibliothek durch manuelle Eingabe ihrer pURL-Komponenten. +- **Findings detail** — Ein Befund, der eine Bibliothek betrifft, zeigt seine Dependency-Locations zusammen mit etwaigen URL-Locations, sodass Sie an einer Stelle sehen können: *„diese CVE betrifft `log4j-core@2.14.1` bei Asset 6 und Asset 9"*. + +## Was nicht im MVP enthalten ist + +- **SWID-Tag-SBOM-Format** — Wird nicht geparst. CycloneDX oder SPDX ist erforderlich. +- **Lizenzrisiko-Bewertung** — Das Feld `license_expression` wird erfasst, sofern es im SBOM vorhanden ist, aber DefectDojo kennzeichnet Befunde noch nicht bei Lizenzinkompatibilität. Lizenzbasierte Berichte stehen als Folgeschritt zum Locations-MVP auf der Roadmap. +- **Container-Image- und Cloud-Ressourcen-Locations** — Zukünftige Location-Subtypen. Derzeit werden Bibliotheken, die innerhalb eines Container-Images gefunden werden, als Dependencies erfasst; das Container-Image selbst ist noch keine eigenständige Location. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_sboms.es.md b/docs/content/asset_modelling/locations/PRO__working_with_sboms.es.md new file mode 100644 index 00000000000..2648f9e4d3e --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_sboms.es.md @@ -0,0 +1,107 @@ +--- +title: Trabajar con SBOMs +description: Gestione las dependencias de software y los SBOMs como Locations +audience: pro +weight: 5 +--- + +DefectDojo Pro modela las bibliotecas de software como **Dependency Locations**. Una Dependency es un subtipo de Location identificado por una [Package URL (pURL)](https://github.com/package-url/purl-spec) y está pensada para representar una única biblioteca o paquete — `org.apache.logging.log4j:log4j-core@2.17.0`, `pypi/django@5.0.2`, `npm/react@18.2.0`, etcétera. + +Las Dependencies reemplazan al modelo anterior de **Components**, que solo se adjuntaba a los Findings. Con Locations, las bibliotecas pueden existir independientemente de cualquier vulnerabilidad: puede cargar un SBOM en un Asset y luego dejar que los Hallazgos se adjunten automáticamente a las dependencias que referencian a medida que llegan los escaneos. + +## Qué contiene una Dependency + +Cada Dependency se identifica de forma única mediante un pURL, descompuesto en campos atómicos sobre los que puede buscar y filtrar: + +| Campo | Significado | Ejemplo | +| --- | --- | --- | +| `purl_type` | Ecosistema de la biblioteca | `npm`, `pypi`, `maven`, `cargo`, `nuget`, `gem` | +| `namespace` | Proveedor u organización | `org.apache.logging` | +| `name` | Nombre de la biblioteca | `log4j-core` | +| `version` | Versión específica | `2.17.0` | +| `qualifiers` *(opcional)* | Detalles de implementación | `arch=amd64` | +| `subpath` *(opcional)* | Ruta dentro de un archivo o monorepo | `src/lib/foo` | +| `artifact_hashes` *(opcional)* | Huellas digitales | sumas SHA256 | +| `license_expression` *(opcional)* | Expresión de licencia SPDX | `Apache-2.0`, `MIT` | +| `file_path` *(opcional)* | Dónde se encontró la biblioteca en el proyecto | `package-lock.json` | + +Esta descomposición atómica es lo que hace útil la búsqueda basada en pURL: puede preguntar *"todos los paquetes `pypi` en el namespace `django` en la versión 4.x"* y DefectDojo puede responder sin necesidad de analizar una cadena de texto libre. + +## Owned-By vs Used-By + +Cuando una Dependency se asocia con un Asset, la Asset Reference lleva una **relationship** opcional que describe *cómo* pertenece la biblioteca al Asset: + +- **`owned_by`** — *"esta biblioteca pertenece a este Asset"*. Úselo para bibliotecas propias que un Asset publica o mantiene. +- **`used_by`** — *"esta biblioteca es utilizada por este Asset"*. Úselo para dependencias de terceros que un Asset consume. + +La misma biblioteca puede ser `owned_by` de un Asset y `used_by` de varios otros, que es exactamente la relación que necesita para responder *"¿quién consume el paquete que publica mi equipo?"* durante el triage de vulnerabilidades. + +## Cargar un SBOM + +Para poblar Dependencies en bloque, cargue un archivo SBOM contra un Product. El endpoint es: + +``` +POST /api/v2/sbom-import/ +``` + +| Campo | Descripción | +| --- | --- | +| `product` | El ID del Product (Asset) de destino | +| `file` | El archivo SBOM | +| `scan_type` | El formato del SBOM — vea los formatos admitidos más abajo | +| `replace` *(opcional)* | Si es `true`, se eliminan las asociaciones de Product obsoletas que no estén respaldadas por una referencia de Finding existente. Predeterminado: `false` (acumulativo) | + +El importador analiza el archivo, extrae los registros `Dependency`, los deduplica contra las Locations existentes (creando nuevas según sea necesario) y crea Asset References que vinculan cada Dependency con el Product. La interfaz de Pro expone el mismo flujo de carga — vea la acción **Upload SBOM** en la pestaña de Locations de un Product. + +### Formatos admitidos + +El MVP incluye parsers para los dos formatos de SBOM dominantes: + +- **CycloneDX** — JSON y XML +- **SPDX** — JSON (v2 y v3), XML y tag-value + +El formato SWID Tag aún no es compatible. + +### Replace vs Append + +De forma predeterminada, las cargas repetidas son **aditivas**: las dependencias que ya existen en el Asset se conservan, se agregan las nuevas y no se elimina nada. Esto coincide con el flujo de trabajo típico de actualizaciones incrementales de SBOM. + +Configure `replace=true` para depurar. Cuando el modo replace está activado, después de una importación exitosa el importador elimina las asociaciones de Product que no estaban presentes en el nuevo SBOM **y** que no están referenciadas actualmente por un Finding activo. Las referencias vinculadas a Findings activos se conservan incluso en modo replace, de modo que no pierde contexto de vulnerabilidad solo porque un nuevo SBOM omita un paquete. + +## Hallazgos que referencian bibliotecas + +Cuando un parser ingiere una vulnerabilidad vinculada a una biblioteca — por ejemplo, una herramienta SCA que reporta `CVE-2021-44228` contra `log4j-core@2.14.1` —, el importador: + +1. Busca una Dependency Location existente por pURL, o crea una nueva. +2. Crea una `LocationFindingReference` que vincula el Hallazgo con la Dependency con estado **Activo**. +3. Crea una `LocationProductReference` para que la Dependency también aparezca en el Product padre, si aún no está presente. + +Dado que los Hallazgos y las cargas de SBOM comparten los mismos objetos Dependency subyacentes, un Hallazgo ingerido *antes* de una carga de SBOM será visible retroactivamente en la vista del SBOM, y viceversa. + +## API REST + +| Tarea | Endpoint | +| --- | --- | +| Cargar un SBOM | `POST /api/v2/sbom-import/` | +| Listar Dependencies | `GET /api/v2/dependencies/` | +| Crear una Dependency manualmente | `POST /api/v2/dependencies/` | +| Listar Dependency Locations | `GET /api/v2/location/?location_type=dependency` | +| Vincular una Dependency con un Finding | `POST /api/v2/location_findings/` | +| Vincular una Dependency con un Product (con `owned_by` / `used_by`) | `POST /api/v2/location_products/` | + +Los filtros en `/api/v2/dependencies/` incluyen los campos componentes del pURL, las etiquetas y la ordenación por `name`, `version` y conteo de Hallazgos activos. + +## En la interfaz de Pro + +Cuando Locations está habilitado, la navegación expone: + +- **Locations / Dependencies** — Lista global de todas las Dependencies de la instancia, con filtros de pURL. +- **Locations en un Product/Asset** — Vista por Asset que muestra tanto las URLs como las Dependencies, con la acción **Upload SBOM** disponible en la pestaña de Dependencies. +- **New Dependency** — Formulario para crear una única biblioteca introduciendo manualmente sus componentes de pURL. +- **Detalle de Hallazgos** — Un Hallazgo que involucra una biblioteca muestra sus Dependency Locations junto con cualquier URL Location, de modo que puede ver *"este CVE afecta a `log4j-core@2.14.1` en el Asset 6 y el Asset 9"* en un solo lugar. + +## Qué no incluye el MVP + +- **Formato SBOM SWID Tag** — No se analiza. Se requiere CycloneDX o SPDX. +- **Puntuación de riesgo de licencia** — El campo `license_expression` se captura cuando está presente en el SBOM, pero DefectDojo aún no marca Hallazgos por incompatibilidad de licencias. La generación de informes basada en licencias está en la hoja de ruta como seguimiento del MVP de Locations. +- **Locations de imágenes de contenedor y recursos en la nube** — Futuros subtipos de Location. Por ahora, las bibliotecas descubiertas dentro de una imagen de contenedor se registran como Dependencies; la imagen de contenedor en sí aún no es una Location de primera clase. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_sboms.fr.md b/docs/content/asset_modelling/locations/PRO__working_with_sboms.fr.md new file mode 100644 index 00000000000..2b347cdc739 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_sboms.fr.md @@ -0,0 +1,107 @@ +--- +title: Utilisation des SBOM +description: Gérer les dépendances logicielles et les SBOM en tant qu'Emplacements +audience: pro +weight: 5 +--- + +DefectDojo Pro modélise les bibliothèques logicielles sous forme d'**Emplacements de dépendance**. Une Dépendance est un sous-type d'Emplacement identifié par une [Package URL (pURL)](https://github.com/package-url/purl-spec) et destiné à représenter une bibliothèque ou un paquet unique — `org.apache.logging.log4j:log4j-core@2.17.0`, `pypi/django@5.0.2`, `npm/react@18.2.0`, etc. + +Les Dépendances remplacent l'ancien modèle **Composants**, qui n'était rattaché qu'aux Constatations. Avec les Emplacements, les bibliothèques peuvent exister indépendamment de toute vulnérabilité — vous pouvez importer un SBOM sur un Actif, puis laisser les Constatations se rattacher automatiquement aux dépendances qu'elles référencent au fur et à mesure des analyses. + +## Ce que contient une Dépendance + +Chaque Dépendance est identifiée de manière unique par une pURL, décomposée en champs atomiques sur lesquels vous pouvez effectuer des recherches et des filtres : + +| Champ | Signification | Exemple | +| --- | --- | --- | +| `purl_type` | Écosystème de la bibliothèque | `npm`, `pypi`, `maven`, `cargo`, `nuget`, `gem` | +| `namespace` | Éditeur ou organisation | `org.apache.logging` | +| `name` | Nom de la bibliothèque | `log4j-core` | +| `version` | Version spécifique | `2.17.0` | +| `qualifiers` *(optionnel)* | Détails d'implémentation | `arch=amd64` | +| `subpath` *(optionnel)* | Chemin au sein d'une archive ou d'un monorepo | `src/lib/foo` | +| `artifact_hashes` *(optionnel)* | Empreintes | sommes SHA256 | +| `license_expression` *(optionnel)* | Expression de licence SPDX | `Apache-2.0`, `MIT` | +| `file_path` *(optionnel)* | Où la bibliothèque a été trouvée dans le projet | `package-lock.json` | + +Cette décomposition atomique est ce qui rend la recherche par pURL utile : vous pouvez demander *« tous les paquets `pypi` dans l'espace de noms `django` en version 4.x »* et DefectDojo peut répondre sans analyser une chaîne de texte libre. + +## Owned-By vs Used-By + +Lorsqu'une Dépendance est associée à un Actif, l'Asset Reference porte une **relation** optionnelle décrivant *comment* la bibliothèque appartient à l'Actif : + +- **`owned_by`** — *« cette bibliothèque est possédée par cet Actif »*. Utilisez cette valeur pour les bibliothèques internes qu'un Actif publie ou maintient. +- **`used_by`** — *« cette bibliothèque est utilisée par cet Actif »*. Utilisez cette valeur pour les dépendances tierces qu'un Actif consomme. + +La même bibliothèque peut être `owned_by` pour un Actif et `used_by` pour plusieurs autres, ce qui est exactement la relation nécessaire pour répondre à *« qui consomme le paquet publié par mon équipe ? »* lors du triage des vulnérabilités. + +## Importer un SBOM + +Pour peupler les Dépendances en masse, importez un fichier SBOM sur un Produit. Le point de terminaison est : + +``` +POST /api/v2/sbom-import/ +``` + +| Champ | Description | +| --- | --- | +| `product` | L'identifiant du Produit (Actif) cible | +| `file` | Le fichier SBOM | +| `scan_type` | Le format du SBOM — voir les formats pris en charge ci-dessous | +| `replace` *(optionnel)* | Si `true`, les associations de Produit obsolètes non adossées à une référence de Constatation existante sont supprimées. Par défaut : `false` (cumulatif) | + +L'importeur analyse le fichier, extrait les enregistrements `Dependency`, les déduplique par rapport aux Emplacements existants (en créant de nouveaux si nécessaire), et crée des Asset References reliant chaque Dépendance au Produit. L'interface Pro expose le même flux d'import — voir l'action **Importer un SBOM** dans l'onglet Emplacements d'un Produit. + +### Formats pris en charge + +Le MVP fournit des parseurs pour les deux formats de SBOM dominants : + +- **CycloneDX** — JSON et XML +- **SPDX** — JSON (v2 et v3), XML, et tag-value + +Le format SWID Tag n'est pas encore pris en charge. + +### Remplacer vs ajouter + +Par défaut, les imports répétés sont **additifs** : les dépendances déjà présentes sur l'Actif sont conservées, les nouvelles sont ajoutées, et rien n'est supprimé. Cela correspond au flux de travail habituel des mises à jour incrémentales de SBOM. + +Définissez `replace=true` pour élaguer. Lorsque le mode remplacement est activé, après un import réussi, l'importeur supprime les associations de Produit qui n'étaient pas présentes dans le nouveau SBOM **et** qui ne sont actuellement référencées par aucune Constatation active. Les références liées à des Constatations actives sont préservées même en mode remplacement, afin de ne pas perdre le contexte de vulnérabilité simplement parce qu'un nouveau SBOM omet un paquet. + +## Constatations référençant des bibliothèques + +Lorsqu'un parseur ingère une vulnérabilité liée à une bibliothèque — par exemple, un outil SCA signalant `CVE-2021-44228` sur `log4j-core@2.14.1` — l'importeur : + +1. Recherche un Emplacement de dépendance existant par pURL, ou en crée un nouveau. +2. Crée une `LocationFindingReference` reliant la Constatation à la Dépendance avec le statut **Actif**. +3. Crée une `LocationProductReference` afin que la Dépendance apparaisse également sur le Produit parent, si ce n'est pas déjà le cas. + +Comme les Constatations et les imports de SBOM partagent les mêmes objets Dépendance sous-jacents, une Constatation ingérée *avant* un import de SBOM sera visible rétroactivement dans la vue SBOM, et inversement. + +## API REST + +| Tâche | Point de terminaison | +| --- | --- | +| Importer un SBOM | `POST /api/v2/sbom-import/` | +| Lister les Dépendances | `GET /api/v2/dependencies/` | +| Créer une Dépendance manuellement | `POST /api/v2/dependencies/` | +| Lister les Emplacements de dépendance | `GET /api/v2/location/?location_type=dependency` | +| Relier une Dépendance à une Constatation | `POST /api/v2/location_findings/` | +| Relier une Dépendance à un Produit (avec `owned_by` / `used_by`) | `POST /api/v2/location_products/` | + +Les filtres sur `/api/v2/dependencies/` incluent les champs composants de la pURL, les étiquettes, et le tri sur `name`, `version`, et le nombre de constatations actives. + +## Dans l'interface Pro + +Lorsque les Emplacements sont activés, la navigation expose : + +- **Emplacements / Dépendances** — Liste globale de toutes les Dépendances de l'instance, avec des filtres pURL. +- **Emplacements sur un Produit/Actif** — Vue par Actif qui affiche à la fois les URL et les Dépendances, avec l'action **Importer un SBOM** accessible depuis l'onglet Dépendances. +- **Nouvelle Dépendance** — Formulaire permettant de créer une seule bibliothèque en saisissant manuellement ses composants pURL. +- **Détail des Constatations** — Une Constatation qui touche une bibliothèque affiche ses Emplacements de dépendance aux côtés de tout Emplacement URL, afin de voir en un seul endroit que *« ce CVE affecte `log4j-core@2.14.1` sur l'Actif 6 et l'Actif 9 »*. + +## Ce qui n'est pas dans le MVP + +- **Format de SBOM SWID Tag** — Non analysé. CycloneDX ou SPDX est requis. +- **Notation du risque de licence** — Le champ `license_expression` est capturé lorsqu'il est présent dans le SBOM, mais DefectDojo ne signale pas encore de constatations en cas d'incompatibilité de licence. Le reporting basé sur les licences figure sur la feuille de route en tant que suite du MVP Emplacements. +- **Emplacements d'image de conteneur et de ressource cloud** — Futurs sous-types d'Emplacement. Pour l'instant, les bibliothèques découvertes à l'intérieur d'une image de conteneur sont enregistrées comme des Dépendances ; l'image de conteneur elle-même n'est pas encore un Emplacement de premier niveau. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_sboms.ja.md b/docs/content/asset_modelling/locations/PRO__working_with_sboms.ja.md new file mode 100644 index 00000000000..18a508fa114 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_sboms.ja.md @@ -0,0 +1,107 @@ +--- +title: SBOMの利用 +description: ソフトウェアの依存関係とSBOMをロケーションとして管理する +audience: pro +weight: 5 +--- + +DefectDojo Proは、ソフトウェアライブラリを**依存関係ロケーション**としてモデル化します。依存関係は、[Package URL (pURL)](https://github.com/package-url/purl-spec) によって識別されるロケーションのサブタイプであり、`org.apache.logging.log4j:log4j-core@2.17.0`、`pypi/django@5.0.2`、`npm/react@18.2.0` などの単一のライブラリまたはパッケージを表すことを意図しています。 + +依存関係は、検出事項にのみ紐付いていた従来の**コンポーネント**モデルに代わるものです。ロケーションでは、ライブラリは脆弱性の有無にかかわらず独立して存在できます。SBOMをアセットにアップロードしておけば、スキャンが取り込まれるたびに検出事項が参照する依存関係へ自動的に紐付きます。 + +## 依存関係が保持する情報 + +すべての依存関係はpURLによって一意に識別され、検索・フィルタリング可能な原子的なフィールドに分解されます。 + +| フィールド | 意味 | 例 | +| --- | --- | --- | +| `purl_type` | ライブラリのエコシステム | `npm`、`pypi`、`maven`、`cargo`、`nuget`、`gem` | +| `namespace` | ベンダーまたは組織 | `org.apache.logging` | +| `name` | ライブラリ名 | `log4j-core` | +| `version` | 特定のバージョン | `2.17.0` | +| `qualifiers` *(オプション)* | 実装の詳細 | `arch=amd64` | +| `subpath` *(オプション)* | アーカイブまたはモノレポ内のパス | `src/lib/foo` | +| `artifact_hashes` *(オプション)* | フィンガープリント | SHA256サム | +| `license_expression` *(オプション)* | SPDXライセンス表現 | `Apache-2.0`、`MIT` | +| `file_path` *(オプション)* | プロジェクト内でライブラリが見つかった場所 | `package-lock.json` | + +この原子的な分解こそが、pURLベースの検索を有用にしています。「`django` 名前空間にある、バージョン4.x系のすべての `pypi` パッケージ」といった問い合わせに対し、DefectDojoは自由記述の文字列を解析することなく回答できます。 + +## Owned-ByとUsed-By + +依存関係がアセットに関連付けられると、Asset Referenceは、そのライブラリがアセットに*どのように*属しているかを示す任意の**relationship(関係)**を持ちます。 + +- **`owned_by`** — 「このライブラリはこのアセットが所有している」。アセットが公開・保守しているファーストパーティライブラリに使用します。 +- **`used_by`** — 「このライブラリはこのアセットによって使用されている」。アセットが利用するサードパーティの依存関係に使用します。 + +同じライブラリが、あるアセットには `owned_by`、他の複数のアセットには `used_by` として関連付けられることがあります。これはまさに、脆弱性のトリアージ中に「自分のチームが公開しているパッケージを消費しているのは誰か」という問いに答えるために必要な関係性です。 + +## SBOMのアップロード + +依存関係を一括で取り込むには、製品に対してSBOMファイルをアップロードします。エンドポイントは次のとおりです。 + +``` +POST /api/v2/sbom-import/ +``` + +| フィールド | 説明 | +| --- | --- | +| `product` | 対象となる製品(アセット)のID | +| `file` | SBOMファイル | +| `scan_type` | SBOMの形式(サポートされる形式は以下を参照) | +| `replace` *(オプション)* | `true` の場合、既存の検出事項の参照に裏付けられていない古い製品の関連付けが削除されます。デフォルト: `false`(累積) | + +インポーターはファイルを解析して `Dependency` レコードを抽出し、既存のロケーションと重複排除を行い(必要に応じて新規作成し)、各依存関係を製品にリンクするAsset Referenceを作成します。Pro UIでも同じアップロードフローが提供されています。製品のロケーションタブにある**SBOMをアップロード**アクションを参照してください。 + +### サポートされる形式 + +MVPには、主要な2つのSBOM形式に対応するパーサーが同梱されています。 + +- **CycloneDX** — JSONおよびXML +- **SPDX** — JSON(v2およびv3)、XML、tag-value + +SWID Tag形式にはまだ対応していません。 + +### ReplaceとAppend + +デフォルトでは、繰り返しのアップロードは**追加方式**です。アセットにすでに存在する依存関係はそのまま保持され、新しいものが追加され、何も削除されません。これは、SBOMを段階的に更新していく一般的なワークフローに合致します。 + +不要なものを削除するには `replace=true` を設定します。replaceモードが有効な場合、インポートが成功した後、新しいSBOMに存在せず**かつ**現在アクティブな検出事項から参照されていない製品の関連付けをインポーターが削除します。アクティブな検出事項に紐付く参照は、replaceモードでも保持されるため、新しいSBOMでパッケージが省略されたからといって脆弱性のコンテキストが失われることはありません。 + +## ライブラリを参照する検出事項 + +パーサーがライブラリに紐付いた脆弱性を取り込む場合、たとえばSCAツールが `log4j-core@2.14.1` に対して `CVE-2021-44228` を報告する場合、インポーターは次の処理を行います。 + +1. pURLで既存の依存関係ロケーションを検索するか、新規に作成します。 +2. 検出事項を依存関係にリンクする `LocationFindingReference` を、ステータス**アクティブ**で作成します。 +3. 依存関係が親製品にまだ表示されていない場合、そこにも表示されるよう `LocationProductReference` を作成します。 + +検出事項とSBOMのアップロードは、同じ依存関係オブジェクトを基盤として共有しているため、SBOMのアップロードより*前*に取り込まれた検出事項も、SBOMビューに遡って表示されます。逆の場合も同様です。 + +## REST API + +| タスク | エンドポイント | +| --- | --- | +| SBOMをアップロード | `POST /api/v2/sbom-import/` | +| 依存関係を一覧表示 | `GET /api/v2/dependencies/` | +| 依存関係を手動で作成 | `POST /api/v2/dependencies/` | +| 依存関係ロケーションを一覧表示 | `GET /api/v2/location/?location_type=dependency` | +| 依存関係を検出事項にリンク | `POST /api/v2/location_findings/` | +| 依存関係を製品にリンク(`owned_by` / `used_by` を使用) | `POST /api/v2/location_products/` | + +`/api/v2/dependencies/` のフィルタには、pURLの構成フィールド、タグ、そして `name`、`version`、アクティブな検出事項数による並べ替えが含まれます。 + +## Pro UIでの表示 + +ロケーションが有効になると、ナビゲーションに以下が表示されます。 + +- **ロケーション / 依存関係** — インスタンス全体のすべての依存関係のグローバル一覧。pURLによるフィルタが可能です。 +- **製品/アセットのロケーション** — URLと依存関係の両方を表示するアセット単位のビュー。依存関係タブに**SBOMをアップロード**アクションが表示されます。 +- **新しい依存関係** — pURLの構成要素を手動で入力して単一のライブラリを作成するフォームです。 +- **検出事項の詳細** — ライブラリに関係する検出事項は、URLロケーションと並んで依存関係ロケーションを表示するため、「このCVEはアセット6とアセット9の `log4j-core@2.14.1` に影響している」といった情報を1か所で確認できます。 + +## MVPに含まれないもの + +- **SWID Tag SBOM形式** — 解析されません。CycloneDXまたはSPDXが必要です。 +- **ライセンスリスクのスコアリング** — SBOMに `license_expression` フィールドが含まれている場合はそれが取り込まれますが、DefectDojoはまだライセンスの非互換性について検出事項にフラグを立てません。ライセンスベースのレポート機能は、ロケーションMVPの後続としてロードマップに含まれています。 +- **コンテナイメージおよびクラウドリソースのロケーション** — 将来のロケーションサブタイプです。現時点では、コンテナイメージ内で見つかったライブラリは依存関係として記録されますが、コンテナイメージ自体はまだファーストクラスのロケーションではありません。 diff --git a/docs/content/asset_modelling/locations/PRO__working_with_urls.de.md b/docs/content/asset_modelling/locations/PRO__working_with_urls.de.md new file mode 100644 index 00000000000..0f839740019 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_urls.de.md @@ -0,0 +1,88 @@ +--- +title: Arbeiten mit URLs +description: Alltägliche Nutzung von URL-Locations als Ersatz für Endpoints +audience: pro +weight: 4 +--- + +URL-Locations sind der funktionale Ersatz für das veraltete Endpoints-Modell. Sie speichern dieselben URL-förmigen Felder, die Sie gewohnt sind — `protocol`, `host`, `port`, `path`, `query`, `fragment` — und erfüllen dieselbe Aufgabe: zu identifizieren, *wo* ein Webanwendungs-Befund liegt. + +Diese Seite beschreibt, was sich bei der täglichen Nutzung von URL-Locations ändert, welche neuen Oberflächen es gibt und welche API-Endpunkte anstelle der veralteten Endpoint-API zu verwenden sind. + +## Der URL-Subtyp + +Jede URL ist eine Location. Das bedeutet, eine URL verfügt über beides: + +- Die strukturierten URL-Felder (`protocol`, `user_info`, `host`, `port`, `path`, `query`, `fragment` sowie einen `hash` zur Deduplizierung). +- Die gemeinsamen Location-Felder (`location_type="url"`, eine kanonische `location_value`-Zeichenkette für Anzeige und Suche, Tags, geerbte Tags, Metadaten sowie Reference-Verknüpfungen zu Assets und Befunden). + +Wenn Sie eine URL erstellen oder hochladen, zerlegt DefectDojo sie in die strukturierten Felder und schreibt sowohl die URL-Zeile als auch die zugehörige übergeordnete Location-Zeile in einer einzigen Transaktion. Die URL-Deduplizierung erfolgt als exakter Abgleich über die strukturierten Felder — zwei URLs gelten als identisch, wenn jede Komponente übereinstimmt, wobei der Standard-Port wie üblich zusammengefasst wird (`http://example.com:80/` und `http://example.com/` ergeben dieselbe URL). + +## In der Pro-Benutzeroberfläche + +Wenn das Feature Locations aktiviert ist, bietet die Navigation: + +- **Locations / All** — Eine Liste aller Locations über die Subtypen URL und Dependency hinweg. Filterbar nach Typ, Status, Asset, Befund oder Tag. +- **Locations / URLs** — Eine eingegrenzte Liste ausschließlich der URL-Locations. Dies entspricht am ehesten der alten Endpoints-Seite. +- **New URL** — Ein Formular zum Erstellen einer einzelnen URL mit strukturierten Feldern, Tags und optionalen Asset-/Befund-Zuordnungen. +- **Locations on an Asset** — Von jedem Asset aus zeigt der Tab **Locations** die diesem Asset zugeordneten URLs und Dependencies, mit Statuszählungen und Schnellaktionen. + +Gängige Workflows aus der Endpoints-Oberfläche bleiben erhalten: + +- **Massen-Statusaktualisierungen.** Wählen Sie mehrere URL-Locations aus und wenden Sie in einer Aktion einen Status (Aktiv, Behoben, Falsch-positiv, Risiko akzeptiert, Außerhalb des Geltungsbereichs) auf deren Befund-Referenzen an. +- **Bestehende URLs zu einem Asset hinzufügen.** Verwenden Sie **Add Existing** im Locations-Tab eines Assets, um bereits im System vorhandene URLs zu verknüpfen, anstatt Duplikate zu erstellen. +- **Tags.** Auf eine URL-Location angewendete Tags werden als geerbte Tags an die Befunde weitergegeben, die auf sie verweisen — genauso, wie es zuvor bei Endpoint-Tags der Fall war. + +## Statusmodell + +URL-Locations verwenden dieselben Einzelstatus-Bezeichnungen wie alle anderen Locations: + +| Status | Bedeutung | +| --- | --- | +| **Aktiv** | Der Befund an dieser URL ist offen. | +| **Behoben** | Der Befund wurde für diese URL behoben. | +| **Falsch-positiv** | Der Befund ist für diese URL keine echte Schwachstelle. | +| **Risiko akzeptiert** | Der Befund wird zur Kenntnis genommen, aber für diese URL akzeptiert. | +| **Außerhalb des Geltungsbereichs** | Diese URL ist vom Engagement ausgeschlossen. | + +Beachten Sie, dass das alte Endpoint-Status-Modell mehrere Flags gleichzeitig zuließ (z. B. `mitigated=True` und `false_positive=True`). Locations erzwingen jeweils nur einen Status. Wenn Sie von Endpoints migriert haben, wurde das spezifischste Flag beibehalten (siehe die Zuordnungstabelle unter [Migrating from Endpoints](../pro__migrating_from_endpoints)). + +Asset References verwenden einen einfacheren Status: nur **Aktiv** oder **Behoben**, da der Status auf Asset-Ebene nicht dieselbe Prüfdetailtiefe benötigt. + +## REST-API + +Verwenden Sie diese Endpunkte anstelle der veralteten Endpoint-API: + +| Aufgabe | Endpunkt | +| --- | --- | +| URLs auflisten | `GET /api/v2/urls/` | +| Eine URL erstellen | `POST /api/v2/urls/` | +| Tags oder Metadaten einer URL aktualisieren | `PATCH /api/v2/urls/{id}/` | +| Alle Locations auflisten (URLs + Dependencies) | `GET /api/v2/location/?location_type=url` | +| Eine URL mit einem Befund verknüpfen | `POST /api/v2/location_findings/` | +| Eine URL mit einem Asset verknüpfen | `POST /api/v2/location_Assets/` | +| Status einer Befund-Verknüpfung aktualisieren | `PATCH /api/v2/location_findings/{id}/` | +| Eine Befund-Verknüpfung entfernen | `DELETE /api/v2/location_findings/{id}/` | + +Filter für `/api/v2/urls/` umfassen die strukturierten URL-Felder sowie `tag(s)`, `has_tags`, `Asset` und die Sortierung nach `host`, `Asset` oder der Anzahl aktiver Befunde. + +Der veraltete Endpunkt `/api/v2/endpoints/` bedient über einen Kompatibilitäts-Shim weiterhin **Lese**-Zugriffe — siehe [Migrating from Endpoints](../pro__migrating_from_endpoints), was dabei erhalten bleibt und wo sich der Shim vom ursprünglichen Verhalten unterscheidet. **Schreibzugriffe** auf die veralteten Endpunkte liefern `403` zurück und müssen auf die obigen Endpunkte umgestellt werden. + +## Importieren von URLs aus Scans + +Scanner-Importe erstellen URL-Locations automatisch. Wenn ein Parser für einen Befund eine URL ausgibt (so wie er früher einen Endpoint ausgegeben hat), führt der Importer Folgendes aus: + +1. Sucht nach einer bestehenden URL mit übereinstimmenden strukturierten Feldern oder erstellt eine neue. +2. Erstellt eine Finding Reference, die den Befund mit dem Status **Aktiv** mit der URL verknüpft. +3. Erstellt eine Asset Reference (oder verwendet eine bestehende weiter), damit die URL auch beim übergeordneten Asset erscheint. + +DefectDojo-Parser, die zuvor Endpoints erstellt haben, wurden aktualisiert, um in Pro automatisch Locations zu erstellen. + +## Dinge, die sich anders verhalten + +Ein paar kleine Verhaltensänderungen sind erwähnenswert: + +- **Ein Status pro URL-/Befund-Paar.** Wie oben beschrieben wird das Mehrfach-Flag-Modell von Endpoint_Status auf einen einzelnen Status reduziert. Workflows, die Flags unabhängig voneinander umgeschaltet haben, müssen sich für einen einzelnen Übergang entscheiden. +- **Tags liegen bei der Location, nicht bei der URL.** Der URL-Subtyp führt keine eigene Tag-Menge; Tags gehören zur übergeordneten Location. Wenn Sie eine URL über die API lesen, stammt das Feld `tags` aus `location.tags`. +- **Deduplizierung erfolgt pro kanonischer URL, nicht pro Asset.** Zwei Assets mit derselben URL teilen sich eine einzige zugrunde liegende URL-Location und referenzieren sie zweimal (jeweils eine Asset Reference). Das ist beabsichtigt und ermöglicht assetübergreifende Berichte. +- **Das Feld `endpoints` bei Befunden.** Ist das Flag aktiviert, liefert dieses Feld der Finding-API weiterhin Zeilen, diese werden jedoch aus URL-Locations statt aus der Endpoint-Tabelle projiziert. Behandeln Sie es als schreibgeschützt und schreiben Sie stattdessen über `/api/v2/location_findings/`. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_urls.es.md b/docs/content/asset_modelling/locations/PRO__working_with_urls.es.md new file mode 100644 index 00000000000..b1facabf1ea --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_urls.es.md @@ -0,0 +1,88 @@ +--- +title: Trabajar con URLs +description: Uso cotidiano de URL Locations como reemplazo de Endpoints +audience: pro +weight: 4 +--- + +Las URL Locations son el reemplazo funcional del modelo heredado de Endpoints. Almacenan los mismos campos con forma de URL a los que está acostumbrado — `protocol`, `host`, `port`, `path`, `query`, `fragment` — y cumplen el mismo rol: identificar *dónde* vive un Hallazgo de aplicación web. + +Esta página cubre qué cambia cuando empieza a usar las URL Locations en el día a día, las nuevas superficies de interfaz y los endpoints de la API que debe usar en lugar de la API heredada de Endpoint. + +## El subtipo URL + +Toda URL es una Location. Eso significa que una URL tiene a la vez: + +- Los campos estructurados de la URL (`protocol`, `user_info`, `host`, `port`, `path`, `query`, `fragment`, además de un `hash` usado para la deduplicación). +- Los campos compartidos de Location (`location_type="url"`, una cadena canónica `location_value` para visualización y búsqueda, etiquetas, etiquetas heredadas, metadatos y enlaces de Reference hacia Assets y Findings). + +Cuando crea o carga una URL, DefectDojo la analiza en los campos estructurados y escribe tanto la fila de URL como su fila de Location padre en una única transacción. La deduplicación de URL es de coincidencia exacta entre los campos estructurados: dos URLs se consideran iguales si cada componente coincide, con el colapso estándar de puerto predeterminado (`http://example.com:80/` y `http://example.com/` se resuelven en la misma URL). + +## En la interfaz de Pro + +Cuando la función Locations está habilitada, la navegación expone: + +- **Locations / All** — Una lista de todas las Locations de la instancia, tanto del subtipo URL como del subtipo Dependency. Filtre por tipo, estado, Asset, Finding o etiqueta. +- **Locations / URLs** — Una lista limitada solo a las URL Locations. Es el equivalente más cercano a la antigua página de Endpoints. +- **New URL** — Un formulario para crear una única URL con campos estructurados, etiquetas y asociaciones opcionales con Assets/Findings. +- **Locations en un Asset** — Desde cualquier Asset, la pestaña **Locations** muestra las URLs y Dependencies adjuntas a ese Asset, con conteos de estado y acciones rápidas. + +Se conservan los flujos de trabajo comunes de la interfaz de Endpoints: + +- **Actualizaciones de estado en bloque.** Seleccione varias URL Locations y aplique un estado (Activo, Mitigado, Falso positivo, Riesgo aceptado, Fuera de alcance) a sus referencias de Finding en una sola acción. +- **Agregar URLs existentes a un Asset.** Use **Add Existing** en la pestaña Locations de un Asset para vincular URLs que ya están en el sistema en lugar de crear duplicados. +- **Etiquetas.** Las etiquetas aplicadas a una URL Location se propagan como etiquetas heredadas en los Findings que la referencian, de la misma manera que antes lo hacían las etiquetas de Endpoint. + +## Modelo de estados + +Las URL Locations usan las mismas etiquetas de estado único que todas las demás Locations: + +| Estado | Significado | +| --- | --- | +| **Activo** | El Hallazgo en esta URL está abierto. | +| **Mitigado** | El Hallazgo se ha remediado para esta URL. | +| **Falso positivo** | El Hallazgo no es una vulnerabilidad real para esta URL. | +| **Riesgo aceptado** | El Hallazgo se reconoce pero se acepta en esta URL. | +| **Fuera de alcance** | Esta URL está excluida del Engagement. | + +Tenga en cuenta que el antiguo modelo de Endpoint Status permitía múltiples indicadores simultáneamente (por ejemplo, `mitigated=True` y `false_positive=True`). Las Locations aplican un solo estado a la vez. Si migró desde Endpoints, se conservó el indicador más específico (vea la tabla de mapeo en [Migrating from Endpoints](../pro__migrating_from_endpoints)). + +Las Asset References usan un estado más simple: solo **Activo** o **Mitigado**, ya que el estado a nivel de Asset no necesita el detalle de auditoría. + +## API REST + +Use estos endpoints en lugar de la API heredada de Endpoint: + +| Tarea | Endpoint | +| --- | --- | +| Listar URLs | `GET /api/v2/urls/` | +| Crear una URL | `POST /api/v2/urls/` | +| Actualizar las etiquetas o metadatos de una URL | `PATCH /api/v2/urls/{id}/` | +| Listar todas las Locations (URLs + Dependencies) | `GET /api/v2/location/?location_type=url` | +| Vincular una URL con un Finding | `POST /api/v2/location_findings/` | +| Vincular una URL con un Asset | `POST /api/v2/location_Assets/` | +| Actualizar el estado de un vínculo de Finding | `PATCH /api/v2/location_findings/{id}/` | +| Eliminar un vínculo de Finding | `DELETE /api/v2/location_findings/{id}/` | + +Los filtros en `/api/v2/urls/` incluyen los campos estructurados de la URL además de `tag(s)`, `has_tags`, `Asset`, y ordenación por `host`, `Asset` o conteo de Hallazgos activos. + +El endpoint heredado `/api/v2/endpoints/` sigue sirviendo tráfico de **lectura** mediante una capa de compatibilidad — vea [Migrating from Endpoints](../pro__migrating_from_endpoints) para saber qué se conserva y en qué difiere la capa del comportamiento original. Las **escrituras** en los endpoints heredados devuelven `403` y deben moverse a los endpoints anteriores. + +## Importar URLs desde escaneos + +Las importaciones de escáneres crean URL Locations automáticamente. Cuando un parser emite una URL para un Hallazgo (de la misma manera en que antes emitía un Endpoint), el importador: + +1. Busca una URL existente con campos estructurados coincidentes, o crea una. +2. Crea una Finding Reference que vincula el Hallazgo con la URL con estado **Activo**. +3. Crea (o reutiliza) una Asset Reference para que la URL también aparezca en el Asset padre. + +Los parsers de DefectDojo que antes creaban Endpoints se han actualizado para crear Locations automáticamente en Pro. + +## Comportamientos que difieren + +Vale la pena señalar algunos pequeños cambios de comportamiento: + +- **Un estado por par URL/Finding.** Como se describió anteriormente, el modelo de múltiples indicadores de Endpoint_Status se reduce a un único estado. Los flujos de trabajo que alternaban indicadores de forma independiente deben elegir una sola transición. +- **Las etiquetas viven en la Location, no en la URL.** El subtipo URL no lleva su propio conjunto de etiquetas; las etiquetas pertenecen a la Location padre. Si lee una URL a través de la API, el campo `tags` proviene de `location.tags`. +- **La deduplicación es por URL canónica, no por Asset.** Dos Assets que tienen la misma URL comparten una única URL Location subyacente y la referencian dos veces (una Asset Reference cada uno). Esto es intencional y es lo que permite la generación de informes entre Assets. +- **El campo `endpoints` en los Findings.** Cuando la función está activada, este campo en la API de Finding sigue devolviendo filas, pero se proyectan a partir de URL Locations en lugar de la tabla de Endpoint. Trátelo como de solo lectura y escriba a través de `/api/v2/location_findings/` en su lugar. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_urls.fr.md b/docs/content/asset_modelling/locations/PRO__working_with_urls.fr.md new file mode 100644 index 00000000000..c47381310fb --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_urls.fr.md @@ -0,0 +1,89 @@ +--- +title: Utilisation des URL +description: Utilisation quotidienne des Emplacements URL en remplacement des Points + de terminaison +audience: pro +weight: 4 +--- + +Les Emplacements URL constituent le remplacement fonctionnel de l'ancien modèle Endpoints. Ils stockent les mêmes champs en forme d'URL que ceux que vous connaissez déjà — `protocol`, `host`, `port`, `path`, `query`, `fragment` — et jouent le même rôle : identifier *où* vit une Constatation d'application web. + +Cette page couvre ce qui change lorsque vous commencez à utiliser les Emplacements URL au quotidien, les nouvelles surfaces d'interface, et les points de terminaison d'API à utiliser à la place de l'API Endpoint héritée. + +## Le sous-type URL + +Chaque URL est un Emplacement. Cela signifie qu'une URL possède à la fois : + +- Les champs URL structurés (`protocol`, `user_info`, `host`, `port`, `path`, `query`, `fragment`, ainsi qu'un `hash` utilisé pour la déduplication). +- Les champs Emplacement partagés (`location_type="url"`, une chaîne canonique `location_value` pour l'affichage et la recherche, les étiquettes, les étiquettes héritées, les métadonnées, et les liens Reference vers les Actifs et les Constatations). + +Lorsque vous créez ou importez une URL, DefectDojo l'analyse pour en extraire les champs structurés et écrit à la fois la ligne URL et sa ligne Emplacement parente dans une seule transaction. La déduplication des URL se fait par correspondance exacte sur les champs structurés — deux URL sont considérées comme identiques si chaque composant correspond, avec la réduction standard du port par défaut (`http://example.com:80/` et `http://example.com/` correspondent à la même URL). + +## Dans l'interface Pro + +Lorsque la fonctionnalité Emplacements est activée, la navigation expose : + +- **Emplacements / Tous** — Une liste de tous les Emplacements, tous sous-types URL et Dépendance confondus. Filtrez par type, statut, Actif, Constatation ou étiquette. +- **Emplacements / URL** — Une liste restreinte aux seuls Emplacements URL. C'est l'équivalent le plus proche de l'ancienne page Endpoints. +- **Nouvelle URL** — Un formulaire pour créer une seule URL avec des champs structurés, des étiquettes, et des associations optionnelles à un Actif/une Constatation. +- **Emplacements sur un Actif** — Depuis n'importe quel Actif, l'onglet **Emplacements** affiche les URL et Dépendances rattachées à cet Actif, avec des décomptes de statut et des actions rapides. + +Les flux de travail courants de l'interface Endpoints sont préservés : + +- **Mises à jour groupées de statut.** Sélectionnez plusieurs Emplacements URL et appliquez un statut (Actif, Atténué, Faux positif, Risque accepté, Hors périmètre) à leurs références de Constatation en une seule action. +- **Ajout d'URL existantes à un Actif.** Utilisez **Ajouter existant** dans l'onglet Emplacements d'un Actif pour relier des URL déjà présentes dans le système plutôt que de créer des doublons. +- **Étiquettes.** Les étiquettes appliquées à un Emplacement URL se propagent en tant qu'étiquettes héritées sur les Constatations qui le référencent, de la même manière que le faisaient auparavant les étiquettes des Points de terminaison. + +## Modèle de statut + +Les Emplacements URL utilisent les mêmes libellés de statut unique que tous les autres Emplacements : + +| Statut | Signification | +| --- | --- | +| **Actif** | La Constatation à cette URL est ouverte. | +| **Atténué** | La Constatation a été corrigée pour cette URL. | +| **Faux positif** | La Constatation n'est pas une vraie vulnérabilité pour cette URL. | +| **Risque accepté** | La Constatation est reconnue mais acceptée pour cette URL. | +| **Hors périmètre** | Cette URL est exclue de l'engagement. | + +Notez que l'ancien modèle Endpoint Status autorisait plusieurs indicateurs simultanément (par ex. `mitigated=True` et `false_positive=True`). Les Emplacements n'appliquent qu'un seul statut à la fois. Si vous avez migré depuis les Points de terminaison, l'indicateur le plus spécifique a été préservé (voir le tableau de mappage dans [Migration depuis les Points de terminaison](../pro__migrating_from_endpoints)). + +Les Asset References utilisent un statut plus simple : uniquement **Actif** ou **Atténué**, car le statut au niveau de l'Actif n'a pas besoin du détail d'audit. + +## API REST + +Utilisez ces points de terminaison à la place de l'API Endpoint héritée : + +| Tâche | Point de terminaison | +| --- | --- | +| Lister les URL | `GET /api/v2/urls/` | +| Créer une URL | `POST /api/v2/urls/` | +| Mettre à jour les étiquettes ou métadonnées d'une URL | `PATCH /api/v2/urls/{id}/` | +| Lister tous les Emplacements (URL + Dépendances) | `GET /api/v2/location/?location_type=url` | +| Relier une URL à une Constatation | `POST /api/v2/location_findings/` | +| Relier une URL à un Actif | `POST /api/v2/location_Assets/` | +| Mettre à jour le statut d'un lien de Constatation | `PATCH /api/v2/location_findings/{id}/` | +| Supprimer un lien de Constatation | `DELETE /api/v2/location_findings/{id}/` | + +Les filtres sur `/api/v2/urls/` incluent les champs URL structurés ainsi que `tag(s)`, `has_tags`, `Asset`, et le tri par `host`, `Asset`, ou le nombre de constatations actives. + +Le point de terminaison hérité `/api/v2/endpoints/` continue de servir le trafic en **lecture** via une couche de compatibilité — voir [Migration depuis les Points de terminaison](../pro__migrating_from_endpoints) pour savoir ce qui est préservé et où cette couche diffère du comportement d'origine. Les **écritures** vers les points de terminaison hérités renvoient `403` et doivent être déplacées vers les points de terminaison ci-dessus. + +## Import d'URL depuis les analyses + +Les imports de scanners créent automatiquement des Emplacements URL. Lorsqu'un parseur émet une URL pour une Constatation (de la même manière qu'il émettait auparavant un Point de terminaison), l'importeur : + +1. Recherche une URL existante dont les champs structurés correspondent, ou en crée une. +2. Crée une Finding Reference reliant la Constatation à l'URL avec le statut **Actif**. +3. Crée (ou réutilise) une Asset Reference afin que l'URL apparaisse également sur l'Actif parent. + +Les parseurs DefectDojo qui créaient auparavant des Points de terminaison ont été mis à jour pour créer automatiquement des Emplacements dans Pro. + +## Éléments qui se comportent différemment + +Quelques petits changements de comportement méritent d'être signalés : + +- **Un seul statut par paire URL/Constatation.** Comme décrit ci-dessus, le modèle Endpoint_Status à indicateurs multiples est réduit à un seul statut. Les flux de travail qui basculaient les indicateurs indépendamment doivent choisir une transition unique. +- **Les étiquettes vivent sur l'Emplacement, pas sur l'URL.** Le sous-type URL ne porte pas son propre ensemble d'étiquettes ; les étiquettes appartiennent à l'Emplacement parent. Si vous lisez une URL via l'API, le champ `tags` provient de `location.tags`. +- **La déduplication se fait par URL canonique, pas par Actif.** Deux Actifs ayant la même URL partagent un seul Emplacement URL sous-jacent et le référencent deux fois (une Asset Reference chacun). Ceci est intentionnel et c'est ce qui permet le reporting inter-Actifs. +- **Le champ `endpoints` sur les Constatations.** Lorsque l'indicateur est activé, ce champ de l'API Finding renvoie toujours des lignes, mais celles-ci sont projetées à partir des Emplacements URL plutôt que de la table Endpoint. Traitez-le comme étant en lecture seule et écrivez plutôt via `/api/v2/location_findings/`. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_urls.ja.md b/docs/content/asset_modelling/locations/PRO__working_with_urls.ja.md new file mode 100644 index 00000000000..1f3874e00d7 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_urls.ja.md @@ -0,0 +1,88 @@ +--- +title: URLの利用 +description: エンドポイントの後継としてのURLロケーションの日常的な利用 +audience: pro +weight: 4 +--- + +URLロケーションは、レガシーなエンドポイントモデルの機能的な後継です。使い慣れたURL形式のフィールド(`protocol`、`host`、`port`、`path`、`query`、`fragment`)を保持し、Webアプリケーションの検出事項が*どこに*存在するかを識別するという同じ役割を果たします。 + +このページでは、URLロケーションを日常的に使い始めた際に変わる点、新しいUIの画面、そしてレガシーエンドポイントAPIの代わりに使用するAPIエンドポイントについて説明します。 + +## URLサブタイプ + +すべてのURLはロケーションです。つまり、URLは次の両方を持ちます。 + +- 構造化されたURLフィールド(`protocol`、`user_info`、`host`、`port`、`path`、`query`、`fragment`、および重複排除に使用される `hash`)。 +- 共有のロケーションフィールド(`location_type="url"`、表示・検索用の正規 `location_value` 文字列、タグ、継承タグ、メタデータ、アセットおよび検出事項へのReferenceリンク)。 + +URLを作成またはアップロードすると、DefectDojoはそれを構造化フィールドに解析し、URLの行とその親ロケーションの行を単一のトランザクションで書き込みます。URLの重複排除は構造化フィールド全体での完全一致で行われます。すべての構成要素が一致すれば同じURLとみなされ、標準的なデフォルトポートの畳み込みも適用されます(`http://example.com:80/` と `http://example.com/` は同じURLとして解決されます)。 + +## Pro UIでの表示 + +ロケーション機能が有効になると、ナビゲーションに以下が表示されます。 + +- **ロケーション / すべて** — URLと依存関係の両方のサブタイプにまたがる、すべてのロケーションの一覧です。種別、ステータス、アセット、検出事項、タグでフィルタできます。 +- **ロケーション / URL** — URLロケーションのみに絞った一覧です。これは旧エンドポイントページに最も近いものです。 +- **新しいURL** — 構造化フィールド、タグ、任意のアセット/検出事項の関連付けを指定して単一のURLを作成するフォームです。 +- **アセットのロケーション** — 任意のアセットで、**ロケーション**タブにはそのアセットに紐付くURLと依存関係が、ステータスごとの件数やクイックアクションとともに表示されます。 + +エンドポイントUIにあった一般的なワークフローは維持されています。 + +- **ステータスの一括更新。** 複数のURLロケーションを選択し、1つの操作でその検出事項への参照にステータス(アクティブ、緩和済み、誤検知、リスク受容済み、対象外)を適用できます。 +- **既存URLをアセットに追加。** アセットのロケーションタブにある**既存を追加**を使うと、重複を作成する代わりに、すでにシステムに存在するURLをリンクできます。 +- **タグ。** URLロケーションに付与されたタグは、以前のエンドポイントのタグと同様に、それを参照する検出事項に継承タグとして伝播します。 + +## ステータスモデル + +URLロケーションは、他のすべてのロケーションと同じ単一ステータスのラベルを使用します。 + +| ステータス | 意味 | +| --- | --- | +| **アクティブ** | このURLにおける検出事項は未対応です。 | +| **緩和済み** | このURLにおける検出事項は修復済みです。 | +| **誤検知** | このURLにおける検出事項は実際の脆弱性ではありません。 | +| **リスク受容済み** | このURLにおける検出事項は認識された上で受容されています。 | +| **対象外** | このURLはエンゲージメントの対象から除外されています。 | + +従来のEndpoint Statusモデルでは、複数のフラグを同時に立てることができました(例: `mitigated=True` と `false_positive=True`)。ロケーションでは、一度に1つのステータスのみが適用されます。エンドポイントから移行した場合、最も具体的なフラグが保持されます([エンドポイントからの移行](../pro__migrating_from_endpoints)のマッピング表を参照してください)。 + +Asset Referenceは、より単純なステータスを使用します。アセットレベルのステータスには詳細な監査情報が不要なため、**アクティブ**または**緩和済み**のみです。 + +## REST API + +レガシーエンドポイントAPIの代わりに、以下のエンドポイントを使用してください。 + +| タスク | エンドポイント | +| --- | --- | +| URLを一覧表示 | `GET /api/v2/urls/` | +| URLを作成 | `POST /api/v2/urls/` | +| URLのタグまたはメタデータを更新 | `PATCH /api/v2/urls/{id}/` | +| すべてのロケーション(URL+依存関係)を一覧表示 | `GET /api/v2/location/?location_type=url` | +| URLを検出事項にリンク | `POST /api/v2/location_findings/` | +| URLをアセットにリンク | `POST /api/v2/location_Assets/` | +| 検出事項リンクのステータスを更新 | `PATCH /api/v2/location_findings/{id}/` | +| 検出事項リンクを削除 | `DELETE /api/v2/location_findings/{id}/` | + +`/api/v2/urls/` のフィルタには、構造化されたURLフィールドに加えて `tag(s)`、`has_tags`、`Asset`、そして `host`、`Asset`、アクティブな検出事項数による並べ替えが含まれます。 + +レガシーの `/api/v2/endpoints/` エンドポイントは、互換シムを通じて引き続き**読み取り**トラフィックを処理します。何が保持され、シムが元の動作とどこで異なるかについては、[エンドポイントからの移行](../pro__migrating_from_endpoints)を参照してください。レガシーエンドポイントへの**書き込み**は `403` を返すため、上記のエンドポイントに移行する必要があります。 + +## スキャンからのURLのインポート + +スキャナーのインポートは、URLロケーションを自動的に作成します。パーサーが(かつてエンドポイントを出力していたのと同じ方法で)検出事項に対してURLを出力すると、インポーターは次の処理を行います。 + +1. 構造化フィールドが一致する既存のURLを検索するか、新規に作成します。 +2. 検出事項をURLにリンクするFinding Referenceを、ステータス**アクティブ**で作成します。 +3. URLが親アセットにも表示されるよう、Asset Referenceを作成(または再利用)します。 + +以前エンドポイントを作成していたDefectDojoのパーサーは、Proにおいてロケーションを自動的に作成するよう更新されています。 + +## 動作が異なる点 + +いくつかの細かな動作の変更に注意してください。 + +- **URL/検出事項のペアごとに1つのステータス。** 上記のとおり、複数フラグのEndpoint_Statusモデルは単一のステータスに集約されます。個々のフラグを独立して切り替えていたワークフローでは、単一の遷移を選ぶ必要があります。 +- **タグはURLではなくロケーションに属します。** URLサブタイプはそれ自体のタグセットを持たず、タグは親のロケーションに属します。APIでURLを読み取ると、`tags` フィールドは `location.tags` に由来します。 +- **重複排除は正規URL単位であり、アセット単位ではありません。** 同じURLを持つ2つのアセットは、単一の基盤となるURLロケーションを共有し、それぞれ(1つずつのAsset Referenceで)2回参照します。これは意図的な設計であり、アセット横断のレポートを可能にしています。 +- **検出事項の `endpoints` フィールド。** このフラグが有効な場合、検出事項APIのこのフィールドは引き続き行を返しますが、それはエンドポイントテーブルではなくURLロケーションから投影されたものです。これは読み取り専用として扱い、書き込みは代わりに `/api/v2/location_findings/` を通じて行ってください。 diff --git a/docs/content/asset_modelling/locations/_index.de.md b/docs/content/asset_modelling/locations/_index.de.md new file mode 100644 index 00000000000..d7a4df3e613 --- /dev/null +++ b/docs/content/asset_modelling/locations/_index.de.md @@ -0,0 +1,12 @@ +--- +title: Locations +description: Asset-Modellierung mit höherer Genauigkeit — URLs, SBOMs und mehr +date: 2026-05-06 00:00:00+00:00 +draft: false +type: docs +audience: pro +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/locations/_index.es.md b/docs/content/asset_modelling/locations/_index.es.md new file mode 100644 index 00000000000..05167c69572 --- /dev/null +++ b/docs/content/asset_modelling/locations/_index.es.md @@ -0,0 +1,12 @@ +--- +title: Locations +description: Modelado de activos de mayor fidelidad — URLs, SBOMs y más allá +date: 2026-05-06 00:00:00+00:00 +draft: false +type: docs +audience: pro +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/locations/_index.fr.md b/docs/content/asset_modelling/locations/_index.fr.md new file mode 100644 index 00000000000..16106c85588 --- /dev/null +++ b/docs/content/asset_modelling/locations/_index.fr.md @@ -0,0 +1,12 @@ +--- +title: Emplacements +description: Modélisation d'actifs à plus haute fidélité — URL, SBOM, et au-delà +date: 2026-05-06 00:00:00+00:00 +draft: false +type: docs +audience: pro +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/locations/_index.ja.md b/docs/content/asset_modelling/locations/_index.ja.md new file mode 100644 index 00000000000..6e5aaeccb2d --- /dev/null +++ b/docs/content/asset_modelling/locations/_index.ja.md @@ -0,0 +1,12 @@ +--- +title: ロケーション +description: より高精度なアセットモデリング — URL、SBOM、その先へ +date: 2026-05-06 00:00:00+00:00 +draft: false +type: docs +audience: pro +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/tags/OS__tagging_objects.de.md b/docs/content/asset_modelling/tags/OS__tagging_objects.de.md new file mode 100644 index 00000000000..c15e18022b3 --- /dev/null +++ b/docs/content/asset_modelling/tags/OS__tagging_objects.de.md @@ -0,0 +1,150 @@ +--- +title: Objekte taggen +description: Verwenden Sie Tags, um eine neue Sicht auf Ihr Datenmodell zu erstellen +draft: false +weight: 2 +exclude_search: false +audience: opensource +--- + +Tags eignen sich hervorragend, um Objekte so zu gruppieren, dass sie sich in kleinere, besser überschaubare Abschnitte filtern lassen. Sie können verwendet werden, um einen Status zu kennzeichnen oder um benutzerdefinierte Gruppen von Organisationen, Assets, Engagements oder Befunden über das gesamte Datenmodell hinweg zu bilden. + +In DefectDojo sind Tags ein zentrales Konzept und gelten als das Mittel zur Organisation +auf jeder Ebene des Datenmodells. + +Hier ein Beispiel mit einem Asset mit zwei Tags und vier Befunden mit jeweils einem Tag: + +![Übersichtsbeispiel für die Verwendung von Tags](images/tags-high-level-example.png) + +### Tag-Formate + +Tags können in jedem der folgenden Formate geschrieben werden: +- StringWithNoSpaces +- string-with-hyphens +- string_with_underscores +- colons:acceptable + +## Tag-Verwaltung + +### Hinzufügen und Entfernen + +Tags lassen sich auf folgende Weise verwalten: + +1. Neue Objekte erstellen oder bearbeiten + + Wenn ein neues Objekt über die UI oder die API erstellt oder bearbeitet wird, gibt es ein Feld + zur Angabe der Tags, die für dieses Objekt gesetzt werden sollen. Dieses Feld ist ein Mehrfachauswahlfeld + mit Autovervollständigung, wodurch sich vorhandene Tags mühelos suchen und hinzufügen lassen. So sieht + das Feld beim Asset aus dem Screenshot im vorherigen Abschnitt aus: + + ![Tag-Verwaltung an einem Objekt](images/tags-management-on-object.png) + +2. Import und Reimport + + Tags können einem Test auch beim Import oder Reimport zugewiesen werden. Das ist besonders nützlich, + wenn der Import per Automatisierung über die API erfolgt, da sich so Details zum Automatisierungslauf + und Tool-Informationen ergänzen lassen, die im Test- oder Befundobjekt selbst nicht direkt erfasst + werden. + + Das Feld sieht genauso aus und verhält sich genauso wie bei einem einzelnen Objekt + +3. Menü „Massenbearbeitung" (nur Befunde) + + Wenn viele Befunde mit demselben Satz von Tags aktualisiert werden müssen, kann das Menü zur + Massenbearbeitung diese Arbeit erleichtern. + + Nehmen wir im folgenden Beispiel an, ich möchte die Tags der beiden Befunde mit dem Tag "tag-group-alpha" auf eine neue Tag-Liste wie diese ["tag-group-charlie", "tag-group-delta"] aktualisieren. + Zunächst wähle ich die zu aktualisierenden Befunde aus: + + ![Befunde für die Massenbearbeitung der Tags auswählen](images/tags-select-findings-for-bulk-edit.png) + + Sobald ein Befund ausgewählt ist, erscheint eine neue Schaltfläche mit dem Namen "Bulk Edit". Ein Klick + auf diese Schaltfläche öffnet ein Dropdown-Menü mit vielen Optionen, wobei der Fokus hier nur auf den + Tags liegt. Aktualisieren Sie das Feld mit der gewünschten Tag-Liste wie folgt und klicken Sie auf + "Absenden" + + ![Änderungen für die Massenbearbeitung der Tags übernehmen](images/tags-bulk-edit-submit.png) + + Die Tags der ausgewählten Befunde werden auf das aktualisiert, was im Tags-Feld des Menüs zur + Massenbearbeitung angegeben wurde + + ![Abgeschlossene Massenbearbeitung der Tags](images/tags-bulk-edit-complete.png) + +## Tag-Vererbung + +Wenn die Tag-Vererbung aktiviert ist, werden Tags, die einem bestimmten Asset zugewiesen sind, automatisch auf alle Objekte unterhalb der Assets in der [Asset-Hierarchie](/asset_modelling/os_hierarchy/os__asset_hierarchy/) angewendet. + +### Konfiguration + +Die Tag-Vererbung kann auf folgenden Geltungsbereichen aktiviert werden: +- Globaler Geltungsbereich + - Jedes Asset im gesamten System beginnt, Tags auf alle untergeordneten Objekte (Engagements, Tests und Befunde) anzuwenden + - Dies wird in den Systemeinstellungen festgelegt +- Asset-Geltungsbereich + - Nur das ausgewählte Asset beginnt, Tags auf alle untergeordneten Objekte (Engagements, Tests und Befunde) anzuwenden + - Dies wird auf der Erstellungs-/Bearbeitungsseite des Assets festgelegt + +### Verhalten + +Wenn die Tag-Vererbung aktiviert ist, können normale Tags wie gewohnt zu Objekten hinzugefügt und von ihnen entfernt werden. +Vererbte Tags lassen sich jedoch nicht von einem untergeordneten Objekt entfernen, ohne sie auch vom übergeordneten Objekt zu entfernen. +Sehen Sie sich das folgende Beispiel an, bei dem ein Tag "test_only_tag" zum Test-Objekt und ein Tag "engagement_only_tag" zum Engagement hinzugefügt wird. + +![Beispiel für vererbte Tags](images/tags-inherit-exmaple.png) + +Wenn die Tag-Liste eines Assets aktualisiert wird, werden dieselben Änderungen asynchron auf alle Objekte innerhalb des Assets angewendet. Die Dauer dieser Aufgabe hängt direkt von der Anzahl der in einem Befund enthaltenen Objekte ab. + +**Open Source:** Wenn Tag-Änderungen nicht innerhalb eines angemessenen Zeitraums sichtbar werden, prüfen Sie die Celery-Worker-Logs, um mögliche Ursachen zu identifizieren. + + +### Filtern nach Tags (klassische UI) + +Tags lassen sich sowohl über die UI als auch über die API auf vielfältige Weise filtern. Hier zum Beispiel +ein Ausschnitt der Befundfilter: + +![Ausschnitt der Befundfilter](images/tags-finding-filter-snippet.png) + +Es gibt zehn Felder im Zusammenhang mit Tags: + + - Tags: filtert nach allen Tags, die einem bestimmten Befund zugeordnet sind + - Beispiele: + - Befund wird zurückgegeben + - Befund-Tags: ["A", "B", "C"] + - Filterabfrage: "B" + - Befund wird *nicht* zurückgegeben + - Befund-Tags: ["A", "B", "C"] + - Filterabfrage: "F" + - Not Tags: filtert nach allen Tags, die einem bestimmten Befund *nicht* zugeordnet sind + - Beispiele: + - Befund wird zurückgegeben + - Befund-Tags: ["A", "B", "C"] + - Filterabfrage: "F" + - Befund wird *nicht* zurückgegeben + - Befund-Tags: ["A", "B", "C"] + - Filterabfrage: "B" + - Tag Name Contains: filtert nach allen Tags eines Befunds, die die Abfrage ganz oder teilweise enthalten + - Beispiele: + - Befund wird zurückgegeben + - Befund-Tags: ["Alpha", "Beta", "Charlie"] + - Filterabfrage: "et" (Teil von "Beta") + - Befund wird *nicht* zurückgegeben + - Befund-Tags: ["Alpha", "Beta", "Charlie"] + - Filterabfrage: "meg" (Teil von "Omega") + - Not Tags: filtert nach allen Tags eines Befunds, die die Abfrage ganz oder teilweise *nicht* enthalten + - Beispiele: + - Befund wird zurückgegeben + - Befund-Tags: ["Alpha", "Beta", "Charlie"] + - Filterabfrage: "meg" (Teil von "Omega") + - Befund wird *nicht* zurückgegeben + - Befund-Tags: ["Alpha", "Beta", "Charlie"] + - Filterabfrage: "et" (Teil von "Beta") + +Die übrigen sechs Tag-Filter folgen denselben Regeln wie "Tags" und "Not Tags" oben, +gelten jedoch für andere Ebenen des Datenmodells: + + - Tags (Test): filtert nach allen Tags, die dem Test eines bestimmten Befunds zugeordnet sind + - Not Tags (Test): filtert nach allen Tags, die dem Test eines bestimmten Befunds *nicht* zugeordnet sind + - Tags (Engagement): filtert nach allen Tags, die dem Engagement eines bestimmten Befunds zugeordnet sind + - Not Tags (Engagement): filtert nach allen Tags, die dem Engagement eines bestimmten Befunds *nicht* zugeordnet sind + - Tags (Asset): filtert nach allen Tags, die dem Asset eines bestimmten Befunds zugeordnet sind + - Not Tags (Asset): filtert nach allen Tags, die dem Asset eines bestimmten Befunds *nicht* zugeordnet sind diff --git a/docs/content/asset_modelling/tags/OS__tagging_objects.es.md b/docs/content/asset_modelling/tags/OS__tagging_objects.es.md new file mode 100644 index 00000000000..5551c537225 --- /dev/null +++ b/docs/content/asset_modelling/tags/OS__tagging_objects.es.md @@ -0,0 +1,150 @@ +--- +title: Etiquetar objetos +description: Use Etiquetas para crear un nuevo corte de su modelo de datos +draft: false +weight: 2 +exclude_search: false +audience: opensource +--- + +Las Etiquetas son ideales para agrupar objetos de forma que puedan filtrarse en fragmentos más pequeños y fáciles de digerir. Pueden usarse para indicar un estado, o para crear conjuntos personalizados de Organizaciones, Activos, Compromisos o Hallazgos en todo el modelo de datos. + +En DefectDojo, las etiquetas son un elemento de primera clase y se reconocen como facilitadoras +de la organización en cada nivel del modelo de datos. + +A continuación se muestra un ejemplo con un Activo con dos etiquetas y cuatro hallazgos, cada uno con una única etiqueta: + +![Ejemplo de alto nivel de uso con etiquetas](images/tags-high-level-example.png) + +### Formatos de etiqueta + +Las etiquetas pueden formatearse de cualquiera de las siguientes maneras: +- StringWithNoSpaces +- string-with-hyphens +- string_with_underscores +- colons:acceptable + +## Gestión de etiquetas + +### Añadir y quitar + +Las etiquetas pueden gestionarse de las siguientes maneras: + +1. Crear o Editar nuevos objetos + + Cuando se crea o edita un nuevo objeto a través de la interfaz o de la API, hay un campo para especificar + las etiquetas que se establecerán en ese objeto. Este campo es un campo de selección múltiple que además + tiene autocompletado, lo que facilita enormemente la búsqueda y adición de etiquetas existentes. Así es + como se ve el campo en el Activo de la captura de pantalla de la sección anterior: + + ![Gestión de etiquetas en un objeto](images/tags-management-on-object.png) + +2. Importar y Reimportar + + Las etiquetas también pueden aplicarse a un test determinado en el momento de la importación o + reimportación. Este es un caso de uso muy útil al importar mediante la API con automatización, ya que + ofrece la posibilidad de añadir detalles de la ejecución de la automatización e información de la + herramienta que puede que no queden recogidos directamente en el objeto test o hallazgo. + + El campo tiene el mismo aspecto y se comporta exactamente igual que en cualquier otro objeto + +3. Menú de Edición masiva (solo Hallazgos) + + Cuando es necesario actualizar muchos Hallazgos con el mismo conjunto de etiquetas, se puede usar el + menú de edición masiva para aliviar la carga de trabajo. + + En el siguiente ejemplo, supongamos que quiero actualizar las etiquetas de los dos hallazgos que tienen + la etiqueta "tag-group-alpha" para que tengan una nueva lista de etiquetas como esta ["tag-group-charlie", "tag-group-delta"]. + Primero seleccionaría las etiquetas que se van a actualizar: + + ![Seleccionar hallazgos para la actualización masiva de etiquetas](images/tags-select-findings-for-bulk-edit.png) + + Una vez seleccionado un hallazgo, aparece un nuevo botón llamado "Bulk Edit". Al hacer clic en este + botón se despliega un menú con muchas opciones, pero por ahora nos centraremos solo en las etiquetas. + Actualice el campo con la lista de etiquetas deseada de la siguiente manera y haga clic en enviar + + ![Aplicar cambios para la actualización masiva de etiquetas](images/tags-bulk-edit-submit.png) + + Las etiquetas de los Hallazgos seleccionados se actualizarán con lo que se haya especificado en el + campo de etiquetas dentro del menú de edición masiva + + ![Actualización masiva de etiquetas completada](images/tags-bulk-edit-complete.png) + +## Herencia de etiquetas + +Cuando la Herencia de etiquetas está habilitada, las etiquetas aplicadas a un Activo determinado se aplicarán automáticamente a todos los objetos bajo los Activos en la [Jerarquía de Activos](/asset_modelling/os_hierarchy/os__asset_hierarchy/). + +### Configuración + +La Herencia de etiquetas puede habilitarse en los siguientes niveles de alcance: +- Alcance global + - Todos los Activos del sistema comenzarán a aplicar etiquetas a todos los objetos hijos (Compromisos, Tests y Hallazgos) + - Esto se configura en la Configuración del Sistema +- Alcance de Activo + - Solo el Activo seleccionado comenzará a aplicar etiquetas a todos los objetos hijos (Compromisos, Tests y Hallazgos) + - Esto se configura en la página de creación/edición del Activo + +### Comportamientos + +Cuando la Herencia de etiquetas está habilitada, las Etiquetas estándar pueden añadirse y eliminarse de los objetos de la forma habitual. +Sin embargo, las etiquetas heredadas no pueden eliminarse de un objeto hijo sin eliminarlas también del objeto padre. +Vea el siguiente ejemplo, en el que se añade una etiqueta "test_only_tag" al objeto Test y una etiqueta "engagement_only_tag" al Compromiso. + +![Ejemplo de etiquetas heredadas](images/tags-inherit-exmaple.png) + +Cuando se realizan actualizaciones en la lista de etiquetas de un Activo, los mismos cambios se aplican de forma asíncrona a todos los objetos dentro del Activo. La duración de esta tarea está directamente relacionada con el número de objetos contenidos dentro de un hallazgo. + +**Código abierto:** Si los cambios de etiquetas no se observan en un período de tiempo razonable, consulte los registros del worker de Celery para identificar dónde pueden haber surgido los problemas. + + +### Filtrar por etiquetas (interfaz clásica) + +Las etiquetas pueden filtrarse de muchas maneras, tanto a través de la interfaz como de la API. Por ejemplo, aquí tiene un fragmento +de los filtros de Hallazgos: + +![Fragmento de los filtros de hallazgos](images/tags-finding-filter-snippet.png) + +Hay diez campos relacionados con las etiquetas: + + - Etiquetas: filtra por cualquier etiqueta que esté adjunta a un Hallazgo determinado + - Ejemplos: + - El Hallazgo se devolverá + - Etiquetas del Hallazgo: ["A", "B", "C"] + - Consulta de filtro: "B" + - El Hallazgo *no* se devolverá + - Etiquetas del Hallazgo: ["A", "B", "C"] + - Consulta de filtro: "F" + - No Etiquetas: filtra por cualquier etiqueta que *no* esté adjunta a un Hallazgo determinado + - Ejemplos: + - El Hallazgo se devolverá + - Etiquetas del Hallazgo: ["A", "B", "C"] + - Consulta de filtro: "F" + - El Hallazgo *no* se devolverá + - Etiquetas del Hallazgo: ["A", "B", "C"] + - Consulta de filtro: "B" + - El nombre de la etiqueta contiene: filtra por cualquier etiqueta que contenga parte o la totalidad de la consulta en el Hallazgo determinado + - Ejemplos: + - El Hallazgo se devolverá + - Etiquetas del Hallazgo: ["Alpha", "Beta", "Charlie"] + - Consulta de filtro: "et" (parte de "Beta") + - El Hallazgo *no* se devolverá + - Etiquetas del Hallazgo: ["Alpha", "Beta", "Charlie"] + - Consulta de filtro: "meg" (parte de "Omega") + - No Etiquetas: filtra por cualquier etiqueta que *no* contenga parte o la totalidad de la consulta en el Hallazgo determinado + - Ejemplos: + - El Hallazgo se devolverá + - Etiquetas del Hallazgo: ["Alpha", "Beta", "Charlie"] + - Consulta de filtro: "meg" (parte de "Omega") + - El Hallazgo *no* se devolverá + - Etiquetas del Hallazgo: ["Alpha", "Beta", "Charlie"] + - Consulta de filtro: "et" (parte de "Beta") + +Para los otros seis filtros de etiquetas, siguen las mismas reglas que "Etiquetas" y "No Etiquetas" descritas anteriormente, +pero en distintos niveles del modelo de datos: + + - Etiquetas (Test): filtra por cualquier etiqueta que esté adjunta al Test de un Hallazgo determinado + - No Etiquetas (Test): filtra por cualquier etiqueta que *no* esté adjunta al Test de un Hallazgo determinado + - Etiquetas (Compromiso): filtra por cualquier etiqueta que esté adjunta al Compromiso de un Hallazgo determinado + - No Etiquetas (Compromiso): filtra por cualquier etiqueta que *no* esté adjunta al Compromiso de un Hallazgo determinado + - Etiquetas (Activo): filtra por cualquier etiqueta que esté adjunta al Activo de un Hallazgo determinado + - No Etiquetas (Activo): filtra por cualquier etiqueta que *no* esté adjunta al Activo de un Hallazgo determinado diff --git a/docs/content/asset_modelling/tags/OS__tagging_objects.fr.md b/docs/content/asset_modelling/tags/OS__tagging_objects.fr.md new file mode 100644 index 00000000000..5be2ea26ea3 --- /dev/null +++ b/docs/content/asset_modelling/tags/OS__tagging_objects.fr.md @@ -0,0 +1,150 @@ +--- +title: Étiqueter les objets +description: Utilisez les Étiquettes pour créer une nouvelle vue de votre modèle de + données +draft: false +weight: 2 +exclude_search: false +audience: opensource +--- + +Les Étiquettes sont idéales pour regrouper des objets de manière à pouvoir les filtrer en ensembles plus petits et plus faciles à traiter. Elles peuvent être utilisées pour indiquer un statut, ou pour créer des ensembles personnalisés d'Organisations, d'Assets, d'Engagements ou de Constatations à travers le modèle de données. + +Dans DefectDojo, les étiquettes sont un concept de premier plan et sont reconnues comme les facilitateurs +de l'organisation à chaque niveau du modèle de données. + +Voici un exemple avec un Asset ayant deux étiquettes et quatre constatations ayant chacune une seule étiquette : + +![High level example of usage with tags](images/tags-high-level-example.png) + +### Formats d'étiquette + +Les étiquettes peuvent être formatées de l'une des manières suivantes : +- ChaîneSansEspaces +- chaine-avec-tirets +- chaine_avec_underscores +- deuxpoints:acceptable + +## Gestion des étiquettes + +### Ajout et suppression + +Les étiquettes peuvent être gérées des manières suivantes : + +1. Création ou modification de nouveaux objets + + Lorsqu'un nouvel objet est créé ou modifié via l'UI ou l'API, un champ permet de spécifier + les étiquettes à définir sur cet objet. Ce champ est un champ à sélection multiple qui dispose également + d'une saisie semi-automatique pour faciliter la recherche et l'ajout d'étiquettes existantes. Voici à quoi ressemble le champ + sur l'Asset de la capture d'écran de la section précédente : + + ![Tag management on an object](images/tags-management-on-object.png) + +2. Importation et réimportation + + Les étiquettes peuvent également être appliquées à un test donné au moment de l'importation ou de la réimportation. C'est un cas d'usage très + pratique lors de l'importation via l'API avec de l'automatisation, car cela permet d'ajouter + des détails d'exécution d'automatisation et des informations sur l'outil qui ne seraient pas capturées directement dans l'objet test + ou constatation. + + Le champ se présente et se comporte exactement comme sur un objet donné + +3. Menu Modification en masse (Constatations uniquement) + + Lorsqu'il faut mettre à jour de nombreuses Constatations avec le même ensemble d'étiquettes, le menu de modification en masse peut être + utilisé pour alléger la tâche. + + Dans l'exemple suivant, supposons que je veuille mettre à jour les étiquettes des deux constatations ayant l'étiquette "tag-group-alpha" avec une nouvelle liste d'étiquettes comme ceci ["tag-group-charlie", "tag-group-delta"]. + Je sélectionnerais d'abord les étiquettes à mettre à jour : + + ![Select findings for bulk edit tag update](images/tags-select-findings-for-bulk-edit.png) + + Une fois une constatation sélectionnée, un nouveau bouton apparaît avec le nom "Bulk Edit". Cliquer sur ce bouton + fait apparaître un menu déroulant avec de nombreuses options, mais on se concentre ici uniquement sur les étiquettes. Mettez à jour le + champ avec la liste d'étiquettes souhaitée comme suit, puis cliquez sur soumettre + + ![Apply changes for bulk edit tag update](images/tags-bulk-edit-submit.png) + + Les étiquettes des Constatations sélectionnées seront mises à jour avec ce qui a été spécifié dans le champ des étiquettes + du menu de modification en masse + + ![Completed bulk edit tag update](images/tags-bulk-edit-complete.png) + +## Héritage des étiquettes + +Lorsque l'Héritage des étiquettes est activé, les étiquettes appliquées à un Asset donné sont automatiquement appliquées à tous les objets sous les Assets dans la [Hiérarchie des Assets](/asset_modelling/os_hierarchy/os__asset_hierarchy/). + +### Configuration + +L'Héritage des étiquettes peut être activé aux niveaux de portée suivants : +- Portée globale + - Chaque Asset, à l'échelle du système, commence à appliquer des étiquettes à tous les objets enfants (Engagements, Tests et Constatations) + - Ceci se configure dans les Paramètres système +- Portée Asset + - Seul l'Asset sélectionné commence à appliquer des étiquettes à tous les objets enfants (Engagements, Tests et Constatations) + - Ceci se configure sur la page de création/modification de l'Asset + +### Comportements + +Lorsque l'Héritage des étiquettes est activé, les Étiquettes standard peuvent être ajoutées à ou supprimées des objets de la manière habituelle. +Cependant, les étiquettes héritées ne peuvent pas être supprimées d'un objet enfant sans les supprimer de l'objet parent +Voir l'exemple suivant, d'ajout d'une étiquette "test_only_tag" à l'objet Test et d'une étiquette "engagement_only_tag" à l'Engagement. + +![Example of inherited tags](images/tags-inherit-exmaple.png) + +Lorsque des mises à jour sont effectuées sur la liste d'étiquettes d'un Asset, les mêmes modifications sont appliquées à tous les objets de l'Asset de manière asynchrone. La durée de cette tâche est directement corrélée au nombre d'objets contenus dans une constatation. + +**Open-Source :** Si les modifications d'étiquettes ne sont pas observées dans un délai raisonnable, consultez les journaux du worker celery pour identifier l'origine d'éventuels problèmes. + + +### Filtrage par étiquettes (UI classique) + +Les étiquettes peuvent être filtrées de nombreuses manières, à la fois via l'UI et l'API. Par exemple, voici un extrait +des filtres de Constatation : + +![Snippet of the finding filters](images/tags-finding-filter-snippet.png) + +Il existe dix champs liés aux étiquettes : + + - Tags : filtre sur toute étiquette rattachée à une Constatation donnée + - Exemples : + - La Constatation sera retournée + - Étiquettes de la Constatation : ["A", "B", "C"] + - Requête de filtre : "B" + - La Constatation ne sera *pas* retournée + - Étiquettes de la Constatation : ["A", "B", "C"] + - Requête de filtre : "F" + - Not Tags : filtre sur toute étiquette *non* rattachée à une Constatation donnée + - Exemples : + - La Constatation sera retournée + - Étiquettes de la Constatation : ["A", "B", "C"] + - Requête de filtre : "F" + - La Constatation ne sera *pas* retournée + - Étiquettes de la Constatation : ["A", "B", "C"] + - Requête de filtre : "B" + - Tag Name Contains : filtre sur toute étiquette contenant tout ou partie de la requête dans la Constatation donnée + - Exemples : + - La Constatation sera retournée + - Étiquettes de la Constatation : ["Alpha", "Beta", "Charlie"] + - Requête de filtre : "et" (partie de "Beta") + - La Constatation ne sera *pas* retournée + - Étiquettes de la Constatation : ["Alpha", "Beta", "Charlie"] + - Requête de filtre : "meg" (partie de "Omega") + - Not Tags : filtre sur toute étiquette qui ne contient *pas* tout ou partie de la requête dans la Constatation donnée + - Exemples : + - La Constatation sera retournée + - Étiquettes de la Constatation : ["Alpha", "Beta", "Charlie"] + - Requête de filtre : "meg" (partie de "Omega") + - La Constatation ne sera *pas* retournée + - Étiquettes de la Constatation : ["Alpha", "Beta", "Charlie"] + - Requête de filtre : "et" (partie de "Beta") + +Pour les six autres filtres d'étiquettes, ils suivent les mêmes règles que "Tags" et "Not Tags" ci-dessus, +mais à différents niveaux du modèle de données : + + - Tags (Test) : filtre sur toute étiquette rattachée au Test d'une Constatation donnée + - Not Tags (Test) : filtre sur toute étiquette *non* rattachée au Test d'une Constatation donnée + - Tags (Engagement) : filtre sur toute étiquette rattachée à l'Engagement d'une Constatation donnée + - Not Tags (Engagement) : filtre sur toute étiquette *non* rattachée à l'Engagement d'une Constatation donnée + - Tags (Asset) : filtre sur toute étiquette rattachée à l'Asset d'une Constatation donnée + - Not Tags (Asset) : filtre sur toute étiquette *non* rattachée à l'Asset d'une Constatation donnée diff --git a/docs/content/asset_modelling/tags/OS__tagging_objects.ja.md b/docs/content/asset_modelling/tags/OS__tagging_objects.ja.md new file mode 100644 index 00000000000..9af34565fec --- /dev/null +++ b/docs/content/asset_modelling/tags/OS__tagging_objects.ja.md @@ -0,0 +1,133 @@ +--- +title: オブジェクトへのタグ付け +description: タグを使用してデータモデルの新しい切り口を作成する +draft: false +weight: 2 +exclude_search: false +audience: opensource +--- + +タグは、オブジェクトをより小さく扱いやすい単位にフィルタできる形でグループ化するのに最適な方法です。ステータスを示すために使用したり、Organizations、Assets、Engagements、Findingsといったデータモデル全体にわたるカスタムなまとまりを作成したりするために使用できます。 + +DefectDojoでは、タグはファーストクラスの存在として扱われており、データモデルの各階層内で整理を促進する仕組みとして認識されています。 + +以下は、2つのタグを持つ1つのAssetと、それぞれ1つずつタグを持つ4つの検出事項の例です。 + +![High level example of usage with tags](images/tags-high-level-example.png) + +### タグの形式 + +タグは以下のいずれの形式でも指定できます。 +- スペースなしの文字列(StringWithNoSpaces) +- ハイフン区切りの文字列(string-with-hyphens) +- アンダースコア区切りの文字列(string_with_underscores) +- コロンを含む形式(colons:acceptable) + +## タグの管理 + +### 追加と削除 + +タグは以下の方法で管理できます。 + +1. 新しいオブジェクトの作成または編集 + + UIまたはAPIを通じて新しいオブジェクトを作成または編集する際、そのオブジェクトに設定するタグを指定するためのフィールドがあります。このフィールドはマルチセレクト形式で、オートコンプリート機能も備えているため、既存のタグを簡単に検索・追加できます。前のセクションのスクリーンショットにあるAssetでは、このフィールドは次のように表示されます。 + + ![Tag management on an object](images/tags-management-on-object.png) + +2. インポートおよび再インポート + + タグは、インポートまたは再インポートの時点で特定のテストに適用することもできます。これは、自動化によりAPI経由でインポートする際に非常に便利なユースケースです。テストや検出事項オブジェクト自体には直接記録されない可能性がある、自動化実行の詳細情報やツール情報を追加する機会になるためです。 + + このフィールドの見た目と動作は、他のオブジェクトの場合とまったく同じです。 + +3. 一括編集メニュー(検出事項のみ) + + 多数の検出事項に同じタグのセットを設定したい場合、一括編集メニューを使用することで手間を軽減できます。 + + 次の例では、タグ「tag-group-alpha」が付いた2つの検出事項のタグを、新しいタグリスト["tag-group-charlie", "tag-group-delta"]に更新したいとします。まず、更新対象のタグ(検出事項)を選択します。 + + ![Select findings for bulk edit tag update](images/tags-select-findings-for-bulk-edit.png) + + 検出事項を選択すると、「Bulk Edit」という名前の新しいボタンが表示されます。このボタンをクリックすると、多数のオプションを持つドロップダウンメニューが表示されますが、ここではタグのみに注目します。以下のように、フィールドを希望のタグリストに更新し、送信をクリックします。 + + ![Apply changes for bulk edit tag update](images/tags-bulk-edit-submit.png) + + 選択した検出事項のタグは、一括編集メニュー内のタグフィールドで指定した内容に更新されます。 + + ![Completed bulk edit tag update](images/tags-bulk-edit-complete.png) + +## タグの継承 + +タグの継承(Tag Inheritance)が有効な場合、特定のAssetに適用されたタグは、[Asset Hierarchy](/asset_modelling/os_hierarchy/os__asset_hierarchy/)内のそのAsset配下にあるすべてのオブジェクトに自動的に適用されます。 + +### 設定 + +タグの継承は、以下のスコープレベルで有効にできます。 +- グローバルスコープ + - システム全体のすべてのAssetが、すべての子オブジェクト(Engagements、Tests、Findings)にタグを適用するようになります + - これはSystem Settings内で設定します +- Assetスコープ + - 選択したAssetのみが、すべての子オブジェクト(Engagements、Tests、Findings)にタグを適用するようになります + - これはAssetの作成/編集ページで設定します + +### 動作 + +タグの継承が有効な場合でも、標準的なタグは通常の方法でオブジェクトに追加・削除できます。ただし、継承されたタグは、親オブジェクトから削除しない限り、子オブジェクトから削除することはできません。以下は、Testオブジェクトに「test_only_tag」タグを、Engagementに「engagement_only_tag」タグを追加した例です。 + +![Example of inherited tags](images/tags-inherit-exmaple.png) + +Asset上のタグリストが更新されると、Asset内のすべてのオブジェクトに対しても非同期で同じ変更が行われます。このタスクにかかる時間は、検出事項に含まれるオブジェクトの数に直接比例します。 + +**オープンソース版:** タグの変更が妥当な時間内に反映されない場合は、celeryワーカーのログを確認し、問題の発生箇所を特定してください。 + + +### タグによるフィルタリング(クラシックUI) + +タグは、UIとAPIの両方を通じてさまざまな方法でフィルタできます。例えば、以下はFindingフィルタの一部です。 + +![Snippet of the finding filters](images/tags-finding-filter-snippet.png) + +タグに関連するフィールドは10種類あります。 + + - Tags:特定の検出事項に付与されているタグでフィルタします + - 例: + - 検出事項が返される場合 + - 検出事項のタグ:["A", "B", "C"] + - フィルタクエリ:"B" + - 検出事項が返され*ない*場合 + - 検出事項のタグ:["A", "B", "C"] + - フィルタクエリ:"F" + - Not Tags:特定の検出事項に付与され*ていない*タグでフィルタします + - 例: + - 検出事項が返される場合 + - 検出事項のタグ:["A", "B", "C"] + - フィルタクエリ:"F" + - 検出事項が返され*ない*場合 + - 検出事項のタグ:["A", "B", "C"] + - フィルタクエリ:"B" + - Tag Name Contains:特定の検出事項において、クエリの一部または全部を含むタグでフィルタします + - 例: + - 検出事項が返される場合 + - 検出事項のタグ:["Alpha", "Beta", "Charlie"] + - フィルタクエリ:"et"("Beta"の一部) + - 検出事項が返され*ない*場合 + - 検出事項のタグ:["Alpha", "Beta", "Charlie"] + - フィルタクエリ:"meg"("Omega"の一部) + - Not Tags:特定の検出事項において、クエリの一部または全部を含ま*ない*タグでフィルタします + - 例: + - 検出事項が返される場合 + - 検出事項のタグ:["Alpha", "Beta", "Charlie"] + - フィルタクエリ:"meg"("Omega"の一部) + - 検出事項が返され*ない*場合 + - 検出事項のタグ:["Alpha", "Beta", "Charlie"] + - フィルタクエリ:"et"("Beta"の一部) + +他の6つのタグフィルタについては、上記の「Tags」および「Not Tags」と同じルールに従いますが、データモデル内の異なる階層に適用されます。 + + - Tags (Test):特定の検出事項のTestに付与されているタグでフィルタします + - Not Tags (Test):特定の検出事項のTestに付与され*ていない*タグでフィルタします + - Tags (Engagement):特定の検出事項のEngagementに付与されているタグでフィルタします + - Not Tags (Engagement):特定の検出事項のEngagementに付与され*ていない*タグでフィルタします + - Tags (Asset):特定の検出事項のAssetに付与されているタグでフィルタします + - Not Tags (Asset):特定の検出事項のAssetに付与され*ていない*タグでフィルタします diff --git a/docs/content/asset_modelling/tags/PRO__tagging_objects copy.de.md b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.de.md new file mode 100644 index 00000000000..82d0dcc306b --- /dev/null +++ b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.de.md @@ -0,0 +1,167 @@ +--- +title: Objekte mit Tags versehen +description: Nutzen Sie Tags, um eine neue Sicht auf Ihr Datenmodell zu erstellen +draft: false +weight: 2 +exclude_search: false +audience: pro +aliases: +- /de/en/working_with_findings/organizing_engagements_tests/tagging_objects +--- + +Tags eignen sich hervorragend, um Objekte so zu gruppieren, dass sie sich in kleinere, leichter überschaubare Abschnitte filtern lassen. Sie können verwendet werden, um einen Status zu kennzeichnen oder um benutzerdefinierte Gruppen aus Produkttyp, Produkten, Engagements oder Findings über das gesamte Datenmodell hinweg zu erstellen. + +In DefectDojo sind Tags ein zentrales Konzept und gelten als die treibende Kraft der Organisation auf jeder Ebene des Datenmodells. + +Hier ist ein Beispiel für ein Produkt mit zwei Tags und vier Findings, die jeweils ein einzelnes Tag haben: + +![Übersichtsbeispiel für die Verwendung von Tags](images/tags-high-level-example.png) + +### Tag-Formate + +Tags können in einem der folgenden Formate geschrieben werden: +- StringWithNoSpaces +- string-with-hyphens +- string_with_underscores +- colons:acceptable + +## Tag-Verwaltung (Pro UI) + +### Hinzufügen und Entfernen + +Tags können auf folgende Weise verwaltet werden: + +1. **Neue Objekte erstellen oder bearbeiten** + + Wenn ein neues Objekt über die Benutzeroberfläche oder die API erstellt oder bearbeitet wird, gibt es ein Feld, in dem die für dieses Objekt festzulegenden Tags angegeben werden können. + + ![tag](images/tags_product.png) + +2. **Beim Importieren/Reimportieren von Findings** + + Tags stehen auf dem Import-/Reimport-Formular sowohl in der Benutzeroberfläche als auch über die API zur Verfügung. Wenn dieses Formular abgeschickt wird, wird der **Test** mit `[tag]` und `[daily-import]` getaggt. Wenn "Apply Tags to Findings" oder "Apply Tags to Endpoints" ausgewählt ist, werden auch diese Objekte getaggt. Tags bieten die Möglichkeit, Details zum Automatisierungslauf und Tool-Informationen zu ergänzen, die nicht direkt im Test- oder Finding-Objekt erfasst werden. + + ![tag](images/tags_importscan.png) + +3. **Über Bulk Edit** + + Wenn in einer Tabelle mehrere Findings ausgewählt werden, können Sie über das Menü Bulk Edit die zugehörigen Tags für viele Findings gleichzeitig ändern. Beachten Sie, dass dadurch alle Tags auf Finding-Ebene durch die angegebenen Tags ersetzt werden; vorhandene Finding-Tags werden überschrieben. + + ![Massenbearbeitung von Findings](images/Bulk_Editing_Findings.png) + + +## Tag-Verwaltung (Classic UI / Open Source) + +### Hinzufügen und Entfernen + +Tags können auf folgende Weise verwaltet werden: + +1. Neue Objekte erstellen oder bearbeiten + + Wenn ein neues Objekt über die Benutzeroberfläche oder die API erstellt oder bearbeitet wird, gibt es ein Feld, in dem die für dieses Objekt festzulegenden Tags angegeben werden können. Dieses Feld ist ein Mehrfachauswahlfeld, das außerdem über eine Autovervollständigung verfügt, mit der sich vorhandene Tags mühelos suchen und hinzufügen lassen. So sieht das Feld beim Produkt aus dem Screenshot im vorherigen Abschnitt aus: + + ![Tag-Verwaltung an einem Objekt](images/tags-management-on-object.png) + +2. Import und Reimport + + Tags können einem bestimmten Test auch zum Zeitpunkt des Imports oder Reimports zugewiesen werden. Das ist ein sehr nützlicher Anwendungsfall beim Importieren über die API mit Automatisierung, da es die Möglichkeit bietet, Details zum Automatisierungslauf und Tool-Informationen zu ergänzen, die nicht direkt im Test- oder Finding-Objekt erfasst werden. + + Das Feld sieht genauso aus und verhält sich genauso wie bei einem einzelnen Objekt + +3. Menü Bulk Edit (nur Findings) + + Wenn viele Findings mit demselben Tag-Satz aktualisiert werden müssen, kann das Bulk-Edit-Menü die Arbeit erleichtern. + + Nehmen wir im folgenden Beispiel an, ich möchte die Tags der beiden Findings mit dem Tag "tag-group-alpha" durch eine neue Tag-Liste wie diese ["tag-group-charlie", "tag-group-delta"] ersetzen. + Zuerst wähle ich die zu aktualisierenden Findings aus: + + ![Auswahl von Findings für die Bulk-Edit-Tag-Aktualisierung](images/tags-select-findings-for-bulk-edit.png) + + Sobald ein Finding ausgewählt ist, erscheint eine neue Schaltfläche mit der Bezeichnung "Bulk Edit". Ein Klick auf diese Schaltfläche öffnet ein Dropdown-Menü mit vielen Optionen; hier konzentrieren wir uns jedoch nur auf die Tags. Aktualisieren Sie das Feld wie folgt mit der gewünschten Tag-Liste, und klicken Sie auf Absenden + + ![Änderungen für die Bulk-Edit-Tag-Aktualisierung übernehmen](images/tags-bulk-edit-submit.png) + + Die Tags der ausgewählten Findings werden auf die im Tags-Feld des Bulk-Edit-Menüs angegebenen Werte aktualisiert + + ![Abgeschlossene Bulk-Edit-Tag-Aktualisierung](images/tags-bulk-edit-complete.png) + +## Tag-Vererbung + +**Hinweis zur Pro-UI: Obwohl die Tag-Vererbung über die Pro-UI konfiguriert werden kann, lassen sich vererbte Tags derzeit nur über die Classic UI oder die API einsehen und filtern.** + +Wenn die Tag-Vererbung aktiviert ist, werden Tags, die einem bestimmten Produkt zugewiesen wurden, automatisch auf alle Objekte unterhalb der Produkte in der [Produkthierarchie](/asset_modelling/os_hierarchy/product_hierarchy/) angewendet. + +### Konfiguration + +Die Tag-Vererbung kann auf den folgenden Geltungsbereichen aktiviert werden: +- Globaler Geltungsbereich + - Jedes Produkt im gesamten System beginnt, Tags auf alle untergeordneten Objekte (Engagements, Tests und Findings) anzuwenden + - Dies wird in den System Settings festgelegt +- Produkt-Geltungsbereich + - Nur das ausgewählte Produkt beginnt, Tags auf alle untergeordneten Objekte (Engagements, Tests und Findings) anzuwenden + - Dies wird auf der Seite zum Erstellen/Bearbeiten des Produkts festgelegt + +### Verhalten + +Wenn die Tag-Vererbung aktiviert ist, können normale Tags weiterhin auf die übliche Weise zu Objekten hinzugefügt und von ihnen entfernt werden. +Vererbte Tags können jedoch nicht von einem untergeordneten Objekt entfernt werden, ohne sie auch vom übergeordneten Objekt zu entfernen +Sehen Sie sich das folgende Beispiel an, bei dem ein Tag "test_only_tag" zum Test-Objekt und ein Tag "engagement_only_tag" zum Engagement hinzugefügt wird. + +![Beispiel für vererbte Tags](images/tags-inherit-exmaple.png) + +Wenn die Tag-Liste eines Produkts aktualisiert wird, werden dieselben Änderungen asynchron auf alle Objekte innerhalb des Produkts angewendet. Die Dauer dieser Aufgabe hängt direkt von der Anzahl der in einem Finding enthaltenen Objekte ab. + +**Open Source:** Wenn Tag-Änderungen nicht innerhalb eines angemessenen Zeitraums sichtbar werden, prüfen Sie die Celery-Worker-Logs, um mögliche Fehlerursachen zu identifizieren. + + +### Nach Tags filtern (Classic UI) + +Tags können sowohl über die Benutzeroberfläche als auch über die API auf viele Arten gefiltert werden. Hier sehen Sie beispielsweise einen Ausschnitt +der Finding-Filter: + +![Ausschnitt der Finding-Filter](images/tags-finding-filter-snippet.png) + +Es gibt zehn Felder, die sich auf Tags beziehen: + + - Tags: Filtert nach allen Tags, die einem bestimmten Finding zugeordnet sind + - Beispiele: + - Das Finding wird zurückgegeben + - Finding Tags: ["A", "B", "C"] + - Filter Query: "B" + - Das Finding wird *nicht* zurückgegeben + - Finding Tags: ["A", "B", "C"] + - Filter Query: "F" + - Not Tags: Filtert nach allen Tags, die einem bestimmten Finding *nicht* zugeordnet sind + - Beispiele: + - Das Finding wird zurückgegeben + - Finding Tags: ["A", "B", "C"] + - Filter Query: "F" + - Das Finding wird *nicht* zurückgegeben + - Finding Tags: ["A", "B", "C"] + - Filter Query: "B" + - Tag Name Contains: Filtert nach allen Tags im gegebenen Finding, die die Suchanfrage ganz oder teilweise enthalten + - Beispiele: + - Das Finding wird zurückgegeben + - Finding Tags: ["Alpha", "Beta", "Charlie"] + - Filter Query: "et" (Teil von "Beta") + - Das Finding wird *nicht* zurückgegeben + - Finding Tags: ["Alpha", "Beta", "Charlie"] + - Filter Query: "meg" (Teil von "Omega") + - Not Tags: Filtert nach allen Tags im gegebenen Finding, die die Suchanfrage *nicht* ganz oder teilweise enthalten + - Beispiele: + - Das Finding wird zurückgegeben + - Finding Tags: ["Alpha", "Beta", "Charlie"] + - Filter Query: "meg" (Teil von "Omega") + - Das Finding wird *nicht* zurückgegeben + - Finding Tags: ["Alpha", "Beta", "Charlie"] + - Filter Query: "et" (Teil von "Beta") + +Für die übrigen sechs Tag-Filter gelten dieselben Regeln wie oben für "Tags" und "Not Tags", +jedoch auf unterschiedlichen Ebenen des Datenmodells: + + - Tags (Test): Filtert nach allen Tags, die dem Test eines bestimmten Findings zugeordnet sind + - Not Tags (Test): Filtert nach allen Tags, die dem Test eines bestimmten Findings *nicht* zugeordnet sind + - Tags (Engagement): Filtert nach allen Tags, die dem Engagement eines bestimmten Findings zugeordnet sind + - Not Tags (Engagement): Filtert nach allen Tags, die dem Engagement eines bestimmten Findings *nicht* zugeordnet sind + - Tags (Product): Filtert nach allen Tags, die dem Produkt eines bestimmten Findings zugeordnet sind + - Not Tags (Product): Filtert nach allen Tags, die dem Produkt eines bestimmten Findings *nicht* zugeordnet sind diff --git a/docs/content/asset_modelling/tags/PRO__tagging_objects copy.es.md b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.es.md new file mode 100644 index 00000000000..3df87b29010 --- /dev/null +++ b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.es.md @@ -0,0 +1,179 @@ +--- +title: Etiquetado de objetos +description: Utilice las Etiquetas para crear un nuevo corte de su modelo de datos +draft: false +weight: 2 +exclude_search: false +audience: pro +aliases: +- /es/en/working_with_findings/organizing_engagements_tests/tagging_objects +--- + +Las Etiquetas son ideales para agrupar objetos de manera que puedan filtrarse en fragmentos más pequeños y manejables. Pueden usarse para indicar el estado o para crear conjuntos personalizados de Tipo de producto, Productos, Compromisos o Hallazgos en todo el modelo de datos. + +En DefectDojo, las etiquetas son un elemento de primera clase y se reconocen como los facilitadores +de la organización dentro de cada nivel del modelo de datos. + +Aquí tiene un ejemplo con un Producto con dos etiquetas y cuatro hallazgos, cada uno con una única etiqueta: + +![Ejemplo de alto nivel de uso con etiquetas](images/tags-high-level-example.png) + +### Formatos de etiqueta + +Las etiquetas se pueden formatear de cualquiera de las siguientes maneras: +- StringWithNoSpaces +- string-with-hyphens +- string_with_underscores +- colons:acceptable + +## Gestión de etiquetas (Pro UI) + +### Agregar y quitar + +Las etiquetas se pueden gestionar de las siguientes maneras: + +1. **Creación o edición de objetos nuevos** + + Cuando se crea o edita un objeto nuevo a través de la UI o la API, hay un campo para especificar + las etiquetas que se establecerán en un objeto determinado. + + ![etiqueta](images/tags_product.png) + +2. **Al importar/reimportar Hallazgos** + + Las etiquetas están disponibles en el formulario de importación/reimportación, tanto en la UI como a través de la API. Cuando se envía este formulario, el **Test** se etiquetará con `[tag]` y `[daily-import]`. Si se selecciona "Aplicar etiquetas a Hallazgos" o "Aplicar etiquetas a Endpoints", esos objetos también se etiquetarán. Las etiquetas ofrecen la oportunidad de agregar detalles de la ejecución de automatización e información de la herramienta que puede no capturarse directamente en el objeto Test o Hallazgo. + + ![etiqueta](images/tags_importscan.png) + +3. **Mediante edición masiva** + + Cuando se seleccionan muchos Hallazgos en una tabla, puede usar el menú de edición masiva para cambiar las Etiquetas asociadas de muchos Hallazgos simultáneamente. Tenga en cuenta que esto reemplazará todas las Etiquetas a nivel de Hallazgo por las Etiquetas especificadas; las Etiquetas de Hallazgo existentes se sobrescribirán. + + ![edición masiva de hallazgos](images/Bulk_Editing_Findings.png) + + +## Gestión de etiquetas (Classic UI / OpenSource) + +### Agregar y quitar + +Las etiquetas se pueden gestionar de las siguientes maneras: + +1. Creación o edición de objetos nuevos + + Cuando se crea o edita un objeto nuevo a través de la UI o la API, hay un campo para especificar + las etiquetas que se establecerán en un objeto determinado. Este campo es un campo de selección múltiple que también cuenta con + autocompletado para facilitar la búsqueda y adición de etiquetas existentes. Así es como se ve el campo + en el Producto de la captura de pantalla de la sección anterior: + + ![Gestión de etiquetas en un objeto](images/tags-management-on-object.png) + +2. Importar y reimportar + + Las etiquetas también se pueden aplicar a un test determinado en el momento de la importación o reimportación. Este es un caso de uso + muy útil al importar a través de la API con automatización, ya que ofrece la oportunidad de + agregar detalles de la ejecución de automatización e información de la herramienta que puede no capturarse directamente en el objeto + test o hallazgo. + + El campo se ve y se comporta exactamente igual que en cualquier otro objeto + +3. Menú de edición masiva (solo Hallazgos) + + Cuando se necesita actualizar muchos Hallazgos con el mismo conjunto de etiquetas, se puede + usar el menú de edición masiva para aliviar la carga. + + En el siguiente ejemplo, supongamos que quiero actualizar las etiquetas de los dos hallazgos con la etiqueta "tag-group-alpha" a una nueva lista de etiquetas como esta ["tag-group-charlie", "tag-group-delta"]. + Primero seleccionaría las etiquetas a actualizar: + + ![Seleccionar hallazgos para la actualización de etiquetas mediante edición masiva](images/tags-select-findings-for-bulk-edit.png) + + Una vez que se selecciona un hallazgo, aparece un nuevo botón con el nombre "Bulk Edit". Al hacer clic en este botón + aparece un menú desplegable con muchas opciones, pero por ahora nos centraremos solo en las etiquetas. Actualice el + campo con la lista de etiquetas deseada de la siguiente manera y haga clic en enviar + + ![Aplicar cambios para la actualización de etiquetas mediante edición masiva](images/tags-bulk-edit-submit.png) + + Las etiquetas de los Hallazgos seleccionados se actualizarán con lo que se haya especificado en el campo de etiquetas + dentro del menú de edición masiva + + ![Actualización de etiquetas mediante edición masiva completada](images/tags-bulk-edit-complete.png) + +## Herencia de etiquetas + +**Nota de Pro UI: aunque la herencia de etiquetas se puede configurar mediante la Pro UI, actualmente las Etiquetas heredadas solo se pueden acceder y filtrar a través de la Classic UI o la API.** + +Cuando la herencia de etiquetas está habilitada, las etiquetas aplicadas a un Producto determinado se aplicarán automáticamente a todos los objetos bajo Productos en la [Jerarquía de productos](/asset_modelling/os_hierarchy/product_hierarchy/). + +### Configuración + +La herencia de etiquetas se puede habilitar en los siguientes niveles de alcance: +- Alcance global + - Todos los Productos del sistema comenzarán a aplicar etiquetas a todos los objetos secundarios (Compromisos, Tests y Hallazgos) + - Esto se establece dentro de la Configuración del sistema +- Alcance de producto + - Solo el Producto seleccionado comenzará a aplicar etiquetas a todos los objetos secundarios (Compromisos, Tests y Hallazgos) + - Esto se establece en la página de creación/edición del Producto + +### Comportamientos + +Cuando la herencia de etiquetas está habilitada, las Etiquetas estándar se pueden agregar y quitar de los objetos de la manera habitual. +Sin embargo, las etiquetas heredadas no se pueden quitar de un objeto secundario sin quitarlas del objeto principal +Vea el siguiente ejemplo de cómo agregar una etiqueta "test_only_tag" al objeto Test y una etiqueta "engagement_only_tag" al Compromiso. + +![Ejemplo de etiquetas heredadas](images/tags-inherit-exmaple.png) + +Cuando se realizan actualizaciones en la lista de etiquetas de un Producto, los mismos cambios se aplican de forma asíncrona a todos los objetos dentro del Producto. La duración de esta tarea está directamente relacionada con la cantidad de objetos contenidos dentro de un hallazgo. + +**Open-Source:** Si los cambios de Etiquetas no se observan dentro de un período de tiempo razonable, consulte los registros del worker de celery para identificar dónde podrían haber surgido los problemas. + + +### Filtrado por etiquetas (Classic UI) + +Las etiquetas se pueden filtrar de muchas maneras tanto a través de la UI como de la API. Por ejemplo, aquí hay un fragmento +de los filtros de Hallazgo: + +![Fragmento de los filtros de hallazgo](images/tags-finding-filter-snippet.png) + +Hay diez campos relacionados con las etiquetas: + + - Tags: filtra por cualquier etiqueta adjunta a un Hallazgo determinado + - Ejemplos: + - El Hallazgo se devolverá + - Etiquetas del hallazgo: ["A", "B", "C"] + - Consulta de filtro: "B" + - El Hallazgo *no* se devolverá + - Etiquetas del hallazgo: ["A", "B", "C"] + - Consulta de filtro: "F" + - Not Tags: filtra por cualquier etiqueta que *no* esté adjunta a un Hallazgo determinado + - Ejemplos: + - El Hallazgo se devolverá + - Etiquetas del hallazgo: ["A", "B", "C"] + - Consulta de filtro: "F" + - El Hallazgo *no* se devolverá + - Etiquetas del hallazgo: ["A", "B", "C"] + - Consulta de filtro: "B" + - Tag Name Contains: filtra por cualquier etiqueta que contenga parte o la totalidad de la consulta en el Hallazgo determinado + - Ejemplos: + - El Hallazgo se devolverá + - Etiquetas del hallazgo: ["Alpha", "Beta", "Charlie"] + - Consulta de filtro: "et" (parte de "Beta") + - El Hallazgo *no* se devolverá + - Etiquetas del hallazgo: ["Alpha", "Beta", "Charlie"] + - Consulta de filtro: "meg" (parte de "Omega") + - Not Tags: filtra por cualquier etiqueta que *no* contenga parte o la totalidad de la consulta en el Hallazgo determinado + - Ejemplos: + - El Hallazgo se devolverá + - Etiquetas del hallazgo: ["Alpha", "Beta", "Charlie"] + - Consulta de filtro: "meg" (parte de "Omega") + - El Hallazgo *no* se devolverá + - Etiquetas del hallazgo: ["Alpha", "Beta", "Charlie"] + - Consulta de filtro: "et" (parte de "Beta") + +Para los otros seis filtros de etiquetas, se aplican las mismas reglas que para "Tags" y "Not Tags" descritas arriba, +pero en diferentes niveles del modelo de datos: + + - Tags (Test): filtra por cualquier etiqueta adjunta al Test de un Hallazgo determinado + - Not Tags (Test): filtra por cualquier etiqueta que *no* esté adjunta al Test de un Hallazgo determinado + - Tags (Engagement): filtra por cualquier etiqueta adjunta al Compromiso de un Hallazgo determinado + - Not Tags (Engagement): filtra por cualquier etiqueta que *no* esté adjunta al Compromiso de un Hallazgo determinado + - Tags (Product): filtra por cualquier etiqueta adjunta al Producto de un Hallazgo determinado + - Not Tags (Product): filtra por cualquier etiqueta que *no* esté adjunta al Producto de un Hallazgo determinado diff --git a/docs/content/asset_modelling/tags/PRO__tagging_objects copy.fr.md b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.fr.md new file mode 100644 index 00000000000..67af19ad7bd --- /dev/null +++ b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.fr.md @@ -0,0 +1,180 @@ +--- +title: Étiquetage des objets +description: Utilisez les étiquettes pour créer une nouvelle tranche de votre modèle + de données +draft: false +weight: 2 +exclude_search: false +audience: pro +aliases: +- /fr/en/working_with_findings/organizing_engagements_tests/tagging_objects +--- + +Les étiquettes sont idéales pour regrouper des objets de manière à pouvoir les filtrer en ensembles plus petits et plus faciles à assimiler. Elles peuvent être utilisées pour indiquer un statut, ou pour créer des ensembles personnalisés de Type de produit, Produits, Engagements ou Constatations dans l'ensemble du modèle de données. + +Dans DefectDojo, les étiquettes sont un élément de première classe et sont reconnues comme les facilitateurs +de l'organisation à chaque niveau du modèle de données. + +Voici un exemple avec un Produit ayant deux étiquettes et quatre constatations ayant chacune une seule étiquette : + +![Exemple général d'utilisation des étiquettes](images/tags-high-level-example.png) + +### Formats d'étiquettes + +Les étiquettes peuvent être formatées de l'une des manières suivantes : +- ChaîneSansEspaces +- chaine-avec-tirets +- chaine_avec_underscores +- deuxpoints:acceptable + +## Gestion des étiquettes (interface Pro) + +### Ajout et suppression + +Les étiquettes peuvent être gérées des manières suivantes : + +1. **Création ou modification de nouveaux objets** + + Lorsqu'un nouvel objet est créé ou modifié via l'interface ou l'API, un champ permet de spécifier + les étiquettes à définir sur un objet donné. + + ![étiquette](images/tags_product.png) + +2. **Lors de l'importation/réimportation de constatations** + + Les étiquettes sont disponibles sur le formulaire d'importation/réimportation, à la fois dans l'interface et via l'API. Lorsque ce formulaire est soumis, le **Test** sera étiqueté avec `[tag]` et `[daily-import]`. Si « Apply Tags to Findings » ou « Apply Tags to Endpoints » est sélectionné, ces objets seront également étiquetés. Les étiquettes offrent la possibilité d'ajouter des détails d'exécution d'automatisation et des informations sur l'outil qui pourraient ne pas être capturées directement dans l'objet Test ou Constatation. + + ![étiquette](images/tags_importscan.png) + +3. **Via la modification en masse** + + Lorsque plusieurs constatations sont sélectionnées dans un tableau, vous pouvez utiliser le menu de modification en masse pour modifier les étiquettes associées à plusieurs constatations simultanément. Notez que cela remplacera toutes les étiquettes au niveau de la constatation par les étiquettes spécifiées ; les étiquettes existantes seront écrasées. + + ![modification en masse des constatations](images/Bulk_Editing_Findings.png) + + +## Gestion des étiquettes (interface classique / Open Source) + +### Ajout et suppression + +Les étiquettes peuvent être gérées des manières suivantes : + +1. Création ou modification de nouveaux objets + + Lorsqu'un nouvel objet est créé ou modifié via l'interface ou l'API, un champ permet de spécifier + les étiquettes à définir sur un objet donné. Ce champ est un champ à sélection multiple qui dispose également + d'une saisie semi-automatique pour faciliter la recherche et l'ajout d'étiquettes existantes. Voici à quoi + ressemble ce champ sur le Produit de la capture d'écran de la section précédente : + + ![Gestion des étiquettes sur un objet](images/tags-management-on-object.png) + +2. Import et réimportation + + Les étiquettes peuvent également être appliquées à un test donné au moment de l'importation ou de la réimportation. C'est un cas d'usage + très pratique lors de l'importation via l'API avec automatisation, car cela offre l'occasion d'ajouter + des détails d'exécution d'automatisation et des informations sur l'outil qui pourraient ne pas être capturées + directement dans l'objet test ou constatation. + + Le champ se présente et se comporte exactement comme sur un objet donné + +3. Menu de modification en masse (constatations uniquement) + + Lorsqu'il est nécessaire de mettre à jour plusieurs constatations avec le même ensemble d'étiquettes, le menu de modification en masse peut être + utilisé pour alléger la tâche. + + Dans l'exemple suivant, supposons que je souhaite mettre à jour les étiquettes des deux constatations portant l'étiquette « tag-group-alpha » avec une nouvelle liste d'étiquettes comme ceci ["tag-group-charlie", "tag-group-delta"]. + Je commencerais par sélectionner les étiquettes à mettre à jour : + + ![Sélection des constatations pour la mise à jour d'étiquettes en masse](images/tags-select-findings-for-bulk-edit.png) + + Une fois qu'une constatation est sélectionnée, un nouveau bouton nommé « Bulk Edit » apparaît. Cliquer sur ce bouton + fait apparaître un menu déroulant proposant de nombreuses options, mais l'attention se porte ici uniquement sur les étiquettes. Modifiez le + champ pour qu'il contienne la liste d'étiquettes souhaitée comme suit, puis cliquez sur soumettre + + ![Application des modifications pour la mise à jour d'étiquettes en masse](images/tags-bulk-edit-submit.png) + + Les étiquettes des constatations sélectionnées seront mises à jour avec ce qui a été spécifié dans le champ des étiquettes + du menu de modification en masse + + ![Mise à jour d'étiquettes en masse terminée](images/tags-bulk-edit-complete.png) + +## Héritage des étiquettes + +**Remarque sur l'interface Pro : bien que l'héritage des étiquettes puisse être configuré via l'interface Pro, les étiquettes héritées ne peuvent actuellement être consultées et filtrées que via l'interface classique ou l'API.** + +Lorsque l'héritage des étiquettes est activé, les étiquettes appliquées à un Produit donné seront automatiquement appliquées à tous les objets sous ce Produit dans la [hiérarchie des produits](/asset_modelling/os_hierarchy/product_hierarchy/). + +### Configuration + +L'héritage des étiquettes peut être activé aux niveaux de portée suivants : +- Portée globale + - Chaque Produit du système entier commencera à appliquer des étiquettes à tous les objets enfants (Engagements, Tests et Constatations) + - Ceci est configuré dans les Paramètres système +- Portée du produit + - Seul le Produit sélectionné commencera à appliquer des étiquettes à tous les objets enfants (Engagements, Tests et Constatations) + - Ceci est configuré sur la page de création/modification du Produit + +### Comportements + +Lorsque l'héritage des étiquettes est activé, les étiquettes standard peuvent être ajoutées et supprimées des objets de la manière habituelle. +Cependant, les étiquettes héritées ne peuvent pas être supprimées d'un objet enfant sans les supprimer de l'objet parent. +Voir l'exemple suivant d'ajout d'une étiquette « test_only_tag » à l'objet Test et d'une étiquette « engagement_only_tag » à l'Engagement. + +![Exemple d'étiquettes héritées](images/tags-inherit-exmaple.png) + +Lorsque des mises à jour sont effectuées sur la liste d'étiquettes d'un Produit, les mêmes modifications sont appliquées de manière asynchrone à tous les objets au sein du Produit. La durée de cette tâche est directement corrélée au nombre d'objets contenus dans une constatation. + +**Open Source :** Si les modifications d'étiquettes ne sont pas observées dans un délai raisonnable, consultez les journaux du worker celery pour identifier l'origine d'éventuels problèmes. + + +### Filtrage par étiquettes (interface classique) + +Les étiquettes peuvent être filtrées de nombreuses manières, à la fois via l'interface et l'API. Par exemple, voici un extrait +des filtres de constatation : + +![Extrait des filtres de constatation](images/tags-finding-filter-snippet.png) + +Il existe dix champs liés aux étiquettes : + + - Tags : filtre sur toutes les étiquettes attachées à une constatation donnée + - Exemples : + - La constatation sera renvoyée + - Étiquettes de la constatation : ["A", "B", "C"] + - Requête de filtre : "B" + - La constatation *ne* sera *pas* renvoyée + - Étiquettes de la constatation : ["A", "B", "C"] + - Requête de filtre : "F" + - Not Tags : filtre sur toutes les étiquettes qui *ne* sont *pas* attachées à une constatation donnée + - Exemples : + - La constatation sera renvoyée + - Étiquettes de la constatation : ["A", "B", "C"] + - Requête de filtre : "F" + - La constatation *ne* sera *pas* renvoyée + - Étiquettes de la constatation : ["A", "B", "C"] + - Requête de filtre : "B" + - Tag Name Contains : filtre sur toutes les étiquettes qui contiennent tout ou partie de la requête dans la constatation donnée + - Exemples : + - La constatation sera renvoyée + - Étiquettes de la constatation : ["Alpha", "Beta", "Charlie"] + - Requête de filtre : "et" (partie de "Beta") + - La constatation *ne* sera *pas* renvoyée + - Étiquettes de la constatation : ["Alpha", "Beta", "Charlie"] + - Requête de filtre : "meg" (partie de "Omega") + - Not Tags : filtre sur toutes les étiquettes qui *ne* contiennent *pas* tout ou partie de la requête dans la constatation donnée + - Exemples : + - La constatation sera renvoyée + - Étiquettes de la constatation : ["Alpha", "Beta", "Charlie"] + - Requête de filtre : "meg" (partie de "Omega") + - La constatation *ne* sera *pas* renvoyée + - Étiquettes de la constatation : ["Alpha", "Beta", "Charlie"] + - Requête de filtre : "et" (partie de "Beta") + +Pour les six autres filtres d'étiquettes, ils suivent les mêmes règles que « Tags » et « Not Tags » ci-dessus, +mais à différents niveaux du modèle de données : + + - Tags (Test) : filtre sur toutes les étiquettes attachées au Test d'une constatation donnée + - Not Tags (Test) : filtre sur toutes les étiquettes qui *ne* sont *pas* attachées au Test d'une constatation donnée + - Tags (Engagement) : filtre sur toutes les étiquettes attachées à l'Engagement d'une constatation donnée + - Not Tags (Engagement) : filtre sur toutes les étiquettes qui *ne* sont *pas* attachées à l'Engagement d'une constatation donnée + - Tags (Product) : filtre sur toutes les étiquettes attachées au Produit d'une constatation donnée + - Not Tags (Product) : filtre sur toutes les étiquettes qui *ne* sont *pas* attachées au Produit d'une constatation donnée diff --git a/docs/content/asset_modelling/tags/PRO__tagging_objects copy.ja.md b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.ja.md new file mode 100644 index 00000000000..52c985f675c --- /dev/null +++ b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.ja.md @@ -0,0 +1,162 @@ +--- +title: オブジェクトへのタグ付け +description: タグを使用してデータモデルの新しいスライスを作成します +draft: false +weight: 2 +exclude_search: false +audience: pro +aliases: +- /ja/en/working_with_findings/organizing_engagements_tests/tagging_objects +--- + +タグは、オブジェクトをフィルタリングして、より小さく扱いやすい単位にグループ化するのに理想的です。ステータスを示すためや、データモデル全体にわたって製品タイプ、製品、エンゲージメント、検出事項のカスタムセットを作成するために使用できます。 + +DefectDojoでは、タグはファーストクラスの存在として扱われ、データモデルの各レベルにおける整理を促進する仕組みとして認識されています。 + +以下は、2つのタグを持つ製品と、それぞれ1つのタグを持つ4件の検出事項の例です。 + +![High level example of usage with tags](images/tags-high-level-example.png) + +### タグの形式 + +タグは以下のいずれかの形式でフォーマットできます。 +- StringWithNoSpaces +- string-with-hyphens +- string_with_underscores +- colons:acceptable + +## タグの管理(Pro UI) + +### 追加と削除 + +タグは以下の方法で管理できます。 + +1. **新しいオブジェクトの作成または編集** + + UIまたはAPIを通じて新しいオブジェクトを作成または編集する際、そのオブジェクトに設定するタグを指定するフィールドがあります。 + + ![tag](images/tags_product.png) + +2. **検出事項のインポート/再インポート時** + + タグは、UIとAPIの両方でインポート/再インポートフォームから利用できます。このフォームが送信されると、**テスト**には`[tag]`と`[daily-import]`のタグが付けられます。「検出事項にタグを適用」または「エンドポイントにタグを適用」が選択されている場合、それらのオブジェクトにもタグが付けられます。タグは、テストや検出事項オブジェクト自体には直接記録されない可能性がある自動化の実行の詳細やツール情報を追加する機会を提供します。 + + ![tag](images/tags_importscan.png) + +3. **一括編集を利用** + + テーブルから多数の検出事項を選択した場合、一括編集メニューを使用して、それら複数の検出事項に関連付けられたタグを一度に変更できます。これにより、指定したタグで検出事項レベルのすべてのタグが置き換えられる点に注意してください。既存の検出事項のタグは上書きされます。 + + ![bulk editing findings](images/Bulk_Editing_Findings.png) + + +## タグの管理(クラシックUI / オープンソース) + +### 追加と削除 + +タグは以下の方法で管理できます。 + +1. 新しいオブジェクトの作成または編集 + + UIまたはAPIを通じて新しいオブジェクトを作成または編集する際、そのオブジェクトに設定するタグを指定するフィールドがあります。このフィールドはマルチセレクトフィールドであり、既存のタグの検索や追加を簡単に行えるオートコンプリート機能も備えています。前のセクションのスクリーンショットにある製品では、このフィールドは次のように表示されます。 + + ![Tag management on an object](images/tags-management-on-object.png) + +2. インポートと再インポート + + タグは、インポートまたは再インポート時に特定のテストに適用することもできます。これは、自動化を用いてAPI経由でインポートする際に非常に便利なユースケースであり、テストや検出事項オブジェクト自体には直接記録されない可能性がある自動化の実行の詳細やツール情報を追加する機会を提供します。 + + このフィールドの見た目と動作は、他のオブジェクトの場合とまったく同じです。 + +3. 一括編集メニュー(検出事項のみ) + + 同じタグのセットで多数の検出事項を更新する必要がある場合、一括編集メニューを使用して手間を軽減できます。 + + 次の例では、タグ「tag-group-alpha」を持つ2件の検出事項のタグを、新しいタグリスト["tag-group-charlie", "tag-group-delta"]に更新したいとします。まず、更新するタグを持つ検出事項を選択します。 + + ![Select findings for bulk edit tag update](images/tags-select-findings-for-bulk-edit.png) + + 検出事項が選択されると、「一括編集」という名前の新しいボタンが表示されます。このボタンをクリックすると、多くのオプションを含むドロップダウンメニューが表示されますが、ここではタグのみに焦点を当てます。次のようにフィールドを目的のタグリストに更新し、送信をクリックします。 + + ![Apply changes for bulk edit tag update](images/tags-bulk-edit-submit.png) + + 選択した検出事項のタグは、一括編集メニュー内のタグフィールドで指定した内容に更新されます。 + + ![Completed bulk edit tag update](images/tags-bulk-edit-complete.png) + +## タグの継承 + +**Pro UIに関する注記:タグの継承はPro UIで設定できますが、継承されたタグは現在のところ、クラシックUIまたはAPIを通じてのみアクセスおよびフィルタリングが可能です。** + +タグの継承が有効になっている場合、ある製品に適用されたタグは、[製品階層](/asset_modelling/os_hierarchy/product_hierarchy/)内でその製品配下にあるすべてのオブジェクトに自動的に適用されます。 + +### 設定 + +タグの継承は、以下のスコープレベルで有効にできます。 +- グローバルスコープ + - システム全体のすべての製品が、すべての子オブジェクト(エンゲージメント、テスト、検出事項)へのタグの適用を開始します。 + - これはシステム設定内で設定されます。 +- 製品スコープ + - 選択した製品のみが、すべての子オブジェクト(エンゲージメント、テスト、検出事項)へのタグの適用を開始します。 + - これは製品の作成/編集ページで設定されます。 + +### 動作 + +タグの継承が有効な場合、標準のタグは通常の方法でオブジェクトに追加および削除できます。ただし、継承されたタグは、親オブジェクトから削除しない限り、子オブジェクトから削除することはできません。次の例では、テストオブジェクトに「test_only_tag」タグを、エンゲージメントに「engagement_only_tag」タグを追加しています。 + +![Example of inherited tags](images/tags-inherit-exmaple.png) + +製品のタグリストが更新されると、同じ変更が製品内のすべてのオブジェクトに非同期的に適用されます。このタスクにかかる時間は、検出事項に含まれるオブジェクトの数に直接相関します。 + +**オープンソース:** タグの変更が妥当な時間内に反映されない場合は、celeryワーカーのログを確認して、問題が発生した箇所を特定してください。 + + +### タグのフィルタリング(クラシックUI) + +タグは、UIとAPIの両方を通じて多くの方法でフィルタリングできます。例えば、以下は検出事項フィルターの抜粋です。 + +![Snippet of the finding filters](images/tags-finding-filter-snippet.png) + +タグに関連するフィールドは10個あります。 + + - タグ:指定した検出事項に付けられているタグでフィルタリングします。 + - 例: + - 検出事項が返される場合 + - 検出事項のタグ:["A", "B", "C"] + - フィルタークエリ:"B" + - 検出事項が返され*ない*場合 + - 検出事項のタグ:["A", "B", "C"] + - フィルタークエリ:"F" + - タグではない:指定した検出事項に付けられて*いない*タグでフィルタリングします。 + - 例: + - 検出事項が返される場合 + - 検出事項のタグ:["A", "B", "C"] + - フィルタークエリ:"F" + - 検出事項が返され*ない*場合 + - 検出事項のタグ:["A", "B", "C"] + - フィルタークエリ:"B" + - タグ名に含む:指定した検出事項において、クエリの一部または全部を含むタグでフィルタリングします。 + - 例: + - 検出事項が返される場合 + - 検出事項のタグ:["Alpha", "Beta", "Charlie"] + - フィルタークエリ:"et"("Beta"の一部) + - 検出事項が返され*ない*場合 + - 検出事項のタグ:["Alpha", "Beta", "Charlie"] + - フィルタークエリ:"meg"("Omega"の一部) + - タグではない(名前に含まない):指定した検出事項において、クエリの一部または全部を含ま*ない*タグでフィルタリングします。 + - 例: + - 検出事項が返される場合 + - 検出事項のタグ:["Alpha", "Beta", "Charlie"] + - フィルタークエリ:"meg"("Omega"の一部) + - 検出事項が返され*ない*場合 + - 検出事項のタグ:["Alpha", "Beta", "Charlie"] + - フィルタークエリ:"et"("Beta"の一部) + +他の6つのタグフィルターは、上記の「タグ」および「タグではない」と同じルールに従いますが、データモデル内の異なるレベルに適用されます。 + + - タグ(テスト):指定した検出事項のテストに付けられているタグでフィルタリングします。 + - タグではない(テスト):指定した検出事項のテストに付けられて*いない*タグでフィルタリングします。 + - タグ(エンゲージメント):指定した検出事項のエンゲージメントに付けられているタグでフィルタリングします。 + - タグではない(エンゲージメント):指定した検出事項のエンゲージメントに付けられて*いない*タグでフィルタリングします。 + - タグ(製品):指定した検出事項の製品に付けられているタグでフィルタリングします。 + - タグではない(製品):指定した検出事項の製品に付けられて*いない*タグでフィルタリングします。 diff --git a/docs/content/asset_modelling/tags/_index.de.md b/docs/content/asset_modelling/tags/_index.de.md new file mode 100644 index 00000000000..e14bb290d3f --- /dev/null +++ b/docs/content/asset_modelling/tags/_index.de.md @@ -0,0 +1,8 @@ +--- +title: Tags +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/asset_modelling/tags/_index.es.md b/docs/content/asset_modelling/tags/_index.es.md new file mode 100644 index 00000000000..0b80cd771ab --- /dev/null +++ b/docs/content/asset_modelling/tags/_index.es.md @@ -0,0 +1,8 @@ +--- +title: Etiquetas +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/asset_modelling/tags/_index.fr.md b/docs/content/asset_modelling/tags/_index.fr.md new file mode 100644 index 00000000000..534afce081c --- /dev/null +++ b/docs/content/asset_modelling/tags/_index.fr.md @@ -0,0 +1,8 @@ +--- +title: Étiquettes +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/asset_modelling/tags/_index.ja.md b/docs/content/asset_modelling/tags/_index.ja.md new file mode 100644 index 00000000000..26662a276e2 --- /dev/null +++ b/docs/content/asset_modelling/tags/_index.ja.md @@ -0,0 +1,8 @@ +--- +title: タグ +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/automation/api/_index.de.md b/docs/content/automation/api/_index.de.md new file mode 100644 index 00000000000..9da57944f95 --- /dev/null +++ b/docs/content/automation/api/_index.de.md @@ -0,0 +1,16 @@ +--- +title: Automatisierung +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- diff --git a/docs/content/automation/api/_index.es.md b/docs/content/automation/api/_index.es.md new file mode 100644 index 00000000000..39279923f4b --- /dev/null +++ b/docs/content/automation/api/_index.es.md @@ -0,0 +1,16 @@ +--- +title: Automatización +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- diff --git a/docs/content/automation/api/_index.fr.md b/docs/content/automation/api/_index.fr.md new file mode 100644 index 00000000000..4644f7d23d2 --- /dev/null +++ b/docs/content/automation/api/_index.fr.md @@ -0,0 +1,16 @@ +--- +title: Automatisation +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- diff --git a/docs/content/automation/api/_index.ja.md b/docs/content/automation/api/_index.ja.md new file mode 100644 index 00000000000..fa1e8e37a5f --- /dev/null +++ b/docs/content/automation/api/_index.ja.md @@ -0,0 +1,16 @@ +--- +title: 自動化 +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- diff --git a/docs/content/automation/api/api-v2-docs.de.md b/docs/content/automation/api/api-v2-docs.de.md new file mode 100644 index 00000000000..9a982ba21a1 --- /dev/null +++ b/docs/content/automation/api/api-v2-docs.de.md @@ -0,0 +1,419 @@ +--- +title: DefectDojo API v2 +description: Mit der API von DefectDojo können Sie Aufgaben automatisieren, z. B. + das Hochladen von Scan-Berichten in CI/CD-Pipelines. +draft: false +weight: 2 +aliases: +- /de/en/api/api-v2-docs +--- + +Die API von DefectDojo wurde mit dem [Django Rest +Framework](http://www.django-rest-framework.org/) erstellt. Die Dokumentation der +einzelnen Endpunkte ist in jeder DefectDojo-Installation unter +[`/api/v2/oa3/swagger-ui`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/) verfügbar und kann über den Link „API v2 +Docs" im Benutzer-Dropdown-Menü in der Kopfzeile aufgerufen werden. + +![image](images/api_v2_1.png) + +Die Dokumentation wird mit [drf-spectacular](https://drf-spectacular.readthedocs.io/) unter [`/api/v2/oa3/swagger-ui/`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/) generiert und ist +interaktiv. Oben in den API-v2-Docs befindet sich ein Link, der eine OpenAPI-v3-Spezifikation generiert. + +Um mit der Dokumentation zu interagieren, wird ein gültiger Authorization-Header-Wert +benötigt. Rufen Sie die Ansicht `/api/key-v2` auf, um Ihren +API-Schlüssel (`Token `) zu generieren, und kopieren Sie den bereitgestellten Header-Wert. + +![image](images/api_v2_2.png) + +Jeder Abschnitt ermöglicht es Ihnen, Aufrufe an die API zu senden und die Request- +URL, den Response-Body, den Response-Code und die Response-Headers anzuzeigen. + +![image](images/api_v2_3.png) + +Wenn Sie in der Web-UI von DefectDojo angemeldet sind, müssen Sie das Authorization-Token nicht angeben. + +## Authentifizierung + +Die API verwendet eine Header-Authentifizierung mit API-Schlüssel. Das Format des +Headers sollte lauten: : + + Authorization: Token + +Zum Beispiel: : + + Authorization: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +### Alternative Authentifizierungsmethode + +Wenn Sie für Benutzer [eine alternative Authentifizierungsmethode](/admin/sso/) verwenden, sollten Sie DefectDojo-API-Tokens möglicherweise deaktivieren, da diese Ihr Authentifizierungskonzept umgehen könnten. \ +Die Verwendung von DefectDojo-API-Tokens kann deaktiviert werden, indem die Umgebungsvariable `DD_API_TOKENS_ENABLED` auf `False` gesetzt wird. +Oder es kann nur der Endpunkt `api/v2/api-token-auth/` deaktiviert werden, indem `DD_API_TOKEN_AUTH_ENDPOINT_ENABLED` auf `False` gesetzt wird. + +## Beispielcode + +Hier sind einige einfache Python-Beispiele und die damit erzeugten Ergebnisse für +den Endpunkt `/users`: : + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +Dieser Code gibt die Liste aller in DefectDojo definierten Benutzer zurück. +Das JSON-Objekt-Ergebnis sieht folgendermaßen aus: : + +{{< highlight json >}} + [ + { + "first_name": "Tyagi", + "id": 22, + "last_login": "2019-06-18T08:05:51.925743", + "last_name": "Paz", + "username": "dev7958" + }, + { + "first_name": "saurabh", + "id": 31, + "last_login": "2019-06-06T11:44:32.533035", + "last_name": "", + "username": "saurabh.paz" + } + ] +{{< /highlight >}} + +Hier ist ein weiteres Beispiel für den Endpunkt `/users`. Diesmal +filtern wir die Ergebnisse so, dass nur Benutzer angezeigt werden, deren Benutzername +`jay` enthält: + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users/?username__contains=jay' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +Das JSON-Objekt-Ergebnis lautet: : + +{{< highlight json >}} +[ + { + "first_name": "Jay", + "id": 22, + "last_login": "2015-10-28T08:05:51.925743", + "last_name": "Paz", + "username": "jay7958" + }, + { + "first_name": "", + "id": 31, + "last_login": "2015-10-13T11:44:32.533035", + "last_name": "", + "username": "jay.paz" + } +] +{{< /highlight >}} + +Weitere Beispiele und Tipps finden Sie in der [Dokumentation des Django Rest +Frameworks zur Interaktion mit einer +API](https://www.django-rest-framework.org/). + +## Manuelles Aufrufen der API + +Tools wie Postman können zum Testen der API verwendet werden. + +Beispiel für den Import eines Scan-Ergebnisses: + +- Verb: POST +- URI: +- Registerkarte „Headers": + + Fügen Sie den Authentifizierungsheader hinzu + : - Key: Authorization + - Value: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +- Registerkarte „Body" + + - Wählen Sie \"form-data\" aus, klicken Sie auf \"bulk edit\". Beispiel für einen ZAP-Scan: + + + + engagement:3 + verified:true + active:true + lead:1 + tags:test + scan_type:ZAP Scan + minimum_severity:Info + close_old_findings:false + +- Registerkarte „Body" + + - Klicken Sie auf die Bearbeitung \"Key-value\" + - Fügen Sie einen Parameter \"file\" vom Typ \"file\" hinzu. Dadurch werden + Multipart-Formulardaten zum Senden des Dateiinhalts ausgelöst + - Suchen Sie die hochzuladende Datei + +- Klicken Sie auf Senden + +## Clients / API-Wrapper + +| Wrapper | Status | Hinweise | +| -----------------------------| ------------------------| ------------------------| +| [Spezifischer Python-Wrapper](https://github.com/DefectDojo/defectdojo_api) | funktionsfähig (2021-01-21) | API-Wrapper einschließlich Skripten für kontinuierliches CI/CD-Uploading. Hinkt bei den neuesten API-Funktionen etwas hinterher, da eine Überarbeitung des API-Wrappers geplant ist | +| [Openapi-Python-Wrapper](https://github.com/alles-klar/defectdojo-api-v2-client) | | nur ein Proof of Concept, bei dem wir festgestellt haben, dass die OpenAPI-Spezifikation noch nicht perfekt ist | +| [Java-Bibliothek](https://github.com/secureCodeBox/defectdojo-client-java) | funktionsfähig (2021-08-30) | Erstellt von den freundlichen Leuten von [SecureCodeBox](https://github.com/secureCodeBox/secureCodeBox) | +| [Image mit der Java-Bibliothek](https://github.com/SDA-SE/defectdojo-client) | funktionsfähig (2021-08-30) | | +| [.Net/C#-Bibliothek](https://www.nuget.org/packages/DefectDojo.Api/) | funktionsfähig (2021-06-08) | | +| [dd-import](https://github.com/MaibornWolff/dd-import) | funktionsfähig (2021-08-24) | dd-import ist nicht direkt ein API-Wrapper. Es bietet einige praktische Funktionen, mit denen sich Befunde und Sprachdaten aus CI/CD-Pipelines einfacher importieren lassen. | + +Einige der API-Wrapper enthalten recht viel Logik, um das Scannen und Importieren in CI/CD-Umgebungen zu erleichtern. Wir sind dabei, dies zu vereinfachen, indem wir die DefectDojo-API intelligenter machen (damit API-Wrapper/Skripte einfacher gehalten werden können). + +## API-Hinweise + +### Import / Reimport + +**Reimport** ist eigentlich der einfachste Weg, um loszulegen, da dabei bei Bedarf automatisch alle nötigen Entitäten erstellt werden und automatisch erkannt wird, ob es sich um einen erstmaligen Upload oder einen erneuten Upload handelt. + +## Import +Der Import über die API erfolgt über den Endpunkt [import-scan](https://demo.defectdojo.org/api/v2/doc/). + +Wie in der [Produkthierarchie](/asset_modelling/os_hierarchy/product_hierarchy/) beschrieben, wird ein Test innerhalb eines Engagements erstellt, das wiederum innerhalb eines Produkts liegt, das wiederum innerhalb eines Produkttyps liegt. + +Ein Import kann durchgeführt werden, indem die Namen dieser Entitäten in der API-Anfrage angegeben werden: + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, +} +``` + +Wenn `auto_create_context` auf `True` gesetzt ist, werden das Produkt, das Engagement und die Umgebung bei Bedarf erstellt. Stellen Sie sicher, dass Ihr Benutzer über ausreichende [Berechtigungen](/admin/user_management/about_perms_and_roles/) dafür verfügt. + +Eine klassische Methode zum Importieren eines Scans besteht darin, stattdessen die ID des Engagements anzugeben: + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "engagement": 123, +} +``` + +## Reimport +Der Reimport über die API erfolgt über den Endpunkt [reimport-scan](https://demo.defectdojo.org/api/v2/doc/). + +Ein Reimport kann durchgeführt werden, indem die Namen dieser Entitäten in der API-Anfrage angegeben werden: + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, + "do_not_reactivate": False, +} +``` + +Wenn `auto_create_context` auf `True` gesetzt ist, werden der Produkttyp, das Produkt und das Engagement erstellt, sofern sie noch nicht existieren. Stellen Sie sicher, dass Ihr Benutzer über ausreichende [Berechtigungen](/admin/user_management/about_perms_and_roles/) zum Erstellen eines Produkts/Produkttyps verfügt. + +Wenn `do_not_reactivate` auf `True` gesetzt ist, ignorieren Import/Reimport hochgeladene aktive Befunde und reaktivieren zuvor geschlossene Befunde nicht, erstellen aber weiterhin neue Befunde, sofern welche vorhanden sind. Sie erhalten am Befund einen Hinweis, der erklärt, dass er aus diesem Grund nicht reaktiviert wurde. + +Ein Reimport wählt automatisch den neuesten Test innerhalb des angegebenen Engagements aus, der dem angegebenen `scan_type` und (optional) dem angegebenen `test_title` entspricht. + +Wird kein vorhandener Test gefunden, verwendet der Reimport-Endpunkt die Import-Funktion, um den bereitgestellten Bericht in einen neuen Test zu importieren. Das bedeutet, dass ein (CI/CD-)Skript, das die API verwendet, nicht wissen muss, ob bereits ein Test existiert oder ob es sich um einen erstmaligen Upload für dieses Produkt/Engagement handelt. + +Eine klassische Methode zum Reimportieren eines Scans besteht darin, stattdessen die ID des Tests anzugeben: + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test": 123, +} +``` + +## Berichte erstellen + +DefectDojo kann über die API einen Befundbericht im Format **JSON**, **HTML**, **CSV** oder **Excel** erstellen. + +Ein Bericht wird mit einer `POST`-Anfrage an eine `generate_report/`-Aktion erstellt. Der Endpunkt für Befunde berichtet instanzweit, und die meisten anderen Objekte bieten eine objektspezifische Aktion: + +| Endpunkt | Umfang | +|---|---| +| `POST /api/v2/findings/generate_report/` | Jeder Befund, den Sie einsehen dürfen | +| `POST /api/v2/products/{id}/generate_report/` | Ein Produkt | +| `POST /api/v2/engagements/{id}/generate_report/` | Ein Engagement | +| `POST /api/v2/tests/{id}/generate_report/` | Ein Test | +| `POST /api/v2/product_types/{id}/generate_report/` | Ein Produkttyp | +| `POST /api/v2/endpoints/{id}/generate_report/` | Ein Endpunkt | + +Die Pro-Objekt-Aliase bieten dieselbe Aktion: `/api/v2/assets/{id}/generate_report/`, `/api/v2/organizations/{id}/generate_report/` und `/api/v2/location/{id}/generate_report/`. + +### Anfrageoptionen + +Alle Felder sind optional – das Senden eines leeren Bodys (`{}`) liefert einen JSON-Bericht. + +| Feld | Typ | Standard | Beschreibung | +|---|---|---|---| +| `report_type` | string | `JSON` | Einer von `JSON`, `HTML`, `CSV`, `Excel`. | +| `include_finding_notes` | boolean | `false` | Notizen zu jedem Befund einschließen. | +| `include_finding_images` | boolean | `false` | An Befunde angehängte Bilder einschließen. | +| `include_executive_summary` | boolean | `false` | Einen Abschnitt mit einer Management-Zusammenfassung einschließen. | +| `include_table_of_contents` | boolean | `false` | Ein Inhaltsverzeichnis einschließen. | + +Ein nicht unterstützter `report_type` (zum Beispiel `PDF`) liefert `400 Bad Request` mit einem Fehler im Feld `report_type`. + +### Beispiel + +Erstellen Sie einen CSV-Bericht aller Befunde, die Sie einsehen können, und speichern Sie ihn in einer Datei: + +```bash +curl -X POST \ + -H "Authorization: Token " \ + -H "Content-Type: application/json" \ + -d '{"report_type": "CSV"}' \ + https:///api/v2/findings/generate_report/ \ + -o findings.csv +``` + +### Antwortformate + +| `report_type` | Content-Type | Antwort | +|---|---|---| +| `JSON` (Standard) | `application/json` | Berichtsinhalt in der Antwort | +| `HTML` | `text/html` | Gerenderte Berichtsseite | +| `CSV` | `text/csv` | Dateianhang | +| `Excel` | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` | `.xlsx`-Dateianhang | + +CSV und Excel werden als Dateianhänge mit einem `Content-Disposition`-Header zurückgegeben und nicht als JSON-Body. Der Dateiname leitet sich von dem Objekt ab, für das der Bericht erstellt wurde – zum Beispiel `product_1_findings.csv` oder `test_42_findings.xlsx`. Der Endpunkt `/findings/generate_report/` ist nicht auf ein einzelnes Objekt beschränkt, daher heißen seine Downloads `findings.csv` und `findings.xlsx`. + +### Hinweise und Einschränkungen + +* Die `include_*`-Optionen wirken sich nur auf die **JSON**- und **HTML**-Berichte aus. Die **CSV**- und **Excel**-Exporte enthalten immer die Befundzeilen. +* Für die Berichtserstellung ist die Berechtigung **view** für die betroffenen Objekte erforderlich, und ein Bericht enthält nur Befunde, die Sie einsehen dürfen. +* **Standard-Query-Parameter-Filter werden auf diese Aktion nicht angewendet.** Anders als bei `GET /api/v2/findings/` wendet die Aktion `generate_report/` die Finding-Filter nicht an, sodass eine Anfrage wie `POST /api/v2/findings/generate_report/?severity=High` weiterhin über jeden Befund berichtet, den Sie einsehen können. Um einen Bericht einzugrenzen, erstellen Sie ihn stattdessen aus einem bestimmten Produkt, Engagement oder Test. + +## Asynchrones Löschverhalten + +Löschvorgänge in DefectDojo (sowohl über die API als auch über die UI) werden **asynchron** von Celery-Hintergrund-Workern verarbeitet. Wenn Sie ein Engagement, einen Test oder ein anderes Objekt löschen, liefert die API oder UI sofort eine Erfolgsmeldung, die eigentliche Löschung läuft jedoch im Hintergrund. + +Das bedeutet: +- Objekte können nach der Bestätigung der Löschung noch eine Zeit lang in Abfragen erscheinen. +- Kaskadierende Löschungen (z. B. löscht das Löschen eines Engagements auch dessen Tests und Befunde) werden als eine Kette von Hintergrundaufgaben verarbeitet. Untergeordnete Objekte werden in Abhängigkeitsreihenfolge entfernt: zuerst Befunde, dann Tests, dann Engagements. +- Bei großen Engagements mit vielen Befunden kann dieser Vorgang mehrere Minuten dauern. + +Es ist nicht nötig, eigene Skripte zu erstellen, um Objekte in Abhängigkeitsreihenfolge zu löschen. Eine einzelne `DELETE`-Anfrage für ein Engagement kaskadiert automatisch auf alle untergeordneten Objekte. Geben Sie den Hintergrundaufgaben einfach genug Zeit, um abgeschlossen zu werden. + +## API-Paginierungslimits + +DefectDojo Pro erzwingt eine maximale Seitengröße von **250** Ergebnissen pro API-Anfrage. Wird `limit` höher als 250 gesetzt, kann dies aufgrund von Abfrage-Timeouts zu HTTP-502-Fehlern führen. + +Open-Source-DefectDojo-Instanzen können bei sehr großen Seitengrößen ebenfalls Timeouts erleben, abhängig von der Datensatzgröße und den Serverressourcen. + +Verwenden Sie bei großen Ergebnismengen eine Paginierung mit einer Seitengröße von 50-250 und fügen Sie kurze Verzögerungen zwischen paginierten Anfragen ein, um eine Überlastung des Worker-Pools zu vermeiden. + +## Best Practices für Imports im großen Maßstab + +Beachten Sie beim Import von Scan-Ergebnissen im großen Maßstab (z. B. SBOM-Pipelines mit Tausenden von Komponenten) Folgendes: + +- **Verwenden Sie `background_import=true`** für große Payloads. Synchrone Importe belegen für die Dauer des Imports einen uwsgi-Worker, was die Performance für alle Benutzer beeinträchtigen kann. +- **Streben Sie nach Möglichkeit Payload-Größen unter 1 MB pro Import an.** Teilen Sie große SBOMs in kleinere Dateien pro Produkt oder Komponentengruppe auf. +- **Fügen Sie Verzögerungen zwischen aufeinanderfolgenden API-Aufrufen ein**, um eine Erschöpfung des Worker-Pools zu vermeiden, die zu HTTP-502-Fehlern führt. +- **Verwenden Sie Reimport** (`/api/v2/reimport-scan/`) für wiederkehrende Scans, um vorhandene Befunde zu aktualisieren, statt Duplikate zu erstellen. + +## Antworten bei Hintergrundimporten (API: `background_import`) + +Ein Hintergrundimport liefert eine Antwort, sobald der hochgeladene Bericht geparst wurde, noch bevor +Befunde geschrieben wurden. Seine Antwort beschreibt daher *geplante* Arbeit, und sie ist +anders aufgebaut als bei einem synchronen Import. Dies gilt für `/api/v2/import-scan/` und +`/api/v2/reimport-scan/`, wenn `background_import` auf `true` gesetzt ist, oder wenn die +Systemeinstellung `api_async_import` dies für jeden Import aktiviert. + +Eine Hintergrundantwort enthält: + +- `background_import` — `true`. Dies ist das Feld, anhand dessen Sie verzweigen sollten. +- `status` — der Lifecycle-Status des Tests zum Zeitpunkt der Antworterstellung: + `Processing`, `Post Processing - Deduplication`, + `Post Processing - False Positive History`, `Processed` oder `Failed`. +- `findings_parsed` — wie viele Befunde aus dem Bericht ausgelesen wurden. Dies ist eine Parse- + Anzahl, keine Anzahl erstellter Befunde: Die Deduplizierung und die von Ihnen angegebenen Importoptionen + entscheiden, wie viele Befunde tatsächlich geschrieben werden. +- `test_id` (sowie `engagement_id`, `product_id`, `product_type_id`) — die Kennungen, die + abgefragt werden können. +- `message` — dieselben Informationen wie `status` und `findings_parsed`, in Textform. Bevorzugen Sie + die strukturierten Felder. + +Sie enthält **nicht** `statistics`, und sie enthält auch nicht `deduplication_complete`. +Diese Schlüssel fehlen, statt null zu sein, weil zu diesem Zeitpunkt noch keine Befunde +erstellt wurden und die Angabe von Nullen den Import falsch beschreiben würde. Ein Client, der +`response["statistics"]` bedingungslos ausliest, schlägt bei einem Hintergrundimport fehl — lesen Sie +zuerst `background_import`, oder verwenden Sie `statistics` nur auf dem synchronen Pfad. + +Um einen Hintergrundimport bis zum Abschluss zu verfolgen, fragen Sie den Test ab: + +``` +POST /api/v2/import-scan/ (background_import=true) -> test_id, status, findings_parsed +GET /api/v2/tests/{test_id}/ -> status, processing +``` + +Wiederholen Sie den `GET`-Aufruf, bis `status` den Wert `Processed` hat (der Import ist abgeschlossen, und +die Befundzahlen des Tests sind jetzt aussagekräftig) oder `Failed` (der Import wurde nicht abgeschlossen). Während der +Import läuft, ist `processing` `true`, und `status` gibt an, in welcher Phase er sich befindet. Lassen Sie +zwischen den Abfragen einige Sekunden vergehen; bei einem großen Bericht kann die Nachbearbeitung mehrere Minuten dauern. + +Ein synchroner Import (`background_import` weggelassen oder auf `false` gesetzt) bleibt unverändert: Er liefert eine Antwort, +sobald die Befunde geschrieben wurden, enthält `statistics` und enthält weder `status` +noch `findings_parsed`. + +## Verwendung des Felds für das Scan-Abschlussdatum (API: `scan_date`) + +DefectDojo unterstützt eine Vielzahl von Scanner-Berichten, aber nicht alle enthalten die +für einen Benutzer wichtigsten Informationen. Das Feld `scan_date` ist eine flexible intelligente Funktion, die +es Benutzern erlaubt, das Abschlussdatum eines bestimmten Scan-Berichts festzulegen und +es auf alle importierten Befunde übertragen zu lassen. Dieses Feld ist **nicht** verpflichtend, aber der +Standardwert für dieses Feld ist das Datum des Imports (also der Zeitpunkt, zu dem die Anfrage verarbeitet und eine erfolgreiche Antwort zurückgegeben wird). + +Im Folgenden finden Sie die Anwendungsfälle für dieses Feld: + +1. Der Bericht legt **kein** Datum fest, und `scan_date` wird beim Import **nicht** gesetzt + - Das Befund-Datum entspricht dem Standardwert von `scan_date` +2. Der Bericht **legt** das Datum fest, und `scan_date` wird beim Import **nicht** gesetzt + - Das Befund-Datum entspricht dem, was der Bericht festlegt +3. Der Bericht legt **kein** Datum fest, und `scan_date` wird beim Import **gesetzt** + - Das Befund-Datum entspricht dem, was der Benutzer für `scan_date` festgelegt hat +4. Der Bericht **legt** das Datum fest, und `scan_date` wird beim Import **gesetzt** + - Das Befund-Datum entspricht dem, was der Benutzer für `scan_date` festgelegt hat diff --git a/docs/content/automation/api/api-v2-docs.es.md b/docs/content/automation/api/api-v2-docs.es.md new file mode 100644 index 00000000000..742e537f052 --- /dev/null +++ b/docs/content/automation/api/api-v2-docs.es.md @@ -0,0 +1,420 @@ +--- +title: API v2 de DefectDojo +description: La API de DefectDojo le permite automatizar tareas, por ejemplo, subir + informes de escaneo en pipelines de CI/CD. +draft: false +weight: 2 +aliases: +- /es/en/api/api-v2-docs +--- + +La API de DefectDojo está creada con [Django Rest +Framework](http://www.django-rest-framework.org/). La documentación de +cada endpoint está disponible en cada instalación de DefectDojo en +[`/api/v2/oa3/swagger-ui`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/) y se puede acceder a ella eligiendo el enlace API v2 +Docs en el menú desplegable de usuario del encabezado. + +![image](images/api_v2_1.png) + +La documentación se genera con [drf-spectacular](https://drf-spectacular.readthedocs.io/) en [`/api/v2/oa3/swagger-ui/`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/), y es +interactiva. En la parte superior de la documentación de la API v2 hay un enlace que genera una especificación OpenAPI v3. + +Para interactuar con la documentación, se necesita un valor de encabezado Authorization +válido. Visite la vista `/api/key-v2` para generar su +API Key (`Token `) y copie el valor de encabezado proporcionado. + +![image](images/api_v2_2.png) + +Cada sección le permite realizar llamadas a la API y ver la Request +URL, el Response Body, el Response Code y los Response Headers. + +![image](images/api_v2_3.png) + +Si ha iniciado sesión en la interfaz web de Defect Dojo, no necesita proporcionar el token de autorización. + +## Authentication + +La API utiliza autenticación por encabezado con clave de API. El formato del +encabezado debe ser: : + + Authorization: Token + +Por ejemplo: : + + Authorization: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +### Alternative authentication method + +Si utiliza [un método de autenticación alternativo](/admin/sso/) para los usuarios, es posible que desee deshabilitar los tokens de API de DefectDojo, ya que podrían eludir su esquema de autenticación. \ +Los tokens de API de DefectDojo se pueden deshabilitar especificando la variable de entorno `DD_API_TOKENS_ENABLED` en `False`. +O bien, únicamente el endpoint `api/v2/api-token-auth/` se puede deshabilitar configurando `DD_API_TOKEN_AUTH_ENDPOINT_ENABLED` en `False`. + +## Sample Code + +A continuación se muestran algunos ejemplos sencillos en python y los resultados que producen contra +el endpoint `/users`: : + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +Este código devolverá la lista de todos los usuarios definidos en DefectDojo. +El objeto json resultante se ve así : : + +{{< highlight json >}} + [ + { + "first_name": "Tyagi", + "id": 22, + "last_login": "2019-06-18T08:05:51.925743", + "last_name": "Paz", + "username": "dev7958" + }, + { + "first_name": "saurabh", + "id": 31, + "last_login": "2019-06-06T11:44:32.533035", + "last_name": "", + "username": "saurabh.paz" + } + ] +{{< /highlight >}} + +Aquí tiene otro ejemplo contra el endpoint `/users`; esta +vez filtraremos los resultados para incluir solo los usuarios cuyo nombre de +usuario incluya `jay`: + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users/?username__contains=jay' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +El objeto json resultante es: : + +{{< highlight json >}} +[ + { + "first_name": "Jay", + "id": 22, + "last_login": "2015-10-28T08:05:51.925743", + "last_name": "Paz", + "username": "jay7958" + }, + { + "first_name": "", + "id": 31, + "last_login": "2015-10-13T11:44:32.533035", + "last_name": "", + "username": "jay.paz" + } +] +{{< /highlight >}} + +Consulte [la documentación de Django Rest Framework sobre cómo interactuar con una +API](https://www.django-rest-framework.org/) para ver +ejemplos y consejos adicionales. + +## Manually calling the API + +Se pueden usar herramientas como Postman para probar la API. + +Ejemplo para importar un resultado de escaneo: + +- Verbo: POST +- URI: +- Pestaña Headers: + + agregue el encabezado de autenticación + : - Clave: Authorization + - Valor: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +- Pestaña Body + + - seleccione "form-data", haga clic en "bulk edit". Ejemplo para un escaneo ZAP: + + + + engagement:3 + verified:true + active:true + lead:1 + tags:test + scan_type:ZAP Scan + minimum_severity:Info + close_old_findings:false + +- Pestaña Body + + - Haga clic en la edición "Key-value" + - Agregue un parámetro "file" de tipo "file". Esto activará + el envío de datos de formulario multi-part para transmitir el contenido del archivo + - Busque el archivo para subirlo + +- Haga clic en enviar + +## Clients / API Wrappers + +| Wrapper | Estado | Notas | +| -----------------------------| ------------------------| ------------------------| +| [Wrapper específico para python](https://github.com/DefectDojo/defectdojo_api) | funcional (2021-01-21) | Wrapper de API que incluye scripts para la subida continua en CI/CD. Va un poco por detrás de las últimas funciones de la API, ya que planeamos renovar el wrapper de la API | +| [Wrapper de python para OpenAPI](https://github.com/alles-klar/defectdojo-api-v2-client) | | solo es una prueba de concepto con la que descubrimos que la especificación OpenAPI aún no es perfecta | +| [Biblioteca Java](https://github.com/secureCodeBox/defectdojo-client-java) | funcional (2021-08-30) | Creada por las amables personas de [SecureCodeBox](https://github.com/secureCodeBox/secureCodeBox) | +| [Imagen que usa la biblioteca Java](https://github.com/SDA-SE/defectdojo-client) | funcional (2021-08-30) | | +| [Biblioteca .Net/C#](https://www.nuget.org/packages/DefectDojo.Api/) | funcional (2021-06-08) | | +| [dd-import](https://github.com/MaibornWolff/dd-import) | funcional (2021-08-24) | dd-import no es directamente un wrapper de API. Ofrece algunas funciones de conveniencia para facilitar la importación de hallazgos y datos de lenguaje desde pipelines de CI/CD. | + +Algunos de los wrappers de API contienen bastante lógica para facilitar el escaneo y la importación en entornos de CI/CD. Estamos en proceso de simplificar esto haciendo que la API de DefectDojo sea más inteligente (de modo que los wrappers de API o los scripts puedan ser más simples). + +## API Notes + +### Import / Reimport + +**Reimportar** es en realidad la forma más fácil de empezar, ya que creará todas las entidades sobre la marcha si es necesario y detectará automáticamente si se trata de una primera carga o de una recarga. + +## Import +La importación a través de la API se realiza mediante el endpoint [import-scan](https://demo.defectdojo.org/api/v2/doc/). + +Como se describe en [Jerarquía de producto](/asset_modelling/os_hierarchy/product_hierarchy/), el Test se crea dentro de un Compromiso, dentro de un Producto, dentro de un Tipo de producto. + +Una importación se puede realizar especificando los nombres de estas entidades en la solicitud a la API: + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, +} +``` + +Cuando `auto_create_context` es `True`, el producto, el compromiso y el entorno se crearán si es necesario. Asegúrese de que su usuario tenga los [permisos](/admin/user_management/about_perms_and_roles/) suficientes para hacerlo. + +Una forma clásica de importar un escaneo es especificando en su lugar el ID del compromiso: + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "engagement": 123, +} +``` + +## Reimport +La reimportación a través de la API se realiza mediante el endpoint [reimport-scan](https://demo.defectdojo.org/api/v2/doc/). + +Una reimportación se puede realizar especificando los nombres de estas entidades en la solicitud a la API: + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, + "do_not_reactivate": False, +} +``` + +Cuando `auto_create_context` es `True`, el Tipo de producto, el Producto y el Compromiso se crearán si aún no existen. Asegúrese de que su usuario tenga los [permisos](/admin/user_management/about_perms_and_roles/) suficientes para crear un Producto/Tipo de producto. + +Cuando `do_not_reactivate` es `True`, la importación/reimportación ignorará los hallazgos activos subidos y no reactivará los hallazgos previamente cerrados, aunque seguirá creando nuevos hallazgos si los hay. Se agregará una nota al hallazgo explicando que no se reactivó por ese motivo. + +Una reimportación seleccionará automáticamente el test más reciente dentro del compromiso proporcionado que cumpla con el `scan_type` indicado y (opcionalmente) el `test_title` indicado. + +Si no se encuentra ningún Test existente, el endpoint de reimportación usará la función de importación para importar el informe proporcionado a un nuevo Test. Esto significa que un script (de CI/CD) que use la API no necesita saber si ya existe un Test, ni si se trata de la primera carga para este Producto / Compromiso. + +Una forma clásica de reimportar un escaneo es especificando en su lugar el ID del test: + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test": 123, +} +``` + +## Generating Reports + +DefectDojo puede generar un informe de hallazgos a través de la API en formato **JSON**, **HTML**, **CSV** o **Excel**. + +Un informe se genera con una solicitud `POST` a una acción `generate_report/`. El endpoint de hallazgos genera informes de toda su instancia, y la mayoría de los demás objetos exponen una acción por objeto: + +| Endpoint | Alcance | +|---|---| +| `POST /api/v2/findings/generate_report/` | Cada hallazgo que tenga permiso para ver | +| `POST /api/v2/products/{id}/generate_report/` | Un producto | +| `POST /api/v2/engagements/{id}/generate_report/` | Un compromiso | +| `POST /api/v2/tests/{id}/generate_report/` | Un test | +| `POST /api/v2/product_types/{id}/generate_report/` | Un tipo de producto | +| `POST /api/v2/endpoints/{id}/generate_report/` | Un endpoint | + +Los alias de objetos Pro exponen la misma acción: `/api/v2/assets/{id}/generate_report/`, `/api/v2/organizations/{id}/generate_report/`, y `/api/v2/location/{id}/generate_report/`. + +### Request options + +Todos los campos son opcionales: enviar un cuerpo vacío (`{}`) devuelve un informe JSON. + +| Campo | Tipo | Valor predeterminado | Descripción | +|---|---|---|---| +| `report_type` | string | `JSON` | Uno de `JSON`, `HTML`, `CSV`, `Excel`. | +| `include_finding_notes` | boolean | `false` | Incluye las notas de cada hallazgo. | +| `include_finding_images` | boolean | `false` | Incluye las imágenes adjuntas a los hallazgos. | +| `include_executive_summary` | boolean | `false` | Incluye una sección de resumen ejecutivo. | +| `include_table_of_contents` | boolean | `false` | Incluye una tabla de contenidos. | + +Un `report_type` no admitido (por ejemplo `PDF`) devuelve `400 Bad Request` con un error en el campo `report_type`. + +### Example + +Genere un informe CSV de todos los hallazgos que puede ver, y guárdelo en un archivo: + +```bash +curl -X POST \ + -H "Authorization: Token " \ + -H "Content-Type: application/json" \ + -d '{"report_type": "CSV"}' \ + https:///api/v2/findings/generate_report/ \ + -o findings.csv +``` + +### Response formats + +| `report_type` | Tipo de contenido | Respuesta | +|---|---|---| +| `JSON` (predeterminado) | `application/json` | Cuerpo del informe en la respuesta | +| `HTML` | `text/html` | Página del informe renderizada | +| `CSV` | `text/csv` | Archivo adjunto | +| `Excel` | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` | Archivo adjunto `.xlsx` | + +CSV y Excel se devuelven como archivos adjuntos con un encabezado `Content-Disposition`, en lugar de como un cuerpo JSON. El nombre del archivo se deriva del objeto a partir del cual se generó el informe; por ejemplo `product_1_findings.csv` o `test_42_findings.xlsx`. El endpoint `/findings/generate_report/` no está limitado a un solo objeto, por lo que sus descargas se llaman `findings.csv` y `findings.xlsx`. + +### Notes and limitations + +* Las opciones `include_*` solo afectan a los informes **JSON** y **HTML**. Las exportaciones **CSV** y **Excel** siempre contienen las filas de hallazgos. +* La generación de informes requiere permiso de **view** sobre los objetos implicados, y un informe solo contiene los hallazgos que usted está autorizado a ver. +* **Los filtros de parámetros de consulta estándar no se aplican a esta acción.** A diferencia de `GET /api/v2/findings/`, la acción `generate_report/` no aplica los filtros de hallazgos, por lo que una solicitud como `POST /api/v2/findings/generate_report/?severity=High` seguirá informando sobre todos los hallazgos que puede ver. Para acotar un informe, genérelo en su lugar desde un producto, compromiso o test específico. + +## Asynchronous Deletion Behavior + +Las eliminaciones en DefectDojo (tanto por la API como por la interfaz) se procesan de forma **asíncrona** mediante workers en segundo plano de Celery. Cuando elimina un Compromiso, un Test u otro objeto, la API o la interfaz devuelven inmediatamente una respuesta de éxito, pero la eliminación real se ejecuta en segundo plano. + +Esto significa que: +- Los objetos pueden seguir apareciendo en las consultas durante un tiempo después de que se confirme la eliminación. +- Las eliminaciones en cascada (por ejemplo, eliminar un Compromiso también elimina sus Tests y Hallazgos) se procesan como una cadena de tareas en segundo plano. Los objetos hijos se eliminan en orden de dependencia: primero los Hallazgos, luego los Tests y después los Compromisos. +- En Compromisos grandes con muchos Hallazgos, este proceso puede tardar varios minutos en completarse. + +No es necesario crear scripts personalizados para eliminar objetos en orden de dependencia. Una única solicitud `DELETE` sobre un Compromiso se propagará automáticamente en cascada a todos los objetos hijos. Simplemente deje tiempo para que se completen las tareas en segundo plano. + +## API Pagination Limits + +DefectDojo Pro impone un tamaño de página máximo de **250** resultados por solicitud a la API. Configurar `limit` por encima de 250 puede provocar errores HTTP 502 debido a tiempos de espera agotados en la consulta. + +Las instancias de DefectDojo Open Source también pueden experimentar tiempos de espera agotados con tamaños de página muy grandes, según el tamaño del conjunto de datos y los recursos del servidor. + +Para conjuntos de resultados grandes, use paginación con un tamaño de página de 50-250 y agregue breves demoras entre las solicitudes paginadas para evitar saturar el pool de workers. + +## Large-Scale Import Best Practices + +Al importar resultados de escaneo a gran escala (por ejemplo, pipelines de SBOM con miles de componentes), tenga en cuenta lo siguiente: + +- **Use `background_import=true`** para payloads grandes. Las importaciones síncronas ocupan un worker de uwsgi durante toda la importación, lo que puede degradar el rendimiento para todos los usuarios. +- **Procure payloads de menos de 1 MB por importación** siempre que sea posible. Divida los SBOM grandes en archivos más pequeños por producto o grupo de componentes. +- **Agregue demoras entre llamadas consecutivas a la API** para evitar agotar el pool de workers, lo que provoca errores HTTP 502. +- **Use Reimport** (`/api/v2/reimport-scan/`) para escaneos recurrentes, de modo que se actualicen los hallazgos existentes en lugar de crear duplicados. + +## Background import responses (API: `background_import`) + +Una importación en segundo plano devuelve una respuesta tan pronto como se ha analizado el informe +subido, antes de que se haya escrito ningún hallazgo. Por lo tanto, su respuesta describe un trabajo +*programado*, y tiene una forma distinta a la de una importación síncrona. Esto aplica a `/api/v2/import-scan/` y +`/api/v2/reimport-scan/` siempre que `background_import` sea `true`, o siempre que el ajuste de +sistema `api_async_import` lo active para todas las importaciones. + +Una respuesta en segundo plano contiene: + +- `background_import` — `true`. Este es el campo sobre el que decidir el flujo. +- `status` — el estado del ciclo de vida del test en el momento en que se produjo la respuesta: + `Processing`, `Post Processing - Deduplication`, + `Post Processing - False Positive History`, `Processed` o `Failed`. +- `findings_parsed` — cuántos hallazgos se leyeron del informe. Es un recuento de + análisis, no un recuento de creación: la deduplicación y las opciones de importación que + proporcionó determinan cuántos hallazgos se escriben realmente. +- `test_id` (y `engagement_id`, `product_id`, `product_type_id`) — los identificadores a + consultar. +- `message` — la misma información que `status` y `findings_parsed`, en forma de texto. Prefiera + los campos estructurados. + +**No** contiene `statistics`, ni tampoco contiene `deduplication_complete`. +Estas claves están ausentes en lugar de ser cero, porque en ese momento no se ha +creado ningún hallazgo, y reportar ceros describiría incorrectamente la importación. Un cliente que +lea `response["statistics"]` de forma incondicional fallará en una importación en segundo plano; lea +primero `background_import`, o use `statistics` solo en la ruta síncrona. + +Para seguir una importación en segundo plano hasta su finalización, consulte el test: + +``` +POST /api/v2/import-scan/ (background_import=true) -> test_id, status, findings_parsed +GET /api/v2/tests/{test_id}/ -> status, processing +``` + +Repita la solicitud `GET` hasta que `status` sea `Processed` (la importación finalizó, y los +recuentos de hallazgos del test ya son significativos) o `Failed` (la importación no se +completó). Mientras la importación se ejecuta, `processing` es `true` y `status` indica en qué +fase se encuentra. Deje unos segundos entre cada consulta; un informe grande puede pasar +varios minutos en el posprocesamiento. + +Una importación síncrona (`background_import` omitido o `false`) no cambia: devuelve una +respuesta una vez que se han escrito los hallazgos, incluye `statistics`, y no incluye `status` +ni `findings_parsed`. + +## Using the Scan Completion Date (API: `scan_date`) field + +DefectDojo ofrece una gran variedad de informes de escáner compatibles, pero no todos contienen la +información más importante para un usuario. El campo `scan_date` es una función inteligente y flexible que +permite a los usuarios establecer la fecha de finalización de un informe de escaneo dado, y que esta se propague +a todos los hallazgos importados. Este campo **no** es obligatorio, pero el valor predeterminado para +este campo es la fecha de importación (el momento en que se procesa la solicitud y se devuelve una respuesta exitosa). + +Estos son los casos de uso para este campo: + +1. El informe **no** establece la fecha, y `scan_date` **no** se establece en la importación + - La fecha del hallazgo será el valor predeterminado de `scan_date` +2. El informe **establece** la fecha, y `scan_date` **no** se establece en la importación + - La fecha del hallazgo será la que establezca el informe +3. El informe **no** establece la fecha, y `scan_date` **se establece** en la importación + - La fecha del hallazgo será la que el usuario haya establecido para `scan_date` +4. El informe **establece** la fecha, y `scan_date` **se establece** en la importación + - La fecha del hallazgo será la que el usuario haya establecido para `scan_date` diff --git a/docs/content/automation/api/api-v2-docs.fr.md b/docs/content/automation/api/api-v2-docs.fr.md new file mode 100644 index 00000000000..236fede2fcf --- /dev/null +++ b/docs/content/automation/api/api-v2-docs.fr.md @@ -0,0 +1,420 @@ +--- +title: API v2 de DefectDojo +description: L'API de DefectDojo vous permet d'automatiser des tâches, par exemple + l'envoi de rapports de scan dans des pipelines CI/CD. +draft: false +weight: 2 +aliases: +- /fr/en/api/api-v2-docs +--- + +L'API de DefectDojo est créée avec [Django Rest +Framework](http://www.django-rest-framework.org/). La documentation de +chaque endpoint est disponible dans chaque installation de DefectDojo à +l'adresse [`/api/v2/oa3/swagger-ui`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/) et est accessible en choisissant le lien API v2 +Docs dans le menu déroulant utilisateur de l'en-tête. + +![image](images/api_v2_1.png) + +La documentation est générée avec [drf-spectacular](https://drf-spectacular.readthedocs.io/) à l'adresse [`/api/v2/oa3/swagger-ui/`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/), et elle est +interactive. En haut de la documentation API v2 se trouve un lien qui génère une spécification OpenAPI v3. + +Pour interagir avec la documentation, une valeur d'en-tête Authorization valide +est nécessaire. Visitez la vue `/api/key-v2` pour générer votre +clé API (`Token `) et copiez la valeur d'en-tête fournie. + +![image](images/api_v2_2.png) + +Chaque section vous permet d'effectuer des appels à l'API et de consulter l'URL de la +requête, le corps de la réponse, le code de réponse et les en-têtes de réponse. + +![image](images/api_v2_3.png) + +Si vous êtes connecté à l'interface web de Defect Dojo, vous n'avez pas besoin de fournir le jeton d'autorisation. + +## Authentication + +L'API utilise une authentification par en-tête avec une clé API. Le format de l'en-tête doit être : + + Authorization: Token + +Par exemple : + + Authorization: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +### Alternative authentication method + +Si vous utilisez [une méthode d'authentification alternative](/admin/sso/) pour les utilisateurs, vous pouvez souhaiter désactiver les jetons API de DefectDojo, car cela pourrait contourner votre dispositif d'authentification. \ +L'utilisation des jetons API de DefectDojo peut être désactivée en définissant la variable d'environnement `DD_API_TOKENS_ENABLED` sur `False`. +Ou seul l'endpoint `api/v2/api-token-auth/` peut être désactivé en définissant `DD_API_TOKEN_AUTH_ENDPOINT_ENABLED` sur `False`. + +## Sample Code + +Voici quelques exemples simples en python et les résultats produits sur +l'endpoint `/users` : + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +Ce code retourne la liste de tous les utilisateurs définis dans DefectDojo. +Le résultat de l'objet json ressemble à ceci : + +{{< highlight json >}} + [ + { + "first_name": "Tyagi", + "id": 22, + "last_login": "2019-06-18T08:05:51.925743", + "last_name": "Paz", + "username": "dev7958" + }, + { + "first_name": "saurabh", + "id": 31, + "last_login": "2019-06-06T11:44:32.533035", + "last_name": "", + "username": "saurabh.paz" + } + ] +{{< /highlight >}} + +Voici un autre exemple sur l'endpoint `/users`, cette +fois nous allons filtrer les résultats pour n'inclure que les utilisateurs +dont le nom d'utilisateur contient `jay` : + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users/?username__contains=jay' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +Le résultat de l'objet json est : + +{{< highlight json >}} +[ + { + "first_name": "Jay", + "id": 22, + "last_login": "2015-10-28T08:05:51.925743", + "last_name": "Paz", + "username": "jay7958" + }, + { + "first_name": "", + "id": 31, + "last_login": "2015-10-13T11:44:32.533035", + "last_name": "", + "username": "jay.paz" + } +] +{{< /highlight >}} + +Consultez la [documentation de Django Rest Framework sur l'interaction avec une +API](https://www.django-rest-framework.org/) pour +d'autres exemples et astuces. + +## Manually calling the API + +Des outils comme Postman peuvent être utilisés pour tester l'API. + +Exemple pour importer un résultat de scan : + +- Verbe : POST +- URI : +- Onglet Headers : + + ajoutez l'en-tête d'authentification + : - Clé : Authorization + - Valeur : Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +- Onglet Body + + - sélectionnez « form-data », cliquez sur « bulk edit ». Exemple pour un scan ZAP : + + + + engagement:3 + verified:true + active:true + lead:1 + tags:test + scan_type:ZAP Scan + minimum_severity:Info + close_old_findings:false + +- Onglet Body + + - Cliquez sur l'édition « Key-value » + - Ajoutez un paramètre « file » de type « file ». Cela déclenchera + l'envoi de données multipart pour le contenu du fichier + - Parcourez pour sélectionner le fichier à envoyer + +- Cliquez sur send + +## Clients / API Wrappers + +| Wrapper | Statut | Notes | +| -----------------------------| ------------------------| ------------------------| +| [Wrapper python spécifique](https://github.com/DefectDojo/defectdojo_api) | fonctionnel (2021-01-21) | Wrapper API incluant des scripts pour l'envoi continu en CI/CD. Il accuse un léger retard sur les dernières fonctionnalités de l'API, car nous prévoyons de refondre le wrapper API | +| [Wrapper python Openapi](https://github.com/alles-klar/defectdojo-api-v2-client) | | preuve de concept uniquement, où nous avons constaté que la spécification OpenAPI n'est pas encore parfaite | +| [Bibliothèque Java](https://github.com/secureCodeBox/defectdojo-client-java) | fonctionnel (2021-08-30) | Créée par les sympathiques membres de [SecureCodeBox](https://github.com/secureCodeBox/secureCodeBox) | +| [Image utilisant la bibliothèque Java](https://github.com/SDA-SE/defectdojo-client) | fonctionnel (2021-08-30) | | +| [Bibliothèque .Net/C#](https://www.nuget.org/packages/DefectDojo.Api/) | fonctionnel (2021-06-08) | | +| [dd-import](https://github.com/MaibornWolff/dd-import) | fonctionnel (2021-08-24) | dd-import n'est pas directement un wrapper API. Il propose des fonctions pratiques pour faciliter l'import des constatations et des données de langage depuis des pipelines CI/CD. | + +Certains wrappers API contiennent une bonne quantité de logique pour faciliter le scan et l'import dans des environnements CI/CD. Nous sommes en train de simplifier cela en rendant l'API DefectDojo plus intelligente (afin que les wrappers API / scripts puissent être plus simples). + +## API Notes + +### Import / Reimport + +**Réimport** est en fait le moyen le plus simple pour démarrer, car il crée à la volée toutes les entités nécessaires et détecte automatiquement s'il s'agit d'un premier envoi ou d'un nouvel envoi. + +## Import +L'import via l'API s'effectue via l'endpoint [import-scan](https://demo.defectdojo.org/api/v2/doc/). + +Comme décrit dans [Hiérarchie des produits](/asset_modelling/os_hierarchy/product_hierarchy/), un Test est créé à l'intérieur d'un Engagement, lui-même à l'intérieur d'un Produit, lui-même à l'intérieur d'un Type de produit. + +Un import peut être effectué en spécifiant les noms de ces entités dans la requête API : + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, +} +``` + +Lorsque `auto_create_context` est à `True`, le produit, l'engagement et l'environnement sont créés si nécessaire. Assurez-vous que votre utilisateur dispose des [permissions](/admin/user_management/about_perms_and_roles/) suffisantes pour cela. + +Une façon classique d'importer un scan consiste à spécifier plutôt l'ID de l'engagement : + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "engagement": 123, +} +``` + +## Reimport +Le réimport via l'API s'effectue via l'endpoint [reimport-scan](https://demo.defectdojo.org/api/v2/doc/). + +Un réimport peut être effectué en spécifiant les noms de ces entités dans la requête API : + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, + "do_not_reactivate": False, +} +``` + +Lorsque `auto_create_context` est à `True`, le Type de produit, le Produit et l'Engagement sont créés s'ils n'existent pas déjà. Assurez-vous que votre utilisateur dispose des [permissions](/admin/user_management/about_perms_and_roles/) suffisantes pour créer un Produit/Type de produit. + +Lorsque `do_not_reactivate` est à `True`, l'import/réimport ignore les constatations actives envoyées et ne réactive pas les constatations précédemment clôturées, tout en créant malgré tout de nouvelles constatations s'il y en a. Une note est ajoutée à la constatation pour expliquer qu'elle n'a pas été réactivée pour cette raison. + +Un réimport sélectionne automatiquement le test le plus récent au sein de l'engagement fourni qui correspond au `scan_type` fourni et, éventuellement, au `test_title` fourni. + +Si aucun Test existant n'est trouvé, l'endpoint de réimport utilise la fonction d'import pour importer le rapport fourni dans un nouveau Test. Cela signifie qu'un script (CI/CD) utilisant l'API n'a pas besoin de savoir si un Test existe déjà, ni s'il s'agit d'un premier envoi pour ce Produit / Engagement. + +Une façon classique de réimporter un scan consiste à spécifier plutôt l'ID du test : + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test": 123, +} +``` + +## Generating Reports + +DefectDojo peut générer un rapport de constatations via l'API aux formats **JSON**, **HTML**, **CSV** ou **Excel**. + +Un rapport est généré via une requête `POST` vers une action `generate_report/`. L'endpoint findings génère un rapport sur l'ensemble de votre instance, et la plupart des autres objets exposent une action par objet : + +| Endpoint | Portée | +|---|---| +| `POST /api/v2/findings/generate_report/` | Toutes les constatations que vous avez la permission de consulter | +| `POST /api/v2/products/{id}/generate_report/` | Un produit | +| `POST /api/v2/engagements/{id}/generate_report/` | Un engagement | +| `POST /api/v2/tests/{id}/generate_report/` | Un test | +| `POST /api/v2/product_types/{id}/generate_report/` | Un type de produit | +| `POST /api/v2/endpoints/{id}/generate_report/` | Un point de terminaison | + +Les alias d'objets Pro exposent la même action : `/api/v2/assets/{id}/generate_report/`, `/api/v2/organizations/{id}/generate_report/`, et `/api/v2/location/{id}/generate_report/`. + +### Request options + +Tous les champs sont facultatifs — l'envoi d'un corps vide (`{}`) renvoie un rapport JSON. + +| Field | Type | Default | Description | +|---|---|---|---| +| `report_type` | string | `JSON` | L'une des valeurs `JSON`, `HTML`, `CSV`, `Excel`. | +| `include_finding_notes` | boolean | `false` | Inclut les notes de chaque constatation. | +| `include_finding_images` | boolean | `false` | Inclut les images jointes aux constatations. | +| `include_executive_summary` | boolean | `false` | Inclut une section de résumé exécutif. | +| `include_table_of_contents` | boolean | `false` | Inclut une table des matières. | + +Un `report_type` non pris en charge (par exemple `PDF`) renvoie une erreur `400 Bad Request` sur le champ `report_type`. + +### Example + +Génère un rapport CSV de toutes les constatations que vous pouvez consulter, et l'enregistre dans un fichier : + +```bash +curl -X POST \ + -H "Authorization: Token " \ + -H "Content-Type: application/json" \ + -d '{"report_type": "CSV"}' \ + https:///api/v2/findings/generate_report/ \ + -o findings.csv +``` + +### Response formats + +| `report_type` | Type de contenu | Réponse | +|---|---|---| +| `JSON` (par défaut) | `application/json` | Corps du rapport dans la réponse | +| `HTML` | `text/html` | Page du rapport rendue | +| `CSV` | `text/csv` | Pièce jointe (fichier) | +| `Excel` | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` | Pièce jointe `.xlsx` | + +CSV et Excel sont renvoyés en pièce jointe avec un en-tête `Content-Disposition`, plutôt que sous forme de corps JSON. Le nom du fichier est dérivé de l'objet à partir duquel le rapport a été généré — par exemple `product_1_findings.csv` ou `test_42_findings.xlsx`. L'endpoint `/findings/generate_report/` n'est pas rattaché à un objet unique, ses téléchargements sont donc nommés `findings.csv` et `findings.xlsx`. + +### Notes and limitations + +* Les options `include_*` n'affectent que les rapports **JSON** et **HTML**. Les exports **CSV** et **Excel** contiennent toujours les lignes de constatations. +* La génération de rapport nécessite la permission **view** sur les objets concernés, et un rapport ne contient jamais que les constatations que vous êtes autorisé à voir. +* **Les filtres de paramètres de requête standard ne s'appliquent pas à cette action.** Contrairement à `GET /api/v2/findings/`, l'action `generate_report/` n'applique pas les filtres de constatations : une requête telle que `POST /api/v2/findings/generate_report/?severity=High` porte donc toujours sur toutes les constatations que vous pouvez consulter. Pour restreindre un rapport, générez-le plutôt depuis un produit, un engagement ou un test spécifique. + +## Asynchronous Deletion Behavior + +Les suppressions dans DefectDojo (via l'API comme via l'UI) sont traitées **de façon asynchrone** par des workers Celery en arrière-plan. Lorsque vous supprimez un Engagement, un Test ou un autre objet, l'API ou l'UI renvoie immédiatement une réponse de succès, mais la suppression réelle s'exécute en arrière-plan. + +Cela signifie que : +- Les objets peuvent encore apparaître dans les requêtes pendant un certain temps après la confirmation de la suppression. +- Les suppressions en cascade (par exemple, la suppression d'un Engagement supprime également ses Tests et ses Constatations) sont traitées comme une chaîne de tâches en arrière-plan. Les objets enfants sont supprimés dans l'ordre de dépendance : les Constatations, puis les Tests, puis les Engagements. +- Pour les Engagements volumineux comportant de nombreuses Constatations, ce processus peut prendre plusieurs minutes. + +Il n'est pas nécessaire de créer des scripts personnalisés pour supprimer les objets dans l'ordre de dépendance. Une seule requête `DELETE` sur un Engagement se propage automatiquement à tous les objets enfants. Il suffit de laisser le temps aux tâches en arrière-plan de se terminer. + +## API Pagination Limits + +DefectDojo Pro impose une taille de page maximale de **250** résultats par requête API. Définir `limit` à une valeur supérieure à 250 peut entraîner des erreurs HTTP 502 dues à des délais d'attente de requête dépassés. + +Les instances DefectDojo Open Source peuvent également rencontrer des délais d'attente dépassés avec des tailles de page très importantes, selon la taille du jeu de données et les ressources du serveur. + +Pour les ensembles de résultats volumineux, utilisez une pagination avec une taille de page de 50 à 250 et ajoutez de courts délais entre les requêtes paginées afin d'éviter de saturer le pool de workers. + +## Large-Scale Import Best Practices + +Lors de l'import de résultats de scan à grande échelle (par exemple des pipelines SBOM comportant des milliers de composants), tenez compte des points suivants : + +- **Utilisez `background_import=true`** pour les charges volumineuses. Les imports synchrones monopolisent un worker uwsgi pendant toute la durée de l'import, ce qui peut dégrader les performances pour tous les utilisateurs. +- **Visez des charges de moins de 1 Mo par import** lorsque c'est possible. Découpez les gros SBOM en fichiers plus petits par produit ou groupe de composants. +- **Ajoutez des délais entre les appels API consécutifs** pour éviter l'épuisement du pool de workers, qui provoque des erreurs HTTP 502. +- **Utilisez le Réimport** (`/api/v2/reimport-scan/`) pour les scans récurrents afin de mettre à jour les constatations existantes plutôt que de créer des doublons. + +## Background import responses (API: `background_import`) + +Un import en arrière-plan renvoie une réponse dès que le rapport envoyé a été analysé, avant que +la moindre constatation ait été écrite. Sa réponse décrit donc un travail *planifié*, et sa forme +diffère de celle d'un import synchrone. Cela s'applique à `/api/v2/import-scan/` et +`/api/v2/reimport-scan/` chaque fois que `background_import` vaut `true`, ou chaque fois que le +paramètre système `api_async_import` l'active pour tous les imports. + +Une réponse en arrière-plan contient : + +- `background_import` — `true`. C'est le champ sur lequel se brancher. +- `status` — le statut du cycle de vie du test au moment où la réponse a été produite : + `Processing`, `Post Processing - Deduplication`, + `Post Processing - False Positive History`, `Processed` ou `Failed`. +- `findings_parsed` — le nombre de constatations lues dans le rapport. Il s'agit d'un compte + d'analyse, pas d'un compte de créations : la déduplication et les options d'import fournies + déterminent le nombre de constatations réellement écrites. +- `test_id` (ainsi que `engagement_id`, `product_id`, `product_type_id`) — les identifiants à + interroger. +- `message` — la même information que `status` et `findings_parsed`, sous forme de texte. + Préférez les champs structurés. + +Elle ne contient **pas** `statistics`, ni `deduplication_complete`. +Ces clés sont absentes plutôt qu'à zéro, car à ce stade aucune constatation n'a été +créée et indiquer des zéros décrirait mal l'import. Un client qui lit +`response["statistics"]` sans condition échouera sur un import en arrière-plan — lisez +`background_import` en premier, ou n'utilisez `statistics` que sur le chemin synchrone. + +Pour suivre un import en arrière-plan jusqu'à son terme, interrogez le test : + +``` +POST /api/v2/import-scan/ (background_import=true) -> test_id, status, findings_parsed +GET /api/v2/tests/{test_id}/ -> status, processing +``` + +Répétez le `GET` jusqu'à ce que `status` vaille `Processed` (l'import est terminé, et les +décomptes de constatations du test sont désormais significatifs) ou `Failed` (l'import ne s'est +pas terminé). Pendant que l'import est en cours, `processing` vaut `true` et `status` indique +dans quelle phase il se trouve. Laissez quelques secondes entre les interrogations ; un gros +rapport peut passer plusieurs minutes en post-traitement. + +Un import synchrone (`background_import` omis ou `false`) reste inchangé : il renvoie une réponse +une fois les constatations écrites, inclut `statistics`, et n'inclut pas `status` +ni `findings_parsed`. + +## Using the Scan Completion Date (API: `scan_date`) field + +DefectDojo prend en charge une multitude de rapports de scanners, mais tous ne contiennent pas +l'information la plus importante pour un utilisateur. Le champ `scan_date` est une fonctionnalité +intelligente et flexible qui permet aux utilisateurs de définir la date de fin d'un rapport de +scan donné, et de la propager à toutes les constatations importées. Ce champ n'est **pas** +obligatoire, mais sa valeur par défaut est la date d'import (au moment où la requête est traitée +et où une réponse de succès est renvoyée). + +Voici les cas d'usage possibles pour ce champ : + +1. Le rapport **ne définit pas** la date, et `scan_date` n'est **pas** défini à l'import + - La date de la constatation sera la valeur par défaut de `scan_date` +2. Le rapport **définit** la date, et `scan_date` n'est **pas** défini à l'import + - La date de la constatation sera celle définie par le rapport +3. Le rapport **ne définit pas** la date, et `scan_date` **est** défini à l'import + - La date de la constatation sera celle définie par l'utilisateur pour `scan_date` +4. Le rapport **définit** la date, et `scan_date` **est** défini à l'import + - La date de la constatation sera celle définie par l'utilisateur pour `scan_date` diff --git a/docs/content/automation/api/api-v2-docs.ja.md b/docs/content/automation/api/api-v2-docs.ja.md new file mode 100644 index 00000000000..431e231113b --- /dev/null +++ b/docs/content/automation/api/api-v2-docs.ja.md @@ -0,0 +1,403 @@ +--- +title: DefectDojo API v2 +description: DefectDojoのAPIを使用すると、CI/CDパイプラインでのスキャンレポートのアップロードなど、タスクを自動化できます。 +draft: false +weight: 2 +aliases: +- /ja/en/api/api-v2-docs +--- + +DefectDojoのAPIは[Django Rest +Framework](http://www.django-rest-framework.org/)を使用して作成されています。各エンドポイントのドキュメントは、各DefectDojoインストール内の +[`/api/v2/oa3/swagger-ui`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/)で利用でき、ヘッダーのユーザードロップダウンメニューにあるAPI v2 +Docsリンクを選択することでアクセスできます。 + +![image](images/api_v2_1.png) + +このドキュメントは[drf-spectacular](https://drf-spectacular.readthedocs.io/)を使用して[`/api/v2/oa3/swagger-ui/`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/)で生成されており、 +インタラクティブに操作できます。API v2 Docsの上部には、OpenAPI v3仕様を生成するリンクがあります。 + +ドキュメントを操作するには、有効なAuthorizationヘッダーの値 +が必要です。`/api/key-v2`ビューにアクセスしてAPIキー(`Token `)を生成し、表示されたヘッダーの値をコピーしてください。 + +![image](images/api_v2_2.png) + +各セクションでは、APIを呼び出し、リクエスト +URL、レスポンスボディ、レスポンスコード、レスポンスヘッダーを確認できます。 + +![image](images/api_v2_3.png) + +Defect DojoのWeb UIにログインしている場合、認証トークンを指定する必要はありません。 + +## Authentication + +APIはAPIキーによるヘッダー認証を使用します。ヘッダーの形式は次のとおりです: : + + Authorization: Token + +例: : + + Authorization: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +### Alternative authentication method + +ユーザーに対して[代替の認証方式](/admin/sso/)を使用している場合、認証の仕組みを回避されてしまう可能性があるため、DefectDojoのAPIトークンを無効化することを検討してください。 \ +DefectDojo APIトークンの使用は、環境変数`DD_API_TOKENS_ENABLED`を`False`に設定することで無効化できます。 +または、`api/v2/api-token-auth/`エンドポイントのみを`DD_API_TOKEN_AUTH_ENDPOINT_ENABLED`を`False`に設定することで無効化できます。 + +## Sample Code + +以下は、`/users`エンドポイントに対する簡単なPythonの例と、その実行結果です: : + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +このコードは、DefectDojoに定義されているすべてのユーザーのリストを返します。 +JSONオブジェクトの結果は次のようになります: : + +{{< highlight json >}} + [ + { + "first_name": "Tyagi", + "id": 22, + "last_login": "2019-06-18T08:05:51.925743", + "last_name": "Paz", + "username": "dev7958" + }, + { + "first_name": "saurabh", + "id": 31, + "last_login": "2019-06-06T11:44:32.533035", + "last_name": "", + "username": "saurabh.paz" + } + ] +{{< /highlight >}} + +次に、`/users`エンドポイントに対する別の例を示します。今回は +ユーザー名に`jay`を含むユーザーのみに結果を絞り込みます: + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users/?username__contains=jay' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +JSONオブジェクトの結果は次のとおりです: : + +{{< highlight json >}} +[ + { + "first_name": "Jay", + "id": 22, + "last_login": "2015-10-28T08:05:51.925743", + "last_name": "Paz", + "username": "jay7958" + }, + { + "first_name": "", + "id": 31, + "last_login": "2015-10-13T11:44:32.533035", + "last_name": "", + "username": "jay.paz" + } +] +{{< /highlight >}} + +APIとの連携に関する追加の例やヒントについては、[Django Rest Framework +のドキュメント](https://www.django-rest-framework.org/)を参照してください。 + +## Manually calling the API + +Postmanなどのツールを使用してAPIをテストできます。 + +スキャン結果をインポートする例: + +- メソッド: POST +- URI: +- ヘッダー タブ: + + 認証ヘッダーを追加します + : - キー: Authorization + - 値: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +- ボディ タブ + + - \"form-data\"を選択し、\"bulk edit\"をクリックします。ZAPスキャンの例: + + + + engagement:3 + verified:true + active:true + lead:1 + tags:test + scan_type:ZAP Scan + minimum_severity:Info + close_old_findings:false + +- ボディ タブ + + - \"Key-value\"編集をクリックします + - タイプが\"file\"の\"file\"パラメーターを追加します。これにより、ファイル + 内容を送信するためのマルチパートフォームデータがトリガーされます + - アップロードするファイルを参照します + +- 送信をクリックします + +## Clients / API Wrappers + +| Wrapper | Status | Notes | +| -----------------------------| ------------------------| ------------------------| +| [Specific python wrapper](https://github.com/DefectDojo/defectdojo_api) | 動作確認済み (2021-01-21) | 継続的なCI/CDアップロード用のスクリプトを含むAPIラッパーです。APIラッパーの刷新を計画しているため、最新のAPI機能に対して多少遅れています。 | +| [Openapi python wrapper](https://github.com/alles-klar/defectdojo-api-v2-client) | | OpenAPI仕様がまだ完全ではないことが判明した、概念実証のみの段階です。 | +| [Java library](https://github.com/secureCodeBox/defectdojo-client-java) | 動作確認済み (2021-08-30) | [SecureCodeBox](https://github.com/secureCodeBox/secureCodeBox)の親切な方々によって作成されました。 | +| [Image using the Java library](https://github.com/SDA-SE/defectdojo-client) | 動作確認済み (2021-08-30) | | +| [.Net/C# library](https://www.nuget.org/packages/DefectDojo.Api/) | 動作確認済み (2021-06-08) | | +| [dd-import](https://github.com/MaibornWolff/dd-import) | 動作確認済み (2021-08-24) | dd-importは厳密にはAPIラッパーではありません。CI/CDパイプラインから検出事項や言語データをインポートしやすくするための便利な機能を提供します。 | + +一部のAPIラッパーには、CI/CD環境でのスキャンやインポートを容易にするための多くのロジックが含まれています。DefectDojoのAPIをよりスマートにすることで、APIラッパーやスクリプト側をよりシンプルにできるよう、簡素化を進めています。 + +## API Notes + +### Import / Reimport + +**再インポート**は、必要に応じてその場でエンティティを作成し、初回アップロードか再アップロードかを自動的に検出するため、実際には最も簡単に始められる方法です。 + +## Import +APIを介したインポートは、[import-scan](https://demo.defectdojo.org/api/v2/doc/)エンドポイントを介して実行されます。 + +[製品階層](/asset_modelling/os_hierarchy/product_hierarchy/)で説明されているとおり、テストはエンゲージメント内に、エンゲージメントは製品内に、製品は製品タイプ内に作成されます。 + +これらのエンティティの名前をAPIリクエストで指定することで、インポートを実行できます: + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, +} +``` + +`auto_create_context`が`True`の場合、必要に応じて製品、エンゲージメント、環境が作成されます。これを行うには、ユーザーが十分な[権限](/admin/user_management/about_perms_and_roles/)を持っている必要があります。 + +従来の方法として、エンゲージメントのIDを指定してスキャンをインポートすることもできます: + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "engagement": 123, +} +``` + +## Reimport +APIを介した再インポートは、[reimport-scan](https://demo.defectdojo.org/api/v2/doc/)エンドポイントを介して実行されます。 + +これらのエンティティの名前をAPIリクエストで指定することで、再インポートを実行できます: + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, + "do_not_reactivate": False, +} +``` + +`auto_create_context`が`True`の場合、製品タイプ、製品、エンゲージメントがまだ存在しなければ作成されます。製品/製品タイプを作成するには、ユーザーが十分な[権限](/admin/user_management/about_perms_and_roles/)を持っている必要があります。 + +`do_not_reactivate`が`True`の場合、インポート/再インポートの際にアップロードされたアクティブな検出事項は無視され、以前にクローズされた検出事項は再アクティブ化されません。ただし、新しい検出事項があればそれは引き続き作成されます。この理由により再アクティブ化されなかったことを説明するメモが、該当の検出事項に付与されます。 + +再インポートでは、指定されたエンゲージメント内で、指定された`scan_type`(および任意で指定された`test_title`)を満たす最新のテストが自動的に選択されます。 + +既存のテストが見つからない場合、再インポートエンドポイントはインポート機能を使用して、指定されたレポートを新しいテストにインポートします。これにより、APIを使用する(CI/CD)スクリプトは、この製品/エンゲージメントに対してテストが既に存在するかどうか、あるいは初回のアップロードであるかどうかを把握する必要がなくなります。 + +従来の方法として、テストのIDを指定してスキャンを再インポートすることもできます: + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test": 123, +} +``` + +## Generating Reports + +DefectDojoは、API経由で**JSON**、**HTML**、**CSV**、または**Excel**形式の検出事項レポートを生成できます。 + +レポートは、`generate_report/`アクションへの`POST`リクエストによって生成されます。findingsエンドポイントはインスタンス全体のレポートを扱い、その他のほとんどのオブジェクトはオブジェクトごとのアクションを公開しています: + +| Endpoint | Scope | +|---|---| +| `POST /api/v2/findings/generate_report/` | 閲覧権限のあるすべての検出事項 | +| `POST /api/v2/products/{id}/generate_report/` | 1つの製品 | +| `POST /api/v2/engagements/{id}/generate_report/` | 1つのエンゲージメント | +| `POST /api/v2/tests/{id}/generate_report/` | 1つのテスト | +| `POST /api/v2/product_types/{id}/generate_report/` | 1つの製品タイプ | +| `POST /api/v2/endpoints/{id}/generate_report/` | 1つのエンドポイント | + +Proオブジェクトのエイリアスも同じアクションを公開しています: `/api/v2/assets/{id}/generate_report/`、`/api/v2/organizations/{id}/generate_report/`、および`/api/v2/location/{id}/generate_report/`。 + +### Request options + +すべてのフィールドは任意です — 空のボディ(`{}`)をPOSTするとJSONレポートが返されます。 + +| Field | Type | Default | Description | +|---|---|---|---| +| `report_type` | string | `JSON` | `JSON`、`HTML`、`CSV`、`Excel`のいずれか。 | +| `include_finding_notes` | boolean | `false` | 各検出事項のメモを含めます。 | +| `include_finding_images` | boolean | `false` | 検出事項に添付された画像を含めます。 | +| `include_executive_summary` | boolean | `false` | エグゼクティブサマリーセクションを含めます。 | +| `include_table_of_contents` | boolean | `false` | 目次を含めます。 | + +サポートされていない`report_type`(例: `PDF`)を指定すると、`report_type`フィールドのエラーとともに`400 Bad Request`が返されます。 + +### Example + +閲覧可能なすべての検出事項のCSVレポートを生成し、ファイルに保存します: + +```bash +curl -X POST \ + -H "Authorization: Token " \ + -H "Content-Type: application/json" \ + -d '{"report_type": "CSV"}' \ + https:///api/v2/findings/generate_report/ \ + -o findings.csv +``` + +### Response formats + +| `report_type` | Content type | Response | +|---|---|---| +| `JSON` (default) | `application/json` | レスポンス内のレポート本文 | +| `HTML` | `text/html` | レンダリングされたレポートページ | +| `CSV` | `text/csv` | ファイル添付 | +| `Excel` | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` | `.xlsx`ファイル添付 | + +CSVとExcelは、JSON本文としてではなく、`Content-Disposition`ヘッダーを持つファイル添付として返されます。ファイル名は、レポートの生成元となったオブジェクトから決定されます — 例えば`product_1_findings.csv`や`test_42_findings.xlsx`のようになります。`/findings/generate_report/`エンドポイントは単一のオブジェクトに限定されないため、そのダウンロードファイルは`findings.csv`および`findings.xlsx`という名前になります。 + +### Notes and limitations + +* `include_*`オプションは**JSON**および**HTML**レポートにのみ影響します。**CSV**および**Excel**のエクスポートには常にすべての検出事項の行が含まれます。 +* レポートの生成には、対象オブジェクトに対する**閲覧**権限が必要であり、レポートにはユーザーが閲覧を許可されている検出事項のみが含まれます。 +* **標準のクエリパラメータフィルターはこのアクションには適用されません。** `GET /api/v2/findings/`とは異なり、`generate_report/`アクションは検出事項のフィルターを適用しないため、`POST /api/v2/findings/generate_report/?severity=High`のようなリクエストを送信しても、閲覧可能なすべての検出事項がレポートされます。レポートを絞り込むには、代わりに特定の製品、エンゲージメント、またはテストから生成してください。 + +## Asynchronous Deletion Behavior + +DefectDojoでの削除操作(APIとUIの両方経由)は、Celeryのバックグラウンドワーカーによって**非同期的に**処理されます。エンゲージメント、テスト、その他のオブジェクトを削除すると、APIまたはUIは即座に成功レスポンスを返しますが、実際の削除処理はバックグラウンドで実行されます。 + +つまり: +- 削除が確認された後もしばらくの間、オブジェクトがクエリ結果に表示され続けることがあります。 +- カスケード削除(例: エンゲージメントを削除すると、そのテストと検出事項も削除される)は、一連のバックグラウンドタスクとして処理されます。子オブジェクトは依存関係の順序で削除されます: 検出事項、次にテスト、次にエンゲージメントの順です。 +- 検出事項が多い大規模なエンゲージメントの場合、この処理が完了するまでに数分かかることがあります。 + +オブジェクトを依存関係の順序で削除するためのカスタムスクリプトを作成する必要はありません。エンゲージメントに対して単一の`DELETE`リクエストを送信するだけで、すべての子オブジェクトが自動的にカスケード削除されます。バックグラウンドタスクが完了するまで、時間を置いて待つだけで構いません。 + +## API Pagination Limits + +DefectDojo Proでは、APIリクエストあたりの最大ページサイズが**250**件に制限されています。`limit`を250より大きく設定すると、クエリタイムアウトによりHTTP 502エラーが発生する可能性があります。 + +オープンソース版のDefectDojoインスタンスでも、データセットのサイズやサーバーリソースによっては、非常に大きなページサイズでタイムアウトが発生する場合があります。 + +大量の結果セットを扱う場合は、50〜250件のページサイズでページネーションを使用し、ページ分割されたリクエストの間に短い遅延を挟んでワーカープールの過負荷を避けてください。 + +## Large-Scale Import Best Practices + +大量のスキャン結果をインポートする場合(例: 数千のコンポーネントを含むSBOMパイプライン)、以下の点を考慮してください: + +- **大きなペイロードには`background_import=true`を使用してください。** 同期インポートは、インポートが完了するまでuwsgiワーカーを占有するため、すべてのユーザーのパフォーマンスが低下する可能性があります。 +- **可能な限り、インポートあたりのペイロードサイズを1MB未満に抑えてください。** 大きなSBOMは、製品またはコンポーネントグループごとに小さなファイルに分割してください。 +- **連続するAPI呼び出しの間に遅延を追加してください。** そうしないと、ワーカープールが枯渇し、HTTP 502エラーが発生します。 +- **繰り返し行うスキャンには再インポート**(`/api/v2/reimport-scan/`)を使用し、重複を作成するのではなく既存の検出事項を更新してください。 + +## Background import responses (API: `background_import`) + +バックグラウンドインポートは、アップロードされたレポートが解析され次第、検出事項が書き込まれる前にレスポンスを返します。そのため、レスポンスは*スケジュールされた*処理内容を表しており、同期インポートとは異なる形をしています。これは、`background_import`が`true`の場合、または`api_async_import`システム設定によってすべてのインポートで有効化されている場合の、`/api/v2/import-scan/`および`/api/v2/reimport-scan/`に適用されます。 + +バックグラウンドレスポンスには次の内容が含まれます: + +- `background_import` — `true`。この値によって処理を分岐させます。 +- `status` — レスポンスが生成された時点でのテストのライフサイクルステータス: + `Processing`、`Post Processing - Deduplication`、 + `Post Processing - False Positive History`、`Processed`、`Failed`のいずれか。 +- `findings_parsed` — レポートから読み取られた検出事項の数。これは解析件 + 数であり、作成件数ではありません。重複排除や指定したインポートオプションによって、 + 実際に書き込まれる検出事項の数が決まります。 +- `test_id`(および`engagement_id`、`product_id`、`product_type_id`) — ポーリングに使用する + 識別子。 +- `message` — `status`と`findings_parsed`と同じ情報を文章で表したものです。 + 構造化されたフィールドの使用を推奨します。 + +バックグラウンドインポートには`statistics`は**含まれず**、`deduplication_complete`も含まれません。 +これらのキーは、その時点でまだ検出事項が作成されておらず、ゼロを報告するとインポートの状態を誤って伝えることになるため、値が +ゼロなのではなく存在しないのです。`response["statistics"]`を無条件に読み取るクライアントは、バックグラウンドインポートで失敗します。先に +`background_import`を確認するか、`statistics`は同期処理のパスでのみ使用してください。 + +バックグラウンドインポートを完了まで追跡するには、テストをポーリングします: + +``` +POST /api/v2/import-scan/ (background_import=true) -> test_id, status, findings_parsed +GET /api/v2/tests/{test_id}/ -> status, processing +``` + +`status`が`Processed`(インポートが完了し、テストの検出事項数が意味を持つ状態になった)または`Failed`(インポートが完了しなかった)に +なるまで、`GET`を繰り返してください。インポートの実行中は、`processing`が`true`になり、`status`は現在のフェーズを示します。 +ポーリングの間隔は数秒空けてください。大きなレポートでは、後処理に数分かかることがあります。 + +同期インポート(`background_import`を省略、または`false`)の動作は変わりません。検出事項の書き込みが完了した時点でレスポンスが返され、`statistics` +が含まれ、`status`や`findings_parsed`は含まれません。 + +## Using the Scan Completion Date (API: `scan_date`) field + +DefectDojoは非常に多くのスキャナーレポート形式をサポートしていますが、そのすべてがユーザーにとって最も重要な +情報を含んでいるわけではありません。`scan_date`フィールドは、指定されたスキャンレポートの完了日を設定し、それをインポートされたすべての検出事項に伝播させることが +できる柔軟なスマート機能です。このフィールドは**必須ではありません**が、指定しない場合のデフォルト値はインポート日(リクエストが処理され、成功レスポンスが返された時点の日付)になります。 + +このフィールドの使用例は次のとおりです: + +1. レポートに日付が設定されて**おらず**、インポート時に`scan_date`も設定され**ていない**場合 + - 検出事項の日付は`scan_date`のデフォルト値になります +2. レポートに日付が**設定されており**、インポート時に`scan_date`が設定され**ていない**場合 + - 検出事項の日付はレポートが設定した値になります +3. レポートに日付が設定されて**おらず**、インポート時に`scan_date`が**設定されている**場合 + - 検出事項の日付はユーザーが`scan_date`に設定した値になります +4. レポートに日付が**設定されており**、インポート時に`scan_date`も**設定されている**場合 + - 検出事項の日付はユーザーが`scan_date`に設定した値になります diff --git a/docs/content/automation/api/languages.de.md b/docs/content/automation/api/languages.de.md new file mode 100644 index 00000000000..fbd4e2c6e3d --- /dev/null +++ b/docs/content/automation/api/languages.de.md @@ -0,0 +1,39 @@ +--- +title: Sprachen und Codezeilen +description: Daten zur Sprachzusammensetzung für ein Produkt mit dem Werkzeug cloc + importieren +weight: 3 +audience: opensource +aliases: +- /de/en/open_source/languages +--- + +DefectDojo kann eine Aufschlüsselung der Programmiersprachen und Codezeilen für ein Produkt anzeigen, die durch den Import eines Berichts des Werkzeugs [cloc](https://github.com/AlDanial/cloc) (Count Lines of Code) über die API gefüllt wird. + +## Den cloc-Bericht erzeugen + +Führen Sie `cloc` mit dem Flag `--json` gegen Ihre Codebasis aus, um eine JSON-Datei im richtigen Format zu erzeugen: + +```bash +cloc --json /path/to/your/project > cloc-report.json +``` + +## Import über die API + +Laden Sie den JSON-Bericht über die API in DefectDojo hoch. Beim Import werden alle vorhandenen Sprachdaten des Produkts durch den Inhalt der neuen Datei ersetzt. + +Der Import-Endpunkt ist in der [Dokumentation zur DefectDojo API v2](../api-v2-docs/) beschrieben. + +## Ergebnisse ansehen + +Nach dem Import wird die Sprachaufschlüsselung auf der linken Seite der Produktdetailseite angezeigt, mit jeder Sprache und ihrer Zeilenanzahl. Die Farben der einzelnen Sprachen werden durch Einträge in der Tabelle `Language_Type` definiert, die mit Daten von GitHub vorbelegt ist. + +## Sprachfarben aktualisieren + +GitHub aktualisiert die Sprachfarben regelmäßig, wenn neue Sprachen entstehen. Um die neuesten Farbdaten zu übernehmen, führen Sie den folgenden Management-Befehl aus: + +```bash +./manage.py import_github_languages +``` + +Dieser liest aus [ozh/github-colors](https://github.com/ozh/github-colors) und ergänzt neue Sprachen oder aktualisiert vorhandene Farben. diff --git a/docs/content/automation/api/languages.es.md b/docs/content/automation/api/languages.es.md new file mode 100644 index 00000000000..64fa00c8e49 --- /dev/null +++ b/docs/content/automation/api/languages.es.md @@ -0,0 +1,39 @@ +--- +title: Idiomas y líneas de código +description: Importe datos de composición de idiomas para un Producto usando la herramienta + cloc +weight: 3 +audience: opensource +aliases: +- /es/en/open_source/languages +--- + +DefectDojo puede mostrar un desglose de los lenguajes de programación y las líneas de código de un Producto, que se completa importando un informe de la herramienta [cloc](https://github.com/AlDanial/cloc) (Count Lines of Code) a través de la API. + +## Generating the cloc Report + +Ejecute `cloc` sobre su base de código usando el flag `--json` para producir un archivo JSON con el formato correcto: + +```bash +cloc --json /path/to/your/project > cloc-report.json +``` + +## Importing via the API + +Suba el informe JSON a DefectDojo a través de la API. Al importar, todos los datos de idiomas existentes del Producto se reemplazan con el contenido del nuevo archivo. + +El endpoint de importación está documentado en la [documentación de la API v2 de DefectDojo](../api-v2-docs/). + +## Viewing Results + +Después de la importación, el desglose de idiomas se muestra en el lado izquierdo de la página de detalles del Producto, mostrando cada idioma y su recuento de líneas. Los colores de cada idioma se definen mediante entradas en la tabla `Language_Type`, previamente completada con datos de GitHub. + +## Updating Language Colors + +GitHub actualiza periódicamente los colores de los idiomas a medida que surgen nuevos lenguajes. Para obtener los datos de color más recientes, ejecute el siguiente comando de administración: + +```bash +./manage.py import_github_languages +``` + +Esto lee desde [ozh/github-colors](https://github.com/ozh/github-colors) y agrega nuevos idiomas o actualiza los colores existentes. diff --git a/docs/content/automation/api/languages.fr.md b/docs/content/automation/api/languages.fr.md new file mode 100644 index 00000000000..a7fa9183d76 --- /dev/null +++ b/docs/content/automation/api/languages.fr.md @@ -0,0 +1,39 @@ +--- +title: Langages et lignes de code +description: Importer les données de composition des langages pour un Produit à l'aide + de l'outil cloc +weight: 3 +audience: opensource +aliases: +- /fr/en/open_source/languages +--- + +DefectDojo peut afficher une répartition des langages de programmation et des lignes de code pour un Produit, alimentée par l'import d'un rapport de l'outil [cloc](https://github.com/AlDanial/cloc) (Count Lines of Code) via l'API. + +## Generating the cloc Report + +Exécutez `cloc` sur votre base de code avec l'option `--json` pour produire un fichier JSON au format attendu : + +```bash +cloc --json /path/to/your/project > cloc-report.json +``` + +## Importing via the API + +Envoyez le rapport JSON à DefectDojo via l'API. Lors de l'import, toutes les données de langage existantes pour le Produit sont remplacées par le contenu du nouveau fichier. + +L'endpoint d'import est documenté dans la [documentation de l'API DefectDojo v2](../api-v2-docs/). + +## Viewing Results + +Après l'import, la répartition des langages s'affiche sur le côté gauche de la page de détails du Produit, indiquant chaque langage et son nombre de lignes. Les couleurs de chaque langage sont définies par les entrées de la table `Language_Type`, préremplie avec les données de GitHub. + +## Updating Language Colors + +GitHub met périodiquement à jour les couleurs des langages à mesure que de nouveaux langages apparaissent. Pour récupérer les dernières données de couleurs, exécutez la commande de gestion suivante : + +```bash +./manage.py import_github_languages +``` + +Cette commande lit les données depuis [ozh/github-colors](https://github.com/ozh/github-colors) et ajoute les nouveaux langages ou met à jour les couleurs existantes. diff --git a/docs/content/automation/api/languages.ja.md b/docs/content/automation/api/languages.ja.md new file mode 100644 index 00000000000..47aa0705d8b --- /dev/null +++ b/docs/content/automation/api/languages.ja.md @@ -0,0 +1,38 @@ +--- +title: 言語とコード行数 +description: clocツールを使用して製品の言語構成データをインポートする +weight: 3 +audience: opensource +aliases: +- /ja/en/open_source/languages +--- + +DefectDojoでは、[cloc](https://github.com/AlDanial/cloc)(Count Lines of Code)ツールのレポートをAPI経由でインポートすることで、製品のプログラミング言語とコード行数の内訳を表示できます。 + +## Generating the cloc Report + +`--json`フラグを付けて`cloc`をコードベースに対して実行し、正しい形式のJSONファイルを生成します: + +```bash +cloc --json /path/to/your/project > cloc-report.json +``` + +## Importing via the API + +JSONレポートをAPI経由でDefectDojoにアップロードします。インポート時には、製品の既存の言語データはすべて新しいファイルの内容に置き換えられます。 + +インポートエンドポイントについては、[DefectDojo API v2 docs](../api-v2-docs/)に記載されています。 + +## Viewing Results + +インポート後、言語の内訳は製品詳細ページの左側に表示され、各言語とその行数が示されます。各言語の色は`Language_Type`テーブルのエントリーで定義されており、GitHubのデータで事前に設定されています。 + +## Updating Language Colors + +GitHubは新しい言語が登場するたびに、定期的に言語の色を更新しています。最新の色データを取得するには、次の管理コマンドを実行します: + +```bash +./manage.py import_github_languages +``` + +これは[ozh/github-colors](https://github.com/ozh/github-colors)から読み込み、新しい言語を追加したり、既存の色を更新したりします。 diff --git a/docs/content/automation/api/notification_webhooks.de.md b/docs/content/automation/api/notification_webhooks.de.md new file mode 100644 index 00000000000..1a38d3eb83b --- /dev/null +++ b/docs/content/automation/api/notification_webhooks.de.md @@ -0,0 +1,347 @@ +--- +title: Benachrichtigungs-Webhooks +description: HTTP-Webhook-Benachrichtigungen bei DefectDojo-Ereignissen an einen externen + Server senden +weight: 8 +audience: opensource +aliases: +- /de/en/open_source/notification_webhooks/how_to +--- + +**Dies ist eine experimentelle Open-Source-Funktion — das Verhalten kann sich in künftigen Releases ändern.** + +Webhooks sind ausgehende HTTP-Anfragen, die von Ihrer DefectDojo-Instanz an einen benutzerdefinierten Server gesendet werden, sobald bestimmte Ereignisse eintreten. + +## Einrichtung + +Webhook-Endpunkte werden von Administratoren konfiguriert. Wenn ein Webhook erstellt wird, sendet DefectDojo ein [`ping`](#ping)-Ereignis, um zu prüfen, ob der Endpunkt erreichbar ist und den erwarteten Statuscode zurückgibt. + +## Zustandsübergänge von Endpunkten + +DefectDojo überwacht den Zustellerfolg und deaktiviert einen Endpunkt auf Basis von HTTP-Antworten oder Netzwerkfehlern vorübergehend oder dauerhaft. Eine manuelle Reaktivierung durch einen Administrator ist ebenfalls möglich. + +- **Stadionförmige Zustände**: Aktiv — Webhooks können gesendet werden +- **Rechteckige Zustände**: Inaktiv — die Webhook-Zustellung schlägt fehl und wird nicht wiederholt +- **Übergänge ausgelöst durch**: HTTP-Antworten des Zielservers, Celery-Automatisierung oder manuelle Administratoraktion + +## Anfrage-Header + +Jede Webhook-Anfrage enthält die folgenden Header: + +```yaml +User-Agent: DefectDojo- +X-DefectDojo-Event: +X-DefectDojo-Instance: +``` + +## Ereignisse + +### product_type_added + +Wird ausgelöst, wenn ein neuer Produkttyp erstellt wird. + +**Header:** +```yaml +X-DefectDojo-Event: product_type_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### product_added + +Wird ausgelöst, wenn ein neues Produkt erstellt wird. + +**Header:** +```yaml +X-DefectDojo-Event: product_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### engagement_added + +Wird ausgelöst, wenn ein neues Engagement erstellt wird. + +**Header:** +```yaml +X-DefectDojo-Event: engagement_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### test_added + +Wird ausgelöst, wenn ein neuer Test erstellt wird. + +**Header:** +```yaml +X-DefectDojo-Event: test_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "test": { + "id": 90, + "title": "notif test", + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90" + }, + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### scan_added / scan_added_empty + +Wird ausgelöst, wenn ein Scan importiert oder erneut importiert wird. `scan_added_empty` wird ausgelöst, wenn ein Reimport zu keinen Änderungen führt (keine Befunde erstellt oder geschlossen). + +**Header:** +```yaml +X-DefectDojo-Event: scan_added +``` +```yaml +X-DefectDojo-Event: scan_added_empty +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "finding_count": 4, + "findings": { + "mitigated": [ + { + "id": 233, + "severity": "Medium", + "title": "Mitigated Finding", + "url_api": "http://localhost:8080/api/v2/findings/233/", + "url_ui": "http://localhost:8080/finding/233" + } + ], + "new": [ + { + "id": 232, + "severity": "Critical", + "title": "New Finding", + "url_api": "http://localhost:8080/api/v2/findings/232/", + "url_ui": "http://localhost:8080/finding/232" + } + ], + "reactivated": [ + { + "id": 234, + "severity": "Low", + "title": "Reactivated Finding", + "url_api": "http://localhost:8080/api/v2/findings/234/", + "url_ui": "http://localhost:8080/finding/234" + } + ], + "untouched": [ + { + "id": 235, + "severity": "Info", + "title": "Untouched Finding", + "url_api": "http://localhost:8080/api/v2/findings/235/", + "url_ui": "http://localhost:8080/finding/235" + } + ] + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "test": { + "id": 90, + "title": "notif test", + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90" + }, + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### ping + +Wird während der Webhook-Einrichtung gesendet, um zu prüfen, ob der Endpunkt erreichbar ist. + +**Header:** +```yaml +X-DefectDojo-Event: ping +``` + +**Body:** +```json +{ + "description": "Test webhook notification", + "title": "", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +## Roadmap + +Bekannte geplante Verbesserungen: + +- SLA-bezogene Ereignisse (noch nicht unterstützt) +- Benutzerdefinierte Webhooks (derzeit nur für Administratoren) +- Verbesserte Oberfläche mit Filterung und Paginierung für Webhook-Endpunkte diff --git a/docs/content/automation/api/notification_webhooks.es.md b/docs/content/automation/api/notification_webhooks.es.md new file mode 100644 index 00000000000..60fbfe21aea --- /dev/null +++ b/docs/content/automation/api/notification_webhooks.es.md @@ -0,0 +1,347 @@ +--- +title: Webhooks de notificación +description: Envíe notificaciones de webhook HTTP a un servidor externo ante eventos + de DefectDojo +weight: 8 +audience: opensource +aliases: +- /es/en/open_source/notification_webhooks/how_to +--- + +**Esta es una función experimental de Open Source; su comportamiento puede cambiar en futuras versiones.** + +Los webhooks son solicitudes HTTP salientes que se envían desde su instancia de DefectDojo a un servidor definido por el usuario cada vez que ocurren eventos específicos. + +## Setup + +Los endpoints de webhook los configuran los administradores. Cuando se crea un webhook, DefectDojo envía un evento [`ping`](#ping) para verificar que el endpoint sea accesible y devuelva el código de estado esperado. + +## Endpoint State Transitions + +DefectDojo supervisa el éxito de la entrega y deshabilitará un endpoint de forma temporal o permanente según las respuestas HTTP o los fallos de red. También es posible la reactivación manual por parte de un administrador. + +- **Estados con forma de estadio**: Activo — se pueden enviar webhooks +- **Estados rectangulares**: Inactivo — la entrega de webhooks fallará y no se reintentará +- **Transiciones impulsadas por**: respuestas HTTP del servidor de destino, automatización de celery o acción manual de un administrador + +## Request Headers + +Cada solicitud de webhook incluye los siguientes encabezados: + +```yaml +User-Agent: DefectDojo- +X-DefectDojo-Event: +X-DefectDojo-Instance: +``` + +## Events + +### product_type_added + +Se dispara cuando se crea un nuevo Tipo de producto. + +**Encabezado:** +```yaml +X-DefectDojo-Event: product_type_added +``` + +**Cuerpo:** +```json +{ + "description": "", + "title": "", + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### product_added + +Se dispara cuando se crea un nuevo Producto. + +**Encabezado:** +```yaml +X-DefectDojo-Event: product_added +``` + +**Cuerpo:** +```json +{ + "description": "", + "title": "", + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### engagement_added + +Se dispara cuando se crea un nuevo Compromiso. + +**Encabezado:** +```yaml +X-DefectDojo-Event: engagement_added +``` + +**Cuerpo:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### test_added + +Se dispara cuando se crea un nuevo Test. + +**Encabezado:** +```yaml +X-DefectDojo-Event: test_added +``` + +**Cuerpo:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "test": { + "id": 90, + "title": "notif test", + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90" + }, + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### scan_added / scan_added_empty + +Se dispara cuando se importa o reimporta un escaneo. `scan_added_empty` se dispara cuando una reimportación no produce cambios (no se crean ni cierran hallazgos). + +**Encabezados:** +```yaml +X-DefectDojo-Event: scan_added +``` +```yaml +X-DefectDojo-Event: scan_added_empty +``` + +**Cuerpo:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "finding_count": 4, + "findings": { + "mitigated": [ + { + "id": 233, + "severity": "Medium", + "title": "Mitigated Finding", + "url_api": "http://localhost:8080/api/v2/findings/233/", + "url_ui": "http://localhost:8080/finding/233" + } + ], + "new": [ + { + "id": 232, + "severity": "Critical", + "title": "New Finding", + "url_api": "http://localhost:8080/api/v2/findings/232/", + "url_ui": "http://localhost:8080/finding/232" + } + ], + "reactivated": [ + { + "id": 234, + "severity": "Low", + "title": "Reactivated Finding", + "url_api": "http://localhost:8080/api/v2/findings/234/", + "url_ui": "http://localhost:8080/finding/234" + } + ], + "untouched": [ + { + "id": 235, + "severity": "Info", + "title": "Untouched Finding", + "url_api": "http://localhost:8080/api/v2/findings/235/", + "url_ui": "http://localhost:8080/finding/235" + } + ] + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "test": { + "id": 90, + "title": "notif test", + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90" + }, + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### ping + +Se envía durante la configuración del webhook para verificar que el endpoint sea accesible. + +**Encabezado:** +```yaml +X-DefectDojo-Event: ping +``` + +**Cuerpo:** +```json +{ + "description": "Test webhook notification", + "title": "", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +## Roadmap + +Mejoras planificadas conocidas: + +- Eventos relacionados con SLA (aún no compatibles) +- Webhooks definidos por el usuario (actualmente solo para administradores) +- Interfaz mejorada con filtrado y paginación para los endpoints de webhook diff --git a/docs/content/automation/api/notification_webhooks.fr.md b/docs/content/automation/api/notification_webhooks.fr.md new file mode 100644 index 00000000000..314a619fb96 --- /dev/null +++ b/docs/content/automation/api/notification_webhooks.fr.md @@ -0,0 +1,347 @@ +--- +title: Webhooks de notification +description: Envoyer des notifications webhook HTTP vers un serveur externe lors d'événements + DefectDojo +weight: 8 +audience: opensource +aliases: +- /fr/en/open_source/notification_webhooks/how_to +--- + +**Il s'agit d'une fonctionnalité Open Source expérimentale — son comportement peut évoluer dans les prochaines versions.** + +Les webhooks sont des requêtes HTTP sortantes envoyées depuis votre instance DefectDojo vers un serveur défini par l'utilisateur lorsque certains événements se produisent. + +## Setup + +Les endpoints de webhook sont configurés par les administrateurs. Lors de la création d'un webhook, DefectDojo envoie un événement [`ping`](#ping) pour vérifier que l'endpoint est accessible et renvoie le code de statut attendu. + +## Endpoint State Transitions + +DefectDojo surveille le succès des livraisons et désactive temporairement ou définitivement un endpoint en fonction des réponses HTTP ou des échecs réseau. Une réactivation manuelle par un administrateur reste également possible. + +- **États en forme de stade** : Active — les webhooks peuvent être envoyés +- **États en forme de rectangle** : Inactive — la livraison du webhook échoue et n'est pas retentée +- **Transitions déclenchées par** : les réponses HTTP du serveur cible, l'automatisation celery, ou une action manuelle de l'administrateur + +## Request Headers + +Chaque requête webhook inclut les en-têtes suivants : + +```yaml +User-Agent: DefectDojo- +X-DefectDojo-Event: +X-DefectDojo-Instance: +``` + +## Events + +### product_type_added + +Déclenché lors de la création d'un nouveau Type de produit. + +**Header:** +```yaml +X-DefectDojo-Event: product_type_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### product_added + +Déclenché lors de la création d'un nouveau Produit. + +**Header:** +```yaml +X-DefectDojo-Event: product_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### engagement_added + +Déclenché lors de la création d'un nouvel Engagement. + +**Header:** +```yaml +X-DefectDojo-Event: engagement_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### test_added + +Déclenché lors de la création d'un nouveau Test. + +**Header:** +```yaml +X-DefectDojo-Event: test_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "test": { + "id": 90, + "title": "notif test", + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90" + }, + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### scan_added / scan_added_empty + +Déclenché lorsqu'un scan est importé ou réimporté. `scan_added_empty` se déclenche lorsqu'un réimport n'entraîne aucun changement (aucune constatation créée ou clôturée). + +**Headers:** +```yaml +X-DefectDojo-Event: scan_added +``` +```yaml +X-DefectDojo-Event: scan_added_empty +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "finding_count": 4, + "findings": { + "mitigated": [ + { + "id": 233, + "severity": "Medium", + "title": "Mitigated Finding", + "url_api": "http://localhost:8080/api/v2/findings/233/", + "url_ui": "http://localhost:8080/finding/233" + } + ], + "new": [ + { + "id": 232, + "severity": "Critical", + "title": "New Finding", + "url_api": "http://localhost:8080/api/v2/findings/232/", + "url_ui": "http://localhost:8080/finding/232" + } + ], + "reactivated": [ + { + "id": 234, + "severity": "Low", + "title": "Reactivated Finding", + "url_api": "http://localhost:8080/api/v2/findings/234/", + "url_ui": "http://localhost:8080/finding/234" + } + ], + "untouched": [ + { + "id": 235, + "severity": "Info", + "title": "Untouched Finding", + "url_api": "http://localhost:8080/api/v2/findings/235/", + "url_ui": "http://localhost:8080/finding/235" + } + ] + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "test": { + "id": 90, + "title": "notif test", + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90" + }, + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### ping + +Envoyé lors de la configuration du webhook pour vérifier que l'endpoint est accessible. + +**Header:** +```yaml +X-DefectDojo-Event: ping +``` + +**Body:** +```json +{ + "description": "Test webhook notification", + "title": "", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +## Roadmap + +Améliorations prévues connues : + +- Événements liés aux SLA (non encore pris en charge) +- Webhooks définis par l'utilisateur (actuellement réservés aux administrateurs) +- UI améliorée avec filtrage et pagination pour les endpoints de webhook diff --git a/docs/content/automation/api/notification_webhooks.ja.md b/docs/content/automation/api/notification_webhooks.ja.md new file mode 100644 index 00000000000..f9f388cfcd0 --- /dev/null +++ b/docs/content/automation/api/notification_webhooks.ja.md @@ -0,0 +1,346 @@ +--- +title: 通知Webhook +description: DefectDojoのイベント発生時に、外部サーバーへHTTP Webhook通知を送信する +weight: 8 +audience: opensource +aliases: +- /ja/en/open_source/notification_webhooks/how_to +--- + +**これは実験的なオープンソース機能です — 今後のリリースで動作が変更される可能性があります。** + +Webhookは、特定のイベントが発生するたびに、DefectDojoインスタンスからユーザー定義のサーバーへ送信されるアウトバウンドHTTPリクエストです。 + +## Setup + +Webhookエンドポイントは管理者が設定します。Webhookが作成されると、DefectDojoはエンドポイントに到達可能であり、期待されるステータスコードを返すことを確認するために[`ping`](#ping)イベントを送信します。 + +## Endpoint State Transitions + +DefectDojoは配信の成功状況を監視し、HTTPレスポンスやネットワーク障害に基づいてエンドポイントを一時的または恒久的に無効化します。管理者による手動での再有効化も可能です。 + +- **スタジアム型の状態**: アクティブ — Webhookを送信できます +- **矩形の状態**: 非アクティブ — Webhookの配信は失敗し、再試行されません +- **状態遷移のトリガー**: 対象サーバーからのHTTPレスポンス、celeryの自動処理、または管理者による手動操作 + +## Request Headers + +すべてのWebhookリクエストには、以下のヘッダーが含まれます: + +```yaml +User-Agent: DefectDojo- +X-DefectDojo-Event: +X-DefectDojo-Instance: +``` + +## Events + +### product_type_added + +新しい製品タイプが作成されたときに発火します。 + +**Header:** +```yaml +X-DefectDojo-Event: product_type_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### product_added + +新しい製品が作成されたときに発火します。 + +**Header:** +```yaml +X-DefectDojo-Event: product_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### engagement_added + +新しいエンゲージメントが作成されたときに発火します。 + +**Header:** +```yaml +X-DefectDojo-Event: engagement_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### test_added + +新しいテストが作成されたときに発火します。 + +**Header:** +```yaml +X-DefectDojo-Event: test_added +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "test": { + "id": 90, + "title": "notif test", + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90" + }, + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### scan_added / scan_added_empty + +スキャンがインポートまたは再インポートされたときに発火します。`scan_added_empty`は、再インポートの結果、変更が発生しなかった場合(検出事項が新規作成もクローズもされなかった場合)に発火します。 + +**Headers:** +```yaml +X-DefectDojo-Event: scan_added +``` +```yaml +X-DefectDojo-Event: scan_added_empty +``` + +**Body:** +```json +{ + "description": "", + "title": "", + "engagement": { + "id": 7, + "name": "notif eng", + "url_api": "http://localhost:8080/api/v2/engagements/7/", + "url_ui": "http://localhost:8080/engagement/7" + }, + "finding_count": 4, + "findings": { + "mitigated": [ + { + "id": 233, + "severity": "Medium", + "title": "Mitigated Finding", + "url_api": "http://localhost:8080/api/v2/findings/233/", + "url_ui": "http://localhost:8080/finding/233" + } + ], + "new": [ + { + "id": 232, + "severity": "Critical", + "title": "New Finding", + "url_api": "http://localhost:8080/api/v2/findings/232/", + "url_ui": "http://localhost:8080/finding/232" + } + ], + "reactivated": [ + { + "id": 234, + "severity": "Low", + "title": "Reactivated Finding", + "url_api": "http://localhost:8080/api/v2/findings/234/", + "url_ui": "http://localhost:8080/finding/234" + } + ], + "untouched": [ + { + "id": 235, + "severity": "Info", + "title": "Untouched Finding", + "url_api": "http://localhost:8080/api/v2/findings/235/", + "url_ui": "http://localhost:8080/finding/235" + } + ] + }, + "product": { + "id": 4, + "name": "notif prod", + "url_api": "http://localhost:8080/api/v2/products/4/", + "url_ui": "http://localhost:8080/product/4" + }, + "product_type": { + "id": 4, + "name": "notif prod type", + "url_api": "http://localhost:8080/api/v2/product_types/4/", + "url_ui": "http://localhost:8080/product/type/4" + }, + "test": { + "id": 90, + "title": "notif test", + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90" + }, + "url_api": "http://localhost:8080/api/v2/tests/90/", + "url_ui": "http://localhost:8080/test/90", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +--- + +### ping + +Webhookのセットアップ時に、エンドポイントへの到達可能性を確認するために送信されます。 + +**Header:** +```yaml +X-DefectDojo-Event: ping +``` + +**Body:** +```json +{ + "description": "Test webhook notification", + "title": "", + "user": { + "id": 1, + "email": "admin@defectdojo.local", + "first_name": "Admin", + "last_name": "User", + "username": "admin", + "url_api": "http://localhost:8080/api/v2/users/1/", + "url_ui": "http://localhost:8080/user/1" + } +} +``` + +## Roadmap + +計画されている既知の改善事項: + +- SLA関連イベント(まだサポートされていません) +- ユーザー定義のWebhook(現在は管理者のみ設定可能) +- Webhookエンドポイント向けのフィルタリングとページネーションを備えたUIの改善 diff --git a/docs/content/automation/api/rate_limiting.de.md b/docs/content/automation/api/rate_limiting.de.md new file mode 100644 index 00000000000..e334a94240c --- /dev/null +++ b/docs/content/automation/api/rate_limiting.de.md @@ -0,0 +1,45 @@ +--- +title: Ratenbegrenzung +description: Ratenbegrenzung auf der Anmeldeseite konfigurieren, um Brute-Force-Angriffe + abzuschwächen +weight: 4 +audience: opensource +aliases: +- /de/en/open_source/rate_limiting +--- + +DefectDojo enthält eine Ratenbegrenzung für die Anmeldeseite zum Schutz vor Brute-Force-Angriffen, umgesetzt mit [Django Ratelimit](https://django-ratelimit.readthedocs.io/en/stable/index.html). + +## Konfiguration + +Die Ratenbegrenzung wird über die folgenden Einstellungen konfiguriert (siehe [Konfiguration](/get_started/open_source/configuration/) für die Anwendung dieser Einstellungen): + +```python +DD_RATE_LIMITER_ENABLED=(bool, True), +DD_RATE_LIMITER_RATE=(str, '5/m'), +DD_RATE_LIMITER_BLOCK=(bool, True), +DD_RATE_LIMITER_ACCOUNT_LOCKOUT=(bool, True), +``` + +### Ratenlimit (`DD_RATE_LIMITER_RATE`) + +Legt fest, wie häufig Anfragen begrenzt werden. Unterstützte Einheiten: + +- Sekunden: `1s` +- Minuten: `5m` +- Stunden: `100h` +- Tage: `2400d` + +Weitere Konfigurationsmöglichkeiten finden Sie in der [Dokumentation zu den Raten von Django Ratelimit](https://django-ratelimit.readthedocs.io/en/stable/rates.html). + +### Anfragen blockieren (`DD_RATE_LIMITER_BLOCK`) + +Standardmäßig protokolliert die Ratenbegrenzung Verstöße, blockiert Anfragen aber nicht. Wird `DD_RATE_LIMITER_BLOCK` auf `True` gesetzt, werden alle eingehenden Anfragen aktiv blockiert, sobald die konfigurierte Rate überschritten wird. + +### Kontosperrung (`DD_RATE_LIMITER_ACCOUNT_LOCKOUT`) + +Ist diese Option aktiviert, muss ein Benutzer, dessen Anmeldeversuche die Ratenbegrenzung auslösen, sein Passwort zurücksetzen, bevor er sich wieder anmelden kann. Das verringert das Risiko einer Kompromittierung von Zugangsdaten während eines Brute-Force-Angriffs. + +## Verhalten bei mehreren Prozessen + +Beim Betrieb mit mehreren `uwsgi`-Prozessen verwendet das Paket für die Ratenbegrenzung einen speicherbasierten Cache, der für jeden Prozess lokal ist. Die Zähler der Ratenbegrenzung werden in dieser Standardkonfiguration nicht prozessübergreifend geteilt. diff --git a/docs/content/automation/api/rate_limiting.es.md b/docs/content/automation/api/rate_limiting.es.md new file mode 100644 index 00000000000..f993acd7b4c --- /dev/null +++ b/docs/content/automation/api/rate_limiting.es.md @@ -0,0 +1,45 @@ +--- +title: Limitación de tasa +description: Configure la limitación de tasa en la página de inicio de sesión para + mitigar ataques de fuerza bruta +weight: 4 +audience: opensource +aliases: +- /es/en/open_source/rate_limiting +--- + +DefectDojo incluye limitación de tasa en la página de inicio de sesión para proteger contra ataques de fuerza bruta, mediante [Django Ratelimit](https://django-ratelimit.readthedocs.io/en/stable/index.html). + +## Configuration + +La limitación de tasa se configura mediante los siguientes ajustes (consulte [Configuración](/get_started/open_source/configuration/) para saber cómo aplicarlos): + +```python +DD_RATE_LIMITER_ENABLED=(bool, True), +DD_RATE_LIMITER_RATE=(str, '5/m'), +DD_RATE_LIMITER_BLOCK=(bool, True), +DD_RATE_LIMITER_ACCOUNT_LOCKOUT=(bool, True), +``` + +### Rate Limit (`DD_RATE_LIMITER_RATE`) + +Establece con qué frecuencia se limitarán las solicitudes. Unidades admitidas: + +- Segundos: `1s` +- Minutos: `5m` +- Horas: `100h` +- Días: `2400d` + +Consulte la [documentación de tasas de Django Ratelimit](https://django-ratelimit.readthedocs.io/en/stable/rates.html) para ver opciones de configuración extendidas. + +### Block Requests (`DD_RATE_LIMITER_BLOCK`) + +De forma predeterminada, la limitación de tasa registra las infracciones pero no bloquea las solicitudes. Configurar `DD_RATE_LIMITER_BLOCK` en `True` bloqueará activamente todas las solicitudes entrantes una vez que se supere la tasa configurada. + +### Account Lockout (`DD_RATE_LIMITER_ACCOUNT_LOCKOUT`) + +Cuando está habilitado, un usuario cuyos intentos de inicio de sesión activen el límite de tasa deberá restablecer su contraseña antes de poder volver a iniciar sesión. Esto reduce el riesgo de compromiso de credenciales durante un ataque de fuerza bruta. + +## Multi-Process Behaviour + +Al ejecutarse con varios procesos de `uwsgi`, el paquete de limitación de tasa usa una caché basada en memoria que es local a cada proceso. En esta configuración predeterminada, los contadores del límite de tasa no se comparten entre procesos. diff --git a/docs/content/automation/api/rate_limiting.fr.md b/docs/content/automation/api/rate_limiting.fr.md new file mode 100644 index 00000000000..4671029074a --- /dev/null +++ b/docs/content/automation/api/rate_limiting.fr.md @@ -0,0 +1,45 @@ +--- +title: Limitation de débit +description: Configurer la limitation de débit sur la page de connexion pour atténuer + les attaques par force brute +weight: 4 +audience: opensource +aliases: +- /fr/en/open_source/rate_limiting +--- + +DefectDojo intègre une limitation de débit sur la page de connexion pour se protéger contre les attaques par force brute, basée sur [Django Ratelimit](https://django-ratelimit.readthedocs.io/en/stable/index.html). + +## Configuration + +La limitation de débit se configure via les paramètres suivants (voir [Configuration](/get_started/open_source/configuration/) pour savoir comment les appliquer) : + +```python +DD_RATE_LIMITER_ENABLED=(bool, True), +DD_RATE_LIMITER_RATE=(str, '5/m'), +DD_RATE_LIMITER_BLOCK=(bool, True), +DD_RATE_LIMITER_ACCOUNT_LOCKOUT=(bool, True), +``` + +### Rate Limit (`DD_RATE_LIMITER_RATE`) + +Définit la fréquence à laquelle les requêtes sont limitées. Unités prises en charge : + +- Secondes : `1s` +- Minutes : `5m` +- Heures : `100h` +- Jours : `2400d` + +Consultez la [documentation Django Ratelimit sur les taux](https://django-ratelimit.readthedocs.io/en/stable/rates.html) pour des options de configuration avancées. + +### Block Requests (`DD_RATE_LIMITER_BLOCK`) + +Par défaut, la limitation de débit enregistre les infractions mais ne bloque pas les requêtes. Définir `DD_RATE_LIMITER_BLOCK` sur `True` bloque activement toutes les requêtes entrantes une fois le débit configuré dépassé. + +### Account Lockout (`DD_RATE_LIMITER_ACCOUNT_LOCKOUT`) + +Lorsque cette option est activée, un utilisateur dont les tentatives de connexion déclenchent la limite de débit doit réinitialiser son mot de passe avant de pouvoir se reconnecter. Cela réduit le risque de compromission des identifiants lors d'une attaque par force brute. + +## Multi-Process Behaviour + +Lors de l'exécution avec plusieurs processus `uwsgi`, le package de limitation de débit utilise un cache en mémoire local à chaque processus. Dans cette configuration par défaut, les compteurs de limitation de débit ne sont pas partagés entre les processus. diff --git a/docs/content/automation/api/rate_limiting.ja.md b/docs/content/automation/api/rate_limiting.ja.md new file mode 100644 index 00000000000..33bfdc71e76 --- /dev/null +++ b/docs/content/automation/api/rate_limiting.ja.md @@ -0,0 +1,44 @@ +--- +title: レート制限 +description: ブルートフォース攻撃を軽減するため、ログインページのレート制限を設定する +weight: 4 +audience: opensource +aliases: +- /ja/en/open_source/rate_limiting +--- + +DefectDojoには、ブルートフォース攻撃から保護するためのログインページのレート制限機能が含まれており、[Django Ratelimit](https://django-ratelimit.readthedocs.io/en/stable/index.html)によって実現されています。 + +## Configuration + +レート制限は以下の設定によって構成されます(これらの適用方法については[Configuration](/get_started/open_source/configuration/)を参照してください): + +```python +DD_RATE_LIMITER_ENABLED=(bool, True), +DD_RATE_LIMITER_RATE=(str, '5/m'), +DD_RATE_LIMITER_BLOCK=(bool, True), +DD_RATE_LIMITER_ACCOUNT_LOCKOUT=(bool, True), +``` + +### Rate Limit (`DD_RATE_LIMITER_RATE`) + +リクエストを制限する頻度を設定します。サポートされている単位: + +- 秒: `1s` +- 分: `5m` +- 時間: `100h` +- 日: `2400d` + +より詳細な設定オプションについては、[Django Ratelimit rates docs](https://django-ratelimit.readthedocs.io/en/stable/rates.html)を参照してください。 + +### Block Requests (`DD_RATE_LIMITER_BLOCK`) + +デフォルトでは、レート制限は違反を記録しますが、リクエストをブロックしません。`DD_RATE_LIMITER_BLOCK`を`True`に設定すると、設定されたレートを超過した時点で、すべての受信リクエストが積極的にブロックされるようになります。 + +### Account Lockout (`DD_RATE_LIMITER_ACCOUNT_LOCKOUT`) + +有効にすると、ログイン試行がレート制限をトリガーしたユーザーは、再度ログインする前にパスワードのリセットを求められます。これにより、ブルートフォース攻撃時における認証情報漏洩のリスクが軽減されます。 + +## Multi-Process Behaviour + +複数の`uwsgi`プロセスで実行している場合、レート制限パッケージは各プロセスに固有のメモリベースのキャッシュを使用します。このデフォルト設定では、レート制限のカウンターはプロセス間で共有されません。 diff --git a/docs/content/automation/rules_engine/_index.de.md b/docs/content/automation/rules_engine/_index.de.md new file mode 100644 index 00000000000..14d1a6ce7bc --- /dev/null +++ b/docs/content/automation/rules_engine/_index.de.md @@ -0,0 +1,17 @@ +--- +title: Rules Engine +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine/_index.es.md b/docs/content/automation/rules_engine/_index.es.md new file mode 100644 index 00000000000..14d1a6ce7bc --- /dev/null +++ b/docs/content/automation/rules_engine/_index.es.md @@ -0,0 +1,17 @@ +--- +title: Rules Engine +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine/_index.fr.md b/docs/content/automation/rules_engine/_index.fr.md new file mode 100644 index 00000000000..097b78063c8 --- /dev/null +++ b/docs/content/automation/rules_engine/_index.fr.md @@ -0,0 +1,17 @@ +--- +title: Moteur de règles +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine/_index.ja.md b/docs/content/automation/rules_engine/_index.ja.md new file mode 100644 index 00000000000..14d1a6ce7bc --- /dev/null +++ b/docs/content/automation/rules_engine/_index.ja.md @@ -0,0 +1,17 @@ +--- +title: Rules Engine +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine/about.de.md b/docs/content/automation/rules_engine/about.de.md new file mode 100644 index 00000000000..17f9da34c52 --- /dev/null +++ b/docs/content/automation/rules_engine/about.de.md @@ -0,0 +1,126 @@ +--- +title: Rules Engine-Automatisierung +description: Arbeiten mit der Rules Engine-Automatisierung +weight: 1 +audience: pro +aliases: +- /de/en/customize_dojo/rules_engine +--- + +Hinweis: Rules Engine ist eine reine DefectDojo-Pro-Funktion. + +Mit der Rules Engine von DefectDojo können Sie benutzerdefinierte Workflows und Massenaktionen erstellen, um Befunde und andere Objekte zu verarbeiten. Mit der Rules Engine können Sie automatisierte Aktionen erstellen, die ausgelöst werden, wenn ein Objekt einer Regel entspricht. + +Die Rules Engine ist nur über die [Pro UI](/get_started/about/ui_pro_vs_os/) zugänglich. + +**Suchen Sie den grafischen Editor?** [Rules Engine 2.0](/automation/rules_engine_2/about/) baut Automatisierung als visuelle Knotengraphen auf und fügt Verzweigungen, ausgehende Aktionen wie Tickets und Nachrichten, Spuren pro Lauf und ein Zustellungsprotokoll hinzu. Beide Engines laufen nebeneinander, und bestehende Regeln können [dorthin übertragen werden](/automation/rules_engine_2/converting_from_rules_engine/). + +## Rules Engine aktivieren + +Die Rules Engine befindet sich in der Beta-Phase und ist standardmäßig deaktiviert. Ein Superuser kann sie unter **Settings > Feature Flags** aktivieren, sowohl bei Cloud- als auch bei On-Premise-Instanzen. Siehe [Feature Flags](/admin/feature_flags/pro__feature_flags/). + +Aktuell können Regeln nur für Befunde erstellt werden, weitere Objekttypen werden jedoch in Zukunft unterstützt. + +Regeln können manuell über die Seite **All Rules** ausgelöst oder so geplant werden, dass sie automatisch nach einem wiederkehrenden Zeitplan laufen. Wenn eine Regel ausgelöst wird, wird sie auf alle vorhandenen Befunde angewendet, die den festgelegten Filterbedingungen entsprechen. + +## Mögliche Regelaktionen +Jede Regel kann eine oder mehrere dieser Änderungen an einem Befund vornehmen, wenn sie erfolgreich ausgelöst wird (d. h. wenn die festgelegten Filterbedingungen erfüllt sind). + +### Feldänderungen +* **Ein Feld festlegen** an einem Befund, einschließlich Titel, Beschreibung, Schweregrad, CVSSv3-Vektor, Aktiv, Verifiziert, Risiko akzeptiert, Falsch-positiv, Behoben +* **Text anhängen oder voranstellen** an den Titel oder die Beschreibung eines Befunds +* **Priorität festlegen** — überschreibt den berechneten Prioritätswert eines Befunds (überschreibt die automatische Prioritätsberechnung) +* **Risiko festlegen** — überschreibt die berechnete Risikostufe eines Befunds (überschreibt die automatische Risikoberechnung) +* **Addieren, Subtrahieren, Multiplizieren oder Dividieren** des Prioritätswerts eines Befunds um eine bestimmte Zahl + +### Zuweisungen und Eigentümerschaft +* **Einen Benutzer zur Überprüfung festlegen** für einen Befund +* **Eine Gruppe als Eigentümer zuweisen** für einen Befund +* **Eine Mitigation-Richtlinie festlegen** an einem Befund — weist dem Befund eine vorkonfigurierte Mitigation-Richtlinie zu +* **Zur Risikoakzeptanz hinzufügen** — fügt einen Befund zu einem bestehenden Risikoakzeptanz-Datensatz hinzu (setzt risk_accepted=True, active=False, und verarbeitet die Jira-Integration sowie die Endpunkt-Status) + +### Tags, Notizen und Warnungen +* **Tags hinzufügen** zu einem Befund +* **Eine Notiz hinzufügen** zu einem Befund +* **Eine Warnung erstellen** in DefectDojo mit benutzerdefiniertem Text + +### Filterbedingungen +Regeln werden automatisch ausgelöst, wenn ein Befund bestimmte Filterbedingungen erfüllt. Weitere Informationen zu Filtern, die zum Erstellen von Regelaktionen verwendet werden können, finden Sie auf der Seite [Filter Index](/navigation/pro__filter_index). + +## Eine neue Regel erstellen +Beginnen Sie diesen Vorgang auf der Seite Neue Regel. Erweitern Sie in der [Pro UI](/get_started/about/ui_pro_vs_os/) unter **Manage Category** das Dropdown-Menü **Rules Engine** und klicken Sie auf **+ New Rule**. + +![image](images/rules_engine_1.png) + +### Schritt 1: Benennen Sie Ihre Regel +Geben Sie eine Bezeichnung als Identifikator für die neue Regel ein und klicken Sie auf Weiter. + +![image](images/rules_engine_2.png) + +### Schritt 2: Auslösebedingungen mit einem Filter festlegen +Sie sehen eine Tabelle mit allen Befunden (All Findings). Legen Sie mithilfe dieser Tabelle die Filterbedingungen fest, um die Menge der Befunde einzugrenzen, auf die Ihre Regel angewendet werden soll. Weitere Informationen zum Anwenden von Filtern auf eine Tabelle finden Sie in [unserem Leitfaden zur Pro UI](/get_started/about/ui_pro_vs_os/#navigational-changes). + +Die Tabelle zeigt eine Vorschau der Liste vorhandener Befunde, die Sie gefiltert haben. + +In diesem Screenshot filtern wir beispielsweise nach allen Befunden, die sich in 'Product One' befinden. Sobald wir diesen Filter anwenden (indem wir außerhalb des Filtermenüs klicken), wird er unserer Liste der geltenden Filter hinzugefügt. + +![image](images/rules_engine_3.png) + +Im obigen Screenshot werden Aktionen auf alle Befunde angewendet, die sich im Produkt 'Product One' befinden. + +Sobald Sie die gewünschten Filter festgelegt haben, klicken Sie auf die Schaltfläche Weiter. + +### Schritt 3: Regelaktionen festlegen +Wählen Sie im Dropdown-Menü **Aktion** die Aktion aus, die Sie auf einen Befund anwenden möchten, der allen Filtern aus Schritt 2 entspricht. Es können mehrere Aktionen angewendet werden. + +Sie können zusätzliche bedingte Werte festlegen, die es Ihnen ermöglichen, weitere Aktionen auszuführen, wenn bestimmte Kriterien erfüllt sind. + +![image](images/rules_engine_4.png) + + +Im obigen Screenshot haben wir beispielsweise 4 Regelaktionen festgelegt. Zwei dieser Aktionen sind bedingt. + +Alle Befunde, die den Filterbedingungen entsprechen, lösen diese unbedingten Aktionen aus: + +* Der Befund wird der Benutzergruppe 'Group 1' zugewiesen +* Der Befund wird mit dem Tag `all_group_1` versehen + +Befunde, die den Filterbedingungen sowie diesen **zusätzlichen** Bedingungen entsprechen, lösen zusätzlich zu den beiden oben aufgeführten unbedingten Aktionen diese bedingten Aktionen aus: + +* **wenn der Befund den Schweregrad Kritisch hat**, wird er mit `critical_group_1` getaggt. +* **wenn der Befund den Schweregrad Hoch hat**, wird er mit `high_group_1` getaggt. + +### Schritt 4 - Vorschau Ihrer Regel + +Die Regelvorschau zeigt alle Befunde an, die durch diese Regel bei ihrer Ausführung geändert werden, zusammen mit einer Vorschau der ausgeführten Aktionen. Bestätigen Sie, dass Sie mit den vorgeschlagenen Änderungen einverstanden sind, und klicken Sie auf Absenden, um Ihre Regel zu speichern. + +Wenn Sie der Meinung sind, dass diese Regel nicht korrekt angewendet wurde, können Sie auf die Schaltfläche Zurück klicken und zu einem der vorherigen Schritte zurückkehren. + +![image](images/rules_engine_5.png) + +Im obigen Screenshot sehen wir beispielsweise eine Liste von Befunden, die von der Regel bei ihrer Ausführung betroffen sein werden. Anhand der Spalten rechts in der Befundliste können wir erkennen, dass jedem dieser Befunde neue Tags und Eigentümer zugewiesen werden. + +Sie werden erneut aufgefordert zu bestätigen, dass Ihre Regel erstellt werden soll. Beachten Sie, dass die **Regel nicht sofort angewendet wird** und manuell ausgelöst werden muss. + +## Eine Regel ausführen +Auf der Seite Alle Regeln können Sie eine Regel auswählen, die Sie ausführen möchten. Klicken Sie auf den Titel der Regel, um weitere Details anzuzeigen. + +![image](images/rules_engine_6.png) + +Auf dieser Seite finden Sie unter **Metadaten** detaillierte Informationen zu dieser Regel, einschließlich Angaben dazu, wann die Regel zuletzt ausgelöst wurde. Unter **Regelvorschau** sehen Sie außerdem eine Vorschau der Befunde, die von einer neuen Ausführung dieser Regel betroffen sein werden. + +Um die Regel auszuführen, klicken Sie auf die grüne Schaltfläche Regel ausführen. Sobald Sie bestätigt haben, dass Sie die Regel ausführen möchten, erscheint eine Meldung, dass die Regel zur Ausführung im Hintergrund eingereiht wurde. + +Sobald die Regel erfolgreich ausgeführt wurde, wird die Anzahl der geänderten Elemente im Abschnitt Regel-Metadaten der Regelbeschreibung aktualisiert. + +## Referenz: Regel-Metadaten +* **Regel für**: die Objekte, die von der Regel verwaltet werden. +* **Regelname**: der Name der Regel. +* **Filter**: die Anzahl der von dieser Regel angewendeten Filter. +* **Aktionen**: die Anzahl der von dieser Regel ausgeführten Aktionen. +* **Eigentümer**: der Benutzer, der diese Regel erstellt hat. +* **Status**: der Statusbericht der letzten Ausführung dieser Regel. + 'E' = 'Error', 'R' = 'Running', 'S' = 'Success'. +* **Letzter Lauf**: der Zeitstempel der letzten Ausführung dieser Regel. +* **Geänderte Elemente:** Anzahl der Objekte, die bei der letzten Regelausführung geändert wurden. +* **Übersprungene Elemente:** Anzahl der Objekte, die bei der letzten Regelausführung übersprungen wurden. Wenn ein gefiltertes Objekt bereits dem 'Ergebnis' einer auf es angewendeten Regelaktion entspricht (wenn es zum Beispiel bereits die Tags hat, die durch eine Regelaktion angewendet würden), wird das Objekt einfach übersprungen. diff --git a/docs/content/automation/rules_engine/about.es.md b/docs/content/automation/rules_engine/about.es.md new file mode 100644 index 00000000000..8875fbcf58e --- /dev/null +++ b/docs/content/automation/rules_engine/about.es.md @@ -0,0 +1,126 @@ +--- +title: Automatización de Rules Engine +description: Cómo trabajar con la automatización de Rules Engine +weight: 1 +audience: pro +aliases: +- /es/en/customize_dojo/rules_engine +--- + +Nota: Rules Engine es una función exclusiva de DefectDojo Pro. + +El Rules Engine de DefectDojo permite crear flujos de trabajo personalizados y acciones masivas para gestionar Hallazgos y otros objetos. Rules Engine permite crear acciones automatizadas que se activan cuando un objeto coincide con una Regla. + +Solo se puede acceder a Rules Engine a través de la [interfaz Pro](/get_started/about/ui_pro_vs_os/). + +**¿Busca el editor de grafos?** [Rules Engine 2.0](/automation/rules_engine_2/about/) construye la automatización como grafos visuales de nodos, y añade ramificaciones, acciones salientes como tickets y mensajes, rastros por ejecución y un libro de entregas. Ambos motores funcionan en paralelo, y las reglas existentes se pueden [convertir](/automation/rules_engine_2/converting_from_rules_engine/) de uno a otro. + +## Enabling Rules Engine + +Rules Engine está en Beta y está desactivado de forma predeterminada. Un superusuario puede activarlo desde **Settings > Feature Flags**, tanto en instancias Cloud como On-Premise. Consulte [Feature Flags](/admin/feature_flags/pro__feature_flags/). + +Actualmente, las Reglas solo se pueden crear para Hallazgos, aunque en el futuro se admitirán más tipos de objetos. + +Las Reglas se pueden activar manualmente desde la página **All Rules**, o programarse para ejecutarse automáticamente de forma recurrente. Cuando una regla se activa, se aplica a todos los Hallazgos existentes que coincidan con las condiciones de filtro establecidas. + +## Possible Rule Actions +Cada Regla puede aplicar uno o más de estos cambios a un Hallazgo cuando se activa correctamente (es decir, cuando coincide con las condiciones de Filtro establecidas). + +### Field Modifications +* **Set a field** en un Hallazgo, incluyendo Título, Descripción, Severidad, Vector CVSSv3, Activo, Verificado, Riesgo aceptado, Falso positivo, Mitigado +* **Añadir o anteponer texto** al Título o la Descripción de un Hallazgo +* **Set Priority** — anula el valor de Prioridad calculado en un Hallazgo (anula el cálculo automático de prioridad) +* **Set Risk** — anula el nivel de Riesgo calculado en un Hallazgo (anula el cálculo automático de riesgo) +* **Sumar, restar, multiplicar o dividir** el valor de Prioridad de un Hallazgo por un número dado + +### Assignments & Ownership +* **Set a User to Review** un Hallazgo +* **Assign a Group as Owners** de un Hallazgo +* **Set a Mitigation Policy** en un Hallazgo — asigna una Política de Mitigación preconfigurada al Hallazgo +* **Add to Risk Acceptance** — añade un Hallazgo a un registro de Aceptación de riesgo existente (establece risk_accepted=True, active=False, y gestiona la integración con Jira y los estados de los endpoints) + +### Tags, Notes & Alerts +* **Add Tags** a un Hallazgo +* **Add a Note** a un Hallazgo +* **Create an Alert** en DefectDojo con texto personalizado + +### Filter conditions +Las Reglas se activan automáticamente cuando un Hallazgo cumple condiciones de Filtro específicas. Para más información sobre los Filtros que se pueden usar para crear Acciones de Regla, consulte la página [Filter Index](/navigation/pro__filter_index). + +## Creating a New Rule +Inicie este proceso desde la página New Rule. En la [interfaz Pro](/get_started/about/ui_pro_vs_os/), en **Manage Category**, expanda el menú desplegable **Rules Engine** y haga clic en **+ New Rule**. + +![image](images/rules_engine_1.png) + +### Step 1: Label your Rule +Introduzca una Etiqueta como identificador de la nueva regla y haga clic en Next. + +![image](images/rules_engine_2.png) + +### Step 2: Set trigger conditions with a Filter +Verá una tabla All Findings. Con la tabla All Findings, establezca las condiciones de Filtro para filtrar el conjunto de Hallazgos a los que quiere que se aplique su regla. Para más información sobre cómo aplicar Filtros a una tabla, consulte [nuestra guía de la interfaz Pro](/get_started/about/ui_pro_vs_os/#navigational-changes). + +La tabla mostrará una vista previa de la lista de Hallazgos existentes que ha filtrado. + +Por ejemplo, en esta captura de pantalla estamos filtrando todos los Hallazgos que están en 'Product One'. Una vez que aplicamos este filtro (haciendo clic fuera del menú Filters), se añadirá a nuestra lista de Filtros aplicables. + +![image](images/rules_engine_3.png) + +En la captura de pantalla anterior, se tomarán acciones sobre todos los Hallazgos que estén en el Producto 'Product One'. + +Una vez que tenga el conjunto de Filtros que quiere aplicar, haga clic en el botón Next. + +### Step 3: Set the Rule Actions +En el menú desplegable **Action**, seleccione la Acción que quiere aplicar a un Hallazgo que coincida con todos los filtros del Paso 2. Se pueden aplicar varias Acciones. + +Puede establecer Valores Condicionales adicionales que permiten tomar acciones adicionales si se cumplen ciertos criterios. + +![image](images/rules_engine_4.png) + + +Por ejemplo, en la captura de pantalla anterior tenemos 4 Acciones de Regla establecidas. Dos de estas acciones son Condicionales. + +Todos los Hallazgos que coincidan con las condiciones de filtro activarán estas Acciones No Condicionales: + +* El Hallazgo se asignará al grupo de usuarios 'Group 1' +* El Hallazgo se etiquetará con `all_group_1` + +Cualquier Hallazgo que coincida con las condiciones de filtro, además de estas condiciones **adicionales**, activará estas Acciones Condicionales, sumadas a las dos Acciones No Condicionales indicadas arriba: + +* **si el Hallazgo tiene Severidad Crítica**, se etiquetará con `critical_group_1`. +* **si el Hallazgo tiene Severidad Alta**, se etiquetará con `high_group_1`. + +### Step 4 - Preview your Rule + +La vista previa de la Regla (Rule Preview) muestra todos los Hallazgos que esta regla cambiará una vez que se ejecute, junto con una vista previa de las Acciones tomadas. Confirme que está conforme con los cambios propuestos y haga clic en Submit para guardar su regla. + +Si considera que esta regla no se aplicó correctamente, puede seleccionar el botón Back y volver a cualquiera de los pasos anteriores. + +![image](images/rules_engine_5.png) + +Por ejemplo, en la captura de pantalla anterior tenemos una lista de Hallazgos que se verán afectados por la Regla una vez que se ejecute. Podemos ver que se aplicarán nuevas Etiquetas y Propietarios a cada uno de estos Hallazgos, en las columnas de la derecha de la lista de Hallazgos. + +Se le pedirá de nuevo que confirme que quiere crear su Regla. Tenga en cuenta que la **Regla no se aplicará de inmediato**, y debe activarse manualmente. + +## Running a Rule +Desde la página All Rules, puede seleccionar una Regla que desee ejecutar. Haga clic en el título de la regla para verla con más detalle. + +![image](images/rules_engine_6.png) + +En esta página puede ver información detallada sobre esta regla en **Metadata**, incluida información sobre cuándo se activó la regla por última vez. También puede ver una vista previa de los Hallazgos que se verán afectados por una nueva ejecución de esta Regla, debajo de **Rule Preview**. + +Para ejecutar la Regla, haga clic en el botón verde Run Rule. Una vez que confirme que quiere ejecutar la regla, aparecerá un mensaje indicando que la regla está en cola para ejecutarse en segundo plano. + +Una vez que la Regla haya terminado de ejecutarse correctamente, el número de Items Changed se actualizará en la sección Rule Metadata de la descripción de la Regla. + +## Rule Metadata Reference +* **Rule For**: los objetos regidos por la Regla. +* **Rule Name**: el nombre de la Regla. +* **Filters**: el número de Filtros aplicados por esta Regla. +* **Actions**: el número de Acciones tomadas por esta Regla. +* **Owner**: el Usuario que creó esta Regla. +* **Status**: el informe de Estado de la última vez que se ejecutó esta Regla. + 'E' = 'Error', 'R' = 'Running', 'S' = 'Success'. +* **Last Run**: la marca de tiempo de la última vez que se ejecutó esta Regla. +* **Items Changed:** el número de objetos que se cambiaron en la última ejecución de la regla. +* **Items Skipped:** el número de objetos que se omitieron en la última ejecución de la regla. Si un objeto filtrado ya coincide con el 'resultado' de una Acción de Regla aplicada a él (por ejemplo, si ya tiene las Etiquetas que aplicaría una Acción de Regla), el objeto simplemente se omitirá. diff --git a/docs/content/automation/rules_engine/about.fr.md b/docs/content/automation/rules_engine/about.fr.md new file mode 100644 index 00000000000..c4f24878c10 --- /dev/null +++ b/docs/content/automation/rules_engine/about.fr.md @@ -0,0 +1,126 @@ +--- +title: Automatisation du Moteur de règles +description: Utilisation de l'automatisation du Moteur de règles +weight: 1 +audience: pro +aliases: +- /fr/en/customize_dojo/rules_engine +--- + +Remarque : le Moteur de règles est une fonctionnalité réservée à DefectDojo Pro. + +Le Moteur de règles de DefectDojo vous permet de créer des workflows personnalisés et des actions en masse pour traiter les Constatations et d'autres objets. Le Moteur de règles vous permet de créer des actions automatisées qui se déclenchent lorsqu'un objet correspond à une Règle. + +Le Moteur de règles n'est accessible que via l'[interface Pro](/get_started/about/ui_pro_vs_os/). + +**Vous cherchez l'éditeur de graphes ?** Le [Moteur de règles 2.0](/automation/rules_engine_2/about/) construit l'automatisation sous forme de graphes de nœuds visuels, et ajoute des embranchements, des actions sortantes telles que des tickets et des messages, des traces par exécution et un registre des livraisons. Les deux moteurs fonctionnent côte à côte, et les règles existantes peuvent être [converties vers l'autre moteur](/automation/rules_engine_2/converting_from_rules_engine/). + +## Activer le Moteur de règles + +Le Moteur de règles est en version bêta et est désactivé par défaut. Un superutilisateur peut l'activer depuis **Paramètres > Feature Flags**, aussi bien sur les instances Cloud que sur site (On-Premise). Voir [Feature Flags](/admin/feature_flags/pro__feature_flags/). + +Actuellement, les Règles ne peuvent être créées que pour les Constatations, mais davantage de types d'objets seront pris en charge à l'avenir. + +Les Règles peuvent être déclenchées manuellement depuis la page **Toutes les règles**, ou planifiées pour s'exécuter automatiquement selon une périodicité récurrente. Lorsqu'une règle est déclenchée, elle s'applique à toutes les Constatations existantes qui correspondent aux conditions de filtre définies. + +## Actions de règle possibles +Chaque Règle peut appliquer un ou plusieurs de ces changements à une Constatation lorsqu'elle se déclenche avec succès (c'est-à-dire lorsqu'elle correspond aux conditions de filtre définies). + +### Modifications de champs +* **Définir un champ** sur une Constatation, notamment Titre, Description, Sévérité, Vecteur CVSSv3, Actif, Vérifié, Risque accepté, Faux positif, Atténué +* **Ajouter du texte au début ou à la fin** du Titre ou de la Description d'une Constatation +* **Définir la priorité** — remplace la valeur de priorité calculée sur une Constatation (annule le calcul automatique de la priorité) +* **Définir le risque** — remplace le niveau de risque calculé sur une Constatation (annule le calcul automatique du risque) +* **Ajouter, soustraire, multiplier ou diviser** la valeur de priorité d'une Constatation par un nombre donné + +### Attributions et propriété +* **Définir un Utilisateur pour réviser** une Constatation +* **Attribuer un Groupe comme propriétaire** d'une Constatation +* **Définir une politique d'atténuation** sur une Constatation — attribue une politique d'atténuation préconfigurée à la Constatation +* **Ajouter à une acceptation du risque** — ajoute une Constatation à un enregistrement d'Acceptation du risque existant (définit risk_accepted=True, active=False, et gère l'intégration Jira ainsi que les statuts des points de terminaison) + +### Étiquettes, notes et alertes +* **Ajouter des étiquettes** à une Constatation +* **Ajouter une note** à une Constatation +* **Créer une alerte** dans DefectDojo avec un texte personnalisé + +### Conditions de filtre +Les Règles se déclenchent automatiquement lorsqu'une Constatation répond à des conditions de filtre spécifiques. Pour plus d'informations sur les Filtres pouvant être utilisés pour créer des Actions de règle, consultez la page [Index des filtres](/navigation/pro__filter_index). + +## Créer une nouvelle règle +Démarrez ce processus depuis la page Nouvelle règle. Dans l'[interface Pro](/get_started/about/ui_pro_vs_os/), sous **Gérer la catégorie**, développez le menu déroulant **Moteur de règles** et cliquez sur **+ Nouvelle règle**. + +![image](images/rules_engine_1.png) + +### Étape 1 : nommez votre règle +Saisissez un Libellé servant d'identifiant pour la nouvelle règle, puis cliquez sur Suivant. + +![image](images/rules_engine_2.png) + +### Étape 2 : définissez les conditions de déclenchement avec un filtre +Vous verrez un tableau Toutes les Constatations. À l'aide de ce tableau, définissez les conditions de filtre afin de restreindre l'ensemble des Constatations auquel votre règle doit s'appliquer. Pour en savoir plus sur l'application de filtres à un tableau, consultez [notre guide de l'interface Pro](/get_started/about/ui_pro_vs_os/#navigational-changes). + +Le tableau affiche un aperçu de la liste des Constatations existantes que vous avez filtrées. + +Par exemple, dans cette capture d'écran, nous filtrons toutes les Constatations qui se trouvent dans « Product One ». Une fois ce filtre appliqué (en cliquant en dehors du menu Filtres), il est ajouté à notre liste de Filtres applicables. + +![image](images/rules_engine_3.png) + +Dans la capture d'écran ci-dessus, des actions seront appliquées à toutes les Constatations du Produit « Product One ». + +Une fois que vous disposez de l'ensemble de Filtres que vous souhaitez appliquer, cliquez sur le bouton Suivant. + +### Étape 3 : définissez les actions de la règle +Dans le menu déroulant **Action**, sélectionnez l'Action que vous souhaitez appliquer à une Constatation correspondant à tous les filtres de l'étape 2. Plusieurs Actions peuvent être appliquées. + +Vous pouvez définir des Valeurs conditionnelles supplémentaires qui permettent de déclencher des actions additionnelles si certains critères sont remplis. + +![image](images/rules_engine_4.png) + + +Par exemple, dans la capture d'écran ci-dessus, nous avons défini 4 Actions de règle. Deux de ces actions sont Conditionnelles. + +Toutes les Constatations qui correspondent aux conditions de filtre déclencheront ces Actions non conditionnelles : + +* La Constatation sera attribuée au groupe d'utilisateurs « Group 1 » +* La Constatation sera étiquetée avec `all_group_1` + +Toute Constatation qui correspond aux conditions de filtre, ainsi qu'à ces conditions **supplémentaires**, déclenchera ces Actions conditionnelles en plus des deux Actions non conditionnelles listées ci-dessus : + +* **si la Constatation a une Sévérité Critique**, elle sera étiquetée avec `critical_group_1`. +* **si la Constatation a une Sévérité Élevée**, elle sera étiquetée avec `high_group_1`. + +### Étape 4 - Aperçu de votre règle + +L'Aperçu de la règle affiche toutes les Constatations qui seront modifiées par cette règle une fois exécutée, ainsi qu'un aperçu des Actions effectuées. Vérifiez que les changements proposés vous conviennent, puis cliquez sur Valider pour enregistrer votre règle. + +Si vous estimez que cette règle n'a pas été appliquée correctement, vous pouvez cliquer sur le bouton Précédent pour revenir à l'une des étapes précédentes. + +![image](images/rules_engine_5.png) + +Par exemple, dans la capture d'écran ci-dessus, nous avons une liste de Constatations qui seront affectées par la Règle une fois qu'elle sera exécutée. Nous pouvons voir que de nouvelles Étiquettes et de nouveaux Propriétaires seront appliqués à chacune de ces Constatations, dans les colonnes à droite de la liste des Constatations. + +Il vous sera de nouveau demandé de confirmer la création de votre Règle. Notez que la **Règle ne sera pas appliquée immédiatement**, et devra être déclenchée manuellement. + +## Exécuter une règle +Depuis la page Toutes les règles, vous pouvez sélectionner la Règle que vous souhaitez exécuter. Cliquez sur le titre de la règle pour en voir le détail. + +![image](images/rules_engine_6.png) + +Sur cette page, vous pouvez consulter des informations détaillées sur cette règle sous **Métadonnées**, y compris des informations sur la date de son dernier déclenchement. Vous pouvez également voir un aperçu des Constatations qui seront affectées par une nouvelle exécution de cette Règle, sous **Aperçu de la règle**. + +Pour exécuter la Règle, cliquez sur le bouton vert Exécuter la règle. Une fois que vous avez confirmé vouloir exécuter la règle, un message apparaît indiquant que la règle est mise en file d'attente pour s'exécuter en arrière-plan. + +Une fois que la Règle a terminé son exécution avec succès, le nombre d'Éléments modifiés est mis à jour dans la section Métadonnées de la description de la Règle. + +## Référence des métadonnées de la règle +* **Règle pour** : les objets régis par la Règle. +* **Nom de la règle** : le nom de la Règle. +* **Filtres** : le nombre de Filtres appliqués par cette Règle. +* **Actions** : le nombre d'Actions effectuées par cette Règle. +* **Propriétaire** : l'Utilisateur qui a créé cette Règle. +* **Statut** : le rapport de statut de la dernière exécution de cette Règle. + 'E' = 'Error', 'R' = 'Running', 'S' = 'Success'. +* **Dernière exécution** : l'horodatage de la dernière exécution de cette Règle. +* **Éléments modifiés :** le nombre d'objets modifiés lors de la dernière exécution de la règle. +* **Éléments ignorés :** le nombre d'objets ignorés lors de la dernière exécution de la règle. Si un objet filtré correspond déjà au « résultat » d'une Action de règle qui lui serait appliquée (par exemple, s'il possède déjà les Étiquettes qu'une Action de règle appliquerait), l'objet est simplement ignoré. diff --git a/docs/content/automation/rules_engine/about.ja.md b/docs/content/automation/rules_engine/about.ja.md new file mode 100644 index 00000000000..4a3c49fca73 --- /dev/null +++ b/docs/content/automation/rules_engine/about.ja.md @@ -0,0 +1,128 @@ +--- +title: Rules Engine 自動化 +description: Rules Engineの自動化機能の使い方 +weight: 1 +audience: pro +aliases: +- /ja/en/customize_dojo/rules_engine +--- + +注: Rules EngineはDefectDojo Pro限定機能です。 + +DefectDojoのRules Engineを使用すると、Findingやその他のオブジェクトを処理するためのカスタムワークフローや一括アクションを構築できます。Rules Engineでは、オブジェクトがルールに一致したときにトリガーされる自動化アクションを構築できます。 + +Rules Engineは[Pro UI](/get_started/about/ui_pro_vs_os/)からのみアクセスできます。 + +**グラフエディタをお探しですか？** [Rules Engine 2.0](/automation/rules_engine_2/about/)は、自動化をビジュアルなノードグラフとして構築できるようにし、分岐、チケットやメッセージなどのアウトバウンドアクション、実行ごとのトレース、配信台帳を追加します。両エンジンは並行して稼働しており、既存のルールは[変換](/automation/rules_engine_2/converting_from_rules_engine/)することができます。 + +## Rules Engineの有効化 + +Rules Engineはベータ版であり、デフォルトでは無効になっています。スーパーユーザーは、CloudとOn-Premiseの両方のインスタンスで**Settings > Feature Flags**から有効にできます。[Feature Flags](/admin/feature_flags/pro__feature_flags/)を参照してください。 + +現在のところ、ルールを作成できるのはFindingに対してのみですが、今後はより多くのオブジェクトタイプがサポートされる予定です。 + +ルールは**All Rules**ページから手動でトリガーすることも、定期的なスケジュールで自動的に実行されるようスケジュールすることもできます。ルールがトリガーされると、設定されたフィルター条件に一致するすべての既存Findingに適用されます。 + +## 設定可能なルールアクション +各ルールは、正常にトリガーされた場合（つまり、設定されたフィルター条件に一致した場合）に、以下の変更を1つ以上Findingに適用できます。 + +### フィールドの変更 +* Findingの**フィールドを設定**する。対象はTitle（タイトル）、Description（説明）、Severity（深刻度）、CVSSv3 Vector、Active（アクティブ）、Verified（検証済み）、Risk Accepted（リスク受容済み）、False Positive（誤検知）、Mitigated（緩和済み）を含みます +* FindingのTitle（タイトル）またはDescription（説明）に**テキストを追記・先頭挿入**する +* **Priorityを設定** — Findingの算出されたPriority値を上書きする（自動的な優先度計算を上書きします） +* **Riskを設定** — Findingの算出されたRiskレベルを上書きする（自動的なリスク計算を上書きします） +* FindingのPriority値に対して、指定した数値で**加算、減算、乗算、除算**を行う + +### 割り当てと所有権 +* Findingを**レビューするユーザーを設定**する +* Findingの**所有者としてグループを割り当て**る +* Findingに**Mitigation Policyを設定**する — 事前設定されたMitigation PolicyをそのFindingに割り当てます +* **Risk Acceptance（リスク受容）に追加** — Findingを既存のRisk Acceptanceレコードに追加する（risk_accepted=True、active=Falseを設定し、Jira連携とエンドポイントのステータスを処理します） + +### タグ、メモ、アラート +* Findingに**タグを追加**する +* Findingに**メモを追加**する +* カスタムテキストを添えてDefectDojo内に**アラートを作成**する + +### フィルター条件 +ルールは、Findingが特定のフィルター条件を満たしたときに自動的にトリガーされます。ルールアクションの作成に使用できるフィルターについての詳細は、[Filter Index](/navigation/pro__filter_index)ページを参照してください。 + +## 新しいルールの作成 +この手順はNew Ruleページから開始します。[Pro UI](/get_started/about/ui_pro_vs_os/)で**Manage Category**の下にある**Rules Engine**ドロップダウンを展開し、**+ New Rule**をクリックします。 + +![image](images/rules_engine_1.png) + +### ステップ1: ルールにラベルを付ける +新しいルールの識別子となるLabelを入力し、Nextをクリックします。 + +![image](images/rules_engine_2.png) + +### ステップ2: フィルターでトリガー条件を設定する +All Findingsテーブルが表示されます。このAll Findingsテーブルを使用して、ルールを適用したいFindingの集合を絞り込むフィルター条件を設定します。テーブルへのフィルターの適用方法についての詳細は、[Pro UIガイド](/get_started/about/ui_pro_vs_os/#navigational-changes)を参照してください。 + +このテーブルには、フィルターした既存Findingの一覧がプレビュー表示されます。 + +例えば、このスクリーンショットでは「Product One」に含まれるすべてのFindingを絞り込んでいます。このフィルターを適用する（Filtersメニューの外側をクリックする）と、適用対象のフィルター一覧に追加されます。 + +![image](images/rules_engine_3.png) + +上のスクリーンショットでは、Product「Product One」に含まれるすべてのFindingに対してアクションが実行されます。 + +適用したいフィルターのセットが揃ったら、Nextボタンをクリックします。 + +### ステップ3: ルールアクションを設定する +**Action**ドロップダウンから、ステップ2のすべてのフィルターに一致するFindingに適用したいアクションを選択します。複数のアクションを適用できます。 + +特定の条件が満たされた場合に追加のアクションを実行できる、追加のConditional Values（条件付き値）を設定することもできます。 + +![image](images/rules_engine_4.png) + + +例えば、上のスクリーンショットでは4つのルールアクションが設定されています。 + +このうち2つのアクションは条件付きです。 + +フィルター条件に一致するすべてのFindingは、以下の非条件付きアクションをトリガーします。 + +* Findingはユーザーグループ「Group 1」に割り当てられます +* Findingには`all_group_1`というタグが付けられます + +フィルター条件に加えて、これらの**追加**条件にも一致するFindingは、上記の2つの非条件付きアクションに加えて、以下の条件付きアクションもトリガーします。 + +* **FindingのSeverityがCritical（重大）の場合**、`critical_group_1`というタグが付けられます。 +* **FindingのSeverityがHigh（高）の場合**、`high_group_1`というタグが付けられます。 + +### ステップ4 - ルールをプレビューする + +Rule Previewには、このルールを実行した場合に変更されるすべてのFindingと、実行されるアクションのプレビューが表示されます。提案された変更内容に問題がなければ、Submitをクリックしてルールを保存します。 + +このルールが正しく適用されていないと思われる場合は、Backボタンを選択して、前のいずれかのステップに戻ることができます。 + +![image](images/rules_engine_5.png) + +例えば、上のスクリーンショットには、このルールを実行した場合に影響を受けるFindingの一覧が表示されています。Finding一覧の右側の列から、これらの各Findingに新しいTagsとOwnersが適用されることが分かります。 + +ルールを作成することを確認するよう再度プロンプトが表示されます。**ルールはすぐには適用されず**、手動でトリガーする必要があることに注意してください。 + +## ルールの実行 +All Rulesページから、実行したいルールを選択できます。ルールのタイトルをクリックすると、詳細を確認できます。 + +![image](images/rules_engine_6.png) + +このページでは、**Metadata**の下に、このルールが最後にトリガーされた日時などの詳細情報を確認できます。また、**Rule Preview**の下で、このルールを新たに実行した場合に影響を受けるFindingのプレビューも確認できます。 + +ルールを実行するには、緑色のRun Ruleボタンをクリックします。ルールを実行することを確認すると、ルールがバックグラウンドで実行キューに入った旨のメッセージが表示されます。 + +ルールの実行が正常に完了すると、ルールの説明のRule MetadataセクションにあるItems Changedの数が更新されます。 + +## ルールメタデータのリファレンス +* **Rule For**: このルールが対象とするオブジェクト。 +* **Rule Name**: ルールの名前。 +* **Filters**: このルールに適用されているフィルターの数。 +* **Actions**: このルールが実行するアクションの数。 +* **Owner**: このルールを作成したユーザー。 +* **Status**: このルールが最後に実行された際のステータスレポート。 + 「E」=「Error」、「R」=「Running」、「S」=「Success」。 +* **Last Run**: このルールが最後に実行された日時。 +* **Items Changed:** 直近のルール実行で変更されたオブジェクトの数。 +* **Items Skipped:** 直近のルール実行でスキップされたオブジェクトの数。フィルターされたオブジェクトが、適用されるルールアクションの「結果」に既に一致している場合（例えば、ルールアクションによって付与されるはずのタグを既に持っている場合）、そのオブジェクトは単にスキップされます。 diff --git a/docs/content/automation/rules_engine/scheduling.de.md b/docs/content/automation/rules_engine/scheduling.de.md new file mode 100644 index 00000000000..09503dbaa44 --- /dev/null +++ b/docs/content/automation/rules_engine/scheduling.de.md @@ -0,0 +1,55 @@ +--- +title: Regeln planen +description: Rules Engine-Regeln automatisch nach einem wiederkehrenden oder einmaligen + Zeitplan ausführen +weight: 2 +audience: pro +--- + +Hinweis: Die Zeitplanung der Rules Engine ist eine reine DefectDojo-Pro-Funktion. + +Regeln können so geplant werden, dass sie automatisch ausgeführt werden, anstatt jedes Mal manuell ausgelöst zu werden. Eine geplante Regel wird zur konfigurierten Zeit auf alle Befunde angewendet, die ihren Filterbedingungen entsprechen. + +Die Zeitplanung ist standardmäßig deaktiviert und wird von DefectDojo pro Instanz aktiviert, nicht über die Feature-Flags-Seite. Wenden Sie sich an den [DefectDojo Support](mailto:support@defectdojo.com), um den **Scheduling Service** aktivieren zu lassen; die Option **Regel planen** erscheint, sobald dies geschehen ist. Siehe [Feature Flags](/admin/feature_flags/pro__feature_flags/), um zu erfahren, wie zentral von DefectDojo verwaltete Funktionen angezeigt werden. + +Der Benutzer, der den Zeitplan einrichtet, muss über die Konfigurationsberechtigung **Change Scheduling Service Schedule** verfügen. + +## Zeitplantypen + +### Einmalige Ausführung + +Ein Zeitplan vom Typ Einmalige Ausführung führt die Regel einmal zu einem bestimmten Datum und einer bestimmten Uhrzeit aus. Nach Abschluss des Laufs wird der Zeitplan nicht wiederholt. + +### Wiederkehrende Ausführung + +Ein Zeitplan vom Typ Wiederkehrende Ausführung ermöglicht es Ihnen, eine Regel wiederkehrend auszulösen — zum Beispiel täglich um 9:00 Uhr oder jeden Montag um 15:00 Uhr. + +**Hinweis:** Zeitpläne der Rules Engine sind auf Viertelstundenmarken beschränkt. Das Minutenfeld eines Cron-Zeitplans muss einen der folgenden Werte haben: **0, 15, 30 oder 45**. Andere Minutenwerte sind nicht zulässig. + +Beispiele für gültige Zeitpläne: +- Jede volle Stunde: `0 * * * *` +- Jeden Tag um 9:15 Uhr: `15 9 * * *` +- Jeden Montag um 15:00 Uhr: `0 15 * * 1` +- Alle 15 Minuten: `0,15,30,45 * * * *` + +## Einen Zeitplan für eine Regel erstellen + +1. Navigieren Sie über das Menü **Rules Engine** in der Seitenleiste zur Seite **Alle Regeln**. +2. Suchen Sie die Regel, die Sie planen möchten, und öffnen Sie deren Aktionsmenü (**⋮**). +3. Klicken Sie auf **Regel planen**. Diese Option ist nur sichtbar, wenn der Scheduling Service aktiviert ist und Sie über die erforderliche Berechtigung verfügen. +4. Füllen Sie im Modal **Regel planen** die folgenden Felder aus: + +| Feld | Beschreibung | +|---|---| +| **Name** | Ein eindeutiger Name für diesen Zeitplan (erforderlich, max. 100 Zeichen). | +| **Beschreibung** | Optionale Beschreibung des Zwecks des Zeitplans. | +| **Auslösertyp** | Wählen Sie **Einmalige Ausführung** für eine einmalige Ausführung oder **Wiederkehrende Ausführung** für einen wiederkehrenden Cron-Zeitplan. | +| **Häufigkeit** | Für Wiederkehrende Ausführung: Verwenden Sie den Cron-Builder, um den Zeitraum (stündlich, täglich, wöchentlich usw.) sowie die konkreten Minuten-, Stunden- und Tageswerte auszuwählen. Für Einmalige Ausführung: Wählen Sie über die Datumsauswahl ein Datum und eine Uhrzeit aus. | +| **Zeitplan aktivieren** | Schalter zum Aktivieren oder Deaktivieren des Zeitplans. Ein deaktivierter Zeitplan wird erst nach erneuter Aktivierung ausgeführt. | + +5. Klicken Sie auf **Absenden**, um den Zeitplan zu speichern. Die Regel wird automatisch zum nächsten geplanten Zeitpunkt ausgeführt. + + +## Berechtigungen + +Der Zugriff auf die Zeitplanung innerhalb der Rules Engine erfordert Superuser-Berechtigungen oder die entsprechende Konfigurationsberechtigung. Siehe [User Permission Chart](/admin/user_management/user_permission_chart) für Details. diff --git a/docs/content/automation/rules_engine/scheduling.es.md b/docs/content/automation/rules_engine/scheduling.es.md new file mode 100644 index 00000000000..fbea597e659 --- /dev/null +++ b/docs/content/automation/rules_engine/scheduling.es.md @@ -0,0 +1,55 @@ +--- +title: Programación de Reglas +description: Ejecutar automáticamente las reglas de Rules Engine según una programación + recurrente o única +weight: 2 +audience: pro +--- + +Nota: la programación de Rules Engine es una función exclusiva de DefectDojo Pro. + +Las Reglas se pueden programar para ejecutarse automáticamente en lugar de activarse manualmente cada vez. Una regla programada se ejecutará contra todos los Hallazgos que coincidan con sus condiciones de filtro en el momento configurado. + +La programación está desactivada de forma predeterminada y DefectDojo la habilita por instancia, en lugar de hacerlo desde la página de Feature Flags. Contacte con [DefectDojo Support](mailto:support@defectdojo.com) para que se active el **Scheduling Service**; la opción **Schedule Rule** aparece una vez activado. Consulte [Feature Flags](/admin/feature_flags/pro__feature_flags/) para ver cómo se muestran las funciones que DefectDojo gestiona de forma centralizada. + +El usuario que configura la programación debe tener el permiso de configuración **Change Scheduling Service Schedule**. + +## Schedule Types + +### Single Run + +Una programación de Single Run ejecuta la regla una vez en una fecha y hora específicas. Después de que la ejecución se complete, la programación no se repite. + +### Repeated Run + +Una programación de Repeated Run permite activar una regla de forma recurrente — por ejemplo, todos los días a las 9:00 AM, o todos los lunes a las 15:00. + +**Nota:** las programaciones de Rules Engine están limitadas a marcas de cuarto de hora. El campo de minutos de una programación cron debe ser uno de: **0, 15, 30 o 45**. No se permiten otros valores de minutos. + +Ejemplos de programaciones válidas: +- Cada hora en punto: `0 * * * *` +- Todos los días a las 9:15 AM: `15 9 * * *` +- Todos los lunes a las 3:00 PM: `0 15 * * 1` +- Cada 15 minutos: `0,15,30,45 * * * *` + +## Creating a Schedule for a Rule + +1. Vaya a la página **All Rules** desde el menú **Rules Engine** en la barra lateral. +2. Busque la regla que quiere programar y abra su menú de acciones (**⋮**). +3. Haga clic en **Schedule Rule**. Esta opción solo es visible si el Scheduling Service está habilitado y usted tiene el permiso requerido. +4. En el modal **Schedule Rule**, complete los siguientes campos: + +| Field | Description | +|---|---| +| **Name** | Un nombre único para esta programación (obligatorio, máximo 100 caracteres). | +| **Description** | Descripción opcional del propósito de la programación. | +| **Trigger Type** | Elija **Single Run** para una ejecución única, o **Repeated Run** para una programación cron recurrente. | +| **Frequency** | Para Repeated Run: use el generador de cron para seleccionar el período (por hora, diario, semanal, etc.) y los valores específicos de minuto, hora y día. Para Single Run: seleccione una fecha y hora con el selector de fecha. | +| **Enable Schedule** | Active o desactive la programación con este control. Una programación desactivada no se ejecutará hasta que se vuelva a activar. | + +5. Haga clic en **Submit** para guardar la programación. La regla se ejecutará automáticamente en el próximo horario programado. + + +## Permissions + +El acceso a la programación dentro de Rules Engine requiere permisos de Superusuario o el Permiso de Configuración correspondiente. Consulte [User Permission Chart](/admin/user_management/user_permission_chart) para más detalles. diff --git a/docs/content/automation/rules_engine/scheduling.fr.md b/docs/content/automation/rules_engine/scheduling.fr.md new file mode 100644 index 00000000000..07f68317b7c --- /dev/null +++ b/docs/content/automation/rules_engine/scheduling.fr.md @@ -0,0 +1,55 @@ +--- +title: Planification des règles +description: Exécuter automatiquement les règles du Moteur de règles selon une périodicité + récurrente ou ponctuelle +weight: 2 +audience: pro +--- + +Remarque : la planification du Moteur de règles est une fonctionnalité réservée à DefectDojo Pro. + +Les Règles peuvent être planifiées pour s'exécuter automatiquement plutôt que d'être déclenchées manuellement à chaque fois. Une règle planifiée s'exécute sur toutes les Constatations qui correspondent à ses conditions de filtre, à l'heure configurée. + +La planification est désactivée par défaut et est activée instance par instance par DefectDojo, plutôt que depuis la page Feature Flags. Contactez le [support DefectDojo](mailto:support@defectdojo.com) pour faire activer le **Service de planification** ; l'option **Planifier la règle** apparaît une fois celui-ci activé. Voir [Feature Flags](/admin/feature_flags/pro__feature_flags/) pour savoir comment sont présentées les fonctionnalités gérées de façon centralisée par DefectDojo. + +L'utilisateur qui configure la planification doit disposer de la permission de configuration **Change Scheduling Service Schedule**. + +## Types de planification + +### Exécution unique + +Une planification de type Exécution unique exécute la règle une seule fois, à une date et une heure précises. Une fois l'exécution terminée, la planification ne se répète pas. + +### Exécution répétée + +Une planification de type Exécution répétée permet de déclencher une règle de façon récurrente — par exemple, tous les jours à 9h00, ou tous les lundis à 15h00. + +**Remarque :** les planifications du Moteur de règles sont limitées aux quarts d'heure. Le champ des minutes d'une planification cron doit être l'une des valeurs suivantes : **0, 15, 30 ou 45**. Aucune autre valeur de minute n'est autorisée. + +Exemples de planifications valides : +- Toutes les heures, à l'heure pile : `0 * * * *` +- Tous les jours à 9h15 : `15 9 * * *` +- Tous les lundis à 15h00 : `0 15 * * 1` +- Toutes les 15 minutes : `0,15,30,45 * * * *` + +## Créer une planification pour une règle + +1. Accédez à la page **Toutes les règles** depuis le menu **Moteur de règles** de la barre latérale. +2. Repérez la règle que vous souhaitez planifier, puis ouvrez son menu d'actions (**⋮**). +3. Cliquez sur **Planifier la règle**. Cette option n'est visible que si le Service de planification est activé et que vous disposez de la permission requise. +4. Dans la fenêtre modale **Planifier la règle**, renseignez les champs suivants : + +| Field | Description | +|---|---| +| **Nom** | Un nom unique pour cette planification (obligatoire, 100 caractères maximum). | +| **Description** | Description facultative de l'objet de la planification. | +| **Type de déclenchement** | Choisissez **Exécution unique** pour une exécution ponctuelle, ou **Exécution répétée** pour une planification cron récurrente. | +| **Fréquence** | Pour une Exécution répétée : utilisez le générateur cron pour sélectionner la période (horaire, quotidienne, hebdomadaire, etc.) ainsi que les valeurs précises de minute, d'heure et de jour. Pour une Exécution unique : sélectionnez une date et une heure à l'aide du sélecteur de date. | +| **Activer la planification** | Basculez pour activer ou désactiver la planification. Une planification désactivée ne s'exécutera pas tant qu'elle n'aura pas été réactivée. | + +5. Cliquez sur **Valider** pour enregistrer la planification. La règle s'exécutera automatiquement à la prochaine heure planifiée. + + +## Permissions + +L'accès à la planification au sein du Moteur de règles nécessite les permissions Superutilisateur ou la permission de configuration appropriée. Voir le [tableau des permissions utilisateur](/admin/user_management/user_permission_chart) pour plus de détails. diff --git a/docs/content/automation/rules_engine/scheduling.ja.md b/docs/content/automation/rules_engine/scheduling.ja.md new file mode 100644 index 00000000000..bf5f67d0390 --- /dev/null +++ b/docs/content/automation/rules_engine/scheduling.ja.md @@ -0,0 +1,54 @@ +--- +title: ルールのスケジュール設定 +description: Rules Engineのルールを、繰り返しまたは単発のスケジュールで自動実行する +weight: 2 +audience: pro +--- + +注: Rules Engine SchedulingはDefectDojo Pro限定機能です。 + +ルールは、毎回手動でトリガーする代わりに、自動的に実行されるようスケジュールできます。スケジュールされたルールは、設定された時刻に、そのフィルター条件に一致するすべてのFindingに対して実行されます。 + +Schedulingはデフォルトでは無効になっており、Feature Flagsページからではなく、DefectDojoによってインスタンスごとに有効化されます。**Scheduling Service**を有効にするには[DefectDojo Support](mailto:support@defectdojo.com)にお問い合わせください。有効化されると**Schedule Rule**オプションが表示されるようになります。DefectDojoが一元管理する機能がどのように表示されるかについては、[Feature Flags](/admin/feature_flags/pro__feature_flags/)を参照してください。 + +スケジュールを設定するユーザーは、**Change Scheduling Service Schedule**の設定権限を持っている必要があります。 + +## スケジュールの種類 + +### Single Run（単発実行） + +Single Runスケジュールは、指定した日時に1回だけルールを実行します。実行が完了すると、そのスケジュールが繰り返されることはありません。 + +### Repeated Run（繰り返し実行） + +Repeated Runスケジュールを使用すると、例えば毎日午前9:00や毎週月曜日の15:00など、定期的にルールをトリガーできます。 + +**注:** Rules Engineのスケジュールは15分単位に制限されています。cronスケジュールの分フィールドは**0、15、30、45**のいずれかでなければなりません。それ以外の分の値は使用できません。 + +有効なスケジュールの例: +- 毎時0分: `0 * * * *` +- 毎日午前9:15: `15 9 * * *` +- 毎週月曜日の午後3:00: `0 15 * * 1` +- 15分ごと: `0,15,30,45 * * * *` + +## ルールのスケジュールを作成する + +1. サイドバーの**Rules Engine**メニューから**All Rules**ページに移動します。 +2. スケジュールしたいルールを見つけ、そのアクションメニュー（**⋮**）を開きます。 +3. **Schedule Rule**をクリックします。このオプションは、Scheduling Serviceが有効になっており、かつ必要な権限を持っている場合にのみ表示されます。 +4. **Schedule Rule**モーダルで、以下のフィールドを入力します。 + +| Field | Description | +|---|---| +| **Name** | このスケジュールの一意の名前（必須、最大100文字）。 | +| **Description** | スケジュールの目的についての任意の説明。 | +| **Trigger Type** | 1回限りの実行には**Single Run**を、繰り返しのcronスケジュールには**Repeated Run**を選択します。 | +| **Frequency** | Repeated Runの場合: cronビルダーを使用して、期間（毎時、毎日、毎週など）と、具体的な分・時・日の値を選択します。Single Runの場合: 日付ピッカーを使用して日時を選択します。 | +| **Enable Schedule** | スケジュールを有効化または無効化するトグルです。無効化されたスケジュールは、再度有効化されるまで実行されません。 | + +5. **Submit**をクリックしてスケジュールを保存します。ルールは次にスケジュールされた時刻に自動的に実行されます。 + + +## 権限 + +Rules Engine内のスケジュール機能へのアクセスには、Superuser権限または適切なConfiguration Permissionが必要です。詳細については、[User Permission Chart](/admin/user_management/user_permission_chart)を参照してください。 diff --git a/docs/content/automation/rules_engine_2/_index.de.md b/docs/content/automation/rules_engine_2/_index.de.md new file mode 100644 index 00000000000..98255528d38 --- /dev/null +++ b/docs/content/automation/rules_engine_2/_index.de.md @@ -0,0 +1,18 @@ +--- +title: Rules Engine 2.0 +description: Bauen Sie Automatisierungen als visuelle Node-Graphen, mit Traces je + Ausführung und einem Zustellungsprotokoll +summary: '' +date: 2026-08-02 09:00:00+00:00 +lastmod: 2026-08-02 09:00:00+00:00 +draft: false +weight: 99 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine_2/_index.es.md b/docs/content/automation/rules_engine_2/_index.es.md new file mode 100644 index 00000000000..a2c9c266e4d --- /dev/null +++ b/docs/content/automation/rules_engine_2/_index.es.md @@ -0,0 +1,18 @@ +--- +title: Rules Engine 2.0 +description: Cree automatizaciones como grafos de nodos visuales, con trazas por ejecución + y un libro de registro de entregas +summary: '' +date: 2026-08-02 09:00:00+00:00 +lastmod: 2026-08-02 09:00:00+00:00 +draft: false +weight: 99 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine_2/_index.fr.md b/docs/content/automation/rules_engine_2/_index.fr.md new file mode 100644 index 00000000000..158a5146ef3 --- /dev/null +++ b/docs/content/automation/rules_engine_2/_index.fr.md @@ -0,0 +1,18 @@ +--- +title: Moteur de règles 2.0 +description: Créez des automatisations sous forme de graphes de nœuds visuels, avec + des traces par exécution et un registre de livraison +summary: '' +date: 2026-08-02 09:00:00+00:00 +lastmod: 2026-08-02 09:00:00+00:00 +draft: false +weight: 99 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine_2/_index.ja.md b/docs/content/automation/rules_engine_2/_index.ja.md new file mode 100644 index 00000000000..fd95f600973 --- /dev/null +++ b/docs/content/automation/rules_engine_2/_index.ja.md @@ -0,0 +1,17 @@ +--- +title: Rules Engine 2.0 +description: 自動化をビジュアルなノードグラフとして構築し、実行ごとのトレースと配信台帳を確認できます +summary: '' +date: 2026-08-02 09:00:00+00:00 +lastmod: 2026-08-02 09:00:00+00:00 +draft: false +weight: 99 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine_2/about.de.md b/docs/content/automation/rules_engine_2/about.de.md new file mode 100644 index 00000000000..691859f2bc2 --- /dev/null +++ b/docs/content/automation/rules_engine_2/about.de.md @@ -0,0 +1,119 @@ +--- +title: Über Rules Engine 2.0 +description: Was Rules Engine 2.0 ist, wie man sie aktiviert, und die Konzepte, auf + denen sie aufbaut +weight: 1 +audience: pro +aliases: +- /de/automation/rules_engine_v2/about/ +--- + +Hinweis: Rules Engine 2.0 ist eine Funktion, die nur in DefectDojo Pro verfügbar ist. + +Rules Engine 2.0 ist ein visueller Automatisierungs-Baukasten. Statt eines Filters plus einer flachen Liste von Aktionen ist eine Regel ein **Graph**: ein Trigger-Knoten, der entscheidet, wann die Regel aufwacht, sowie eine beliebige Anzahl von Logik-, Befunde- und Egress-Knoten, die miteinander verbunden festlegen, was als Nächstes passiert. + +Rules Engine 2.0 ist ausschließlich über die [Pro-UI](/get_started/about/ui_pro_vs_os/) zugänglich. + +## Was sie gegenüber der Rules Engine hinzufügt + +Die ursprüngliche [Rules Engine](/automation/rules_engine/about/) wendet eine geordnete Liste von Aktionen auf jeden Befund an, der auf einen Filter passt. Rules Engine 2.0 behält diese Fähigkeit bei und fügt vier Dinge hinzu: + +* **Verzweigung.** Ein **Wenn / Filter**-Knoten leitet Elemente in einen true-Zweig und einen false-Zweig, sodass eine Regel kritische Befunde anders behandeln kann als den Rest, ohne in zwei Regeln aufgeteilt werden zu müssen. +* **Egress.** Eine Regel kann DefectDojo verlassen: ein JIRA-Issue oder ein Downstream-Ticket eröffnen, in Slack oder Microsoft Teams posten, eine E-Mail senden, einen Webhook aufrufen, eine In-App-Benachrichtigung auslösen oder einen Bericht erstellen. +* **Nachvollziehbarkeit.** Jede Ausführung wird Knoten für Knoten als [Ausführung](../runs/) erfasst, und jeder ausgehende Versand wird als [Zustellung](../deliveries/) erfasst, die genau angibt, was gesendet wurde, wohin es ging und wie es endete. +* **Ein Simulationsmodus.** Eine Regel kann exakt erfassen, was sie senden würde, ohne tatsächlich etwas zu senden – so testen Sie eine Regel sicher, bevor sie mit der Außenwelt in Berührung kommt. + +Beide Engines laufen nebeneinander. Das Aktivieren von Rules Engine 2.0 deaktiviert oder konvertiert Ihre bestehenden Regeln nicht, und es gibt einen [Konverter](../converting_from_rules_engine/), falls Sie sie übertragen möchten. + +## Rules Engine 2.0 aktivieren + +Rules Engine 2.0 befindet sich in der Beta-Phase und ist standardmäßig ausgeschaltet. Ein Superuser aktiviert sie unter **Settings > Feature Flags**, sowohl auf Cloud- als auch auf On-Premise-Instanzen. Siehe [Feature Flags](/admin/feature_flags/pro__feature_flags/). + +Sobald das Flag aktiviert ist, erscheint in der Seitenleiste ein Abschnitt **Rules Engine 2.0** mit drei Seiten: + +| Page | What it is for | +|------|----------------| +| **Alle Regeln** | Die Regelliste. Erstellen, bearbeiten, aktivieren, ausführen und löschen Sie Regeln von hier aus. | +| **Ausführungen** | Jede Ausführung, mit ihrem Trace pro Knoten. | +| **Zustellungen** | Das Protokoll von allem, was Regeln nach außen gesendet haben. | + +### Berechtigungen + +Der Zugriff wird durch zwei globale Rollenberechtigungen geregelt, die mit der ursprünglichen Rules Engine geteilt werden: + +* **Regel anzeigen** wird benötigt, um den Abschnitt in der Seitenleiste und alles darunter zu sehen. +* **Regel bearbeiten** wird benötigt, um zu erstellen, zu ändern, auszuführen, zu löschen, zu konvertieren, das Eigentum zu übernehmen und zu wiederholen. + +Regel bearbeiten kommt einer administrativen Berechtigung nahe. Der Autor einer Regel kann auf jeden Befund zugreifen, den der Eigentümer der Regel sehen kann, und Ausgaben an externe Systeme richten. Vergeben Sie diese Berechtigung daher bewusst. + +## Die Konzepte + +### Regeln und Graphen + +Eine Regel besteht aus einem Namen, einer Beschreibung, einem Eigentümer, einem Modus, einem Aktivierungsschalter und einem Graphen. Der Graph ist eine Menge von **Knoten** und den **Kanten** dazwischen. Er muss genau einen Trigger-Knoten enthalten und darf keinen Zyklus enthalten. Alles andere bleibt Ihnen überlassen, einschließlich der Möglichkeit, einen Knoten unverbunden zu lassen – das bedeutet lediglich, dass er ohne etwas zu bearbeiten läuft. + +Neue Regeln werden immer **deaktiviert** erstellt, sodass das Aktivieren ein bewusster Vorgang ist. + +### Elemente + +Was sich entlang der Kanten eines Graphen bewegt, ist ein **Element**: eine JSON-Momentaufnahme eines Befunds samt seines umgebenden Kontexts. + +```json +{ + "finding": { "id": 1234, "title": "...", "severity": "High", "...": "..." }, + "test": { "id": 12, "title": "...", "scan_type": "..." }, + "engagement": { "id": 5, "name": "..." }, + "product": { "id": 3, "name": "..." }, + "product_type": { "id": 1, "name": "..." }, + "ctx": { "trigger": "finding.created", "depth": 0, "source": "app" } +} +``` + +Bedingungen und Nachrichtenvorlagen werden anhand der Pfade in dieser Struktur geschrieben, zum Beispiel `finding.severity` oder `product.name`. Die vollständige Feldliste finden Sie unter [Regeln erstellen](../building_rules/). + +### Eigentümer + +Jede Regel läuft **als ihr Eigentümer**. Sie sieht genau die Befunde, die dieser Benutzer sehen kann, über dieselbe Autorisierung, die überall sonst im Produkt verwendet wird. Zwei Konsequenzen sind wissenswert: + +* Wird der Zugriff des Regel-Eigentümers eingeschränkt, wird auch die Regel eingeschränkt. +* Eine Regel, deren Eigentümer-Konto gelöscht wurde, hat keinen Eigentümer mehr, sodass sie auf nichts mehr passt und nichts tut. Weisen Sie einen neuen Eigentümer zu, oder verwenden Sie **Eigentum übernehmen** aus der Regelliste, um sie wieder nutzbar zu machen. + +### Modus: Simulate oder Live + +Der Modus wird pro Regel festgelegt, nicht pro Knoten. + +* **Simulate** (die Standardeinstellung) führt den gesamten Graphen real aus, einschließlich jeder Änderung an Befunden, aber Egress-Knoten erfassen lediglich, was sie *gesendet hätten*, und stoppen dort. Nichts verlässt DefectDojo. +* **Live** führt die Versände tatsächlich aus. + +Simulierte Versände erscheinen weiterhin im Zustellungsprotokoll, markiert als `simulated`, mit ihrer vollständigen Payload. Das ist der vorgesehene Weg, eine Regel zu prüfen, bevor Sie sie freigeben. + +Der Modus gilt bewusst für die gesamte Regel. Ein Graph, in dem manche Versände real sind und andere nicht, ist schwerer nachzuvollziehen als zwei getrennte Regeln. + +### Ausführungen + +Eine Ausführung einer Regel ist ein [Run](../runs/). Ein Run erfasst das Ereignis, das ihn ausgelöst hat, seinen Status, seinen Trace pro Knoten und etwaige Fehler. Eine Regel kann jeweils nur einen laufenden Run haben, sodass eine ausgelastete Regel in eine Warteschlange gerät, statt mit sich selbst zu konkurrieren. + +### Zustellungen + +Jeder ausgehende Nebeneffekt ist eine Zeile im [Zustellungs](../deliveries/)-Protokoll, geschrieben **bevor** ein Netzwerkaufruf stattfindet. Die Zeile enthält die Payload, das aufgelöste Ziel, den Status, die Anzahl der Wiederholungsversuche und alles, was das Ziel zurückgemeldet hat. Auch übersprungene Versände werden erfasst, sodass sich „die Regel hat nichts getan" und „die Regel hat nichts getan, weil der Befund bereits ein Ticket hatte" unterscheiden lassen. + +### Herkunft + +Jede Änderung, die eine Regel an einem Befund vornimmt, wird der Regel, dem Run und dem Knoten zugeordnet, die sie vorgenommen haben. Diese Zeitleiste ist am Befund selbst sichtbar, sodass Sie die Frage „Warum hat sich dieser Befund geändert?" beantworten können, ohne Regeldefinitionen zu lesen. + +### Skalierung + +Eine Regel verarbeitet alles, worauf ihr Geltungsbereich passt. Es gibt keine Obergrenze dafür, wie viele Befunde ein Run verarbeitet: Er arbeitet sie in Blöcken ab, sodass der Speicherverbrauch begrenzt bleibt statt der Abdeckung. Nur die Vorschau begrenzt, und sie sagt Ihnen, wenn sie das tut. + +### Aufbewahrung + +Ausführungen und Zustellungen werden beide standardmäßig 180 Tage lang aufbewahrt und danach entfernt. Das Produkt zeigt Ihnen das Zeitfenster und das Datum, an dem ein bestimmter Datensatz gelöscht wird, statt es implizit zu lassen, und beide Zeitfenster sind konfigurierbar. Siehe [Konfiguration](../configuration/#retention). + +## Wie es weitergeht + +* [Regeln erstellen](../building_rules/) behandelt den Editor, Trigger, Geltungsbereich, Bedingungen und Vorlagen. +* [Node-Referenz](../node_reference/) dokumentiert alle 25 Knoten. +* [Ausführungen](../runs/) behandelt Ausführung, Traces, Kaskadierung und Limits. +* [Zustellungen](../deliveries/) behandelt Kanäle, Status-Werte, Wiederholungsversuche und das erneute Senden. +* [Konvertieren aus der Rules Engine](../converting_from_rules_engine/) behandelt das Übertragen bestehender Regeln. +* [Konfiguration](../configuration/) behandelt die Einstellungen auf Deployment-Ebene. diff --git a/docs/content/automation/rules_engine_2/about.es.md b/docs/content/automation/rules_engine_2/about.es.md new file mode 100644 index 00000000000..6498750c5c5 --- /dev/null +++ b/docs/content/automation/rules_engine_2/about.es.md @@ -0,0 +1,119 @@ +--- +title: Acerca de Rules Engine 2.0 +description: Qué es Rules Engine 2.0, cómo activarlo y los conceptos en los que se + basa +weight: 1 +audience: pro +aliases: +- /es/automation/rules_engine_v2/about/ +--- + +Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro. + +Rules Engine 2.0 es un generador visual de automatizaciones. En lugar de un filtro más una lista plana de acciones, una regla es un **grafo**: un nodo disparador que decide cuándo se activa la regla, y cualquier cantidad de nodos de lógica, de Hallazgos y de salida conectados entre sí para determinar qué ocurre a continuación. + +Solo se puede acceder a Rules Engine 2.0 a través de la [interfaz de Pro](/get_started/about/ui_pro_vs_os/). + +## Qué aporta respecto a Rules Engine + +El [Rules Engine](/automation/rules_engine/about/) original aplica una lista ordenada de acciones a cada Hallazgo que coincide con un filtro. Rules Engine 2.0 conserva esa capacidad y añade cuatro cosas: + +* **Ramificación.** Un nodo **Si / Filtro** dirige los elementos por una rama verdadera y una rama falsa, de modo que una regla puede tratar los Hallazgos Críticos de forma distinta al resto sin tener que dividirse en dos reglas. +* **Salida.** Una regla puede salir de DefectDojo: abrir un issue de JIRA o un ticket en un sistema externo, publicar en Slack o Microsoft Teams, enviar un correo electrónico, llamar a un webhook, generar una alerta dentro de la aplicación o generar un informe. +* **Trazabilidad.** Cada ejecución se registra nodo por nodo como una [Ejecución](../runs/), y cada envío saliente se registra como una [Entrega](../deliveries/) que indica exactamente qué se envió, adónde fue y cómo terminó. +* **Un modo de simulación.** Una regla puede registrar con precisión lo que enviaría sin enviar realmente nada, que es la forma de probarla de manera segura antes de que llegue al mundo exterior. + +Ambos motores funcionan en paralelo. Activar Rules Engine 2.0 no desactiva ni convierte las reglas existentes, y existe un [conversor](../converting_from_rules_engine/) para cuando se quiera migrarlas. + +## Activación de Rules Engine 2.0 + +Rules Engine 2.0 está en Beta y viene desactivado de forma predeterminada. Un superusuario lo activa desde **Settings > Feature Flags**, tanto en instancias Cloud como On-Premise. Consulte [Feature Flags](/admin/feature_flags/pro__feature_flags/). + +Una vez activado el indicador, aparece una sección **Rules Engine 2.0** en la barra lateral con tres páginas: + +| Página | Para qué sirve | +|------|----------------| +| **All Rules** | La lista de reglas. Desde aquí se crean, editan, activan, ejecutan y eliminan reglas. | +| **Runs** | Todas las ejecuciones, con su traza por nodo. | +| **Deliveries** | El registro de todo lo que las reglas han enviado hacia el exterior. | + +### Permisos + +El acceso está gobernado por dos permisos de rol global, compartidos con el Rules Engine original: + +* **Rule View** es necesario para ver la sección de la barra lateral y todo lo que contiene. +* **Rule Edit** es necesario para crear, modificar, ejecutar, eliminar, convertir, tomar posesión y volver a ejecutar reglas. + +Rule Edit se acerca a un permiso administrativo. Un autor de reglas puede llegar a cualquier Hallazgo que el propietario de su regla pueda ver, y puede dirigir la salida hacia sistemas externos, así que debe otorgarse con criterio. + +## Los conceptos + +### Reglas y grafos + +Una regla es un nombre, una descripción, un propietario, un modo, un interruptor de activación y un grafo. El grafo es un conjunto de **nodos** y las **aristas** entre ellos. Debe contener exactamente un nodo disparador y no debe contener ningún ciclo. Todo lo demás depende de usted, incluida la posibilidad de dejar un nodo sin conectar, lo que simplemente significa que se ejecuta sin nada sobre lo que trabajar. + +Las reglas nuevas siempre se crean **desactivadas**, de modo que activar una es un acto deliberado. + +### Elementos + +Lo que viaja por las aristas de un grafo es un **elemento**: una instantánea JSON de un Hallazgo junto con el contexto que lo rodea. + +```json +{ + "finding": { "id": 1234, "title": "...", "severity": "High", "...": "..." }, + "test": { "id": 12, "title": "...", "scan_type": "..." }, + "engagement": { "id": 5, "name": "..." }, + "product": { "id": 3, "name": "..." }, + "product_type": { "id": 1, "name": "..." }, + "ctx": { "trigger": "finding.created", "depth": 0, "source": "app" } +} +``` + +Las condiciones y las plantillas de mensajes se escriben contra las rutas de esa estructura, por ejemplo `finding.severity` o `product.name`. La lista completa de campos está en [Creación de reglas](../building_rules/). + +### Propietario + +Toda regla se ejecuta **como su propietario**. Ve exactamente los Hallazgos que ese usuario puede ver, mediante la misma autorización usada en el resto del producto. Vale la pena conocer dos consecuencias: + +* Restringir el acceso del propietario de una regla restringe la regla. +* Una regla cuyo propietario tiene la cuenta eliminada no tiene propietario, por lo que no coincide con nada y no hace nada. Asigne un nuevo propietario, o use **Tomar posesión** en la lista de reglas, para recuperarla. + +### Modo: Simulación o En vivo + +El modo se establece por regla, no por nodo. + +* **Simulación** (el valor predeterminado) ejecuta todo el grafo de verdad, incluida cada edición de Hallazgo, pero los nodos de salida registran lo que *habrían* enviado y se detienen ahí. Nada sale de DefectDojo. +* **En vivo** realiza los envíos. + +Los envíos simulados también aparecen en el registro de Entregas, marcados como `simulated`, con su payload completo. Esa es la forma prevista de revisar una regla antes de dejarla salir al exterior. + +El modo se aplica deliberadamente a toda la regla. Un grafo donde algunos envíos son reales y otros no lo son es más difícil de razonar que dos reglas separadas. + +### Ejecuciones + +Una ejecución de una regla es una [Ejecución](../runs/). Una ejecución registra el evento que la activó, su estado, su traza por nodo y cualquier error. Una regla solo puede tener una ejecución en curso a la vez, de modo que una regla ocupada se pone en cola en lugar de competir consigo misma. + +### Entregas + +Cada efecto secundario saliente es una fila en el registro de [Entregas](../deliveries/), escrita **antes** de que ocurra cualquier llamada de red. La fila contiene el payload, el destino resuelto, el estado, el número de reintentos y lo que haya respondido el destino. Las omisiones también se registran, de modo que "la regla no hizo nada" y "la regla no hizo nada porque el Hallazgo ya tenía un ticket" son distinguibles. + +### Procedencia + +Cada cambio que una regla hace a un Hallazgo se atribuye de vuelta a la regla, la ejecución y el nodo que lo realizó. Esa cronología es visible en el propio Hallazgo, de modo que se puede responder "¿por qué cambió este Hallazgo?" sin leer las definiciones de las reglas. + +### Escala + +Una regla procesa todo lo que coincide con su alcance. No hay límite en cuántos Hallazgos puede manejar una ejecución: los procesa en bloques para que la memoria se mantenga acotada en lugar de la cobertura. Solo la vista previa tiene un límite, y lo indica cuando lo aplica. + +### Retención + +Las ejecuciones y las entregas se conservan durante 180 días de forma predeterminada, y luego se depuran. El producto muestra la ventana y la fecha en la que se eliminará un registro determinado en lugar de dejarlo implícito, y ambas ventanas son configurables. Consulte [Configuración](../configuration/#retention). + +## Próximos pasos + +* [Creación de reglas](../building_rules/) cubre el editor, los disparadores, el alcance, las condiciones y las plantillas. +* [Referencia de nodos](../node_reference/) documenta los 25 nodos. +* [Ejecuciones](../runs/) cubre la ejecución, las trazas, el encadenamiento y los límites. +* [Entregas](../deliveries/) cubre los canales, los estados, los reintentos y la repetición de envíos. +* [Migración desde Rules Engine](../converting_from_rules_engine/) cubre la migración de reglas existentes. +* [Configuración](../configuration/) cubre los ajustes a nivel de despliegue. diff --git a/docs/content/automation/rules_engine_2/about.fr.md b/docs/content/automation/rules_engine_2/about.fr.md new file mode 100644 index 00000000000..57e5ba4eaa4 --- /dev/null +++ b/docs/content/automation/rules_engine_2/about.fr.md @@ -0,0 +1,119 @@ +--- +title: À propos de Rules Engine 2.0 +description: Ce qu'est Rules Engine 2.0, comment l'activer, et les concepts sur lesquels + il repose +weight: 1 +audience: pro +aliases: +- /fr/automation/rules_engine_v2/about/ +--- + +Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro. + +Rules Engine 2.0 est un générateur d'automatisation visuel. Au lieu d'un filtre associé à une liste plate d'actions, une règle est un **graphe** : un nœud déclencheur qui décide quand la règle se réveille, et un nombre quelconque de nœuds de logique, de Constatations et de sortie reliés entre eux pour indiquer ce qui se passe ensuite. + +Rules Engine 2.0 n'est accessible que via l'[interface Pro](/get_started/about/ui_pro_vs_os/). + +## Ce qu'il ajoute par rapport à Rules Engine + +Le [Rules Engine](/automation/rules_engine/about/) d'origine applique une liste ordonnée d'actions à chaque Constatation correspondant à un filtre. Rules Engine 2.0 conserve cette capacité et ajoute quatre éléments : + +* **Le branchement.** Un nœud **If / Filter** (Si / Filtre) dirige les éléments vers une branche vraie et une branche fausse, de sorte qu'une seule règle puisse traiter les Constatations Critiques différemment du reste sans devoir être scindée en deux règles. +* **La sortie (egress).** Une règle peut sortir de DefectDojo : ouvrir un ticket JIRA ou un ticket en aval, publier sur Slack ou Microsoft Teams, envoyer un e-mail, appeler un webhook, déclencher une alerte dans l'application, ou générer un rapport. +* **La traçabilité.** Chaque exécution est enregistrée nœud par nœud sous forme d'[Exécution](../runs/), et chaque envoi sortant est enregistré comme une [Livraison](../deliveries/) qui indique exactement ce qui a été envoyé, où cela a été envoyé, et comment cela s'est terminé. +* **Un mode de simulation.** Une règle peut enregistrer précisément ce qu'elle aurait envoyé sans rien envoyer réellement, ce qui permet de la tester en toute sécurité avant de la laisser agir à l'extérieur. + +Les deux moteurs fonctionnent côte à côte. Activer Rules Engine 2.0 ne désactive ni ne convertit vos règles existantes, et il existe un [convertisseur](../converting_from_rules_engine/) pour le jour où vous voudrez les faire migrer. + +## Activer Rules Engine 2.0 + +Rules Engine 2.0 est en version bêta et est désactivé par défaut. Un superutilisateur l'active depuis **Settings > Feature Flags** (Paramètres > Indicateurs de fonctionnalités), aussi bien sur les instances Cloud que sur les instances On-Premise. Voir [Indicateurs de fonctionnalités](/admin/feature_flags/pro__feature_flags/). + +Une fois l'indicateur activé, une section **Rules Engine 2.0** apparaît dans la barre latérale avec trois pages : + +| Page | À quoi elle sert | +|------|----------------| +| **All Rules** (Toutes les règles) | La liste des règles. Créez, modifiez, activez, exécutez et supprimez des règles depuis cet endroit. | +| **Runs** (Exécutions) | Chaque exécution, avec sa trace détaillée par nœud. | +| **Deliveries** (Livraisons) | Le registre de tout ce que les règles ont envoyé vers l'extérieur. | + +### Permissions + +L'accès est régi par deux permissions de rôle globales, partagées avec le Rules Engine d'origine : + +* **Rule View** (Consultation des règles) est requise pour voir la section de la barre latérale et tout ce qu'elle contient. +* **Rule Edit** (Modification des règles) est requise pour créer, modifier, exécuter, supprimer, convertir, prendre possession et rejouer une règle. + +Rule Edit se rapproche d'une permission administrative. Un auteur de règle peut atteindre toute Constatation que le propriétaire de sa règle peut voir, et peut diriger la sortie vers des systèmes externes ; accordez-la donc de façon réfléchie. + +## Les concepts + +### Règles et graphes + +Une règle est constituée d'un nom, d'une description, d'un propriétaire, d'un mode, d'un interrupteur d'activation et d'un graphe. Le graphe est un ensemble de **nœuds** et des **arêtes** qui les relient. Il doit contenir exactement un nœud déclencheur et ne doit pas contenir de cycle. Tout le reste est à votre discrétion, y compris le fait de laisser un nœud non connecté, ce qui signifie simplement qu'il s'exécute sans rien à traiter. + +Les nouvelles règles sont toujours créées **désactivées**, de sorte qu'en activer une est un acte délibéré. + +### Éléments + +Ce qui circule le long des arêtes d'un graphe est un **élément** : un instantané JSON d'une Constatation ainsi que le contexte qui l'entoure. + +```json +{ + "finding": { "id": 1234, "title": "...", "severity": "High", "...": "..." }, + "test": { "id": 12, "title": "...", "scan_type": "..." }, + "engagement": { "id": 5, "name": "..." }, + "product": { "id": 3, "name": "..." }, + "product_type": { "id": 1, "name": "..." }, + "ctx": { "trigger": "finding.created", "depth": 0, "source": "app" } +} +``` + +Les conditions et les modèles de message sont écrits par rapport aux chemins de cette structure, par exemple `finding.severity` ou `product.name`. La liste complète des champs se trouve dans [Créer des règles](../building_rules/). + +### Propriétaire + +Chaque règle s'exécute **en tant que son propriétaire**. Elle voit exactement les Constatations que cet utilisateur peut voir, via la même autorisation utilisée partout ailleurs dans le produit. Deux conséquences sont à connaître : + +* Restreindre l'accès du propriétaire d'une règle restreint la règle. +* Une règle dont le compte du propriétaire est supprimé n'a plus de propriétaire ; elle ne correspond donc à rien du tout et ne fait rien. Attribuez un nouveau propriétaire, ou utilisez **Take Ownership** (Prendre possession) depuis la liste des règles, pour la rétablir. + +### Mode : Simulate ou Live + +Le mode est défini par règle, et non par nœud. + +* **Simulate** (Simuler, par défaut) exécute réellement l'ensemble du graphe, y compris chaque modification de Constatation, mais les nœuds de sortie enregistrent ce qu'ils *auraient* envoyé et s'arrêtent là. Rien ne sort de DefectDojo. +* **Live** effectue réellement les envois. + +Les envois simulés apparaissent tout de même dans le registre des Livraisons, marqués `simulated`, avec leur charge utile complète. C'est la manière prévue de vérifier une règle avant de la laisser s'exécuter en conditions réelles. + +Le mode s'applique délibérément à l'ensemble de la règle. Un graphe où certains envois sont réels et d'autres non est plus difficile à comprendre que deux règles distinctes. + +### Exécutions + +Une exécution d'une règle est une [Exécution](../runs/). Une exécution enregistre l'événement qui l'a déclenchée, son statut, sa trace détaillée par nœud, et toute erreur éventuelle. Une règle ne peut avoir qu'une seule exécution en cours à la fois ; une règle occupée est donc mise en file d'attente plutôt que de s'exécuter en parallèle avec elle-même. + +### Livraisons + +Chaque effet de bord sortant correspond à une ligne du registre des [Livraisons](../deliveries/), écrite **avant** que le moindre appel réseau n'ait lieu. La ligne contient la charge utile, la destination résolue, le statut, le nombre de tentatives, et ce que la destination a répondu. Les éléments ignorés sont également enregistrés, de sorte que « la règle n'a rien fait » et « la règle n'a rien fait car la Constatation avait déjà un ticket » soient distinguables. + +### Provenance + +Chaque modification qu'une règle apporte à une Constatation est attribuée à la règle, à l'exécution et au nœud qui l'a effectuée. Cette chronologie est visible directement sur la Constatation, ce qui permet de répondre à la question « pourquoi cette Constatation a-t-elle changé ? » sans avoir à lire les définitions des règles. + +### Échelle + +Une règle traite tout ce que son périmètre couvre. Il n'y a aucune limite au nombre de Constatations qu'une exécution peut traiter : elle les parcourt par lots afin que ce soit la mémoire qui reste bornée, et non la couverture. Seul l'aperçu (Preview) impose une limite, et il vous en informe lorsque c'est le cas. + +### Rétention + +Les exécutions et les livraisons sont toutes deux conservées 180 jours par défaut, puis purgées. Le produit affiche la fenêtre et la date à laquelle un enregistrement donné sera supprimé plutôt que de laisser cela implicite, et les deux fenêtres sont configurables. Voir [Configuration](../configuration/#retention). + +## Pour aller plus loin + +* [Créer des règles](../building_rules/) couvre l'éditeur, les déclencheurs, le périmètre, les conditions et les modèles. +* [Référence des nœuds](../node_reference/) documente les 25 nœuds. +* [Exécutions](../runs/) couvre l'exécution, les traces, l'enchaînement et les limites. +* [Livraisons](../deliveries/) couvre les canaux, les statuts, les tentatives et la relecture. +* [Conversion depuis Rules Engine](../converting_from_rules_engine/) couvre le déplacement des règles existantes. +* [Configuration](../configuration/) couvre les paramètres au niveau du déploiement. diff --git a/docs/content/automation/rules_engine_2/about.ja.md b/docs/content/automation/rules_engine_2/about.ja.md new file mode 100644 index 00000000000..391695c9038 --- /dev/null +++ b/docs/content/automation/rules_engine_2/about.ja.md @@ -0,0 +1,118 @@ +--- +title: Rules Engine 2.0 について +description: Rules Engine 2.0 とは何か、有効化の方法、基盤となる概念について +weight: 1 +audience: pro +aliases: +- /ja/automation/rules_engine_v2/about/ +--- + +注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。 + +Rules Engine 2.0 は、ビジュアルな自動化ビルダーです。フィルターとフラットなアクションのリストの代わりに、ルールは**グラフ**として構成されます。グラフは、ルールがいつ起動するかを決めるトリガーノードと、その後の処理内容を指定する任意の数のロジックノード、Finding ノード、Egress ノードが配線されたものです。 + +Rules Engine 2.0 には [Pro UI](/get_started/about/ui_pro_vs_os/) からのみアクセスできます。 + +## Rules Engine と比べて追加されるもの + +従来の [Rules Engine](/automation/rules_engine/about/) は、1つのフィルターに一致するすべての Finding に対して、順序付けられたアクションのリストを適用します。Rules Engine 2.0 はこの機能を維持しつつ、次の4つを追加します。 + +* **分岐。** **If / Filter** ノードは、項目を true 分岐と false 分岐に振り分けます。これにより、1つのルールを2つに分割することなく、Critical の Finding をそれ以外と異なる方法で扱うことができます。 +* **Egress。** ルールは DefectDojo の外部にアクションを送信できます。JIRA の課題やダウンストリームのチケットの起票、Slack や Microsoft Teams への投稿、メールの送信、Webhook の呼び出し、アプリ内アラートの発生、レポートの生成などが可能です。 +* **トレーサビリティ。** すべての実行はノードごとに [Run](../runs/) として記録され、すべての送信は [Delivery](../deliveries/) として記録されます。Delivery には、何が送信され、どこへ送られ、どのように終了したかが正確に記録されます。 +* **Simulate モード。** ルールは、実際には何も送信せずに、送信するはずだった内容を正確に記録できます。これにより、外部に影響を与える前にルールを安全にテストできます。 + +両方のエンジンは並行して動作します。Rules Engine 2.0 を有効にしても、既存のルールが無効化されたり変換されたりすることはありません。ルールを移行したい場合のために [converter](../converting_from_rules_engine/) が用意されています。 + +## Rules Engine 2.0 の有効化 + +Rules Engine 2.0 はベータ版であり、デフォルトでは無効になっています。スーパーユーザーが、Cloud インスタンス・On-Premise インスタンスの両方で **Settings > Feature Flags** から有効化します。[Feature Flags](/admin/feature_flags/pro__feature_flags/) を参照してください。 + +フラグが有効になると、サイドバーに **Rules Engine 2.0** セクションが表示され、次の3つのページが含まれます。 + +| ページ | 用途 | +|------|----------------| +| **All Rules** | ルール一覧です。ここからルールの作成、編集、有効化、実行、削除を行います。 | +| **Runs** | ノードごとのトレースを含む、すべての実行記録です。 | +| **Deliveries** | ルールが外部に送信したすべての内容の台帳です。 | + +### アクセス権限 + +アクセスは、従来の Rules Engine と共有される2つのグローバルロール権限によって制御されます。 + +* サイドバーのセクションおよびその配下のすべてを閲覧するには **Rule View** が必要です。 +* 作成、変更、実行、削除、変換、所有権の取得、リプレイを行うには **Rule Edit** が必要です。 + +Rule Edit は管理者権限に近いものです。ルールの作成者は、そのルールの所有者が閲覧できる任意の Finding にアクセスでき、また出力を外部システムに向けることができるため、慎重に付与してください。 + +## 概念 + +### ルールとグラフ + +ルールは、名前、説明、所有者、モード、有効/無効の切り替え、そしてグラフから構成されます。グラフは**ノード**とその間の**エッジ**の集合です。トリガーノードをちょうど1つ含む必要があり、循環を含んではいけません。それ以外はすべて自由です。ノードを何にも接続しないままにしておくこともでき、その場合はそのノードは処理対象が何もない状態で実行されるだけです。 + +新しいルールは常に**無効**な状態で作成されるため、ルールを有効にすることは意図的な操作になります。 + +### Item + +グラフのエッジに沿って流れるのは**item**です。これは、1つの Finding とその周辺コンテキストの JSON スナップショットです。 + +```json +{ + "finding": { "id": 1234, "title": "...", "severity": "High", "...": "..." }, + "test": { "id": 12, "title": "...", "scan_type": "..." }, + "engagement": { "id": 5, "name": "..." }, + "product": { "id": 3, "name": "..." }, + "product_type": { "id": 1, "name": "..." }, + "ctx": { "trigger": "finding.created", "depth": 0, "source": "app" } +} +``` + +条件やメッセージテンプレートは、この構造内のパス、例えば `finding.severity` や `product.name` に対して記述します。全フィールドの一覧は [Building Rules](../building_rules/) にあります。 + +### 所有者 + +すべてのルールは**所有者として**実行されます。ルールは、その所有者が閲覧できる Finding だけを、製品の他の箇所と同じ認可の仕組みを通じて見ます。ここから生じる2つの帰結を知っておく価値があります。 + +* ルール所有者のアクセス権を制限すると、ルールも制限されます。 +* ルールの所有者アカウントが削除されると、そのルールには所有者がいなくなり、何にも一致せず何も実行しなくなります。新しい所有者を割り当てるか、ルール一覧から **Take Ownership** を使うことで復旧できます。 + +### モード: Simulate または Live + +モードはノードごとではなく、ルールごとに設定します。 + +* **Simulate**(デフォルト)は、あらゆる Finding の編集を含め、グラフ全体を実際に実行しますが、Egress ノードは*送信するはずだった*内容を記録するだけで、そこで止まります。DefectDojo の外には何も出ていきません。 +* **Live** は実際に送信を行います。 + +Simulate による送信も、`simulated` としてマークされ、完全なペイロードとともに Deliveries の台帳に表示されます。これが、ルールを外部に公開する前にレビューするための想定された方法です。 + +モードは意図的にルール全体に適用されます。一部の送信は本物で残りはそうではない、というグラフは、2つのルールに分けるよりも判断が難しくなります。 + +### Run + +ルールの1回の実行が [Run](../runs/) です。Run には、それをトリガーしたイベント、ステータス、ノードごとのトレース、そしてエラーが記録されます。1つのルールは同時に1つの Run しか進行できないため、実行中のルールは自分自身と競合するのではなくキューに入ります。 + +### Delivery + +すべての外向きの副作用は、ネットワーク呼び出しが発生する**前に**、[Deliveries](../deliveries/) 台帳の1行として書き込まれます。この行には、ペイロード、解決された送信先、ステータス、リトライ回数、そして送信先から返ってきた内容が保持されます。スキップも記録されるため、「ルールが何もしなかった」ことと「Finding が既にチケット化されていたためルールが何もしなかった」ことを区別できます。 + +### 来歴(Provenance) + +ルールが Finding に加えたすべての変更は、そのルール、Run、そして変更を行ったノードに紐づけて記録されます。このタイムラインは Finding 自体で確認できるため、ルール定義を読まなくても「この Finding はなぜ変更されたのか」に答えられます。 + +### スケール + +ルールは、そのスコープに一致するすべてを処理します。1回の Run が扱える Finding の件数に上限はありません。カバレッジではなくメモリ使用量を一定に保つため、チャンク単位で処理を進めます。上限があるのは Preview だけで、切り詰めが発生した場合はその旨が通知されます。 + +### 保持期間 + +Run と Delivery は、デフォルトでどちらも180日間保持された後に削除されます。製品は、保持期間の長さとレコードが削除される日付を暗黙のままにせず表示し、両方の期間は設定可能です。[Configuration](../configuration/#retention) を参照してください。 + +## 次に読むべきページ + +* [Building Rules](../building_rules/) では、エディター、トリガー、スコープ、条件、テンプレートについて説明しています。 +* [Node Reference](../node_reference/) では、25個すべてのノードについて説明しています。 +* [Runs](../runs/) では、実行、トレース、カスケード、制限について説明しています。 +* [Deliveries](../deliveries/) では、チャネル、ステータス、リトライ、リプレイについて説明しています。 +* [Converting from Rules Engine](../converting_from_rules_engine/) では、既存のルールを移行する方法について説明しています。 +* [Configuration](../configuration/) では、デプロイメントレベルの設定について説明しています。 diff --git a/docs/content/automation/rules_engine_2/building_rules.de.md b/docs/content/automation/rules_engine_2/building_rules.de.md new file mode 100644 index 00000000000..91383c52525 --- /dev/null +++ b/docs/content/automation/rules_engine_2/building_rules.de.md @@ -0,0 +1,197 @@ +--- +title: Regeln erstellen +description: Der Grafikeditor, Trigger, Geltungsbereich, Bedingungen und Nachrichtenvorlagen +weight: 2 +audience: pro +aliases: +- /de/automation/rules_engine_v2/building_rules/ +--- + +Note: Rules Engine 2.0 is a DefectDojo Pro-only feature. + +Eine Regel wird auf einer Zeichenfläche (Canvas) erstellt. Sie ziehen Knoten aus einer Palette, verbinden sie miteinander und konfigurieren jeden davon in einem Seitenpanel. Diese Seite behandelt die Teile dieses Prozesses, die unabhängig von den verwendeten Knoten gleich sind. Die Knoten selbst finden Sie in der [Node-Referenz](../node_reference/). + +## Der Editor + +Öffnen Sie **Rules Engine 2.0 > All Rules** und wählen Sie **New Rule**, oder öffnen Sie eine bestehende Regel zur Bearbeitung. + +Die Palette ist in vier Kategorien gegliedert, was auch der Reihenfolge entspricht, in der Elemente einen typischen Graphen durchlaufen: + +| Category | What the nodes do | +|----------|-------------------| +| **Triggers** | Entscheiden, wann die Regel aktiviert wird und welche Befunde sie durchlaufen. Genau einer pro Graph. | +| **Logic** | Leiten, begrenzen und deduplizieren die durchlaufenden Elemente. | +| **Findings** | Ändern die Befunde. | +| **Egress** | Senden etwas nach außen: ein Ticket, eine Nachricht, einen Bericht. | + +Die Palette wird direkt aus der Engine generiert, sodass das, was Sie im Editor sehen, immer genau dem entspricht, was die Engine ausführen kann. + +### Graph-Regeln + +Ein Graph wird beim Speichern und erneut vor jedem Lauf überprüft. Er muss alle folgenden Bedingungen erfüllen: + +* Er hat mindestens einen Knoten. +* Er hat **genau einen** Trigger-Knoten. +* Jeder Knoten hat eine eindeutige, nicht leere ID mit maximal 100 Zeichen. +* Jeder Knoten ist von einem Typ, den die Engine kennt. +* Jede Kante verbindet zwei existierende Knoten. +* Er enthält keinen Zyklus. + +Ein Knoten, in den nichts eingespeist wird, ist zulässig. Er läuft mit einer leeren Eingabeliste, was in der Regel bedeutet, dass er nichts tut. + +Ein Knoten mit mehreren eingehenden Kanten erhält alle deren Ausgaben zusammengeführt. + +### Vorschau vor dem Speichern + +**Preview** führt den Graphen, den Sie aktuell auf der Zeichenfläche haben, testweise aus (Dry-Run) und zeigt Ihnen den Trace pro Knoten, den er erzeugen würde: wie viele Elemente in jeden Knoten eingegangen sind, wie viele über welchen Ausgang verlassen wurden und was jeder Knoten geändert hätte. + +Preview führt die echte Engine aus, nicht eine Simulation davon, und macht anschließend alles rückgängig. Es wird nichts geschrieben, kein Lauf wird aufgezeichnet, und der Egress wird gezwungen, zu simulieren, was auch immer der Modus der Regel vorgibt. Es ist der schnellste Weg zu prüfen, ob Ihre Bedingungen das treffen, was Sie erwartet haben. + +Preview ist die einzige Ausführung, die begrenzt, wie viele Befunde betrachtet werden, damit sie schnell bleibt. Wenn gekürzt wird, wird dies im Trace vermerkt. Ein echter Lauf kennt keine solche Grenze. + +## Trigger und Geltungsbereich + +Jeder Graph beginnt mit einem von drei Triggern. + +* **On Finding Event** aktiviert die Regel, wenn Befunde erstellt, aktualisiert, geschlossen oder wieder geöffnet werden. Wählen Sie in der **Event**-Einstellung des Knotens aus, welche davon gelten sollen, oder `any` für alle vier. +* **On a Schedule** durchsucht Befunde nach einem wiederkehrenden Zeitplan. +* **Manual Run** durchsucht Befunde, wenn Sie auf der Regel auf **Run** klicken. + +### Geltungsbereich + +Alle drei Trigger nehmen einen **Scope** (Geltungsbereich) entgegen, und mit dem Geltungsbereich grenzen Sie ein, was die Regel berücksichtigt. Es handelt sich um dasselbe Filtervokabular, das die ursprüngliche Rules Engine verwendet, rund sechzig Filter, die Befunde und die sie umgebenden Objekte abdecken. Ein Filter, den Sie dort bereits zu schreiben wissen, bedeutet also hier dasselbe. + +Zwei Dinge zum Geltungsbereich sollten Sie verstehen: + +* **Der Geltungsbereich wird zusätzlich zur Autorisierung angewendet, niemals anstelle davon.** Die Regel läuft als ihr Eigentümer, sodass der Geltungsbereich eine bereits autorisierte Menge von Befunden einschränkt. Einen leeren Geltungsbereich zu lassen bedeutet nicht „jeder Befund in der Instanz“, sondern „jeder Befund, den der Regeleigentümer sehen kann“. +* **Ein ungültiger Geltungsbereich lässt den Lauf fehlschlagen, statt ihn zu erweitern.** Existiert ein Filterschlüssel nicht, oder ist ein Wert einer, den der Filter stillschweigend verwerfen würde, bricht der Lauf mit einem Fehler ab. Eine Regel, die nichts tut, ist wiederherstellbar. Eine Regel, die stillschweigend jeden Befund in der Instanz bearbeitet, ist es nicht. + +Bei einem Event-Trigger fungiert der Geltungsbereich als zweites Tor: Die im Event genannten Befunde werden gegen ihn abgeglichen, und nur die, die ihn passieren, gelangen in den Graphen. + +### Zeitplanung + +Eine Regel, deren Trigger **On a Schedule** ist, wird direkt aus der Regel heraus geplant. Das Festlegen des Zeitplans erfordert Rule Edit, dieselbe Berechtigung wie das Bearbeiten der Regel, denn eine zeitplan-ausgelöste Regel tut überhaupt nichts, solange sie keinen hat. + +Zeitpläne sind auf Viertelstundenmarken beschränkt. Das Minutenfeld eines Cron-Ausdrucks muss `0`, `15`, `30` oder `45` sein. + +Gültige Beispiele: + +``` +0 * * * * every hour, on the hour +15 9 * * * every day at 09:15 +0 15 * * 1 every Monday at 15:00 +30 2 * * * every day at 02:30 +``` + +## Auf Befunddaten verweisen + +An zwei Stellen liest eine Regel Werte aus dem durchlaufenden Element aus: **Conditions** (Bedingungen) und **Templates** (Vorlagen). Beide verwenden dieselben Punktpfade. + +``` +finding.severity +finding.title +finding.vulnerability_ids.0 +product.name +product_type.name +test.scan_type +ctx.rule_name +``` + +Ein Pfad, der sich nicht auflösen lässt, ergibt keinen Wert statt eines Fehlers. + +### Verfügbare Felder + +Jedes Element trägt einen festen Satz von Befundfeldern. Diese Liste ist ein Vertrag und ändert sich daher nur bewusst. + +| Group | Fields | +|-------|--------| +| Identität | `id`, `title`, `hash_code`, `unique_id_from_tool` | +| Schweregrad und Bewertung | `severity`, `numerical_severity`, `cvssv3`, `cvssv3_score`, `epss_score`, `epss_percentile`, `priority`, `risk`, `risk_score` | +| Text | `description`, `mitigation`, `impact` | +| Status | `active`, `verified`, `false_p`, `duplicate`, `is_mitigated`, `out_of_scope`, `risk_accepted`, `under_review` | +| Daten | `date`, `mitigated`, `last_status_update`, `sla_expiration_date` | +| Ort | `file_path`, `line`, `component_name`, `component_version`, `service` | +| Klassifizierung | `cwe`, `vulnerability_ids`, `tags` | + +Neben `finding` trägt jedes Element `test` (`id`, `title`, `scan_type`), `engagement` (`id`, `name`), `product` (`id`, `name`), `product_type` (`id`, `name`) und `ctx`. + +Daten sind ISO-8601-Zeichenketten. Das ist beabsichtigt: Es bedeutet, dass `gt` und `lt` sie als Text korrekt ordnen, sodass `2026-07-28` korrekt größer ist als `2026-01-01`. + +`priority`, `risk` und `risk_score` stammen aus der Priorisierung von Pro. Ein Befund, der noch nicht bewertet wurde, trägt für sie keinen Wert. + +### Bedingungen + +Ein **If / Filter**-Knoten enthält eine Liste von Bedingungszeilen. Jede Zeile besteht aus einem Pfad, einem Operator und einem Wert. **Match** entscheidet, ob jede Zeile zutreffen muss (`all`) oder nur eine davon (`any`). + +| Operator | Meaning | +|----------|---------| +| `eq` | ist gleich | +| `neq` | ist ungleich | +| `contains` | enthält | +| `not_contains` | enthält nicht | +| `in` | ist eines von | +| `not_in` | ist keines von | +| `gt` | ist größer als | +| `gte` | ist größer als oder gleich | +| `lt` | ist kleiner als | +| `lte` | ist kleiner als oder gleich | +| `startswith` | beginnt mit | +| `endswith` | endet mit | +| `exists` | ist gesetzt | +| `not_exists` | ist nicht gesetzt | + +Vergleiche sind **tolerant**. Zunächst wird eine Zahl versucht, und wenn das fehlschlägt, werden die Werte als getrimmter, Groß-/Kleinschreibung ignorierender Text verglichen. Eine Bedingung wie `finding.severity eq high` trifft daher auf einen Befund mit dem Schweregrad `High` zu, was fast immer das ist, was der Verfasser gemeint hat. + +#### Transformationen + +Eine Bedingungszeile kann den gelesenen Wert vor dem Vergleich nachbearbeiten. + +| Transform | Effect | +|-----------|--------| +| `int` | Ganzzahl | +| `float` | Dezimalzahl | +| `str` | Text | +| `first` | erster Eintrag einer Liste | +| `list` | als Liste | +| `join` | mit Kommas verbunden | +| `upper` | GROSSBUCHSTABEN | +| `lower` | Kleinbuchstaben | +| `strip` | getrimmt | +| `cwe_int` | CWE-Nummer | +| `severity` | normalisierter Schweregrad, sodass Werte im Stil von `critical`, `error` und `warning` aus verschiedenen Scannern auf die fünf Stufen von DefectDojo abgebildet werden | +| `numerical_severity` | sortierbarer Schweregrad-Code, für Vergleiche zur Reihenfolge | + +### Vorlagen + +Jede Einstellung, die als Nachricht, Notiz, Titel oder Wert bezeichnet ist, akzeptiert `{{ path }}`-Platzhalter, die pro Element aufgelöst werden: + +``` +{{finding.severity}}: {{finding.title}} ({{product.name}}) +``` + +Ein Pfad ohne Wert wird als leere Zeichenkette dargestellt. Eine Liste wird durch Kommas getrennt dargestellt. + +Vorlagen sehen außerdem einen `ctx`-Block mit Details zum Lauf selbst. Welche Schlüssel verfügbar sind, hängt vom Knoten ab, aber die gängigen sind: + +| Placeholder | Meaning | +|-------------|---------| +| `{{ctx.rule_name}}` | Der Name der Regel | +| `{{ctx.count}}` | Wie viele Befunde die Nachricht umfasst | +| `{{ctx.trigger}}` | Das Event, das den Lauf gestartet hat | +| `{{ctx.findings_html}}` | Die gerenderte Befundliste, im E-Mail-Knoten | +| `{{ctx.report_url}}` | Der Download-Link, im Berichts-Knoten | +| `{{ctx.template_name}}` | Der Name der Berichtsvorlage, im Berichts-Knoten | + +Vorlagen sind reine Textersetzung. Es gibt keine Auswertung von Ausdrücken, keine Codeausführung und keinen Attributzugriff auf Objekte irgendwo in einer Regelkonfiguration. + +## Eine Regel sicher testen + +Die empfohlene Reihenfolge für eine Regel, die irgendetwas sendet: + +1. Erstellen Sie den Graphen und verwenden Sie **Preview**, bis die Elementzahlen stimmen. +2. Speichern Sie ihn. Neue Regeln werden deaktiviert erstellt. +3. Belassen Sie den Modus auf **Simulate** und aktivieren Sie die Regel. +4. Lassen Sie sie laufen, lesen Sie dann **Deliveries** und prüfen Sie, ob die aufgezeichneten Payloads das sind, was Sie beabsichtigt haben. +5. Stellen Sie den Modus auf **Live** um. + +Simulate ist kein Teillauf. Jede Befundänderung im Graphen erfolgt im Simulationsmodus tatsächlich. Nur die ausgehenden Sendungen werden zurückgehalten. diff --git a/docs/content/automation/rules_engine_2/building_rules.es.md b/docs/content/automation/rules_engine_2/building_rules.es.md new file mode 100644 index 00000000000..5cb523a3c03 --- /dev/null +++ b/docs/content/automation/rules_engine_2/building_rules.es.md @@ -0,0 +1,198 @@ +--- +title: Creación de reglas +description: El editor de grafos, los disparadores, el alcance, las condiciones y + las plantillas de mensajes +weight: 2 +audience: pro +aliases: +- /es/automation/rules_engine_v2/building_rules/ +--- + +Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro. + +Una regla se construye en un lienzo. Se arrastran nodos desde una paleta, se conectan entre sí y cada uno se configura en un panel lateral. Esta página cubre las partes de ese proceso que son iguales sea cual sea el nodo que se use. Los propios nodos están en la [Referencia de nodos](../node_reference/). + +## El editor + +Abra **Rules Engine 2.0 > Todas las reglas** y elija **Nueva regla**, o abra una regla existente para editarla. + +La paleta está agrupada en cuatro categorías, que también es el orden en que los elementos fluyen a través de un grafo típico: + +| Categoría | Qué hacen los nodos | +|----------|-------------------| +| **Disparadores** | Deciden cuándo se activa la regla y qué Hallazgos entran en ella. Exactamente uno por grafo. | +| **Lógica** | Enrutan, limitan y deduplican los elementos que fluyen. | +| **Hallazgos** | Modifican los Hallazgos. | +| **Salida** | Envían algo hacia el exterior: un ticket, un mensaje, un informe. | + +La paleta se genera a partir del propio motor, de modo que lo que se ve en el editor es siempre exactamente lo que el motor puede ejecutar. + +### Reglas del grafo + +Un grafo se valida al guardarlo, y de nuevo antes de cada ejecución. Debe cumplir todo lo siguiente: + +* Tiene al menos un nodo. +* Tiene **exactamente un** nodo disparador. +* Cada nodo tiene un id único y no vacío de 100 caracteres o menos. +* Cada nodo es de un tipo que el motor conoce. +* Cada arista conecta dos nodos que existen. +* No contiene ningún ciclo. + +Un nodo sin nada conectado a su entrada es válido. Se ejecuta con una lista de entrada vacía, lo que normalmente significa que no hace nada. + +Un nodo con varias aristas entrantes recibe todas sus salidas concatenadas. + +### Vista previa antes de guardar + +**Vista previa** ejecuta en seco el grafo que se tiene actualmente en el lienzo y muestra la traza por nodo que produciría: cuántos elementos entraron en cada nodo, cuántos salieron por cada salida, y qué habría cambiado cada nodo. + +La vista previa ejecuta el motor real, no una simulación de él, y luego revierte todo. No se escribe nada, no se registra ninguna ejecución, y la salida se fuerza a simular lo que indique el modo de la regla. Es la forma más rápida de comprobar que las condiciones coinciden con lo esperado. + +La vista previa es la única ejecución que limita cuántos Hallazgos examina, para mantenerse rápida. Cuando trunca, lo indica en la traza. Una ejecución real no tiene ese límite. + +## Disparadores y alcance + +Todo grafo empieza con uno de tres disparadores. + +* **Ante un evento de Hallazgo** activa la regla cuando se crean, actualizan, cierran o reabren Hallazgos. Elija cuál de esos en el ajuste **Evento** del nodo, o `any` para los cuatro. +* **Según una programación** recorre los Hallazgos con una periodicidad recurrente. +* **Ejecución manual** recorre los Hallazgos cuando se pulsa **Ejecutar** en la regla. + +### Alcance + +Los tres disparadores admiten un **Alcance**, y el alcance es la forma de acotar lo que la regla considera. Es el mismo vocabulario de filtros que usa el Rules Engine original, alrededor de sesenta filtros que abarcan los Hallazgos y los objetos a su alrededor, de modo que un filtro que ya se sepa escribir allí significa lo mismo aquí. + +Vale la pena entender dos cosas sobre el alcance: + +* **El alcance se aplica por encima de la autorización, nunca en su lugar.** La regla se ejecuta como su propietario, de modo que el alcance acota un conjunto de Hallazgos ya autorizado. Dejar el alcance vacío no significa "todos los Hallazgos de la instancia", significa "todos los Hallazgos que el propietario de la regla puede ver". +* **Un alcance inválido hace fallar la ejecución en lugar de ampliarla.** Si una clave de filtro no existe, o un valor es uno que el filtro descartaría silenciosamente, la ejecución termina en error. Una regla que no hace nada es recuperable. Una regla que edita silenciosamente todos los Hallazgos de la instancia no lo es. + +Para un disparador de evento, el alcance actúa como una segunda puerta: los Hallazgos nombrados en el evento se comparan con él, y solo los que la superan entran en el grafo. + +### Programación + +Una regla cuyo disparador es **Según una programación** se programa desde la propia regla. Establecer la programación requiere Rule Edit, el mismo permiso que editar la regla, porque una regla activada por programación no hace nada en absoluto hasta que tiene una. + +Las programaciones están limitadas a marcas de cuarto de hora. El campo de minutos de una expresión cron debe ser `0`, `15`, `30` o `45`. + +Ejemplos válidos: + +``` +0 * * * * every hour, on the hour +15 9 * * * every day at 09:15 +0 15 * * 1 every Monday at 15:00 +30 2 * * * every day at 02:30 +``` + +## Cómo hacer referencia a los datos de un Hallazgo + +Hay dos lugares en una regla que leen valores del elemento que pasa por ella: las **condiciones** y las **plantillas**. Ambos usan las mismas rutas con puntos. + +``` +finding.severity +finding.title +finding.vulnerability_ids.0 +product.name +product_type.name +test.scan_type +ctx.rule_name +``` + +Una ruta que no se resuelve no produce ningún valor, en lugar de un error. + +### Campos disponibles + +Cada elemento lleva un conjunto fijo de campos de Hallazgo. Esta lista es un contrato, así que solo cambia de forma deliberada. + +| Grupo | Campos | +|-------|--------| +| Identidad | `id`, `title`, `hash_code`, `unique_id_from_tool` | +| Severidad y puntuación | `severity`, `numerical_severity`, `cvssv3`, `cvssv3_score`, `epss_score`, `epss_percentile`, `priority`, `risk`, `risk_score` | +| Texto | `description`, `mitigation`, `impact` | +| Estado | `active`, `verified`, `false_p`, `duplicate`, `is_mitigated`, `out_of_scope`, `risk_accepted`, `under_review` | +| Fechas | `date`, `mitigated`, `last_status_update`, `sla_expiration_date` | +| Ubicación | `file_path`, `line`, `component_name`, `component_version`, `service` | +| Clasificación | `cwe`, `vulnerability_ids`, `tags` | + +Además de `finding`, cada elemento lleva `test` (`id`, `title`, `scan_type`), `engagement` (`id`, `name`), `product` (`id`, `name`), `product_type` (`id`, `name`), y `ctx`. + +Las fechas son cadenas ISO-8601. Eso es deliberado: significa que `gt` y `lt` las ordenan correctamente como texto, de modo que `2026-07-28` es correctamente mayor que `2026-01-01`. + +`priority`, `risk` y `risk_score` provienen de la priorización de Pro. Un Hallazgo que aún no se ha puntuado no lleva ningún valor para ellos. + +### Condiciones + +Un nodo **Si / Filtro** contiene una lista de filas de condición. Cada fila es una ruta, un operador y un valor. **Coincidencia** decide si todas las filas deben cumplirse (`all`) o basta con una (`any`). + +| Operador | Significado | +|----------|---------| +| `eq` | es igual a | +| `neq` | no es igual a | +| `contains` | contiene | +| `not_contains` | no contiene | +| `in` | es uno de | +| `not_in` | no es uno de | +| `gt` | es mayor que | +| `gte` | es mayor o igual que | +| `lt` | es menor que | +| `lte` | es menor o igual que | +| `startswith` | comienza con | +| `endswith` | termina con | +| `exists` | está definido | +| `not_exists` | no está definido | + +Las comparaciones son **flexibles**. Primero se intenta como número, y si eso falla, los valores se comparan como texto recortado e insensible a mayúsculas/minúsculas. Así, una condición escrita como `finding.severity eq high` coincide con un Hallazgo cuya severidad es `High`, que es casi siempre lo que el autor quiso decir. + +#### Transformaciones + +Una fila de condición puede procesar el valor leído antes de compararlo. + +| Transformación | Efecto | +|-----------|--------| +| `int` | número entero | +| `float` | número decimal | +| `str` | texto | +| `first` | primer elemento de una lista | +| `list` | como lista | +| `join` | unido con comas | +| `upper` | MAYÚSCULAS | +| `lower` | minúsculas | +| `strip` | recortado | +| `cwe_int` | número de CWE | +| `severity` | severidad normalizada, de modo que valores de estilo `critical`, `error` y `warning` de distintos escáneres se convierten en los cinco niveles de DefectDojo | +| `numerical_severity` | código de severidad ordenable, para comparaciones de orden | + +### Plantillas + +Cualquier ajuste etiquetado como mensaje, nota, título o valor acepta marcadores `{{ path }}`, resueltos por elemento: + +``` +{{finding.severity}}: {{finding.title}} ({{product.name}}) +``` + +Una ruta sin valor se representa como una cadena vacía. Una lista se representa unida con comas. + +Las plantillas también ven un bloque `ctx` con detalles sobre la propia ejecución. Las claves disponibles dependen del nodo, pero las habituales son: + +| Marcador | Significado | +|-------------|---------| +| `{{ctx.rule_name}}` | El nombre de la regla | +| `{{ctx.count}}` | Cuántos Hallazgos cubre el mensaje | +| `{{ctx.trigger}}` | El evento que inició la ejecución | +| `{{ctx.findings_html}}` | La lista de Hallazgos renderizada, en el nodo de correo electrónico | +| `{{ctx.report_url}}` | El enlace de descarga, en el nodo de informe | +| `{{ctx.template_name}}` | El nombre de la plantilla de informe, en el nodo de informe | + +Las plantillas son sustitución simple. No hay evaluación de expresiones, ni ejecución de código, ni acceso a atributos de objetos en ninguna parte de la configuración de una regla. + +## Cómo probar una regla de forma segura + +El orden recomendado para una regla que envía algo: + +1. Construya el grafo y use **Vista previa** hasta que los recuentos de elementos parezcan correctos. +2. Guárdela. Las reglas nuevas se crean desactivadas. +3. Deje el modo en **Simulación** y active la regla. +4. Déjela ejecutarse, luego revise **Entregas** y compruebe que los payloads registrados son los previstos. +5. Cambie el modo a **En vivo**. + +Simulación no es una ejecución parcial. Cada edición de Hallazgo del grafo ocurre de verdad en modo simulación. Solo se retienen los envíos salientes. diff --git a/docs/content/automation/rules_engine_2/building_rules.fr.md b/docs/content/automation/rules_engine_2/building_rules.fr.md new file mode 100644 index 00000000000..7c501ed757a --- /dev/null +++ b/docs/content/automation/rules_engine_2/building_rules.fr.md @@ -0,0 +1,198 @@ +--- +title: Créer des règles +description: L'éditeur de graphe, les déclencheurs, le périmètre, les conditions et + les modèles de message +weight: 2 +audience: pro +aliases: +- /fr/automation/rules_engine_v2/building_rules/ +--- + +Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro. + +Une règle est construite sur un canevas. Vous glissez des nœuds depuis une palette, vous les reliez entre eux, et vous configurez chacun d'eux dans un panneau latéral. Cette page couvre les aspects de ce processus qui sont identiques quels que soient les nœuds utilisés. Les nœuds eux-mêmes sont décrits dans la [Référence des nœuds](../node_reference/). + +## L'éditeur + +Ouvrez **Rules Engine 2.0 > All Rules** et choisissez **New Rule** (Nouvelle règle), ou ouvrez une règle existante pour la modifier. + +La palette est organisée en quatre catégories, qui correspondent aussi à l'ordre dans lequel les éléments traversent un graphe typique : + +| Catégorie | Ce que font les nœuds | +|----------|-------------------| +| **Triggers** (Déclencheurs) | Décident quand la règle se réveille et quelles Constatations y entrent. Exactement un par graphe. | +| **Logic** (Logique) | Acheminent, limitent et dédupliquent les éléments qui circulent. | +| **Findings** (Constatations) | Modifient les Constatations. | +| **Egress** (Sortie) | Envoient quelque chose vers l'extérieur : un ticket, un message, un rapport. | + +La palette est générée à partir du moteur lui-même, de sorte que ce que vous voyez dans l'éditeur est toujours exactement ce que le moteur peut exécuter. + +### Règles du graphe + +Un graphe est vérifié lors de son enregistrement, puis à nouveau avant chaque exécution. Il doit satisfaire toutes les conditions suivantes : + +* Il comporte au moins un nœud. +* Il comporte **exactement un** nœud déclencheur. +* Chaque nœud possède un identifiant unique et non vide de 100 caractères ou moins. +* Chaque nœud est d'un type que le moteur connaît. +* Chaque arête relie deux nœuds qui existent. +* Il ne contient aucun cycle. + +Un nœud auquel rien n'est relié est valide. Il s'exécute avec une liste d'entrée vide, ce qui, en général, signifie qu'il ne fait rien. + +Un nœud comportant plusieurs arêtes entrantes reçoit la concaténation de toutes leurs sorties. + +### Prévisualiser avant d'enregistrer + +**Preview** (Aperçu) exécute à blanc le graphe actuellement présent sur le canevas et affiche la trace par nœud qu'il produirait : combien d'éléments sont entrés dans chaque nœud, combien en sont sortis par chaque sortie, et ce que chaque nœud aurait modifié. + +Preview exécute le véritable moteur, et non une simulation de celui-ci, puis annule l'ensemble. Rien n'est écrit, aucune exécution n'est enregistrée, et la sortie est forcée à simuler quel que soit le mode indiqué par la règle. C'est le moyen le plus rapide de vérifier que vos conditions correspondent à ce que vous attendiez. + +Preview est la seule exécution qui plafonne le nombre de Constatations examinées, afin de rester rapide. Lorsqu'elle tronque, elle le signale dans la trace. Une exécution réelle n'a pas une telle limite. + +## Déclencheurs et périmètre + +Chaque graphe démarre avec l'un des trois déclencheurs suivants. + +* **On Finding Event** (Sur événement de Constatation) réveille la règle lorsque des Constatations sont créées, modifiées, clôturées ou rouvertes. Choisissez lequel de ces événements dans le paramètre **Event** (Événement) du nœud, ou `any` pour les quatre. +* **On a Schedule** (Sur une planification) balaie les Constatations selon une planification récurrente. +* **Manual Run** (Exécution manuelle) balaie les Constatations lorsque vous appuyez sur **Run** (Exécuter) sur la règle. + +### Périmètre + +Les trois déclencheurs acceptent un **Scope** (Périmètre), et le périmètre est ce qui vous permet de restreindre ce que la règle prend en compte. C'est le même vocabulaire de filtres que celui utilisé par le Rules Engine d'origine, soit une soixantaine de filtres couvrant les Constatations et les objets qui les entourent ; un filtre que vous savez déjà écrire là-bas signifie donc la même chose ici. + +Deux points concernant le périmètre méritent d'être compris : + +* **Le périmètre s'applique par-dessus l'autorisation, jamais à sa place.** La règle s'exécute en tant que son propriétaire, de sorte que le périmètre restreint un ensemble de Constatations déjà autorisé. Laisser le périmètre vide ne signifie pas « toutes les Constatations de l'instance », mais « toutes les Constatations que le propriétaire de la règle peut voir ». +* **Un périmètre invalide fait échouer l'exécution plutôt que de l'élargir.** Si une clé de filtre n'existe pas, ou si une valeur est de celles que le filtre rejetterait silencieusement, l'exécution se termine en erreur. Une règle qui ne fait rien est récupérable. Une règle qui modifie silencieusement toutes les Constatations de l'instance ne l'est pas. + +Pour un déclencheur d'événement, le périmètre agit comme une seconde porte : les Constatations nommées dans l'événement y sont confrontées, et seules celles qui passent entrent dans le graphe. + +### Planification + +Une règle dont le déclencheur est **On a Schedule** est planifiée depuis la règle elle-même. Définir la planification nécessite Rule Edit, la même permission que pour modifier la règle, car une règle déclenchée par planification ne fait absolument rien tant qu'elle n'en a pas une. + +Les planifications sont limitées aux quarts d'heure. Le champ des minutes d'une expression cron doit être `0`, `15`, `30` ou `45`. + +Exemples valides : + +``` +0 * * * * every hour, on the hour +15 9 * * * every day at 09:15 +0 15 * * 1 every Monday at 15:00 +30 2 * * * every day at 02:30 +``` + +## Faire référence aux données de Constatation + +Deux endroits d'une règle lisent des valeurs à partir de l'élément qui les traverse : les **conditions** et les **modèles**. Tous deux utilisent les mêmes chemins pointés. + +``` +finding.severity +finding.title +finding.vulnerability_ids.0 +product.name +product_type.name +test.scan_type +ctx.rule_name +``` + +Un chemin qui ne se résout pas ne produit aucune valeur plutôt qu'une erreur. + +### Champs disponibles + +Chaque élément porte un ensemble fixe de champs de Constatation. Cette liste est un contrat, elle ne change donc que délibérément. + +| Groupe | Champs | +|-------|--------| +| Identité | `id`, `title`, `hash_code`, `unique_id_from_tool` | +| Sévérité et notation | `severity`, `numerical_severity`, `cvssv3`, `cvssv3_score`, `epss_score`, `epss_percentile`, `priority`, `risk`, `risk_score` | +| Texte | `description`, `mitigation`, `impact` | +| Statut | `active`, `verified`, `false_p`, `duplicate`, `is_mitigated`, `out_of_scope`, `risk_accepted`, `under_review` | +| Dates | `date`, `mitigated`, `last_status_update`, `sla_expiration_date` | +| Emplacement | `file_path`, `line`, `component_name`, `component_version`, `service` | +| Classification | `cwe`, `vulnerability_ids`, `tags` | + +En plus de `finding`, chaque élément porte `test` (`id`, `title`, `scan_type`), `engagement` (`id`, `name`), `product` (`id`, `name`), `product_type` (`id`, `name`), et `ctx`. + +Les dates sont des chaînes ISO-8601. C'est délibéré : cela signifie que `gt` et `lt` les ordonnent correctement en tant que texte, de sorte que `2026-07-28` est correctement supérieur à `2026-01-01`. + +`priority`, `risk` et `risk_score` proviennent de la priorisation de Pro. Une Constatation qui n'a pas encore été notée ne porte aucune valeur pour ces champs. + +### Conditions + +Un nœud **If / Filter** contient une liste de lignes de condition. Chaque ligne est un chemin, un opérateur et une valeur. **Match** (Correspondance) détermine si toutes les lignes doivent être vraies (`all`) ou une seule d'entre elles (`any`). + +| Opérateur | Signification | +|----------|---------| +| `eq` | est égal à | +| `neq` | n'est pas égal à | +| `contains` | contient | +| `not_contains` | ne contient pas | +| `in` | fait partie de | +| `not_in` | ne fait pas partie de | +| `gt` | est supérieur à | +| `gte` | est supérieur ou égal à | +| `lt` | est inférieur à | +| `lte` | est inférieur ou égal à | +| `startswith` | commence par | +| `endswith` | se termine par | +| `exists` | est défini | +| `not_exists` | n'est pas défini | + +Les comparaisons sont **souples**. Un nombre est d'abord tenté, et si cela échoue, les valeurs sont comparées comme du texte, sans tenir compte de la casse et après suppression des espaces superflus. Ainsi, une condition écrite comme `finding.severity eq high` correspond à une Constatation dont la sévérité est `High`, ce qui est presque toujours ce que l'auteur voulait dire. + +#### Transformations + +Une ligne de condition peut post-traiter la valeur qu'elle a lue avant de la comparer. + +| Transformation | Effet | +|-----------|--------| +| `int` | nombre entier | +| `float` | nombre décimal | +| `str` | texte | +| `first` | première entrée d'une liste | +| `list` | sous forme de liste | +| `join` | jointe par des virgules | +| `upper` | MAJUSCULES | +| `lower` | minuscules | +| `strip` | espaces superflus supprimés | +| `cwe_int` | numéro CWE | +| `severity` | sévérité normalisée, de sorte que des valeurs comme `critical`, `error` et `warning`, propres à différents scanners, soient ramenées aux cinq niveaux de DefectDojo | +| `numerical_severity` | code de sévérité triable, pour ordonner les comparaisons | + +### Modèles + +Tout paramètre étiqueté comme message, note, titre ou valeur accepte des espaces réservés `{{ path }}`, résolus par élément : + +``` +{{finding.severity}}: {{finding.title}} ({{product.name}}) +``` + +Un chemin sans valeur s'affiche comme une chaîne vide. Une liste s'affiche jointe par des virgules. + +Les modèles voient également un bloc `ctx` transportant des détails sur l'exécution elle-même. Les clés disponibles dépendent du nœud, mais les plus courantes sont : + +| Espace réservé | Signification | +|-------------|---------| +| `{{ctx.rule_name}}` | Le nom de la règle | +| `{{ctx.count}}` | Le nombre de Constatations couvertes par le message | +| `{{ctx.trigger}}` | L'événement qui a déclenché l'exécution | +| `{{ctx.findings_html}}` | La liste des Constatations mise en forme, dans le nœud d'e-mail | +| `{{ctx.report_url}}` | Le lien de téléchargement, dans le nœud de rapport | +| `{{ctx.template_name}}` | Le nom du modèle de rapport, dans le nœud de rapport | + +Les modèles reposent sur une simple substitution. Il n'y a aucune évaluation d'expression, aucune exécution de code, et aucun accès aux attributs d'objets nulle part dans la configuration d'une règle. + +## Tester une règle en toute sécurité + +L'ordre recommandé pour une règle qui envoie quelque chose : + +1. Construisez le graphe et utilisez **Preview** jusqu'à ce que les décomptes d'éléments semblent corrects. +2. Enregistrez-la. Les nouvelles règles sont créées désactivées. +3. Laissez le mode sur **Simulate** et activez la règle. +4. Laissez-la s'exécuter, puis consultez **Deliveries** et vérifiez que les charges utiles enregistrées correspondent à ce que vous vouliez. +5. Basculez le mode sur **Live**. + +Simulate n'est pas une exécution partielle. Chaque modification de Constatation dans le graphe se produit réellement en mode simulation. Seuls les envois sortants sont retenus. diff --git a/docs/content/automation/rules_engine_2/building_rules.ja.md b/docs/content/automation/rules_engine_2/building_rules.ja.md new file mode 100644 index 00000000000..99a0d2d71d0 --- /dev/null +++ b/docs/content/automation/rules_engine_2/building_rules.ja.md @@ -0,0 +1,197 @@ +--- +title: ルールの作成 +description: グラフエディター、トリガー、スコープ、条件、メッセージテンプレートについて +weight: 2 +audience: pro +aliases: +- /ja/automation/rules_engine_v2/building_rules/ +--- + +注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。 + +ルールはキャンバス上で構築します。パレットからノードをドラッグして配線し、それぞれをサイドパネルで設定します。このページでは、どのノードを使う場合でも共通するプロセスの部分を扱います。ノード自体については [Node Reference](../node_reference/) を参照してください。 + +## エディター + +**Rules Engine 2.0 > All Rules** を開き、**New Rule** を選択するか、既存のルールを開いて編集します。 + +パレットは4つのカテゴリーにグループ分けされており、これは一般的なグラフの中を項目が流れていく順序でもあります。 + +| カテゴリー | ノードの役割 | +|----------|-------------------| +| **Triggers** | ルールがいつ起動するか、どの Finding が入ってくるかを決定します。グラフごとにちょうど1つです。 | +| **Logic** | 流れてくる項目のルーティング、制限、重複排除を行います。 | +| **Findings** | Finding を変更します。 | +| **Egress** | チケット、メッセージ、レポートなど、外部に何かを送信します。 | + +パレットはエンジン自体から生成されているため、エディターに表示される内容は常にエンジンが実行できる内容そのものです。 + +### グラフのルール + +グラフは保存時、およびすべての実行前に検証されます。次のすべてを満たしている必要があります。 + +* 少なくとも1つのノードを持つこと。 +* トリガーノードを**ちょうど1つ**持つこと。 +* すべてのノードが、一意で空でない、100文字以下の id を持つこと。 +* すべてのノードが、エンジンが認識するタイプであること。 +* すべてのエッジが、実在する2つのノードを接続していること。 +* 循環を含まないこと。 + +何も配線されていないノードは合法です。空の入力リストで実行され、通常は何もしないことを意味します。 + +複数の入力エッジを持つノードは、それらすべての出力を連結して受け取ります。 + +### 保存前のプレビュー + +**Preview** は、現在キャンバス上にあるグラフをドライランし、それが生成するであろうノードごとのトレースを表示します。各ノードに入った項目数、各出力から出ていった項目数、そして各ノードが何を変更したはずかがわかります。 + +Preview は、シミュレーションではなく実際のエンジンを実行し、その後すべてをロールバックします。何も書き込まれず、Run も記録されず、Egress はルールのモードに関わらず Simulate するよう強制されます。これは、条件が意図した通りに一致しているかを確認する最も速い方法です。 + +Preview は、高速さを保つために処理対象の Finding 件数に上限がある唯一の実行です。切り詰めが発生した場合はトレースにその旨が記載されます。実際の Run にはそのような上限はありません。 + +## トリガーとスコープ + +すべてのグラフは、3種類のトリガーのいずれかから始まります。 + +* **On Finding Event** は、Finding が作成、更新、クローズ、再オープンされたときにルールを起動します。そのうちどれにするかはノードの **Event** 設定で選択します。4つすべてを対象にするには `any` を指定します。 +* **On a Schedule** は、繰り返しスケジュールで Finding を走査します。 +* **Manual Run** は、ルール上で **Run** を押したときに Finding を走査します。 + +### スコープ + +3種類のトリガーはすべて **Scope** を受け取り、スコープはルールが対象とする範囲を絞り込む手段です。これは従来の Rules Engine が使うのと同じフィルター語彙であり、Finding とその周辺オブジェクトにまたがるおよそ60種類のフィルターです。そのため、そちらで既に書き方を知っているフィルターは、ここでも同じ意味を持ちます。 + +スコープについて理解しておく価値のある点が2つあります。 + +* **スコープは認可の上に適用されるものであり、認可の代わりにはなりません。** ルールはその所有者として実行されるため、スコープは既に認可された Finding の集合をさらに絞り込みます。スコープを空のままにすることは「インスタンス内のすべての Finding」を意味するのではなく、「ルール所有者が閲覧できるすべての Finding」を意味します。 +* **無効なスコープは、範囲を広げるのではなく Run を失敗させます。** フィルターのキーが存在しない場合や、フィルターが黙って破棄してしまうような値である場合、Run はエラーになります。何もしないルールは復旧可能です。インスタンス内のすべての Finding を静かに編集してしまうルールは復旧できません。 + +イベントトリガーの場合、スコープは第2の関門として機能します。イベントに含まれる Finding はスコープと照合され、それを通過したものだけがグラフに入ります。 + +### スケジューリング + +トリガーが **On a Schedule** であるルールは、ルール自身からスケジュールを設定します。スケジュールの設定には、ルールの編集と同じ権限である Rule Edit が必要です。スケジュールトリガーのルールは、スケジュールが設定されるまで一切何もしないためです。 + +スケジュールは15分刻みの時刻に限られます。cron 式の分フィールドは `0`、`15`、`30`、`45` のいずれかでなければなりません。 + +有効な例: + +``` +0 * * * * every hour, on the hour +15 9 * * * every day at 09:15 +0 15 * * 1 every Monday at 15:00 +30 2 * * * every day at 02:30 +``` + +## Finding データの参照 + +ルール内の2箇所、**conditions** と **templates** は、そこを流れる item から値を読み取ります。どちらも同じドットパス記法を使います。 + +``` +finding.severity +finding.title +finding.vulnerability_ids.0 +product.name +product_type.name +test.scan_type +ctx.rule_name +``` + +解決できないパスは、エラーではなく値なしという結果になります。 + +### 利用可能なフィールド + +各 item は、固定された Finding フィールドの集合を保持します。この一覧はいわば契約であり、意図的な場合にのみ変更されます。 + +| グループ | フィールド | +|-------|--------| +| 識別情報 | `id`, `title`, `hash_code`, `unique_id_from_tool` | +| 深刻度とスコアリング | `severity`, `numerical_severity`, `cvssv3`, `cvssv3_score`, `epss_score`, `epss_percentile`, `priority`, `risk`, `risk_score` | +| テキスト | `description`, `mitigation`, `impact` | +| ステータス | `active`, `verified`, `false_p`, `duplicate`, `is_mitigated`, `out_of_scope`, `risk_accepted`, `under_review` | +| 日付 | `date`, `mitigated`, `last_status_update`, `sla_expiration_date` | +| 位置情報 | `file_path`, `line`, `component_name`, `component_version`, `service` | +| 分類 | `cwe`, `vulnerability_ids`, `tags` | + +`finding` に加えて、各 item は `test`(`id`, `title`, `scan_type`)、`engagement`(`id`, `name`)、`product`(`id`, `name`)、`product_type`(`id`, `name`)、そして `ctx` を保持します。 + +日付は ISO-8601 形式の文字列です。これは意図的な設計で、`gt` や `lt` がテキストとして正しく順序付けできることを意味します。そのため `2026-07-28` は `2026-01-01` より正しく大きいと判定されます。 + +`priority`、`risk`、`risk_score` は Pro の優先度付け機能から得られます。まだスコアリングされていない Finding には、これらの値は存在しません。 + +### Conditions + +**If / Filter** ノードは、条件行のリストを保持します。各行はパス、演算子、値から構成されます。**Match** は、すべての行を満たす必要があるか(`all`)、いずれか1つでよいか(`any`)を決定します。 + +| 演算子 | 意味 | +|----------|---------| +| `eq` | 等しい | +| `neq` | 等しくない | +| `contains` | 含む | +| `not_contains` | 含まない | +| `in` | いずれかに一致する | +| `not_in` | いずれにも一致しない | +| `gt` | より大きい | +| `gte` | 以上 | +| `lt` | より小さい | +| `lte` | 以下 | +| `startswith` | で始まる | +| `endswith` | で終わる | +| `exists` | 設定されている | +| `not_exists` | 設定されていない | + +比較は**緩やか**です。まず数値として比較を試み、それが失敗した場合はトリムされた大文字小文字を区別しないテキストとして比較されます。そのため `finding.severity eq high` と書かれた条件は、深刻度が `High` である Finding に一致します。これはほとんどの場合、作成者の意図通りです。 + +#### Transforms + +条件行は、比較する前に読み取った値を後処理できます。 + +| Transform | 効果 | +|-----------|--------| +| `int` | 整数 | +| `float` | 小数 | +| `str` | テキスト | +| `first` | リストの最初の要素 | +| `list` | リストとして扱う | +| `join` | カンマ区切りで結合 | +| `upper` | 大文字化 | +| `lower` | 小文字化 | +| `strip` | 前後の空白を除去 | +| `cwe_int` | CWE 番号 | +| `severity` | 正規化された深刻度。これにより、スキャナーごとに異なる `critical`、`error`、`warning` のような値が DefectDojo の5段階の深刻度にマッピングされます | +| `numerical_severity` | 順序比較のための、ソート可能な深刻度コード | + +### Templates + +メッセージ、メモ、タイトル、値としてラベル付けされた設定であれば、`{{ path }}` プレースホルダーを使用でき、item ごとに解決されます。 + +``` +{{finding.severity}}: {{finding.title}} ({{product.name}}) +``` + +値のないパスは空文字列としてレンダリングされます。リストはカンマ区切りでレンダリングされます。 + +Templates は、Run 自体に関する詳細を保持する `ctx` ブロックも参照できます。利用可能なキーはノードによって異なりますが、共通するものは次の通りです。 + +| プレースホルダー | 意味 | +|-------------|---------| +| `{{ctx.rule_name}}` | ルールの名前 | +| `{{ctx.count}}` | メッセージが対象とする Finding の件数 | +| `{{ctx.trigger}}` | Run を開始したイベント | +| `{{ctx.findings_html}}` | email ノードにおける、レンダリングされた Finding のリスト | +| `{{ctx.report_url}}` | report ノードにおける、ダウンロードリンク | +| `{{ctx.template_name}}` | report ノードにおける、レポートテンプレート名 | + +Templates は単純な置換にすぎません。ルール設定のどこにも、式の評価、コードの実行、オブジェクトへの属性アクセスは存在しません。 + +## ルールを安全にテストする + +何かを送信するルールについて推奨される手順は次の通りです。 + +1. グラフを構築し、項目数が正しく見えるまで **Preview** を使います。 +2. 保存します。新しいルールは無効な状態で作成されます。 +3. モードを **Simulate** のままにしてルールを有効化します。 +4. 実行させ、**Deliveries** を確認して、記録されたペイロードが意図した通りであるかを確認します。 +5. モードを **Live** に切り替えます。 + +Simulate は部分的な実行ではありません。グラフ内のすべての Finding の編集は、Simulate モードでも実際に行われます。抑止されるのは外向きの送信だけです。 diff --git a/docs/content/automation/rules_engine_2/configuration.de.md b/docs/content/automation/rules_engine_2/configuration.de.md new file mode 100644 index 00000000000..6f58ca5bb20 --- /dev/null +++ b/docs/content/automation/rules_engine_2/configuration.de.md @@ -0,0 +1,141 @@ +--- +title: Konfiguration +description: Einstellungen auf Deployment-Ebene für Rules Engine 2.0 +weight: 7 +audience: pro +aliases: +- /de/automation/rules_engine_v2/configuration/ +--- + +Note: Rules Engine 2.0 is a DefectDojo Pro-only feature. + +Rules Engine 2.0 funktioniert von Haus aus. Die Einstellungen auf dieser Seite richten sich an Deployments, die Durchsatz, Aufbewahrung oder die Richtlinie für ausgehenden Netzwerkverkehr anpassen müssen. Alle werden auf dieselbe Weise angewendet wie jede andere DefectDojo-Einstellung (siehe [Konfiguration](/get_started/open_source/configuration/)). + +Rules Engine 2.0 wird getrennt von der ursprünglichen Rules Engine konfiguriert. Die beiden Engines teilen sich kein Tuning, sodass eine `DD_RULES_ENGINE_*`-Einstellung sich nicht auf Rules Engine 2.0 auswirkt und eine `DD_RULES_V2_*`-Einstellung sich nicht auf die ursprüngliche Engine auswirkt. + +```python +DD_RULES_V2_EVENT_BATCH=(int, 500), +DD_RULES_V2_CHUNK_SIZE=(int, 1000), +DD_RULES_V2_STALLED_AFTER_MINUTES=(int, 30), +DD_RULES_V2_RUN_TIME_LIMIT_MINUTES=(int, 360), +DD_RULES_V2_ALLOW_PRIVATE_EGRESS=(bool, False), +DD_RULES_V2_DELIVERY_RETENTION_DAYS=(int, 180), +DD_RULES_V2_RUN_RETENTION_DAYS=(int, 180), +DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS=(int, 8000), +DD_RULES_V2_MAX_PER_ITEM_SENDS=(int, 1000), +``` + +## Durchsatz + +### Befunde pro Event (`DD_RULES_V2_EVENT_BATCH`) + +**Standard: 500.** + +Wie viele Befund-IDs ein einzelnes Event trägt. Events überschreiten eine asynchrone Grenze und werden daher klein genug gehalten, um eine günstige Nachricht zu bleiben. Ein größerer Schreibvorgang fächert sich in mehrere Events auf, von denen jedes zu einem eigenen Lauf wird. + +Eine Erhöhung führt zu weniger, größeren Läufen. Eine Verringerung führt zu mehr, kleineren. + +### Befunde pro Chunk (`DD_RULES_V2_CHUNK_SIZE`) + +**Standard: 1000.** + +Wie viele Befunde ein Lauf gleichzeitig im Speicher hält. Ein Lauf wird in Chunks verarbeitet, daher ist dies ein Speicherregler und **keine** Obergrenze für das, was eine Regel verarbeitet: Eine Regel verarbeitet immer alles, was auf ihren Geltungsbereich passt. + +Ein Envelope ist rund 2,7 KB pro Befund groß, sodass der Standardwert jeweils einige Megabyte belegt. Eine Erhöhung tauscht Speicher gegen weniger Round-Trips ein. Eine Verringerung bewirkt das Gegenteil. + +### Envelope-Textobergrenze (`DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS`) + +**Standard: 8000. Auf 0 setzen, um zu deaktivieren.** + +Wie viele Zeichen von `description`, `mitigation` und `impact` ein Element trägt. + +Diese drei Felder machen den größten Teil der Envelope-Größe aus. Die Obergrenze existiert für den ungewöhnlichen Fall eines Befunds mit einer sehr großen Beschreibung, bei dem ein voller Chunk davon deutlich größer wäre, als die Chunk-Größe vermuten lässt. Sie ist großzügig genug bemessen, dass eine gewöhnliche Instanz sie nie bemerkt. + +Beachten Sie, dass dies beeinflusst, was Bedingungen und Vorlagen sehen können. Eine Bedingung, die gegen das Ende einer sehr langen Beschreibung prüft, sieht keinen Text jenseits der Obergrenze. + +## Lebensdauer eines Laufs + +### Stillstandsfenster (`DD_RULES_V2_STALLED_AFTER_MINUTES`) + +**Standard: 30.** + +Wie lange ein Lauf ohne Heartbeat auskommen darf, bevor er als abgebrochen behandelt, als fehlerhaft markiert und seine regelbezogene Sperre freigegeben wird. + +Ein Lauf setzt nach jedem Chunk einen Heartbeat, daher wird dies ab dem letzten Heartbeat gemessen und nicht ab dem Start. Ein langer Durchlauf, der weiterhin Fortschritte macht, wird niemals mit einem abgestürzten Worker verwechselt, wodurch das Fenster kurz bleiben kann. + +### Zeitlimit für Läufe (`DD_RULES_V2_RUN_TIME_LIMIT_MINUTES`) + +**Standard: 360, also sechs Stunden.** + +Die längste Zeit, die ein einzelner Lauf in Anspruch nehmen darf, bevor der Worker ihn beendet. + +Dies ist ein Schutz gegen eine Regel, die nie fertig würde, während sie einen Worker-Slot und die Ausführungssperre ihrer Regel blockiert. Er ist bewusst großzügig bemessen, denn ein in Chunks unterteilter Durchlauf über einen sehr großen Geltungsbereich ist genau die Art von Arbeitslast, für die diese Engine gebaut ist. + +## Aufbewahrung + +Zwei Jobs begrenzen die drei Tabellen, die durch diese Funktion wachsen. Beide sind standardmäßig auf **180 Tage** eingestellt, und beide akzeptieren `0`, um das Bereinigen vollständig zu deaktivieren. + +Die Aufbewahrung wird im Produkt sichtbar gemacht statt implizit zu bleiben: Die API liefert sowohl das Zeitfenster als auch das Datum, an dem ein bestimmter Datensatz gelöscht wird, und die Seiten, die einen Lauf oder eine Zustellung anzeigen, nennen dies in einem Satz. Das Datum wird beim Lesen berechnet, sodass eine Änderung des Zeitfensters sofort wirksam wird und nicht nur auf neue Datensätze angewendet wird. + +### `DD_RULES_V2_DELIVERY_RETENTION_DAYS` + +**Standard: 180.** + +Wie viele Tage eine abgeschlossene Zustellung aufbewahrt wird. + +Dies ist die am schnellsten wachsende Tabelle dieser Funktion. Ein Egress-Knoten pro Befund schreibt pro Lauf bis zu einem Chunk voller Zeilen, auch im Simulate-Modus. Erhöhen Sie den Wert, wenn Sie eine längere Prüfspur für ausgehende Vorgänge benötigen, und verringern Sie ihn, wenn das Volumen ein Problem darstellt. + +### `DD_RULES_V2_RUN_RETENTION_DAYS` + +**Standard: 180.** + +Wie viele Tage ein abgeschlossener Lauf aufbewahrt wird, zusammen mit seinen Zeilen pro Knoten und der Herkunftsnachweis (Provenance) seiner Befunde. + +Die Lauf-Seite wächst schneller als die Zustellungen, da die Provenance eine Zeile pro Befund, pro Mutationsknoten und pro Lauf umfasst. Eine stündliche Regel über einen großen Geltungsbereich erzeugt davon eine Menge. + +Ein Lauf, der noch Zustellungen enthält, wird aufbewahrt, bis diese bereinigt sind, sodass ein kürzeres Lauf-Zeitfenster als Zustellungs-Zeitfenster nichts verwaist zurücklässt. + +## Validierung des ausgehenden Ziels + +Zwei Knoteneinstellungen nehmen ein Ziel als Freitext entgegen statt aus einem konfigurierten Objekt: die **URL** bei Call a Webhook und das **To** bei Send an Email. Beide werden beim Speichern der Regel validiert. + +Für Webhook-URLs: + +* Nur `http` und `https` werden akzeptiert. Andere Schemata werden grundsätzlich abgelehnt. +* Die URL muss einen Host enthalten. +* Standardmäßig wird ein Host abgelehnt, der zu einer Loopback-, Link-Local-, privaten, reservierten oder Multicast-Adresse aufgelöst wird. + +Bei E-Mail-Adressen wird eine leere Adresse abgelehnt, ebenso eine, die einen Zeilenumbruch enthält, was einer Header-Injection entspricht. + +Der Grund für die Netzwerkprüfung ist, dass der Worker, der die Anfrage sendet, sich normalerweise innerhalb Ihres Clusters befindet und weit mehr vom internen Netzwerk erreichen kann als die Person, die die Regel verfasst. Ohne die Prüfung ist eine Freitext-URL eine Primitive für Request Forgery: Richten Sie sie auf einen Metadatendienst oder einen internen Admin-Port, und die Antwort kommt über das Zustellungsprotokoll zurück. + +Dies ist Defence-in-Depth und nicht die einzige Kontrolle. Rule Edit ist ohnehin nahezu administrativ. Es lohnt sich dennoch, denn so ist der Schadensradius einer zu großzügig vergebenen Rolle nicht „jeden internen HTTP-Endpunkt lesen“, und ein Tippfehler schlägt beim Speichern mit einer klaren Meldung fehl statt beim Senden mit einem Verbindungsfehler. + +### Private Adressen zulassen (`DD_RULES_V2_ALLOW_PRIVATE_EGRESS`) + +**Standard: aus.** + +Schaltet die Netzwerkadressprüfung aus, sodass Webhooks an Loopback-, Link-Local- und private Adressen senden dürfen. Schema- und Formvalidierung gelten weiterhin. + +Aktivieren Sie dies, wenn Sie tatsächlich einen Webhook an etwas mit einer privaten Adresse senden, was bei einem selbst gehosteten Chat- oder Webhook-Empfänger normalerweise der Fall ist. + +## Obergrenze für Sendungen pro Befund + +### `DD_RULES_V2_MAX_PER_ITEM_SENDS` + +**Standard: 1000. Auf 0 setzen, um die Obergrenze aufzuheben.** + +Die maximale Anzahl an Sendungen pro Befund, die ein einzelner Egress-Knoten in einem Lauf aufzeichnet. + +Ein Knoten mit aktivierter Option **One Message per Finding** erzeugt eine Zustellungszeile und eine eingereihte Aufgabe pro Befund. Da ein Lauf keine Obergrenze für Elemente hat, würde eine Regel mit sehr breitem Geltungsbereich und aktiviertem Senden pro Befund andernfalls eine unbegrenzte Anzahl von beidem bedeuten. + +Über diese Obergrenze hinaus zeichnet der Knoten ein **sichtbares Überspringen** auf, das angibt, für wie viele Befunde nichts gesendet wurde. Der Lauf schlägt dadurch nicht fehl und stoppt auch nicht stillschweigend. + +## Verwandte Einstellungen + +Einige Rules-Engine-2.0-Knoten verwenden systemweite Integrationskonfiguration statt einer eigenen: + +* **Send a Slack Message** verwendet das System-Slack-Token und greift auf den System-Slack-Kanal zurück, wenn der Knoten keinen nennt. +* **Send a Microsoft Teams Message** verwendet den Microsoft-Teams-Webhook aus den Systemeinstellungen. +* **Create a JIRA Issue** verwendet die JIRA-Konfiguration des Produkts für Zusammenfassung, Beschreibung und Priorität. +* **Raise an In-App Alert** berücksichtigt die eigene **Rules Engine Match**-Benachrichtigungseinstellung jedes Empfängers. diff --git a/docs/content/automation/rules_engine_2/configuration.es.md b/docs/content/automation/rules_engine_2/configuration.es.md new file mode 100644 index 00000000000..93c8d5027d9 --- /dev/null +++ b/docs/content/automation/rules_engine_2/configuration.es.md @@ -0,0 +1,141 @@ +--- +title: Configuración +description: Ajustes a nivel de despliegue para Rules Engine 2.0 +weight: 7 +audience: pro +aliases: +- /es/automation/rules_engine_v2/configuration/ +--- + +Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro. + +Rules Engine 2.0 funciona de fábrica. Los ajustes de esta página son para despliegues que necesitan afinar el rendimiento, la retención o la política de red saliente. Todos se aplican de la misma manera que cualquier otro ajuste de DefectDojo (consulte [Configuración](/get_started/open_source/configuration/)). + +Rules Engine 2.0 se configura por separado del Rules Engine original. Los dos motores no comparten ningún ajuste, de modo que un ajuste `DD_RULES_ENGINE_*` no afecta a Rules Engine 2.0 y un ajuste `DD_RULES_V2_*` no afecta al motor original. + +```python +DD_RULES_V2_EVENT_BATCH=(int, 500), +DD_RULES_V2_CHUNK_SIZE=(int, 1000), +DD_RULES_V2_STALLED_AFTER_MINUTES=(int, 30), +DD_RULES_V2_RUN_TIME_LIMIT_MINUTES=(int, 360), +DD_RULES_V2_ALLOW_PRIVATE_EGRESS=(bool, False), +DD_RULES_V2_DELIVERY_RETENTION_DAYS=(int, 180), +DD_RULES_V2_RUN_RETENTION_DAYS=(int, 180), +DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS=(int, 8000), +DD_RULES_V2_MAX_PER_ITEM_SENDS=(int, 1000), +``` + +## Rendimiento + +### Hallazgos por evento (`DD_RULES_V2_EVENT_BATCH`) + +**Predeterminado: 500.** + +Cuántos ids de Hallazgo lleva un único evento. Los eventos cruzan un límite asíncrono, por lo que se mantienen lo bastante pequeños para seguir siendo un mensaje económico. Una escritura más grande se reparte en varios eventos, cada uno de los cuales se convierte en su propia ejecución. + +Aumentar este valor produce menos ejecuciones, más grandes. Reducirlo produce más ejecuciones, más pequeñas. + +### Hallazgos por bloque (`DD_RULES_V2_CHUNK_SIZE`) + +**Predeterminado: 1000.** + +Cuántos Hallazgos mantiene en memoria una ejecución a la vez. Una ejecución se procesa en bloques, así que este es un control de memoria y **no** un límite de lo que una regla maneja: una regla siempre procesa todo lo que coincide con su alcance. + +Un envelope ocupa aproximadamente 2,7 KB por Hallazgo, de modo que el valor predeterminado mantiene unos pocos megabytes a la vez. Aumentarlo cambia memoria por menos idas y vueltas. Reducirlo hace lo contrario. + +### Límite de texto del envelope (`DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS`) + +**Predeterminado: 8000. Establézcalo en 0 para desactivarlo.** + +Cuántos caracteres de `description`, `mitigation` e `impact` lleva un elemento. + +Esos tres campos son la mayor parte del tamaño de un envelope. El límite existe para el caso inusual de un Hallazgo con una descripción muy extensa, en el que un bloque completo de ellos sería mucho más grande de lo que sugiere el tamaño del bloque. Es lo bastante generoso como para que una instancia habitual nunca lo note. + +Tenga en cuenta que esto afecta a lo que las condiciones y las plantillas pueden ver. Una condición que compare contra el final de una descripción muy larga no verá el texto que sobrepase el límite. + +## Ciclo de vida de la ejecución + +### Ventana de estancamiento (`DD_RULES_V2_STALLED_AFTER_MINUTES`) + +**Predeterminado: 30.** + +Cuánto tiempo puede pasar una ejecución sin una señal de actividad antes de considerarse abandonada, marcarse como errónea y liberar su bloqueo por regla. + +Una ejecución registra una señal de actividad después de cada bloque, de modo que esto se mide desde la última señal de actividad y no desde el inicio. Un barrido largo que sigue avanzando nunca se confunde con un worker caído, que es lo que permite que la ventana se mantenga corta. + +### Límite de tiempo de ejecución (`DD_RULES_V2_RUN_TIME_LIMIT_MINUTES`) + +**Predeterminado: 360, es decir, seis horas.** + +El tiempo máximo que puede tardar una sola ejecución antes de que el worker la termine. + +Esto es una protección contra una regla que nunca terminaría mientras ocupa un slot de worker y el bloqueo de ejecución de su regla. Es deliberadamente generoso, porque un barrido en bloques sobre un alcance muy grande es exactamente la carga de trabajo para la que está construido este motor. + +## Retención + +Dos tareas acotan las tres tablas que hace crecer esta función. Ambas tienen como valor predeterminado **180 días**, y ambas aceptan `0` para desactivar por completo la depuración. + +La retención se muestra en el producto en lugar de dejarse implícita: la API entrega tanto la ventana como la fecha en que se eliminará un registro determinado, y las páginas que muestran una ejecución o una entrega lo indican en una frase. La fecha se calcula al leer, de modo que cambiar la ventana surte efecto de inmediato en lugar de aplicarse solo a los registros nuevos. + +### `DD_RULES_V2_DELIVERY_RETENTION_DAYS` + +**Predeterminado: 180.** + +Cuántos días se conserva una entrega finalizada. + +Esta es la tabla que más rápido crece de la función. Un nodo de salida por Hallazgo escribe hasta un bloque entero de filas por ejecución, incluso en modo Simulación. Auméntelo si necesita un rastro de auditoría saliente más largo, y redúzcalo si el volumen es un problema. + +### `DD_RULES_V2_RUN_RETENTION_DAYS` + +**Predeterminado: 180.** + +Cuántos días se conserva una ejecución finalizada, junto con sus filas por nodo y la procedencia de sus Hallazgos. + +El lado de las ejecuciones crece más rápido que el de las entregas, porque la procedencia es una fila por Hallazgo, por nodo de mutación, por ejecución. Una regla horaria sobre un alcance grande genera una gran cantidad. + +Una ejecución que todavía tiene entregas asociadas se conserva hasta que estas se depuran, de modo que establecer una ventana de ejecución más corta que la de entrega no deja nada huérfano. + +## Validación del destino saliente + +Dos ajustes de nodo toman un destino como texto libre en lugar de a partir de un objeto configurado: la **URL** en Llamar a un webhook, y el **Para** en Enviar un correo electrónico. Ambos se validan al guardar la regla. + +Para las URL de webhook: + +* Solo se aceptan `http` y `https`. Los demás esquemas se rechazan de inmediato. +* La URL debe tener un host. +* De forma predeterminada, se rechaza un host que resuelva a una dirección loopback, link-local, privada, reservada o multicast. + +Para las direcciones de correo electrónico, se rechaza una dirección vacía, así como una que contenga un salto de línea, lo cual es una inyección de cabeceras. + +La razón de la comprobación de red es que el worker que envía la solicitud normalmente se encuentra dentro de su clúster y puede alcanzar mucha más red interna que la persona que redacta la regla. Sin esta comprobación, una URL en texto libre es un primitivo de falsificación de solicitudes: apúntela a un servicio de metadatos o a un puerto administrativo interno y la respuesta vuelve a través del registro de entregas. + +Esto es defensa en profundidad, no el único control. Rule Edit ya es de por sí casi un permiso administrativo. Vale la pena tenerlo para que el radio de impacto de un rol concedido en exceso no sea "leer cualquier endpoint HTTP interno", y para que una errata falle al guardar con un mensaje claro en lugar de al enviar con un error de conexión. + +### Permitir direcciones privadas (`DD_RULES_V2_ALLOW_PRIVATE_EGRESS`) + +**Predeterminado: desactivado.** + +Desactiva la comprobación de direcciones de red, de modo que los webhooks pueden publicar en direcciones loopback, link-local y privadas. La validación de esquema y de forma sigue aplicándose. + +Actívelo si realmente necesita enviar un webhook a algo en una dirección privada, que es lo habitual en un receptor de chat o de webhooks autoalojado. + +## Límite de envíos por Hallazgo + +### `DD_RULES_V2_MAX_PER_ITEM_SENDS` + +**Predeterminado: 1000. Establézcalo en 0 para eliminar el límite.** + +El máximo de envíos por Hallazgo que un solo nodo de salida registrará en una ejecución. + +Un nodo con **Un mensaje por Hallazgo** activado produce una fila de entrega y una tarea en cola por Hallazgo. Como una ejecución no tiene límite de elementos, una regla con un alcance muy amplio y el envío por Hallazgo activado supondría, de lo contrario, un número ilimitado de ambas cosas. + +Superado este límite, el nodo registra una **omisión visible** que indica sobre cuántos Hallazgos no envió nada. No hace fallar la ejecución, ni se detiene en silencio. + +## Ajustes relacionados + +Algunos nodos de Rules Engine 2.0 usan la configuración de integración de todo el sistema en lugar de la propia: + +* **Enviar un mensaje de Slack** usa el token de Slack del sistema, y recurre al canal de Slack del sistema cuando el nodo no indica ninguno. +* **Enviar un mensaje de Microsoft Teams** usa el webhook de Microsoft Teams de los ajustes del sistema. +* **Crear un issue de JIRA** usa la configuración de JIRA del producto para el resumen, la descripción y la prioridad. +* **Generar una alerta en la aplicación** respeta el ajuste de notificación **Coincidencia de Rules Engine** propio de cada destinatario. diff --git a/docs/content/automation/rules_engine_2/configuration.fr.md b/docs/content/automation/rules_engine_2/configuration.fr.md new file mode 100644 index 00000000000..c04669e81f0 --- /dev/null +++ b/docs/content/automation/rules_engine_2/configuration.fr.md @@ -0,0 +1,141 @@ +--- +title: Configuration +description: Paramètres au niveau du déploiement pour Rules Engine 2.0 +weight: 7 +audience: pro +aliases: +- /fr/automation/rules_engine_v2/configuration/ +--- + +Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro. + +Rules Engine 2.0 fonctionne dès l'installation. Les paramètres de cette page s'adressent aux déploiements qui ont besoin d'ajuster le débit, la rétention ou la politique réseau sortante. Ils s'appliquent tous de la même manière que n'importe quel autre paramètre DefectDojo (voir [Configuration](/get_started/open_source/configuration/)). + +Rules Engine 2.0 se configure séparément du Rules Engine d'origine. Les deux moteurs ne partagent aucun réglage : un paramètre `DD_RULES_ENGINE_*` n'affecte pas Rules Engine 2.0, et un paramètre `DD_RULES_V2_*` n'affecte pas le moteur d'origine. + +```python +DD_RULES_V2_EVENT_BATCH=(int, 500), +DD_RULES_V2_CHUNK_SIZE=(int, 1000), +DD_RULES_V2_STALLED_AFTER_MINUTES=(int, 30), +DD_RULES_V2_RUN_TIME_LIMIT_MINUTES=(int, 360), +DD_RULES_V2_ALLOW_PRIVATE_EGRESS=(bool, False), +DD_RULES_V2_DELIVERY_RETENTION_DAYS=(int, 180), +DD_RULES_V2_RUN_RETENTION_DAYS=(int, 180), +DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS=(int, 8000), +DD_RULES_V2_MAX_PER_ITEM_SENDS=(int, 1000), +``` + +## Débit + +### Constatations par événement (`DD_RULES_V2_EVENT_BATCH`) + +**Par défaut : 500.** + +Le nombre d'identifiants de Constatation qu'un seul événement transporte. Les événements traversent une frontière asynchrone, ils sont donc gardés assez petits pour rester un message peu coûteux. Une écriture plus importante se répartit en plusieurs événements, chacun devenant sa propre exécution. + +Augmenter cette valeur produit des exécutions moins nombreuses mais plus volumineuses. La diminuer en produit davantage, mais plus petites. + +### Constatations par lot (`DD_RULES_V2_CHUNK_SIZE`) + +**Par défaut : 1000.** + +Le nombre de Constatations qu'une exécution conserve en mémoire à la fois. Une exécution est traitée par lots, il s'agit donc d'un réglage de mémoire et **non** d'un plafond sur ce qu'une règle traite : une règle traite toujours tout ce que son périmètre couvre. + +Une enveloppe pèse environ 2,7 Ko par Constatation, de sorte que la valeur par défaut occupe quelques mégaoctets à la fois. L'augmenter échange de la mémoire contre moins d'allers-retours. La diminuer fait l'inverse. + +### Plafond de texte de l'enveloppe (`DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS`) + +**Par défaut : 8000. Réglez sur 0 pour désactiver.** + +Le nombre de caractères de `description`, `mitigation` et `impact` qu'un élément transporte. + +Ces trois champs représentent l'essentiel de la taille d'une enveloppe. Le plafond existe pour le cas inhabituel d'une Constatation à la description très longue, où un lot complet de celles-ci serait bien plus volumineux que ce que suggère la taille du lot. Il est suffisamment généreux pour qu'une instance ordinaire ne le remarque jamais. + +Notez que cela affecte ce que les conditions et les modèles peuvent voir. Une condition portant sur la fin d'une description très longue ne verra pas le texte au-delà du plafond. + +## Durée de vie de l'exécution + +### Fenêtre de blocage (`DD_RULES_V2_STALLED_AFTER_MINUTES`) + +**Par défaut : 30.** + +Le temps qu'une exécution peut rester sans pulsation avant d'être considérée comme abandonnée, marquée en erreur, et son verrou par règle libéré. + +Une exécution émet une pulsation après chaque lot ; cette mesure part donc de la dernière pulsation plutôt que du début. Un long balayage encore en progression n'est ainsi jamais confondu avec un worker planté, ce qui permet à la fenêtre de rester courte. + +### Limite de temps d'exécution (`DD_RULES_V2_RUN_TIME_LIMIT_MINUTES`) + +**Par défaut : 360, soit six heures.** + +La durée maximale qu'une exécution unique peut prendre avant que le worker ne la termine de force. + +Il s'agit d'une protection contre une règle qui ne se terminerait jamais tout en occupant un emplacement de worker et le verrou d'exécution de sa règle. Elle est délibérément généreuse, car un balayage par lots sur un périmètre très large est précisément le type de charge de travail pour lequel ce moteur est conçu. + +## Rétention + +Deux tâches limitent les trois tables que cette fonctionnalité fait grossir. Les deux ont par défaut **180 jours**, et les deux acceptent `0` pour désactiver totalement la purge. + +La rétention est mise en avant dans le produit plutôt que laissée implicite : l'API fournit à la fois la fenêtre et la date à laquelle un enregistrement donné sera supprimé, et les pages qui affichent une exécution ou une livraison l'indiquent en une phrase. La date est calculée à la lecture, de sorte que modifier la fenêtre prend effet immédiatement plutôt que de ne s'appliquer qu'aux nouveaux enregistrements. + +### `DD_RULES_V2_DELIVERY_RETENTION_DAYS` + +**Par défaut : 180.** + +Le nombre de jours pendant lequel une livraison terminée est conservée. + +C'est la table qui croît le plus rapidement dans cette fonctionnalité. Un nœud de sortie par Constatation écrit jusqu'à un lot entier de lignes par exécution, y compris en mode Simulate. Augmentez cette valeur si vous avez besoin d'une piste d'audit sortante plus longue, et diminuez-la si le volume pose problème. + +### `DD_RULES_V2_RUN_RETENTION_DAYS` + +**Par défaut : 180.** + +Le nombre de jours pendant lequel une exécution terminée est conservée, avec ses lignes par nœud et sa provenance de Constatation. + +Le côté exécution croît plus vite que les livraisons, car la provenance représente une ligne par Constatation, par nœud de modification, par exécution. Une règle horaire sur un large périmètre en génère beaucoup. + +Une exécution qui contient encore des livraisons est conservée jusqu'à ce que celles-ci soient purgées ; définir une fenêtre d'exécution plus courte que la fenêtre de livraison n'orpheline donc rien. + +## Validation de la destination sortante + +Deux paramètres de nœud prennent une destination sous forme de texte libre plutôt que depuis un objet configuré : l'**URL** de Call a Webhook (Appeler un webhook), et le **To** (Destinataire) de Send an Email (Envoyer un e-mail). Les deux sont validés lors de l'enregistrement de la règle. + +Pour les URL de webhook : + +* Seuls `http` et `https` sont acceptés. Les autres schémas sont rejetés d'emblée. +* L'URL doit comporter un hôte. +* Par défaut, un hôte qui se résout vers une adresse loopback, link-local, privée, réservée ou multicast est rejeté. + +Pour les adresses e-mail, une adresse vide est rejetée, tout comme une adresse contenant un saut de ligne, ce qui constitue une injection d'en-tête. + +La raison de cette vérification réseau est que le worker qui envoie la requête se trouve généralement à l'intérieur de votre cluster et peut atteindre une bien plus grande partie du réseau interne que la personne qui rédige la règle. Sans cette vérification, une URL en texte libre est un vecteur de falsification de requête : il suffit de la pointer vers un service de métadonnées ou un port d'administration interne pour que la réponse revienne via le registre des livraisons. + +Il s'agit d'une défense en profondeur plutôt que du seul contrôle. Rule Edit se rapproche de toute façon d'une permission administrative. Cela vaut la peine de l'avoir afin que le rayon d'impact d'un rôle trop généreusement accordé ne soit pas « lire n'importe quel point de terminaison HTTP interne », et pour qu'une faute de frappe échoue à l'enregistrement avec un message clair plutôt qu'à l'envoi avec une erreur de connexion. + +### Autoriser les adresses privées (`DD_RULES_V2_ALLOW_PRIVATE_EGRESS`) + +**Par défaut : désactivé.** + +Désactive la vérification d'adresse réseau, de sorte que les webhooks peuvent envoyer vers des adresses loopback, link-local et privées. La validation du schéma et de la forme s'applique toujours. + +Activez ceci si vous envoyez véritablement des webhooks vers quelque chose situé sur une adresse privée, ce qu'est normalement un récepteur de chat ou de webhook auto-hébergé. + +## Plafond d'envoi par Constatation + +### `DD_RULES_V2_MAX_PER_ITEM_SENDS` + +**Par défaut : 1000. Réglez sur 0 pour supprimer le plafond.** + +Le nombre maximal d'envois par Constatation qu'un seul nœud de sortie enregistrera au cours d'une exécution. + +Un nœud avec **One Message per Finding** (Un message par Constatation) activé produit une ligne de livraison et une tâche mise en file d'attente par Constatation. Comme une exécution n'a pas de plafond d'éléments, une règle avec un périmètre très large et l'envoi par Constatation activé signifierait sinon un nombre illimité des deux. + +Au-delà de ce plafond, le nœud enregistre un **saut visible** indiquant combien de Constatations n'ont pas fait l'objet d'un envoi. Cela ne fait pas échouer l'exécution, et ne s'arrête pas silencieusement. + +## Paramètres associés + +Certains nœuds de Rules Engine 2.0 utilisent une configuration d'intégration à l'échelle du système plutôt que la leur propre : + +* **Send a Slack Message** (Envoyer un message Slack) utilise le jeton Slack du système, et se rabat sur le canal Slack du système lorsque le nœud n'en nomme aucun. +* **Send a Microsoft Teams Message** (Envoyer un message Microsoft Teams) utilise le webhook Microsoft Teams des paramètres système. +* **Create a JIRA Issue** (Créer un ticket JIRA) utilise la configuration JIRA du produit pour le résumé, la description et la priorité. +* **Raise an In-App Alert** (Déclencher une alerte dans l'application) respecte le paramètre de notification **Rules Engine Match** (Correspondance Rules Engine) propre à chaque destinataire. diff --git a/docs/content/automation/rules_engine_2/configuration.ja.md b/docs/content/automation/rules_engine_2/configuration.ja.md new file mode 100644 index 00000000000..6d85dafd129 --- /dev/null +++ b/docs/content/automation/rules_engine_2/configuration.ja.md @@ -0,0 +1,141 @@ +--- +title: 設定 +description: Rules Engine 2.0 のデプロイメントレベルの設定 +weight: 7 +audience: pro +aliases: +- /ja/automation/rules_engine_v2/configuration/ +--- + +注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。 + +Rules Engine 2.0 は、そのままの状態で動作します。このページの設定は、スループット、保持期間、または送信先ネットワークポリシーを調整する必要があるデプロイメント向けのものです。これらはすべて、他の DefectDojo の設定と同じ方法で適用されます([設定](/get_started/open_source/configuration/) を参照)。 + +Rules Engine 2.0 は、従来の Rules Engine とは別に設定されます。両エンジンの間でチューニングは共有されないため、`DD_RULES_ENGINE_*` の設定は Rules Engine 2.0 に影響を与えず、`DD_RULES_V2_*` の設定は従来のエンジンに影響を与えません。 + +```python +DD_RULES_V2_EVENT_BATCH=(int, 500), +DD_RULES_V2_CHUNK_SIZE=(int, 1000), +DD_RULES_V2_STALLED_AFTER_MINUTES=(int, 30), +DD_RULES_V2_RUN_TIME_LIMIT_MINUTES=(int, 360), +DD_RULES_V2_ALLOW_PRIVATE_EGRESS=(bool, False), +DD_RULES_V2_DELIVERY_RETENTION_DAYS=(int, 180), +DD_RULES_V2_RUN_RETENTION_DAYS=(int, 180), +DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS=(int, 8000), +DD_RULES_V2_MAX_PER_ITEM_SENDS=(int, 1000), +``` + +## スループット + +### イベントごとの Finding 数(`DD_RULES_V2_EVENT_BATCH`) + +**デフォルト: 500。** + +1つのイベントが保持する Finding id の数です。イベントは非同期の境界を越えるため、軽量なメッセージであり続けられるだけの小ささに保たれています。大きな書き込みは複数のイベントに分散され、それぞれが個別の Run になります。 + +この値を上げると、より大きく、より少ない数の Run が生成されます。下げると、より小さく、より多くの Run が生成されます。 + +### チャンクごとの Finding 数(`DD_RULES_V2_CHUNK_SIZE`) + +**デフォルト: 1000。** + +1回の Run が一度にメモリ上に保持する Finding の数です。Run はチャンク単位で処理されるため、これはメモリ調整用の値であり、ルールが処理する対象の上限では**ありません**。ルールは常に、そのスコープに一致するすべてを処理します。 + +1つの envelope は Finding あたりおよそ2.7KBであるため、デフォルト値では一度に数メガバイトを保持します。この値を上げるとメモリと引き換えにラウンドトリップの回数が減り、下げるとその逆になります。 + +### Envelope のテキスト上限(`DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS`) + +**デフォルト: 8000。0に設定すると無効化されます。** + +item が保持する `description`、`mitigation`、`impact` の文字数です。 + +この3つのフィールドが envelope のサイズの大部分を占めます。この上限は、非常に大きな description を持つ Finding という例外的なケースのために存在します。そのようなケースでは、1チャンク分がチャンクサイズから想定されるよりもはるかに大きくなってしまいます。この上限は十分に余裕を持って設定されているため、通常のインスタンスで意識されることはありません。 + +これは conditions と templates から見える内容にも影響することに注意してください。非常に長い description の末尾に対して一致させる条件は、この上限を超えたテキストを見ることができません。 + +## Run のライフタイム + +### 停止判定までの時間(`DD_RULES_V2_STALLED_AFTER_MINUTES`) + +**デフォルト: 30。** + +Run が放棄されたものとみなされ、エラーとしてマークされ、ルールごとのロックが解放されるまでに、heartbeat なしで経過してよい時間です。 + +Run は各チャンクの後に heartbeat を記録するため、この時間は開始時点からではなく、最後の heartbeat からの経過時間として測定されます。これにより、まだ進行中の長い走査がクラッシュしたワーカーと誤認されることはなく、この時間を短く保つことができます。 + +### Run の実行時間の上限(`DD_RULES_V2_RUN_TIME_LIMIT_MINUTES`) + +**デフォルト: 360(6時間)。** + +ワーカーが Run を強制終了するまでに、1回の Run が取り得る最長時間です。 + +これは、決して終わらないルールがワーカースロットとそのルールの実行ロックを保持し続けることを防ぐための保護策です。非常に大きなスコープに対するチャンク単位の走査は、このエンジンが想定して作られたワークロードであるため、意図的に余裕を持たせた値になっています。 + +## 保持期間 + +この機能が肥大化させる3つのテーブルは、2つのジョブによって制限されます。どちらもデフォルトは**180日**で、どちらも `0` を指定すると削除処理(pruning)を完全に無効化できます。 + +保持期間は暗黙のままにされず、製品内で明示されます。API は保持期間の長さと、あるレコードが削除される日付の両方を返し、Run や Delivery を表示するページにもその内容が一文で示されます。日付は読み取り時に計算されるため、期間を変更するとすぐに反映され、新しいレコードだけに適用されるわけではありません。 + +### `DD_RULES_V2_DELIVERY_RETENTION_DAYS` + +**デフォルト: 180。** + +完了した delivery を保持する日数です。 + +これはこの機能の中で最も速く肥大化するテーブルです。Finding ごとの egress ノードは、Simulate モードを含め、1回の Run につきチャンク分の行を書き込みます。より長い送信監査証跡が必要であれば値を上げ、ボリュームが問題になる場合は値を下げてください。 + +### `DD_RULES_V2_RUN_RETENTION_DAYS` + +**デフォルト: 180。** + +完了した run を、そのノードごとの行および Finding の来歴(provenance)とともに保持する日数です。 + +run 側は delivery 側よりも速く肥大化します。これは、provenance が Run ごと・変更ノードごと・Finding ごとに1行生成されるためです。大きなスコープに対して1時間ごとに実行されるルールは、これを大量に生成します。 + +delivery をまだ保持している run は、それらが削除されるまで保持されます。そのため、run の保持期間を delivery の保持期間より短く設定しても、孤立したレコードが生じることはありません。 + +## 送信先の検証 + +2つのノード設定は、設定済みのオブジェクトからではなく、自由入力のテキストとして送信先を受け取ります。Call a Webhook の **URL** と、Send an Email の **To** です。どちらもルールの保存時に検証されます。 + +Webhook の URL については、次の通りです。 + +* `http` と `https` のみが受け付けられます。それ以外のスキームは即座に拒否されます。 +* URL にはホストが含まれている必要があります。 +* デフォルトでは、loopback、link-local、private、reserved、multicast のいずれかのアドレスに解決されるホストは拒否されます。 + +メールアドレスについては、空のアドレスは拒否され、改行を含むアドレス(ヘッダーインジェクションに該当します)も拒否されます。 + +このネットワークチェックが存在する理由は、リクエストを送信するワーカーが通常クラスター内部に存在し、ルールの作成者本人よりもはるかに広い範囲の内部ネットワークに到達できてしまうためです。このチェックがなければ、自由入力の URL はリクエストフォージェリのプリミティブになり得ます。メタデータサービスや内部の管理用ポートを指定すれば、その応答が delivery の台帳を通じて返ってきてしまいます。 + +これは唯一の制御手段ではなく、多層防御の一環です。Rule Edit はいずれにせよ管理者権限に近いものです。それでもこのチェックがある価値はあります。過剰に付与されたロール1つの被害範囲が「任意の内部 HTTP エンドポイントの読み取り」にならないようにするためであり、また、タイプミスが送信時の接続エラーとしてではなく、保存時にわかりやすいメッセージとして失敗するようにするためです。 + +### プライベートアドレスの許可(`DD_RULES_V2_ALLOW_PRIVATE_EGRESS`) + +**デフォルト: オフ。** + +ネットワークアドレスのチェックを無効化し、Webhook が loopback、link-local、private の各アドレスに投稿できるようにします。スキームと形式の検証は引き続き適用されます。 + +プライベートアドレス上の何かに対して実際に Webhook を送る必要がある場合はこれを有効にしてください。自己ホスト型のチャットや Webhook レシーバーは、通常これに該当します。 + +## Finding ごとの送信上限 + +### `DD_RULES_V2_MAX_PER_ITEM_SENDS` + +**デフォルト: 1000。0に設定すると上限を撤廃できます。** + +1つの egress ノードが1回の Run で記録する、Finding ごとの送信回数の最大値です。 + +**One Message per Finding** が有効になっているノードは、Finding ごとに1つの delivery 行と1つのキュー投入タスクを生成します。Run には item 数の上限がないため、非常に広いスコープを持ち、かつ Finding ごとの送信が有効なルールは、この設定がなければ、両方とも無制限になってしまいます。 + +この上限を超えると、ノードは送信しなかった Finding の件数を示す**可視化されたスキップ**を記録します。Run を失敗させることはなく、また黙って停止することもありません。 + +## 関連する設定 + +一部の Rules Engine 2.0 ノードは、独自の設定ではなくシステム全体のインテグレーション設定を使用します。 + +* **Send a Slack Message** はシステムの Slack トークンを使用し、ノードでチャンネルが指定されていない場合はシステムの Slack チャンネルにフォールバックします。 +* **Send a Microsoft Teams Message** は、システム設定の Microsoft Teams webhook を使用します。 +* **Create a JIRA Issue** は、summary、description、priority について、その製品の JIRA 設定を使用します。 +* **Raise an In-App Alert** は、各受信者自身の **Rules Engine Match** 通知設定に従います。 diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.de.md b/docs/content/automation/rules_engine_2/converting_from_rules_engine.de.md new file mode 100644 index 00000000000..299dd19f065 --- /dev/null +++ b/docs/content/automation/rules_engine_2/converting_from_rules_engine.de.md @@ -0,0 +1,89 @@ +--- +title: Migration von der Rules Engine +description: Bestehende Rules-Engine-Regeln in Rules-Engine-2.0-Graphen überführen +weight: 6 +audience: pro +aliases: +- /de/automation/rules_engine_v2/converting_from_rules_engine/ +--- + +Note: Rules Engine 2.0 is a DefectDojo Pro-only feature. + +Beide Engines laufen nebeneinander. Das Aktivieren von Rules Engine 2.0 ändert nichts an Ihren bestehenden [Rules Engine](/automation/rules_engine/about/)-Regeln, und es gibt keine Frist, bis zu der Sie diese migrieren müssen. + +Wenn Sie sie migrieren möchten, gibt es dafür einen Konverter. Er übersetzt eine Rules-Engine-Regel (ein Filter plus eine geordnete Liste von Aktionen) in einen gleichwertigen Rules-Engine-2.0-Graphen. + +## Was der Konverter garantiert + +**Eine Regel wird entweder sauber konvertiert oder überhaupt nicht.** Jede Konvertierung meldet zwei Arten von Ergebnissen: + +* **Problems** bedeuten, dass die Regel nicht geschrieben wurde. Es wird nichts Unvollständiges gespeichert. +* **Warnings** bedeuten, dass die Regel konvertiert wurde, sich aber etwas daran verändert hat und Sie es sich ansehen sollten. + +Es wird nichts stillschweigend angenähert. Der ganze Wert des Konverters liegt darin, dass Sie einer Regel vertrauen können, die ohne Anmerkung konvertiert wurde, und eine, bei der das nicht der Fall war, von Hand prüfen. + +**Konvertierte Regeln werden immer deaktiviert erstellt.** Beide Engines laufen, und zwei Regeln, die dasselbe mit denselben Befunden tun, sind das eine Ergebnis, das ein Konverter niemals von sich aus erzeugen darf. Prüfen Sie jede konvertierte Regel und aktivieren Sie sie bewusst. + +**Eine Regel wird nur einmal konvertiert.** Jede konvertierte Regel merkt sich, aus welcher Regel sie stammt, sodass ein zweiter Lauf des Konverters überspringt, was bereits erledigt wurde, statt Duplikate zu erzeugen. Verwenden Sie die Overwrite-Option, um einen zuvor konvertierten Graphen bewusst zu ersetzen. + +## Den Konverter ausführen + +### Über die Benutzeroberfläche + +Die Regelliste bietet eine Konvertierungsaktion an, die pro Regel meldet, was konvertiert wurde, was übersprungen wurde und was fehlgeschlagen ist. + +### Über die Kommandozeile + +```bash +python manage.py convert_rules_to_v2 +``` + +| Option | Effect | +|--------|--------| +| `--dry-run` | Gibt den Graphen aus, den jede Regel erzeugen würde, und schreibt nichts. | +| `--rule-ids 1,2,3` | Konvertiert nur diese Regeln. Konvertiert alle Regeln, wenn weggelassen. | +| `--overwrite` | Ersetzt den Graphen einer bereits konvertierten Regel und erhöht ihre Version, statt sie zu überspringen. | +| `--activate-schedules` | Kopiert außerdem jeden Zeitplan auf die konvertierte Regel. Standardmäßig aus. | +| `--drop-invalid-filters` | Verwirft Geltungsbereichsfilter, die das Filterset nicht mehr erkennt, und warnt, statt die Regel fehlschlagen zu lassen. | +| `--json` | Gibt den Bericht als JSON statt als Text aus. | + +Der Befehl gibt nur dann einen Exit-Code ungleich null zurück, wenn eine Regel nicht konvertiert werden kann. Übersprungene Regeln werden gemeldet, gelten aber nicht als Fehlschläge. + +Beginnen Sie mit `--dry-run` auf der gesamten Menge, um zu sehen, worauf Sie sich einlassen, und konvertieren Sie dann tatsächlich. + +## Was die Konvertierung erzeugt + +| Rules Engine concept | Becomes | +|----------------------|---------| +| Der Filter der Regel | Der **Scope** am Trigger-Knoten. | +| Eine Regel mit Zeitplan | Ein **On a Schedule**-Trigger. | +| Eine Regel ohne Zeitplan | Ein **Manual Run**-Trigger. | +| Jede Aktion, in Reihenfolge | Ein Knoten, in derselben Reihenfolge verkettet. | +| Eine durch eine Bedingung geschützte Aktion | Ein **If / Filter**-Knoten vor diesem Knoten. | + +Das Filtervokabular wird von beiden Engines gemeinsam genutzt, sodass ein Geltungsbereich ohne Übersetzung konvertiert wird. Das ist beabsichtigt: Es ist derselbe Filtersatz, mit einer Implementierung. + +Konvertierte Graphen werden auf dieselbe Weise validiert wie ein von Hand erstellter Graph, einschließlich der Konfiguration pro Knoten und der zulässigen Werte jedes Dropdowns. Eine Regel mit einem Schweregrad- oder Risikowert, von dem sich das Produkt inzwischen entfernt hat, wird bei der Konvertierung erkannt statt erst zur Laufzeit. + +## Was nicht übernommen wird + +Vier Dinge, auf die Sie sich einstellen sollten. Der Konverter meldet diese als Hinweise bei jedem Lauf. + +* **Der Lauf-Verlauf bleibt, wo er ist.** Der bestehende Lauf-Verlauf sowie die betroffenen und übersprungenen Datensätze verbleiben in der Rules-Engine-Benutzeroberfläche. Sie werden nicht kopiert. +* **Zeitpläne werden standardmäßig nicht aktiviert.** Eine zeitplan-ausgelöste Regel wird konvertiert, aber ihr Zeitplan wird nur kopiert, wenn Sie `--activate-schedules` übergeben. Dadurch bleibt die alleinige Verantwortung für aktive Zeitpläne bei der ursprünglichen Engine, solange beide laufen, sodass eine konvertierte Regel nicht heimlich zu feuern beginnen kann. Wenn Sie einen Zeitplan tatsächlich kopieren, erhält die Kopie einen eigenen Namen, damit sie nicht mit dem Original kollidiert. +* **Das Nebenläufigkeitsmodell ist unterschiedlich.** Rules Engine hat eine instanzweite Laufsperre. Rules Engine 2.0 serialisiert pro Regel, sodass unterschiedliche Regeln gleichzeitig laufen. Eine Gruppe von Regeln, die sich früher abgewechselt hat, überlappt sich nun. +* **Eine Aktion hat keine Entsprechung.** Eine Aktion „Falsch-positiv auf false setzen“ kann nicht als Rules-Engine-2.0-Knoten ausgedrückt werden und muss von Hand konvertiert werden. + +Eine Regel, deren Eigentümer nicht gesetzt ist, wird mit einer Warnung konvertiert. Denken Sie daran, dass eine Regel ohne Eigentümer keine Befunde sieht, weisen Sie also einen zu, bevor Sie sie aktivieren. + +## Eine vorgeschlagene Reihenfolge + +1. Aktivieren Sie Rules Engine 2.0 und lassen Sie Ihre bestehenden Regeln weiterlaufen. +2. Führen Sie den Konverter mit `--dry-run` aus und lesen Sie den Bericht. +3. Konvertieren Sie. Alles landet deaktiviert. +4. Öffnen Sie jede konvertierte Regel, prüfen Sie den Graphen und belassen Sie den Modus auf **Simulate**. +5. Aktivieren Sie die konvertierte Regel und lassen Sie sie eine Weile parallel zum Original laufen. Simulate bedeutet, dass sie Befunde ändert, aber nichts sendet, sodass Sie ihre Läufe mit denen des Originals vergleichen können. +6. Wenn Sie zufrieden sind, deaktivieren Sie die ursprüngliche Regel und stellen Sie die konvertierte auf **Live** um. +7. Kopieren Sie den Zeitplan zuletzt, sobald die alte Regel nicht mehr läuft. + +Schritt 5 ist der, den Sie nicht überspringen sollten. Dass beide Engines dieselben Befunde bearbeiten, ist zum Beobachten unproblematisch, aber Sie möchten selbst entscheiden, wann die Sendungen beginnen. diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.es.md b/docs/content/automation/rules_engine_2/converting_from_rules_engine.es.md new file mode 100644 index 00000000000..6e6b78167a0 --- /dev/null +++ b/docs/content/automation/rules_engine_2/converting_from_rules_engine.es.md @@ -0,0 +1,89 @@ +--- +title: Migración desde Rules Engine +description: Migrar reglas existentes de Rules Engine a grafos de Rules Engine 2.0 +weight: 6 +audience: pro +aliases: +- /es/automation/rules_engine_v2/converting_from_rules_engine/ +--- + +Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro. + +Ambos motores funcionan en paralelo. Activar Rules Engine 2.0 no cambia nada de las reglas existentes del [Rules Engine](/automation/rules_engine/about/), y no hay ningún plazo para migrarlas. + +Cuando llegue el momento de migrarlas, existe un conversor. Traduce una regla de Rules Engine (un filtro más una lista ordenada de acciones) en un grafo equivalente de Rules Engine 2.0. + +## Qué garantiza el conversor + +**Una regla se convierte por completo o no se convierte en absoluto.** Cada conversión informa de dos tipos de resultado: + +* Los **problemas** significan que la regla no se escribió. No se guarda nada parcial. +* Las **advertencias** significan que la regla se convirtió, pero algo en ella cambió de lugar y conviene revisarlo. + +Nada se aproxima en silencio. Todo el valor del conversor está en que se puede confiar en una regla que se convirtió sin comentarios, y revisar a mano una que no lo hizo. + +**Las reglas convertidas siempre se crean desactivadas.** Ambos motores están en funcionamiento, y que dos reglas hagan lo mismo con los mismos Hallazgos es el único resultado que un conversor nunca debe producir por su cuenta. Revise cada regla convertida y actívela de forma deliberada. + +**Una regla se convierte una sola vez.** Cada regla convertida recuerda de qué regla proviene, de modo que ejecutar el conversor dos veces omite lo que ya se hizo en lugar de crear duplicados. Use la opción de sobrescritura para reemplazar deliberadamente un grafo convertido previamente. + +## Ejecución del conversor + +### Desde la interfaz + +La lista de reglas ofrece una acción de conversión, que informa por regla qué se convirtió, qué se omitió y qué falló. + +### Desde la línea de comandos + +```bash +python manage.py convert_rules_to_v2 +``` + +| Opción | Efecto | +|--------|--------| +| `--dry-run` | Imprime el grafo que produciría cada regla y no escribe nada. | +| `--rule-ids 1,2,3` | Convierte solo estas reglas. Convierte todas las reglas cuando se omite. | +| `--overwrite` | Reemplaza el grafo de una regla ya convertida y aumenta su versión, en lugar de omitirla. | +| `--activate-schedules` | También copia cada programación a su regla convertida. Desactivado de forma predeterminada. | +| `--drop-invalid-filters` | Descarta los filtros de alcance que el conjunto de filtros ya no reconoce y avisa, en lugar de hacer fallar la regla. | +| `--json` | Imprime el informe como JSON en lugar de texto. | + +El comando termina con un código distinto de cero solo cuando una regla no se convierte. Las omisiones se informan, pero no son fallos. + +Empiece con `--dry-run` sobre el conjunto completo para ver a qué se enfrenta, y luego convierta de verdad. + +## Qué produce la conversión + +| Concepto de Rules Engine | Se convierte en | +|----------------------|---------| +| El filtro de la regla | El **Alcance** del nodo disparador. | +| Una regla con una programación | Un disparador **Según una programación**. | +| Una regla sin programación | Un disparador **Ejecución manual**. | +| Cada acción, en orden | Un nodo, encadenado en el mismo orden. | +| Una acción protegida por una condición | Un nodo **Si / Filtro** delante de ese nodo. | + +El vocabulario de filtros se comparte entre ambos motores, de modo que un alcance se convierte sin traducción. Eso es deliberado: es el mismo conjunto de filtros, con una sola implementación. + +Los grafos convertidos se validan de la misma manera que un grafo construido a mano, incluida la configuración por nodo y los valores permitidos de cada lista desplegable. Una regla que contenga un valor de severidad o de riesgo que el producto ya haya dejado atrás se detecta en la conversión y no en tiempo de ejecución. + +## Qué no se traslada + +Cuatro cosas para las que hay que planificar. El conversor las informa como notas en cada ejecución. + +* **El historial de ejecuciones permanece donde está.** El historial de ejecuciones existente, y sus registros afectados y omitidos, permanecen en la interfaz de Rules Engine. No se copian. +* **Las programaciones no se activan de forma predeterminada.** Una regla activada por programación se convierte, pero su programación no se copia a menos que se pase `--activate-schedules`. Esto mantiene la propiedad exclusiva de las programaciones activas en el motor original mientras ambos están en funcionamiento, de modo que una regla convertida no puede empezar a dispararse sin que se note. Cuando sí se copia una programación, la copia recibe un nombre distinto para no colisionar con la original. +* **El modelo de concurrencia es diferente.** Rules Engine tiene un único bloqueo de ejecución para toda la instancia. Rules Engine 2.0 serializa por regla, de modo que reglas distintas se ejecutan de forma concurrente. Un conjunto de reglas que antes se turnaban ahora se solaparán. +* **Una acción no tiene equivalente.** Una acción de "establecer falso positivo en falso" no se puede expresar como un nodo de Rules Engine 2.0 y debe convertirse a mano. + +Una regla sin propietario asignado se convierte, con una advertencia. Recuerde que una regla sin propietario no ve ningún Hallazgo, así que asigne uno antes de activarla. + +## Un orden sugerido + +1. Active Rules Engine 2.0 y deje sus reglas existentes en funcionamiento. +2. Ejecute el conversor con `--dry-run` y lea el informe. +3. Convierta. Todo queda desactivado. +4. Abra cada regla convertida, revise el grafo y deje el modo en **Simulación**. +5. Active la regla convertida y déjela ejecutarse junto a la original durante un tiempo. Simulación significa que cambia los Hallazgos pero no envía nada, así que compare sus ejecuciones con lo que hacía la original. +6. Cuando esté satisfecho, desactive la regla original y cambie la convertida a **En vivo**. +7. Copie la programación al final, una vez que ya no se esté ejecutando la regla antigua. + +El paso 5 es el que vale la pena no saltarse. Que ambos motores editen los mismos Hallazgos está bien para observarlo, pero usted quiere ser quien decida cuándo empiezan los envíos. diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.fr.md b/docs/content/automation/rules_engine_2/converting_from_rules_engine.fr.md new file mode 100644 index 00000000000..938da1afa75 --- /dev/null +++ b/docs/content/automation/rules_engine_2/converting_from_rules_engine.fr.md @@ -0,0 +1,90 @@ +--- +title: Conversion depuis Rules Engine +description: Faire migrer les règles Rules Engine existantes vers des graphes Rules + Engine 2.0 +weight: 6 +audience: pro +aliases: +- /fr/automation/rules_engine_v2/converting_from_rules_engine/ +--- + +Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro. + +Les deux moteurs fonctionnent côte à côte. Activer Rules Engine 2.0 ne change rien à vos règles [Rules Engine](/automation/rules_engine/about/) existantes, et il n'y a aucune échéance à laquelle vous devriez les faire migrer. + +Lorsque vous souhaitez les faire migrer, un convertisseur est disponible. Il traduit une règle Rules Engine (un filtre associé à une liste ordonnée d'actions) en un graphe Rules Engine 2.0 équivalent. + +## Ce que le convertisseur garantit + +**Une règle se convertit proprement ou ne se convertit pas du tout.** Chaque conversion produit deux types de résultats : + +* Les **problèmes** signifient que la règle n'a pas été écrite. Rien de partiel n'est enregistré. +* Les **avertissements** signifient que la règle a été convertie, mais que quelque chose à son sujet a changé et mérite d'être examiné. + +Rien n'est approximé silencieusement. Tout l'intérêt du convertisseur est que vous pouvez faire confiance à une règle convertie sans remarque, et vérifier manuellement celle qui ne l'a pas été. + +**Les règles converties sont toujours créées désactivées.** Les deux moteurs fonctionnent en même temps, et avoir deux règles qui font la même chose aux mêmes Constatations est le seul résultat qu'un convertisseur ne doit jamais produire de lui-même. Passez en revue chaque règle convertie et activez-la délibérément. + +**Une règle ne se convertit qu'une fois.** Chaque règle convertie se souvient de la règle dont elle provient, de sorte qu'exécuter le convertisseur une seconde fois ignore ce qu'il a déjà fait plutôt que de créer des doublons. Utilisez l'option d'écrasement pour remplacer délibérément un graphe déjà converti. + +## Exécuter le convertisseur + +### Depuis l'interface + +La liste des règles propose une action de conversion, qui indique pour chaque règle ce qui a été converti, ce qui a été ignoré, et ce qui a échoué. + +### Depuis la ligne de commande + +```bash +python manage.py convert_rules_to_v2 +``` + +| Option | Effet | +|--------|--------| +| `--dry-run` | Affiche le graphe que chaque règle produirait et n'écrit rien. | +| `--rule-ids 1,2,3` | Ne convertit que ces règles. Convertit toutes les règles si omis. | +| `--overwrite` | Remplace le graphe d'une règle déjà convertie et incrémente sa version, au lieu de l'ignorer. | +| `--activate-schedules` | Copie également chaque planification sur sa règle convertie. Désactivé par défaut. | +| `--drop-invalid-filters` | Supprime les filtres de périmètre que l'ensemble de filtres ne reconnaît plus et avertit, au lieu de faire échouer la règle. | +| `--json` | Affiche le rapport au format JSON plutôt qu'en texte. | + +La commande se termine avec un code non nul uniquement lorsqu'une règle échoue à se convertir. Les éléments ignorés sont signalés mais ne sont pas des échecs. + +Commencez par `--dry-run` sur l'ensemble complet pour voir ce qui vous attend, puis convertissez pour de bon. + +## Ce que produit la conversion + +| Concept Rules Engine | Devient | +|----------------------|---------| +| Le filtre de la règle | Le **Scope** (Périmètre) du nœud déclencheur. | +| Une règle avec une planification | Un déclencheur **On a Schedule** (Sur une planification). | +| Une règle sans planification | Un déclencheur **Manual Run** (Exécution manuelle). | +| Chaque action, dans l'ordre | Un nœud, enchaîné dans le même ordre. | +| Une action protégée par une condition | Un nœud **If / Filter** placé devant ce nœud. | + +Le vocabulaire de filtres est partagé entre les deux moteurs, de sorte qu'un périmètre se convertit sans traduction. C'est délibéré : il s'agit du même ensemble de filtres, avec une seule implémentation. + +Les graphes convertis sont validés de la même manière qu'un graphe construit à la main, y compris la configuration par nœud et les valeurs autorisées de chaque liste déroulante. Une règle contenant une valeur de sévérité ou de risque que le produit a depuis abandonnée est détectée à la conversion plutôt qu'à l'exécution. + +## Ce qui ne se reporte pas + +Quatre points à anticiper. Le convertisseur les signale sous forme de notes à chaque exécution. + +* **L'historique des exécutions reste où il est.** L'historique des exécutions existant, ainsi que ses enregistrements affectés et ignorés, reste dans l'interface de Rules Engine. Il n'est pas copié. +* **Les planifications ne sont pas activées par défaut.** Une règle déclenchée par planification se convertit, mais sa planification n'est pas copiée sauf si vous passez `--activate-schedules`. Cela conserve la seule propriété des planifications actives au moteur d'origine tant que les deux fonctionnent, de sorte qu'une règle convertie ne peut pas commencer à se déclencher à votre insu. Lorsque vous copiez effectivement une planification, la copie reçoit un nom distinct afin de ne pas entrer en collision avec l'original. +* **Le modèle de concurrence est différent.** Rules Engine possède un seul verrou d'exécution à l'échelle de l'instance. Rules Engine 2.0 sérialise par règle, de sorte que des règles distinctes s'exécutent simultanément. Un ensemble de règles qui se relayaient auparavant se chevauchera désormais. +* **Une action n'a pas d'équivalent.** Une action « définir faux positif sur false » ne peut pas être exprimée comme un nœud Rules Engine 2.0 et doit être convertie manuellement. + +Une règle dont le propriétaire n'est pas défini se convertit, avec un avertissement. Rappelez-vous qu'une règle sans propriétaire ne voit aucune Constatation ; attribuez-lui donc un propriétaire avant de l'activer. + +## Un ordre suggéré + +1. Activez Rules Engine 2.0 et laissez vos règles existantes en cours d'exécution. +2. Exécutez le convertisseur avec `--dry-run` et lisez le rapport. +3. Convertissez. Tout est créé désactivé. +4. Ouvrez chaque règle convertie, vérifiez le graphe, et laissez le mode sur **Simulate**. +5. Activez la règle convertie, et laissez-la s'exécuter parallèlement à l'originale pendant un certain temps. Simulate signifie qu'elle modifie les Constatations mais n'envoie rien, ce qui permet de comparer ses exécutions à ce que l'originale a fait. +6. Lorsque vous êtes satisfait, désactivez la règle d'origine et basculez la règle convertie sur **Live**. +7. Copiez la planification en dernier, une fois que plus rien n'exécute l'ancienne règle. + +L'étape 5 est celle qu'il ne faut pas sauter. Que les deux moteurs modifient les mêmes Constatations est acceptable à observer, mais vous voulez être celui qui décide du moment où les envois commencent. diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.ja.md b/docs/content/automation/rules_engine_2/converting_from_rules_engine.ja.md new file mode 100644 index 00000000000..9dde661e20e --- /dev/null +++ b/docs/content/automation/rules_engine_2/converting_from_rules_engine.ja.md @@ -0,0 +1,89 @@ +--- +title: Rules Engine からの移行 +description: 既存の Rules Engine のルールを Rules Engine 2.0 のグラフへ移行する +weight: 6 +audience: pro +aliases: +- /ja/automation/rules_engine_v2/converting_from_rules_engine/ +--- + +注: Rules Engine 2.0 は DefectDojo Pro 専用の機能です。 + +両方のエンジンは並行して動作します。Rules Engine 2.0 を有効にしても、既存の [Rules Engine](/automation/rules_engine/about/) のルールには何の変更もなく、それらを移行しなければならない期限もありません。 + +実際に移行したくなったときのために、converter(変換ツール)が用意されています。これは、Rules Engine のルール(フィルターと順序付けられたアクションのリスト)を、それと同等の Rules Engine 2.0 のグラフに変換します。 + +## Converter が保証すること + +**ルールは、きれいに変換されるか、まったく変換されないかのどちらかです。** すべての変換は、次の2種類の結果を報告します。 + +* **Problems** は、ルールが書き込まれなかったことを意味します。部分的な保存は一切行われません。 +* **Warnings** は、ルールは変換されたものの、何かが変化したため確認すべき点があることを意味します。 + +何かが黙って近似されることはありません。この converter の価値の本質は、特に指摘なく変換されたルールは信頼でき、そうでなかったものは手動で確認できるという点にあります。 + +**変換されたルールは常に無効な状態で作成されます。** 両方のエンジンが稼働している状況で、同じ Finding に対して同じことを行う2つのルールが存在してしまうことは、converter が自ら引き起こしてはならない唯一の結果です。変換された各ルールを確認し、意図的に有効化してください。 + +**ルールの変換は一度きりです。** 変換された各ルールは、その変換元となったルールを記憶しているため、converter を2回実行しても、既に変換済みのものはスキップされ、重複が作成されることはありません。以前に変換したグラフを意図的に置き換えたい場合は、overwrite オプションを使用してください。 + +## Converter の実行 + +### UI から実行する + +ルール一覧には変換用のアクションが用意されており、ルールごとに何が変換され、何がスキップされ、何が失敗したかが報告されます。 + +### コマンドラインから実行する + +```bash +python manage.py convert_rules_to_v2 +``` + +| オプション | 効果 | +|--------|--------| +| `--dry-run` | 各ルールが生成するはずのグラフを表示し、何も書き込みません。 | +| `--rule-ids 1,2,3` | 指定したルールのみを変換します。省略した場合はすべてのルールを変換します。 | +| `--overwrite` | 変換済みルールのグラフをスキップする代わりに置き換え、そのバージョンを上げます。 | +| `--activate-schedules` | 各スケジュールも変換後のルールにコピーします。デフォルトではオフです。 | +| `--drop-invalid-filters` | ルールを失敗させる代わりに、フィルターセットがもはや認識しないスコープフィルターを削除し、警告を出します。 | +| `--json` | レポートをテキストではなく JSON として出力します。 | + +このコマンドは、ルールの変換に失敗した場合にのみ、非ゼロで終了します。スキップは報告されますが、失敗とはみなされません。 + +まずは全ルールに対して `--dry-run` を実行し、何が起きるかを確認してから、実際に変換してください。 + +## 変換によって生成されるもの + +| Rules Engine の概念 | 変換後 | +|----------------------|---------| +| ルールのフィルター | トリガーノード上の **Scope**。 | +| スケジュールを持つルール | **On a Schedule** トリガー。 | +| スケジュールを持たないルール | **Manual Run** トリガー。 | +| 各アクション(順序通り) | 同じ順序で連結された1つのノード。 | +| 条件で制御されたアクション | そのノードの手前に配置される **If / Filter** ノード。 | + +フィルターの語彙は両エンジン間で共有されているため、scope は変換の必要なくそのまま移行されます。これは意図的な設計であり、実装は1つでも、フィルターセット自体は同一だからです。 + +変換されたグラフは、手作業で構築したグラフと同じ方法で検証されます。これには、ノードごとの設定や、各ドロップダウンで許容される値も含まれます。製品側で既に廃止された深刻度や risk の値を保持しているルールは、実行時ではなく変換時に検出されます。 + +## 引き継がれないもの + +計画しておくべき点が4つあります。converter は、これらを実行のたびに注記として報告します。 + +* **Run の履歴はそのままの場所に残ります。** 既存の実行履歴、およびそれに関連する対象レコードとスキップされたレコードは、Rules Engine の UI に残ったままになります。これらはコピーされません。 +* **スケジュールはデフォルトでは有効化されません。** スケジュールトリガーのルールは変換されますが、`--activate-schedules` を指定しない限り、そのスケジュールはコピーされません。これにより、両エンジンが稼働している間、稼働中のスケジュールの所有権は従来のエンジンだけが持つことになり、変換されたルールが気づかないうちに発火し始めることはありません。実際にスケジュールをコピーする場合、コピーには元のものと衝突しないよう別の名前が付けられます。 +* **並行実行モデルが異なります。** Rules Engine には、インスタンス全体で1つの実行ロックがあります。Rules Engine 2.0 はルールごとに直列化されるため、異なるルールは同時に実行されます。これまで順番に実行されていたルール群が、これからは重複して実行されるようになります。 +* **1つのアクションには相当するものがありません。** 「false positive を false に設定する」アクションは Rules Engine 2.0 のノードとして表現できないため、手動で変換する必要があります。 + +所有者が設定されていないルールも、警告付きで変換されます。所有者のいないルールはどの Finding も参照できないことを忘れずに、有効化する前に所有者を割り当ててください。 + +## 推奨される手順 + +1. Rules Engine 2.0 を有効にし、既存のルールはそのまま稼働させておきます。 +2. `--dry-run` を付けて converter を実行し、レポートを確認します。 +3. 変換します。すべて無効な状態になります。 +4. 変換された各ルールを開き、グラフを確認し、モードは **Simulate** のままにしておきます。 +5. 変換されたルールを有効化し、しばらくの間、元のルールと並行して実行させます。Simulate では Finding は変更されますが何も送信されないため、その Run の内容を元のルールが行っていたことと比較します。 +6. 問題がないことを確認できたら、元のルールを無効化し、変換されたルールを **Live** に切り替えます。 +7. 古いルールがもう何も実行しなくなったら、最後にスケジュールをコピーします。 + +手順5は省略しない価値があります。両方のエンジンが同じ Finding を編集すること自体は観察する分には問題ありませんが、送信をいつ開始するかを決めるのはあなた自身であるべきです。 diff --git a/docs/content/automation/rules_engine_2/deliveries.de.md b/docs/content/automation/rules_engine_2/deliveries.de.md new file mode 100644 index 00000000000..3dc87d89b0d --- /dev/null +++ b/docs/content/automation/rules_engine_2/deliveries.de.md @@ -0,0 +1,120 @@ +--- +title: Zustellungen +description: Das Protokoll aller ausgehenden Sendungen von Regeln sowie der Funktionsweise + von Wiederholungsversuchen und erneutem Senden +weight: 5 +audience: pro +aliases: +- /de/automation/rules_engine_v2/deliveries/ +--- + +Hinweis: Rules Engine 2.0 ist eine Funktion, die nur in DefectDojo Pro verfügbar ist. + +Jeder ausgehende Nebeneffekt, den eine Regel erzeugt, ist eine Zeile im Zustellungsprotokoll. **Rules Engine 2.0 > Deliveries** listet sie auf. + +Die Zeile wird geschrieben, **bevor** ein Netzwerkaufruf stattfindet, und sie enthält genau das, was gesendet werden würde oder wurde. Das macht ausgehenden Datenverkehr überprüfbar, statt sich auf eine Logzeile zu verlassen, in der Hoffnung, dass sie jemand aufbewahrt hat, und deshalb ist Simulieren kein eigener Codepfad: Ein simulierter Versand ist dieselbe Zeile, nur ohne den Versandschritt. + +## Was eine Zustellung erfasst + +| Feld | Bedeutung | +|-------|---------| +| **Ausführung** und **Knoten** | Welche Ausführung und welcher Egress-Knoten sie erzeugt hat. | +| **Finding** | Der Befund, um den es bei einem Versand pro Befund geht. Sammelversände erfassen stattdessen die Gruppe. | +| **Channel** | Um welche Art von Versand es sich handelt. | +| **Target** | Das aufgelöste Ziel: ein JIRA-Projektschlüssel, ein Kanal, eine URL, eine Adresse. | +| **Title** | Eine einzeilige Beschreibung des Versands. | +| **Payload** | Genau das, was gesendet werden würde oder wurde. | +| **Mode** | `simulate` oder `live`. | +| **Status** | Wie weit die Zustellung gekommen ist. | +| **Attempts** | Wie viele Versandversuche bereits unternommen wurden, gemessen am zulässigen Maximum. | +| **Last error** | Warum der letzte Versuch fehlgeschlagen ist, oder warum die Zustellung übersprungen wurde. | +| **Response** | Was das Ziel zurückgemeldet hat. | +| **External reference** und **URL** | Der Ticketschlüssel, die Nachrichten-ID oder der Dateipfad, den das Ziel zurückgegeben hat, sowie ein Link dazu, falls vorhanden. | + +## Kanäle + +| Kanal | Erzeugt von | +|---------|-------------| +| **JIRA** | Ein JIRA-Issue erstellen | +| **Downstream connector** | Ein Downstream-Ticket erstellen | +| **Slack** | Eine Slack-Nachricht senden, sowie Berichtsankündigungen, die an Slack gesendet werden | +| **Microsoft Teams** | Eine Microsoft-Teams-Nachricht senden | +| **Email** | Eine E-Mail senden, sowie Berichtsankündigungen, die per E-Mail gesendet werden | +| **Webhook** | Einen Webhook aufrufen | +| **Report** | Einen Bericht erstellen | +| **In-app alert** | Eine In-App-Benachrichtigung auslösen | + +## Status-Werte + +| Status | Bedeutung | +|--------|---------| +| `simulated` | Die Regel befand sich im Simulationsmodus. Es wurde nichts gesendet, und es wird auch nie etwas gesendet werden. | +| `skipped` | Etwas anderes deckte diesen Versand bereits ab, oder eine Gating-Prüfung hat ihn abgelehnt. Der Grund steht im Feld „Last error“. | +| `pending` | Im Live-Modus erfasst, wartet auf ihre Zustellungsaufgabe. | +| `dispatched` | An den Integrationsdienst übergeben, wartet auf Bestätigung. | +| `sent` | Zustellung bestätigt. | +| `failed` | Endgültig abgelehnt, zum Beispiel durch einen 4xx-Fehler oder einen Fehler des Anbieters. Kann wiederholt werden. | +| `dead` | Wiederholungsversuche ausgeschöpft, oder es kam nie eine Bestätigung an. Kann wiederholt werden. | + +`skipped` verdient eine genauere Betrachtung. Übersprungene Versände werden erfasst statt stillschweigend übergangen, denn „die Regel hat nichts getan“ und „die Regel hat nichts getan, weil dieser Befund bereits ein Ticket hatte“ sind unterschiedliche Antworten, und nur eine davon ist ein Problem. + +Es gibt drei häufige Gründe für ein Überspringen, und das Feld „Last error“ nennt immer den jeweiligen: + +* **Idempotenz.** Etwas anderes deckte diesen Versand bereits ab. +* **Der Kanal ist ausgeschaltet.** Eine Regel mit einem Slack-Knoten auf einer Instanz, auf der Slack deaktiviert ist, erfasst ein Überspringen mit entsprechender Erklärung, anstatt fehlzuschlagen. Eine Regel, die gespeichert wurde, während ein Kanal aktiv war, soll nicht plötzlich Fehler werfen, wenn ihn jemand abschaltet. Siehe [Verfügbarkeit von Knoten](../node_reference/#when-a-channel-is-unavailable). +* **Die Obergrenze für Versände pro Befund wurde erreicht.** Ein Knoten, der eine Nachricht pro Befund sendet, stoppt standardmäßig nach 1.000 Nachrichten in einer einzelnen Ausführung und erfasst, für wie viele weitere Befunde nichts gesendet wurde. + +### Payload-Genauigkeit + +Das Protokoll gibt ehrlich an, wie nah die erfasste Payload der tatsächlich übertragenen Nutzlast kommt, denn das ist je nach Kanal unterschiedlich. + +| Genauigkeit | Bedeutung | +|----------|---------| +| `exact` | Byte-identisch mit dem, was gesendet wurde. | +| `rendered` | Von den echten Hilfsfunktionen gerendert, aber ein Gating zum Zeitpunkt des Versands kann sie noch kürzen. | +| `dojo request` | Die exakte Anfrage, die an den Integrationsdienst übergeben wurde. Die anbieterspezifische Payload wird nachgelagert zusammengesetzt. | +| `summary` | Eine Beschreibung des Versands statt einer Reproduktion davon. Ein generierter Bericht ist das Beispiel dafür: Die Datei wird zum Zeitpunkt des Versands aus Live-Daten erstellt, sodass eine gespeicherte Kopie davon in dem Moment falsch wäre, in dem sich irgendetwas ändert. | + +## Der Schutz vor doppeltem Versand + +Pro Idempotenzschlüssel kann nur eine **aktive** Zustellung existieren, durchgesetzt in der Datenbank und nicht nur per Konvention. Aktiv bedeutet `pending`, `dispatched` oder `sent`. + +Ein zweiter Versand, der mit einem aktiven kollidieren würde, wird zu einer `skipped`-Zeile mit erfasstem Grund. Es ist niemals ein stiller No-Op, und es ist niemals ein doppeltes Ticket. + +Da Zeilen mit `simulated`, `skipped`, `failed` und `dead` keinen Anspruch belegen, kann eine fehlgeschlagene Zustellung an Ort und Stelle wiederholt werden, ohne dass eine zweite Zeile um denselben Schlüssel konkurriert. + +## Wiederholungsversuche + +Eine Live-Zustellung wird automatisch wiederholt. Jede Zeile führt ihren eigenen Versuchszähler und ihre eigene Obergrenze, standardmäßig sechs Versuche, sodass ein fehlschlagendes Ziel nicht auch die anderen mit sich reißen kann. Zwischen den Versuchen liegt eine Verzögerung, die mit jedem Versuch wächst. + +Wenn der letzte Wiederholungsversuch verbraucht ist, wird die Zeile als `dead` markiert, statt bei `pending` liegen zu bleiben. Erschöpfung ist sichtbar, nicht stillschweigend. + +Wird ein Worker mitten im Versand beendet, wird die Nachricht erneut zugestellt. Die Zeile wird gesperrt und ihr Status erneut geprüft, bevor irgendetwas erneut gesendet wird, sodass eine erneute Zustellung nicht zu einem doppelten Versand werden kann. + +Zustellungen, die an den Integrationsdienst übergeben wurden, wechseln zu `dispatched` und warten auf einen Bestätigungs-Callback. Trifft innerhalb von sechs Stunden kein Callback ein, wird die Zeile als `dead` markiert, damit sie wiederholt werden kann. Dieses Zeitfenster ist bewusst großzügig bemessen: Dass sich eine nachgelagerte Warteschlange eine Stunde lang staut, ist normal, und eine Zeile zu früh für tot zu erklären, würde aus einer Wiederholung ein doppeltes Ticket machen. + +## Eine Zustellung wiederholen + +Eine `failed`- oder `dead`-Zustellung kann von der Deliveries-Seite aus erneut gesendet werden. Das Protokoll erfasst, wann und von wem sie wiederholt wurde. + +Für das Wiederholen ist **Regel bearbeiten** erforderlich. + +Beim Wiederholen wird die erfasste Payload erneut gesendet. Bei einem Bericht bedeutet das, dass der Bericht aus den aktuellen Daten neu erzeugt wird, denn die Payload ist eine Beschreibung dessen, was erzeugt werden soll, und nicht die Datei selbst. + +## Simulieren + +Im Simulationsmodus schreibt jeder Egress-Knoten seine Zustellungszeile mit dem Status `simulated`, der vollständigen Payload und dem aufgelösten Ziel, und stoppt dann. Es wird kein Versand registriert, sodass später nichts gesendet werden kann, wie auch immer die Ausführung endet. Die Vorschau verhält sich genauso und fügt die Zeilen nicht einmal ein. + +Das ist der vorgesehene Weg, um eine Regel zu prüfen, bevor man sie freigibt: im Simulationsmodus aktivieren, gegen echte Befunde laufen lassen, und dann die erfassten Payloads lesen. + +Bedenken Sie, dass der Simulationsmodus **nur** die ausgehenden Versände zurückhält. Befunde-Knoten verändern Befunde weiterhin. + +## Aufbewahrung + +Zustellungen werden standardmäßig **180 Tage** aufbewahrt, danach entfernt ein Aufbewahrungsjob sie. + +Das ist die am schnellsten wachsende Tabelle in dieser Funktion, denn ein Knoten, der eine Nachricht pro Befund sendet, schreibt eine Zeile pro Befund, sowohl im Simulationsmodus als auch im Live-Modus. Der Standardwert ist ein echtes Zeitfenster statt „alles behalten“, damit das Wachstum nicht unbemerkt zu Ihrem Problem wird. + +Sie werden darüber informiert, statt es selbst entdecken zu müssen. Die Detailansicht einer Zustellung zeigt das Aufbewahrungsfenster und das Datum, an dem diese Zeile gelöscht wird, und das Datum wird bei jedem Lesevorgang neu berechnet, sodass eine Änderung des Zeitfensters sofort wirksam wird. + +Stellen Sie das Zeitfenster länger ein, wenn Sie eine längere Nachweiskette für ausgehende Sendungen benötigen, oder auf `0`, um alles zu behalten. Siehe [Konfiguration](../configuration/#retention). diff --git a/docs/content/automation/rules_engine_2/deliveries.es.md b/docs/content/automation/rules_engine_2/deliveries.es.md new file mode 100644 index 00000000000..98523d99153 --- /dev/null +++ b/docs/content/automation/rules_engine_2/deliveries.es.md @@ -0,0 +1,120 @@ +--- +title: Entregas +description: El registro de todo lo que las reglas envían hacia afuera, y cómo funcionan + los reintentos y la repetición +weight: 5 +audience: pro +aliases: +- /es/automation/rules_engine_v2/deliveries/ +--- + +Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro. + +Cada efecto secundario saliente que produce una regla es una fila en el registro de entregas. **Rules Engine 2.0 > Entregas** las enumera. + +La fila se escribe **antes** de que ocurra cualquier llamada de red, y contiene exactamente lo que se enviaría, o lo que se envió. Eso es lo que hace que el tráfico de salida sea auditable en lugar de una línea de registro que uno espera que alguien haya conservado, y es la razón por la que **Simulate** no es una ruta de código independiente: un envío simulado es la misma fila con el paso de despacho omitido. + +## Qué registra una entrega + +| Campo | Significado | +|-------|---------| +| **Run** y **Node** | Qué ejecución y qué nodo de salida la produjo. | +| **Finding** | El Hallazgo al que se refiere, para un envío por Hallazgo. Los envíos por lotes registran el grupo en su lugar. | +| **Channel** | Qué tipo de envío es. | +| **Target** | El destino resuelto: una clave de proyecto de JIRA, un canal, una URL, una dirección. | +| **Title** | Una descripción de una línea del envío. | +| **Payload** | Exactamente lo que se enviaría, o lo que se envió. | +| **Mode** | `simulate` o `live`. | +| **Status** | Hasta dónde llegó la entrega. | +| **Attempts** | Cuántos envíos se han intentado, respecto al máximo permitido. | +| **Last error** | Por qué falló el último intento, o por qué se omitió la entrega. | +| **Response** | Qué respondió el destino. | +| **External reference** y **URL** | La clave del ticket, el id del mensaje o la ruta del archivo que devolvió el destino, y un enlace a él cuando existe. | + +## Canales + +| Channel | Producido por | +|---------|-------------| +| **JIRA** | Crear una incidencia de JIRA | +| **Downstream connector** | Crear un ticket downstream | +| **Slack** | Enviar un mensaje de Slack, y anuncios de informes enviados a Slack | +| **Microsoft Teams** | Enviar un mensaje de Microsoft Teams | +| **Email** | Enviar un correo electrónico, y anuncios de informes enviados por correo electrónico | +| **Webhook** | Llamar a un webhook | +| **Report** | Generar un informe | +| **In-app alert** | Generar una alerta en la aplicación | + +## Estados + +| Status | Meaning | +|--------|---------| +| `simulated` | La regla estaba en modo Simulate. No se envió nada, y nunca se enviará. | +| `skipped` | Algo ya cubría este envío, o el control de acceso lo rechazó. La razón está en el campo del último error. | +| `pending` | Registrada en modo Live, esperando su tarea de entrega. | +| `dispatched` | Entregada al servicio de integración, esperando confirmación. | +| `sent` | Confirmada como entregada. | +| `failed` | Rechazada permanentemente, por ejemplo un 4xx o un error del proveedor. Se puede repetir. | +| `dead` | Reintentos agotados, o nunca llegó confirmación. Se puede repetir. | + +Vale la pena detenerse en `skipped`. Las omisiones se registran en lugar de pasar en silencio, porque "la regla no hizo nada" y "la regla no hizo nada porque este Hallazgo ya tenía un ticket" son respuestas diferentes, y solo una de ellas es un problema. + +Hay tres razones comunes para una omisión, y el campo del último error siempre indica cuál: + +* **Idempotencia.** Algo ya cubría este envío. +* **El canal está desactivado.** Una regla con un nodo de Slack en una instancia donde Slack está deshabilitado registra una omisión que lo explica, en lugar de fallar. Una regla guardada mientras un canal estaba activo no debería empezar a generar errores cuando alguien lo desactiva. Consulte [disponibilidad de nodos](../node_reference/#when-a-channel-is-unavailable). +* **Se alcanzó el límite de envíos por Hallazgo.** Un nodo que envía un mensaje por Hallazgo se detiene después de 1000 en una sola ejecución de forma predeterminada, y registra cuántos quedaron sin enviar. + +### Fidelidad del payload + +El registro es transparente sobre cuán cercano está el payload registrado al cuerpo real transmitido, porque eso varía según el canal. + +| Fidelity | Meaning | +|----------|---------| +| `exact` | Equivalente byte a byte a lo que se envió. | +| `rendered` | Renderizado por los helpers reales, pero el control de acceso en el momento del envío aún puede recortarlo. | +| `dojo request` | La solicitud exacta entregada al servicio de integración. El payload específico del proveedor se compone más adelante (downstream). | +| `summary` | Una descripción del envío en lugar de una reproducción de este. Un informe generado es el ejemplo: el archivo se construye a partir de datos en vivo en el momento del envío, por lo que una copia almacenada de él sería incorrecta en cuanto algo cambiara. | + +## La protección contra doble envío + +Solo puede existir una entrega **activa** por clave de idempotencia, lo cual se aplica en la base de datos y no por convención. Activa significa `pending`, `dispatched` o `sent`. + +Un segundo envío que colisionaría con uno activo se convierte en una fila `skipped` con su razón registrada. Nunca es una operación silenciosa sin efecto, y nunca es un ticket duplicado. + +Dado que las filas `simulated`, `skipped`, `failed` y `dead` no retienen una reserva, una entrega fallida puede repetirse en el mismo lugar sin que una segunda fila compita por la misma clave. + +## Reintentos + +Una entrega en vivo se reintenta automáticamente. Cada fila lleva su propio contador de intentos y su propio límite, seis intentos de forma predeterminada, de modo que un destino que falla no puede arrastrar consigo a sus filas hermanas. Los reintentos aplican un retroceso entre intentos. + +Cuando se agota el último reintento, la fila se marca como `dead` en lugar de dejarla estancada en `pending`. El agotamiento es visible, no silencioso. + +Si un worker se interrumpe a mitad de un envío, el mensaje se vuelve a entregar. La fila se bloquea y se vuelve a comprobar su estado antes de enviar nada de nuevo, de modo que una reentrega no puede convertirse en un doble envío. + +Las entregas transferidas al servicio de integración pasan a `dispatched` y esperan un callback de confirmación. Si no llega ningún callback en un plazo de seis horas, la fila se marca como `dead` para que pueda repetirse. Esa ventana es deliberadamente generosa: que una cola downstream se acumule durante una hora es normal, y marcar una fila como agotada demasiado pronto convertiría una repetición en un ticket duplicado. + +## Repetir una entrega + +Una entrega `failed` o `dead` puede reenviarse desde la página Entregas. El registro anota cuándo se repitió y por quién. + +Repetir requiere **Rule Edit**. + +Repetir reenvía el payload registrado. Para un informe, eso regenera el informe a partir de los datos actuales, porque el payload es una descripción de lo que se debe generar y no el archivo en sí. + +## Simulate + +En modo Simulate, cada nodo de salida escribe su fila de entrega con estado `simulated`, el payload completo y el destino resuelto, y luego se detiene. No se registra ningún despacho, de modo que nada puede enviarse más tarde sin importar cómo se resuelva la ejecución. Preview se comporta de la misma manera, y ni siquiera inserta las filas. + +Esta es la forma prevista de revisar una regla antes de ponerla en producción: habilítela en Simulate, déjela ejecutarse contra Hallazgos reales, y luego lea los payloads que registró. + +Recuerde que Simulate retiene **únicamente** los envíos salientes. Los nodos de Hallazgos siguen modificando los Hallazgos. + +## Retención + +Las entregas se conservan durante **180 días** de forma predeterminada, después de lo cual un trabajo de retención las elimina. + +Esta es la tabla que crece más rápido en la función, porque un nodo que envía un mensaje por Hallazgo escribe una fila por Hallazgo, tanto en modo Simulate como en Live. El valor predeterminado es una ventana real en lugar de "conservar todo", de modo que el crecimiento no se convierta silenciosamente en su problema. + +Se le informa al respecto en lugar de dejar que lo descubra por sí mismo. El detalle de una entrega muestra la ventana de retención y la fecha en que esa fila se eliminará, y la fecha se recalcula en cada lectura, de modo que cambiar la ventana surte efecto de inmediato. + +Establezca una ventana más larga si necesita un registro de auditoría de salida más extenso, o `0` para conservar todo. Consulte [Configuración](../configuration/#retention). diff --git a/docs/content/automation/rules_engine_2/deliveries.fr.md b/docs/content/automation/rules_engine_2/deliveries.fr.md new file mode 100644 index 00000000000..0313346d379 --- /dev/null +++ b/docs/content/automation/rules_engine_2/deliveries.fr.md @@ -0,0 +1,120 @@ +--- +title: Livraisons +description: Le registre de tout ce que les règles envoient vers l'extérieur, ainsi + que le fonctionnement des nouvelles tentatives et de la relecture +weight: 5 +audience: pro +aliases: +- /fr/automation/rules_engine_v2/deliveries/ +--- + +Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro. + +Chaque effet secondaire sortant produit par une règle correspond à une ligne du registre des livraisons. **Rules Engine 2.0 > Livraisons** les répertorie. + +La ligne est écrite **avant** tout appel réseau, et elle contient exactement ce qui sera, ou a été, envoyé. C'est ce qui rend les envois sortants auditables plutôt qu'une ligne de journal que l'on espère avoir conservée, et c'est pourquoi **Simulate** n'est pas un chemin de code distinct : un envoi simulé correspond à la même ligne, l'étape de dispatch étant simplement ignorée. + +## Ce qu'une livraison enregistre + +| Champ | Signification | +|-------|---------| +| **Exécution** et **Nœud** | L'exécution et le nœud de sortie qui l'ont produite. | +| **Constatation** | La Constatation concernée, pour un envoi par Constatation. Les envois groupés enregistrent le groupe à la place. | +| **Canal** | Le type d'envoi. | +| **Cible** | La destination résolue : une clé de projet JIRA, un canal, une URL, une adresse. | +| **Titre** | Une description en une ligne de l'envoi. | +| **Payload** | Exactement ce qui sera, ou a été, envoyé. | +| **Mode** | `simulate` ou `live`. | +| **Statut** | Où en est la livraison. | +| **Tentatives** | Le nombre d'envois déjà tentés, par rapport au maximum autorisé. | +| **Dernière erreur** | La raison de l'échec de la dernière tentative, ou de l'omission de la livraison. | +| **Réponse** | Ce que la destination a répondu. | +| **Référence externe** et **URL** | La clé de ticket, l'identifiant de message ou le chemin de fichier renvoyé par la destination, ainsi qu'un lien vers celui-ci lorsqu'il existe. | + +## Canaux + +| Canal | Produit par | +|---------|-------------| +| **JIRA** | Créer un ticket JIRA | +| **Downstream connector** | Créer un ticket en aval | +| **Slack** | Envoyer un message Slack, ainsi que les annonces de rapports envoyées vers Slack | +| **Microsoft Teams** | Envoyer un message Microsoft Teams | +| **Email** | Envoyer un e-mail, ainsi que les annonces de rapports envoyées par e-mail | +| **Webhook** | Appeler un webhook | +| **Rapport** | Générer un rapport | +| **In-app alert** | Déclencher une alerte intégrée | + +## Statuts + +| Statut | Signification | +|--------|---------| +| `simulated` | La règle était en mode Simulate. Rien n'a été envoyé, et rien ne le sera jamais. | +| `skipped` | Un élément couvrait déjà cet envoi, ou le filtrage l'a refusé. La raison figure dans le champ Dernière erreur. | +| `pending` | Enregistrée en mode Live, en attente de sa tâche de livraison. | +| `dispatched` | Transmise au service d'intégration, en attente de confirmation. | +| `sent` | Livraison confirmée. | +| `failed` | Rejetée définitivement, par exemple une erreur 4xx ou une erreur du fournisseur. Peut être rejouée. | +| `dead` | Nouvelles tentatives épuisées, ou aucune confirmation n'est jamais arrivée. Peut être rejouée. | + +`skipped` mérite qu'on s'y attarde. Les omissions sont enregistrées plutôt que silencieuses, car « la règle n'a rien fait » et « la règle n'a rien fait parce que cette Constatation avait déjà un ticket » sont deux réponses différentes, et une seule d'entre elles pose problème. + +Il existe trois raisons courantes à une omission, et le champ Dernière erreur indique toujours laquelle : + +* **Idempotence.** Un élément couvrait déjà cet envoi. +* **Le canal est désactivé.** Une règle comportant un nœud Slack sur une instance où Slack est désactivé enregistre une omission l'expliquant, plutôt que d'échouer. Une règle enregistrée alors qu'un canal était actif ne doit pas se mettre à générer des erreurs quand quelqu'un le désactive. Voir [disponibilité des nœuds](../node_reference/#when-a-channel-is-unavailable). +* **Le plafond d'envoi par Constatation a été atteint.** Un nœud envoyant un message par Constatation s'arrête par défaut après 1 000 envois au cours d'une même exécution, et enregistre le nombre de Constatations pour lesquelles il n'a pas envoyé de message. + +### Fidélité du payload + +Le registre indique honnêtement à quel point le payload enregistré est proche du corps réel envoyé sur le réseau, car cela varie selon le canal. + +| Fidélité | Signification | +|----------|---------| +| `exact` | Équivalent, octet pour octet, à ce qui a été envoyé. | +| `rendered` | Généré par les mêmes fonctions d'assistance réelles, mais le filtrage au moment de l'envoi peut encore le réduire. | +| `dojo request` | La requête exacte transmise au service d'intégration. Le payload propre au fournisseur est composé en aval. | +| `summary` | Une description de l'envoi plutôt qu'une reproduction de celui-ci. Un rapport généré en est l'exemple : le fichier est construit à partir de données en direct au moment de l'envoi, si bien qu'une copie stockée serait erronée dès que quelque chose changerait. | + +## La protection contre les doubles envois + +Une seule livraison **active** peut exister par clé d'idempotence, ce qui est imposé au niveau de la base de données plutôt que par convention. Active signifie `pending`, `dispatched` ou `sent`. + +Un second envoi qui entrerait en collision avec un envoi actif devient une ligne `skipped` dont la raison est enregistrée. Ce n'est jamais une absence d'action silencieuse, et ce n'est jamais un ticket en double. + +Comme les lignes `simulated`, `skipped`, `failed` et `dead` ne détiennent pas de réservation, une livraison échouée peut être rejouée sur place sans qu'une seconde ligne n'entre en conflit avec elle pour la même clé. + +## Nouvelles tentatives + +Une livraison en mode Live fait l'objet de nouvelles tentatives automatiques. Chaque ligne porte son propre compteur de tentatives et son propre plafond, six tentatives par défaut, de sorte qu'une destination défaillante ne peut pas entraîner ses voisines dans sa chute. Les nouvelles tentatives s'espacent progressivement entre chaque essai. + +Une fois la dernière tentative épuisée, la ligne est marquée `dead` plutôt que laissée à l'état `pending`. L'épuisement des tentatives est visible, pas silencieux. + +Si un worker est interrompu en pleine transmission, le message est redélivré. La ligne est verrouillée et son statut est revérifié avant tout nouvel envoi, de sorte qu'une redélivrance ne peut pas se transformer en double envoi. + +Les livraisons transmises au service d'intégration passent à l'état `dispatched` et attendent un rappel de confirmation. Si aucun rappel n'arrive dans un délai de six heures, la ligne est marquée `dead` afin de pouvoir être rejouée. Ce délai est délibérément généreux : une file d'attente en aval accumulant du retard pendant une heure est normal, et enterrer une ligne trop rapidement transformerait une relecture en ticket en double. + +## Rejouer une livraison + +Une livraison `failed` ou `dead` peut être renvoyée depuis la page Livraisons. Le registre enregistre quand elle a été rejouée et par qui. + +La relecture nécessite la permission **Rule Edit**. + +La relecture renvoie le payload enregistré. Pour un rapport, cela régénère le rapport à partir des données actuelles, car le payload est une description de ce qu'il faut générer plutôt que le fichier lui-même. + +## Simulate + +En mode Simulate, chaque nœud de sortie écrit sa ligne de livraison avec le statut `simulated`, le payload complet et la cible résolue, puis s'arrête. Aucun dispatch n'est enregistré, si bien que rien ne peut être envoyé plus tard, quelle que soit la façon dont l'exécution se déroule. Preview se comporte de la même manière, et n'insère même pas les lignes. + +C'est la manière prévue de revoir une règle avant de la mettre en production : l'activer en mode Simulate, la laisser s'exécuter sur des Constatations réelles, puis lire les payloads qu'elle a enregistrés. + +Gardez à l'esprit que Simulate ne retient **que** les envois sortants. Les nœuds de type Constatations continuent de modifier les Constatations. + +## Rétention + +Les livraisons sont conservées **180 jours** par défaut, après quoi une tâche de rétention les supprime. + +C'est la table qui croît le plus rapidement dans cette fonctionnalité, car un nœud envoyant un message par Constatation écrit une ligne par Constatation, aussi bien en mode Simulate qu'en mode Live. La valeur par défaut est une véritable fenêtre plutôt que « tout conserver », afin que cette croissance ne devienne pas discrètement votre problème. + +Vous en êtes informé plutôt que d'avoir à le découvrir. Le détail d'une livraison affiche la fenêtre de rétention et la date à laquelle cette ligne sera supprimée, et cette date est recalculée à chaque lecture, de sorte que la modification de la fenêtre prend effet immédiatement. + +Allongez la fenêtre si vous avez besoin d'une piste d'audit sortante plus longue, ou réglez-la sur `0` pour tout conserver. Voir [Configuration](../configuration/#retention). diff --git a/docs/content/automation/rules_engine_2/deliveries.ja.md b/docs/content/automation/rules_engine_2/deliveries.ja.md new file mode 100644 index 00000000000..0ba44fe2672 --- /dev/null +++ b/docs/content/automation/rules_engine_2/deliveries.ja.md @@ -0,0 +1,119 @@ +--- +title: 配信 +description: ルールが外部へ送信するすべてを記録する台帳と、再試行および再送の仕組み +weight: 5 +audience: pro +aliases: +- /ja/automation/rules_engine_v2/deliveries/ +--- + +注: Rules Engine 2.0 は DefectDojo Pro 限定の機能です。 + +ルールが生成するすべての送信(アウトバウンド)側の副作用は、配信台帳の1行になります。**Rules Engine 2.0 > Deliveries** にその一覧が表示されます。 + +この行はネットワーク呼び出しが発生する**前**に書き込まれ、送信される(または送信された)内容を正確に保持します。これにより、送信(egress)は「誰かが保存していることを願うログ行」ではなく、監査可能なものになります。また、これが **Simulate** が別のコードパスではない理由でもあります。シミュレーション送信は、ディスパッチ手順が省略されただけの、同じ行なのです。 + +## 配信が記録する項目 + +| フィールド | 意味 | +|-------|---------| +| **Run** と **Node** | どの実行(Run)とどの送信ノード(Node)がこれを生成したか。 | +| **Finding** | 検出事項単位の送信の場合、対象となる検出事項。バッチ送信の場合はグループを記録します。 | +| **Channel** | 送信の種類。 | +| **Target** | 解決済みの送信先: JIRAプロジェクトキー、チャネル、URL、アドレスなど。 | +| **Title** | 送信内容の一行説明。 | +| **Payload** | 送信される(または送信された)内容そのもの。 | +| **Mode** | `simulate` または `live`。 | +| **Status** | 配信がどこまで到達したか。 | +| **Attempts** | これまでに試行された送信回数と、許容される最大回数。 | +| **Last error** | 直前の試行が失敗した理由、または配信がスキップされた理由。 | +| **Response** | 送信先から返された応答。 | +| **External reference** と **URL** | 送信先が返したチケットキー、メッセージID、ファイルパスと、存在する場合はそこへのリンク。 | + +## チャネル + +| チャネル | 生成元 | +|---------|-------------| +| **JIRA** | JIRA課題を作成 | +| **Downstream connector** | ダウンストリームチケットを作成 | +| **Slack** | Slackメッセージを送信、およびSlackへ送信されるレポート通知 | +| **Microsoft Teams** | Microsoft Teamsメッセージを送信 | +| **Email** | メールを送信、およびメールで送信されるレポート通知 | +| **Webhook** | Webhookを呼び出す | +| **Report** | レポートを生成 | +| **In-app alert** | アプリ内アラートを発行 | + +## ステータス + +| ステータス | 意味 | +|--------|---------| +| `simulated` | ルールが Simulate モードだったことを示します。何も送信されておらず、今後も送信されません。 | +| `skipped` | 既に何かがこの送信をカバーしていたか、ゲーティングによって拒否されたことを示します。理由は last error フィールドに記載されます。 | +| `pending` | Live モードで記録され、配信タスクの実行を待っている状態です。 | +| `dispatched` | 統合サービスに引き渡され、確認を待っている状態です。 | +| `sent` | 配信が確認された状態です。 | +| `failed` | 4xxエラーやベンダー側のエラーなど、恒久的に拒否された状態です。再送可能です。 | +| `dead` | 再試行が尽きたか、確認が一度も届かなかった状態です。再送可能です。 | + +`skipped` については詳しく説明する価値があります。スキップは黙って無視されるのではなく記録されます。なぜなら「ルールは何もしなかった」ことと「この検出事項には既にチケットがあったためルールは何もしなかった」ことは異なる答えであり、そのうち一方だけが問題だからです。 + +スキップにはよくある理由が3つあり、last error フィールドには常にそのどれであるかが記載されます。 + +* **Idempotency(べき等性)。** 何かが既にこの送信をカバーしていました。 +* **チャネルが無効化されている。** Slackが無効化されているインスタンスでSlackノードを持つルールは、失敗するのではなく、その旨を説明するスキップを記録します。チャネルが有効な状態で保存されたルールは、誰かがそのチャネルを無効化したときにエラーを出し始めるべきではありません。[ノードの利用可否](../node_reference/#when-a-channel-is-unavailable)を参照してください。 +* **検出事項単位の送信上限に達した。** 検出事項ごとに1件のメッセージを送信するノードは、デフォルトでは1回の実行につき1,000件で停止し、送信されなかった件数を記録します。 + +### ペイロードの忠実度 + +台帳は、記録されたペイロードが実際に送信されるボディにどれだけ近いかについて正直です。これはチャネルによって異なるためです。 + +| 忠実度 | 意味 | +|----------|---------| +| `exact` | 実際に送信された内容とバイト単位で同一です。 | +| `rendered` | 実際のヘルパーによってレンダリングされていますが、送信時のゲーティングによって内容が削られる場合があります。 | +| `dojo request` | 統合サービスに渡された正確なリクエストです。ベンダー固有のペイロードは下流で組み立てられます。 | +| `summary` | 送信内容そのものの再現ではなく、送信内容の説明です。生成されたレポートがその例です。ファイルは送信時点のライブデータから作成されるため、保存されたコピーは何かが変更された瞬間に不正確になってしまいます。 | + +## 二重送信防止機構 + +べき等性キーごとに存在できる**アクティブ**な配信は1件のみであり、これは慣習ではなくデータベースによって強制されます。アクティブとは `pending`、`dispatched`、または `sent` を意味します。 + +アクティブな配信と衝突する2件目の送信は、理由が記録された `skipped` 行になります。これは決して黙った無処理にはならず、重複したチケットにもなりません。 + +`simulated`、`skipped`、`failed`、`dead` の各行は権利を保持しないため、失敗した配信はその場で再送でき、同じキーを巡って2件目の行が競合することはありません。 + +## 再試行 + +Live状態の配信は自動的に再試行されます。各行はそれぞれ独自の試行回数と上限(デフォルトでは6回)を持つため、失敗している送信先が他の行を道連れにすることはありません。再試行の間隔は徐々に広がります(バックオフ)。 + +最後の再試行を使い切ると、その行は `pending` のまま放置されるのではなく `dead` としてマークされます。使い果たしたことは黙って隠されるのではなく、可視化されます。 + +ワーカーが送信途中で強制終了された場合、メッセージは再配信されます。再送信される前に行がロックされ、ステータスが再確認されるため、再配信が二重送信になることはありません。 + +統合サービスに引き渡された配信は `dispatched` に移行し、確認コールバックを待ちます。6時間以内にコールバックが届かない場合、その行は再送可能となるよう `dead` としてマークされます。この時間枠は意図的に余裕を持たせてあります。下流のキューが1時間程度滞留するのは正常なことであり、行を急いで打ち切ってしまうと、再送が重複チケットを生んでしまうためです。 + +## 配信の再送 + +`failed` または `dead` の配信は、Deliveriesページから再送できます。台帳には、いつ、誰によって再送されたかが記録されます。 + +再送には **Rule Edit** 権限が必要です。 + +再送は記録されたペイロードを再送信します。レポートの場合、ペイロードはファイルそのものではなく生成すべき内容の説明であるため、現在のデータからレポートを再生成することになります。 + +## Simulate + +Simulate モードでは、すべての送信ノードがステータス `simulated`、完全なペイロード、解決済みのターゲットを持つ配信行を書き込んだ後、停止します。ディスパッチは登録されないため、実行がどのように展開しても後から送信されることはありません。Previewも同様に動作しますが、行の挿入すら行いません。 + +これは、ルールを公開する前にレビューするために意図された方法です。Simulateで有効化し、実際の検出事項に対して実行させ、記録されたペイロードを確認します。 + +Simulateが差し止めるのは**送信のみ**であることを忘れないでください。検出事項ノードは引き続き検出事項を変更します。 + +## 保持期間 + +配信はデフォルトで**180日間**保持され、その後は保持ジョブによって削除されます。 + +これはこの機能の中で最も急速に増加するテーブルです。検出事項ごとに1件のメッセージを送信するノードは、SimulateモードでもLiveモードでも検出事項ごとに1行を書き込むためです。デフォルトは「すべて保持する」ではなく実際の期間となっているため、増加が知らぬ間に問題化することはありません。 + +発見を強いられるのではなく、あらかじめ通知されます。配信の詳細には保持期間とその行が削除される日付が表示され、この日付は読み込み時に再計算されるため、期間を変更するとすぐに反映されます。 + +より長い送信監査証跡が必要な場合は期間を長く設定し、すべて保持したい場合は `0` に設定してください。[設定](../configuration/#retention)を参照してください。 diff --git a/docs/content/automation/rules_engine_2/node_reference.de.md b/docs/content/automation/rules_engine_2/node_reference.de.md new file mode 100644 index 00000000000..f0754de767e --- /dev/null +++ b/docs/content/automation/rules_engine_2/node_reference.de.md @@ -0,0 +1,347 @@ +--- +title: Knotenreferenz +description: Jeder Knoten, den Rules Engine 2.0 mitbringt, und was er jeweils tut +weight: 3 +audience: pro +aliases: +- /de/automation/rules_engine_v2/node_reference/ +--- + +Hinweis: Rules Engine 2.0 ist eine Funktion, die nur in DefectDojo Pro verfügbar ist. + +Rules Engine 2.0 bringt 25 Knoten in vier Kategorien mit. Diese Seite dokumentiert sie alle. + +Sofern nicht anders angegeben, nimmt ein Knoten eine Eingabe entgegen, erzeugt eine Ausgabe namens `out` und gibt jedes empfangene Element an diese Ausgabe weiter. Das ist wichtig, wenn Sie Knoten verketten: Ein Befunde-Knoten verändert den Befund und reicht das Element dann weiter, sodass mehrere davon hintereinander alle wirksam werden. + +## Trigger + +Jeder Graph hat genau einen Trigger, und nur ein Trigger kann eine Ausführung starten. Alle drei erzeugen Befund-Elemente, und alle drei verwenden einen **Geltungsbereich**, der eingrenzt, welche Befunde sie erzeugen. Wie der Geltungsbereich funktioniert, erfahren Sie unter [Regeln erstellen](../building_rules/). + +### Bei einem Befund-Ereignis + +`trigger.finding` + +Läuft, wenn Befunde erstellt, aktualisiert, geschlossen oder wieder geöffnet werden. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Ereignis** | `created` | Welche Befund-Änderung diese Regel weckt: `created`, `updated`, `closed`, `reopened`, oder `any` für alle vier. | +| **Geltungsbereich** | leer | Welche Befunde diese Regel berücksichtigt. Leer bedeutet jeden Befund, den der Regel-Eigentümer sehen kann. | + +Von dem Ereignis benannte Befunde werden vor dem Eintritt in den Graphen mit dem Geltungsbereich abgeglichen, sodass das Ereignis entscheidet, *wann*, und der Geltungsbereich entscheidet, *welche*. + +### Nach Zeitplan + +`trigger.schedule` + +Durchsucht nach einem Zeitplan alle Befunde im Geltungsbereich. Der Zeitplan wird an der Regel konfiguriert und ist auf Viertelstundenmarken beschränkt. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Geltungsbereich** | leer | Welche Befunde diese Regel berücksichtigt. | + +### Manuelle Ausführung + +`trigger.manual` + +Durchsucht alle Befunde im Geltungsbereich, wenn Sie bei der Regel auf **Ausführen** klicken. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Geltungsbereich** | leer | Welche Befunde diese Regel berücksichtigt. | + +## Logik + +### Wenn / Filter + +`filter.if` + +Leitet jedes Element anhand von Bedingungen in den **true**- oder den **false**-Zweig. Das ist der einzige Knoten mit zwei Ausgängen, und so verzweigt sich ein Graph. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Bedingungen** | leer | Jede Zeile besteht aus einem Pfad, einem Operator und einem Wert. Siehe [Bedingungen](../building_rules/#conditions). | +| **Übereinstimmung** | `all` | Ob jede Bedingung erfüllt sein muss (`all`) oder nur eine davon (`any`). | + +Eine leere Bedingungsliste lässt alles in den true-Zweig durch. Beide Zweige sind optional: Wird der false-Zweig nicht verbunden, werden die nicht zutreffenden Elemente einfach verworfen. + +### Begrenzung + +`flow.limit` + +Lässt die ersten N Elemente durch und verwirft den Rest. Nützlich als Sicherheitsventil beim Testen einer Regel und um zu begrenzen, wie viele Tickets oder Nachrichten eine einzelne Ausführung erzeugen kann. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Erste behalten** | `100` | Wie viele Elemente weitergegeben werden. | + +### Innerhalb der Ausführung deduplizieren + +`flow.dedupe_batch` + +Behält das erste Element pro Schlüssel und verwirft spätere Elemente mit demselben Schlüssel. Auf die Ausführung beschränkt, sodass innerhalb einer Ausführung dedupliziert wird, nicht über mehrere Ausführungen hinweg. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Schlüsselpfad** | `finding.hash_code` | Der Element-Pfad, dessen Wert ein Duplikat identifiziert. | + +Ein gängiger Anwendungsfall ist `finding.component_name`, um einmal pro betroffener Komponente statt einmal pro Befund zu benachrichtigen. + +## Befunde + +Diese Knoten verändern Befunde. Jede Änderung wird der Regel, der Ausführung und dem Knoten zugeordnet, die sie vorgenommen haben, und erscheint in der Herkunfts-Zeitleiste des Befunds. + +### Schweregrad festlegen + +`finding.set_severity` + +Legt den Schweregrad fest und berechnet dabei das SLA-Datum und die Priorität neu. + +| Einstellung | Optionen | +|---------|---------| +| **Schweregrad** | `Critical`, `High`, `Medium`, `Low`, `Info` | + +### Ein Feld festlegen + +`finding.set_field` + +Legt ein Textfeld fest, hängt daran an oder stellt ihm etwas voran. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Feld** | keiner | Eines von `component_name`, `component_version`, `cvssv3`, `cwe`, `description`, `file_path`, `impact`, `mitigation`, `service`, `title`. | +| **Modus** | `set` | `set`, `append` oder `prepend`. Ein CVSSv3-Vektor kann nur ersetzt werden. | +| **Wert** | keiner | Der zu schreibende Text. Unterstützt Platzhalter im Stil von `{{finding.title}}`. | + +### Status festlegen + +`finding.set_status` + +Versetzt den Befund in einen Status. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Status** | keiner | `active`, `inactive`, `verified`, `unverified`, `false_positive`, `mitigated`, `reopen`. | +| **Notiz** | leer | Eine optionale Notiz, die zusammen mit der Statusänderung erfasst wird. | + +### Tags hinzufügen + +`finding.add_tags` + +Fügt dem Befund Tags hinzu. Vorhandene Tags bleiben erhalten. + +| Einstellung | Hinweise | +|---------|-------| +| **Tags** | Durch Kommas getrennt. Unterstützt Platzhalter im Stil von `{{product.name}}`, sodass Sie mit Daten aus dem Befund taggen können. | + +### Eine Notiz hinzufügen + +`finding.add_note` + +Fügt dem Befund eine Notiz hinzu. + +| Einstellung | Hinweise | +|---------|-------| +| **Notiz** | Der Notiztext. Unterstützt Platzhalter. | + +### Eigentümer festlegen + +`finding.set_owners` + +Macht eine Gruppe für den Befund verantwortlich. + +| Einstellung | Hinweise | +|---------|-------| +| **Gruppe** | Die Gruppe, der diese Befunde gehören. | + +### Prüfer festlegen + +`finding.set_reviewers` + +Stellt den Befund zur Prüfung durch die ausgewählten Benutzer. + +| Einstellung | Hinweise | +|---------|-------| +| **Prüfer** | Ein oder mehrere Benutzer, die diese Befunde prüfen sollen. | + +### Risiko akzeptieren + +`finding.risk_accept` + +Akzeptiert den Befund per einfacher Risikoakzeptanz oder fügt ihn einem Risikoakzeptanz-Datensatz hinzu. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Wie** | `simple` | `simple` setzt eine einfache Risikoakzeptanz auf den Befund. `acceptance` fügt ihn einem Risikoakzeptanz-Datensatz hinzu. | +| **Akzeptiert** | ein | Wird bei `simple` angezeigt. Ausschalten, um die Risikoakzeptanz rückgängig zu machen. | +| **Risikoakzeptanz** | keine | Wird bei `acceptance` angezeigt. Zu welcher Risikoakzeptanz diese Befunde hinzugefügt werden. | + +### Behebungsrichtlinie festlegen + +`finding.set_mitigation_policy` + +Legt die Behebungsrichtlinie fest, unter der der Befund behoben wird. + +| Einstellung | Hinweise | +|---------|-------| +| **Behebungsrichtlinie** | Die anzuwendende Richtlinie. | + +### Priorität ändern + +`finding.set_priority` + +Legt die Priorität fest oder passt sie rechnerisch an. Das überschreibt die berechnete Priorität. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Operation** | `set` | `set`, `add`, `subtract`, `multiply`, `divide`. | +| **Wert** | keiner | Die zu setzende Priorität, oder der Betrag, um den angepasst wird. | + +### Risiko festlegen + +`finding.set_risk` + +Legt das Risiko fest und überschreibt damit das berechnete. + +| Einstellung | Optionen | +|---------|---------| +| **Risiko** | `Low`, `Medium`, `Needs Action`, `Urgent` | + +## Egress + +Egress-Knoten sind die Knoten, die DefectDojo verlassen. Jeder von ihnen erfasst eine [Zustellung](../deliveries/), bevor irgendetwas gesendet wird, und jeder von ihnen beachtet den **Simulate**- oder **Live**-Modus der Regel. + +Mehrere von ihnen bieten dieselbe Option **Eine Nachricht pro Befund**. Ausgeschaltet sendet der Knoten eine Nachricht, die den gesamten Batch beschreibt, mit einer Aufschlüsselung nach Schweregrad und einer begrenzten Liste von Befunden. Eingeschaltet sendet er eine Nachricht pro Befund. + +Ein Knoten, der eine Nachricht pro Befund sendet, stoppt standardmäßig nach 1.000 Versänden in einer einzelnen Ausführung und erfasst ein sichtbares Überspringen, das angibt, für wie viele Befunde nichts gesendet wurde. Siehe [Konfiguration](../configuration/#per-finding-send-ceiling). + +### Wenn ein Kanal nicht verfügbar ist + +Ein Egress-Knoten hängt von etwas außerhalb der Regel ab: einem Slack-Token, einem Microsoft-Teams-Webhook, einer JIRA-Konfiguration, einem lizenzierten Connector. Fehlt das oder ist es abgeschaltet, kann der Knoten nicht arbeiten, und Rules Engine 2.0 macht das an drei verschiedenen Stellen deutlich, statt still zu scheitern: + +* **In der Palette** wird ein nicht verfügbarer Knoten als solcher markiert, mit Angabe des Grundes, bevor Sie ihn auf die Zeichenfläche ziehen. +* **Beim Speichern** wird ein Graph, der einen nicht verfügbaren Knoten enthält, abgelehnt. Das ist der Moment, in dem jemand anwesend ist, um einen anderen auszuwählen. +* **Zur Laufzeit** wird die Zustellung mit angehängtem Grund **übersprungen**, nicht als fehlgeschlagen markiert. Eine Regel, die gespeichert wurde, während Slack aktiv war, soll nicht plötzlich Fehler werfen, sobald jemand Slack abschaltet. Der ehrliche Eintrag ist eine übersprungene Zustellung, die besagt, dass Slack abgeschaltet ist. + +### Ein JIRA-Issue erstellen + +`ticket.jira` + +Erstellt oder aktualisiert das JIRA-Issue für den Befund. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Befunde überspringen, die bereits ein Issue haben** | ein | Lässt Befunde unangetastet, die bereits ein JIRA-Issue haben. | +| **Vorhandenes Issue aktualisieren** | aus | Wird angezeigt, wenn die obige Option ausgeschaltet ist. Übermittelt Befunde, die bereits ein Issue haben, sodass JIRA aktualisiert wird. | + +Zusammenfassung, Beschreibung und Priorität stammen aus der JIRA-Konfiguration des Produkts, nicht aus diesem Knoten. Ein von einer Regel erstelltes Ticket ist daher identisch mit einem, das durch „Alle Issues übermitteln" erstellt wurde. + +### Ein Downstream-Ticket erstellen + +`ticket.downstream` + +Erstellt oder aktualisiert ein Ticket über einen [Downstream-Connector](/connectors/downstream/about/). + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Issue-Tracker** | `auto` | `auto` verwendet die Issue-Tracker, die dem Engagement oder Produkt zugewiesen sind. `mapping` zielt auf ein bestimmtes Mapping. | +| **Issue-Tracker-Mapping** | keines | Wird bei `mapping` angezeigt. An welches Mapping übermittelt wird. | +| **Operation** | `create` | `create` erzeugt ein Ticket, oder `update` aktualisiert das vorhandene. Ein Update ohne vorhandenes Ticket erstellt es. | +| **Befunde überspringen, die bereits ein Ticket haben** | ein | Lässt Befunde unangetastet, die im Ziel-Mapping bereits ein Ticket haben. | + +Die Regel ersetzt die automatischen Übermittlungseinstellungen der Zuweisung: Schweregrad- und „nur aktiv"-Filter werden hier nicht ein zweites Mal angewendet. Ein Befund, dessen Ticket bereits existiert, wird übersprungen, unabhängig davon, wie dieses Ticket erstellt wurde. + +### Eine Slack-Nachricht senden + +`notify.slack` + +Postet über einen Messaging-Connector in einen Slack-Kanal. Die Verbindung führt das Bot-Token; die instanzweiten Slack-Einstellungen unter **Systemeinstellungen** werden nicht verwendet und dienen nicht als Fallback. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Verbindung** | keine | Ein [Messaging-Connector](/issue_tracking/pro_integration/messaging_connectors/) dieses Typs. Erforderlich. | +| **Ziel** | leer | Wird angezeigt, sobald eine Connection ausgewählt ist. Die Felder hängen vom Anbieter der Connection ab. | +| **Eine Nachricht pro Befund** | aus | Ausgeschaltet sendet eine Nachricht über den gesamten Batch. | +| **Nachricht** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Wird pro Befund gerendert. | +| **In der Zusammenfassung aufgeführte Befunde** | `10` | Wird bei Sammelnachrichten angezeigt. Wie viele Befunde die Nachricht auflistet, bevor sie angibt, wie viele weitere es gab. | + +### Eine Microsoft-Teams-Nachricht senden + +`notify.msteams` + +Postet eine Karte über einen Messaging-Connector. Die Verbindung führt die Power-Automate-Workflow-URL; der instanzweite Teams-Webhook unter **Systemeinstellungen** wird nicht verwendet und dient nicht als Fallback. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Verbindung** | keine | Ein [Messaging-Connector](/issue_tracking/pro_integration/messaging_connectors/) dieses Typs. Erforderlich. | +| **Ziel** | leer | Wird angezeigt, sobald eine Connection ausgewählt ist. Die Felder hängen vom Anbieter der Connection ab. | +| **Eine Nachricht pro Befund** | aus | Ausgeschaltet sendet eine Karte über den gesamten Batch. | +| **Nachricht** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Wird pro Befund gerendert. | +| **In der Zusammenfassung aufgeführte Befunde** | `10` | Wird bei Sammelnachrichten angezeigt. | + +### Eine E-Mail senden + +`notify.email` + +Verschickt E-Mails an eine feste Liste von Adressen über einen Messaging-Connector. Die Empfänger sind das Ziel der Connection. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Verbindung** | keine | Ein [Messaging-Connector](/issue_tracking/pro_integration/messaging_connectors/) dieses Typs. Erforderlich. | +| **Ziel** | leer | Wird angezeigt, sobald eine Connection ausgewählt ist. Die Felder hängen vom Anbieter der Connection ab. | + +| **Betreff** | `[DefectDojo] {{ctx.count}} finding(s) from rule {{ctx.rule_name}}` | Wird einmal pro Nachricht gerendert. | +| **Inhalt** | ein HTML-Body, der `{{ctx.findings_html}}` enthält | HTML. `{{ctx.findings_html}}` rendert die Befundliste. | +| **Eine Nachricht pro Befund** | aus | Ausgeschaltet sendet eine E-Mail über den gesamten Batch. | +| **Im Inhalt aufgeführte Befunde** | `25` | Wie viele Befunde `{{ctx.findings_html}}` auflistet, bevor angegeben wird, wie viele weitere es gab. | + +### Einen Webhook aufrufen + +`notify.webhook` + +Sendet JSON per POST an einen Webhook-Endpunkt. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Webhook-Endpunkt** | keiner | Ein konfigurierter [Benachrichtigungs-Webhook](/automation/api/notification_webhooks/). Sein benutzerdefinierter Header wird mit der Anfrage gesendet. | +| **URL** | leer | Wird angezeigt, wenn kein Endpunkt ausgewählt ist. Wohin per POST gesendet wird. | +| | | Eine der beiden oben genannten Optionen ist erforderlich. | +| **Signaturschlüssel** | leer | Signiert den Body als `X-DefectDojo-Signature: sha256=HMAC`. | +| **Eine Nachricht pro Befund** | aus | Ausgeschaltet postet den gesamten Batch in einer einzigen Anfrage. | + +Zwei Dinge sind wichtig zu wissen. Ein hier eingegebenes Signing Secret wird zusammen mit der Regel gespeichert. Bevorzugen Sie daher für alles Sensible einen konfigurierten Endpunkt mit eigenem Header. Und ein von einer Regel aufgerufener Webhook ändert niemals den eigenen Health-Status dieses Endpunkts, sodass eine Regel Ihre Benachrichtigungs-Webhooks nicht durch Fehlschlagen deaktivieren kann. + +Frei eingegebene URLs werden beim Speichern validiert. Siehe [Konfiguration](../configuration/#outbound-destination-validation) für Informationen dazu, was abgelehnt wird und wie private Adressen zugelassen werden können. + +### Eine In-App-Benachrichtigung auslösen + +`notify.alert` + +Erstellt eine In-App-Benachrichtigung über den Batch. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Titel** | `Rules Engine 2.0: {{ctx.rule_name}}` | Wird einmal für den gesamten Batch gerendert. | +| **Beschreibung** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Wird einmal für den gesamten Batch gerendert. | +| **Empfänger** | leer | Benutzernamen, durch Kommas getrennt. Leer benachrichtigt die Administratoren. | + +Empfänger steuern dies weiterhin über ihre eigene Benachrichtigungseinstellung **Rules Engine Match**, sodass eine Benachrichtigung die Benachrichtigungspräferenzen eines Benutzers nicht umgehen kann. + +### Einen Bericht erstellen + +`report.generate` + +Erzeugt einen Bericht aus einer Vorlage, beschränkt auf die Befunde, die diesen Knoten erreicht haben, und kann den Download-Link ankündigen. + +| Einstellung | Standard | Hinweise | +|---------|---------|-------| +| **Berichtsvorlage** | keine | Aus welcher Vorlage erzeugt wird. Erforderlich. | +| **Format** | `pdf` | `pdf` oder `html`. | +| **Enthaltene Befunde** | `batch_findings` | `batch_findings` beschränkt den Bericht auf die Befunde, die diesen Knoten erreicht haben. `template_default` lässt die Vorlage ihre eigenen Filter verwenden. | +| **Ankündigen über** | keine | Ein [Messaging-Connector](/issue_tracking/pro_integration/messaging_connectors/), über den der Download-Link gepostet wird, sobald der Bericht erzeugt wurde. Leer lassen, um nicht anzukündigen. | +| **Ankündigen an** | leer | Wird angezeigt, sobald eine Connection ausgewählt ist. Wohin diese Connection sendet: eine Slack-Kanal-ID, E-Mail-Adressen und so weiter. | +| **Ankündigung** | `Report ready: {{ctx.report_url}}` | Wird bei einer Ankündigung angezeigt. `{{ctx.report_url}}` ist der Download-Link. | + +`batch_findings` ist das, was eine Regel kann und ein geplanter Bericht nicht: genau über die Befunde berichten, die gerade zugetroffen haben. + +Die Ankündigung wird als eigene Zustellung erfasst, getrennt von der Berichtserstellung, sodass Sie sehen können, dass der Bericht erfolgreich war, während die Ankündigung unabhängig davon fehlschlägt. diff --git a/docs/content/automation/rules_engine_2/node_reference.es.md b/docs/content/automation/rules_engine_2/node_reference.es.md new file mode 100644 index 00000000000..f1897353bd9 --- /dev/null +++ b/docs/content/automation/rules_engine_2/node_reference.es.md @@ -0,0 +1,348 @@ +--- +title: Referencia de nodos +description: Todos los nodos con los que se distribuye Rules Engine 2.0, y qué hace + cada uno +weight: 3 +audience: pro +aliases: +- /es/automation/rules_engine_v2/node_reference/ +--- + +Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro. + +Rules Engine 2.0 se distribuye con 25 nodos en cuatro categorías. Esta página los documenta todos. + +A menos que se indique lo contrario, un nodo recibe una entrada, produce una salida llamada `out`, y pasa cada elemento que recibió a esa salida. Esto importa cuando se encadenan nodos: un nodo de Hallazgos modifica el Hallazgo y luego pasa el elemento hacia adelante, de modo que varios de ellos en fila se aplican todos. + +## Triggers + +Cada grafo tiene exactamente un disparador, y solo un disparador puede iniciar una ejecución. Los tres producen elementos de Hallazgo y los tres reciben un **Scope** que restringe qué Hallazgos producen. Consulte [Building Rules](../building_rules/) para saber cómo funciona el alcance. + +### Ante un evento de Hallazgo + +`trigger.finding` + +Se ejecuta cuando se crean, actualizan, cierran o reabren Hallazgos. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Event** | `created` | Qué cambio de Hallazgo activa esta regla: `created`, `updated`, `closed`, `reopened`, o `any` para las cuatro. | +| **Scope** | vacío | Qué Hallazgos considera esta regla. Vacío significa todos los Hallazgos que el propietario de la regla puede ver. | + +Los Hallazgos identificados por el evento se comparan con el alcance antes de entrar en el grafo, de modo que el evento decide *cuándo* y el alcance decide *cuáles*. + +### Según una programación + +`trigger.schedule` + +Recorre todos los Hallazgos dentro del alcance según una programación. La programación se configura en la regla y está limitada a marcas de cuarto de hora. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Scope** | vacío | Qué Hallazgos considera esta regla. | + +### Ejecución manual + +`trigger.manual` + +Recorre todos los Hallazgos dentro del alcance cuando se presiona **Run** en la regla. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Scope** | vacío | Qué Hallazgos considera esta regla. | + +## Lógica + +### Si / Filtro + +`filter.if` + +Enruta cada elemento hacia la rama **true** o la rama **false**, según condiciones. Este es el único nodo con dos salidas, y es la forma en que un grafo se ramifica. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Conditions** | vacío | Cada fila es una ruta, un operador y un valor. Consulte [Conditions](../building_rules/#conditions). | +| **Match** | `all` | Si todas las condiciones deben cumplirse (`all`), o basta con una de ellas (`any`). | + +Una lista de condiciones vacía pasa todo por la rama true. Ambas ramas son opcionales: dejar la rama false sin conectar simplemente descarta los elementos que fallaron. + +### Límite + +`flow.limit` + +Pasa los primeros N elementos y descarta el resto. Es útil como válvula de seguridad mientras se prueba una regla, y para limitar cuántos tickets o mensajes puede producir una sola ejecución. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Keep First** | `100` | Cuántos elementos dejar pasar. | + +### Deduplicar dentro de la ejecución + +`flow.dedupe_batch` + +Mantiene el primer elemento por clave y descarta los posteriores que llevan la misma clave. Está limitado a la ejecución, de modo que deduplica dentro de una sola ejecución y no entre ejecuciones. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Key Path** | `finding.hash_code` | La ruta del elemento cuyo valor identifica un duplicado. | + +Un uso común es `finding.component_name`, para notificar una vez por componente afectado en lugar de una vez por Hallazgo. + +## Hallazgos + +Estos nodos modifican Hallazgos. Cada cambio se atribuye a la regla, la ejecución y el nodo que lo realizó, y aparece en la línea de tiempo de procedencia del Hallazgo. + +### Establecer severidad + +`finding.set_severity` + +Establece la severidad, y recalcula con ella la fecha del SLA y la prioridad. + +| Setting | Options | +|---------|---------| +| **Severity** | `Critical`, `High`, `Medium`, `Low`, `Info` | + +### Establecer un campo + +`finding.set_field` + +Establece, agrega al final de, o antepone a un campo de texto. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Field** | ninguno | Uno de `component_name`, `component_version`, `cvssv3`, `cwe`, `description`, `file_path`, `impact`, `mitigation`, `service`, `title`. | +| **Mode** | `set` | `set`, `append` o `prepend`. Un vector CVSSv3 solo puede reemplazarse. | +| **Value** | ninguno | El texto que se escribirá. Admite marcadores de posición del estilo `{{finding.title}}`. | + +### Establecer estado + +`finding.set_status` + +Mueve el Hallazgo a un estado. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Status** | ninguno | `active`, `inactive`, `verified`, `unverified`, `false_positive`, `mitigated`, `reopen`. | +| **Note** | vacío | Una nota opcional registrada junto con el cambio de estado. | + +### Agregar etiquetas + +`finding.add_tags` + +Agrega etiquetas al Hallazgo. Las etiquetas existentes se conservan. + +| Setting | Notes | +|---------|-------| +| **Tags** | Separadas por comas. Admite marcadores de posición del estilo `{{product.name}}`, de modo que se puede etiquetar con datos del Hallazgo. | + +### Agregar una nota + +`finding.add_note` + +Agrega una nota al Hallazgo. + +| Setting | Notes | +|---------|-------| +| **Note** | El texto de la nota. Admite marcadores de posición. | + +### Establecer propietarios + +`finding.set_owners` + +Hace que un grupo sea responsable del Hallazgo. + +| Setting | Notes | +|---------|-------| +| **Group** | El grupo propietario de estos Hallazgos. | + +### Establecer revisores + +`finding.set_reviewers` + +Pone el Hallazgo en revisión por los usuarios seleccionados. + +| Setting | Notes | +|---------|-------| +| **Reviewers** | Uno o más usuarios que deben revisar estos Hallazgos. | + +### Aceptar riesgo + +`finding.risk_accept` + +Acepta el riesgo del Hallazgo de forma simple, o lo agrega a un registro de aceptación de riesgo. + +| Setting | Default | Notes | +|---------|---------|-------| +| **How** | `simple` | `simple` establece la aceptación de riesgo simple en el Hallazgo. `acceptance` lo agrega a un registro de aceptación de riesgo. | +| **Accepted** | activado | Se muestra para `simple`. Desactive para anular la aceptación del riesgo. | +| **Risk Acceptance** | ninguno | Se muestra para `acceptance`. A qué aceptación de riesgo agregar estos Hallazgos. | + +### Establecer política de mitigación + +`finding.set_mitigation_policy` + +Establece la política de mitigación bajo la cual se remedia el Hallazgo. + +| Setting | Notes | +|---------|-------| +| **Mitigation Policy** | La política que se aplicará. | + +### Cambiar prioridad + +`finding.set_priority` + +Establece la prioridad, o la ajusta aritméticamente. Esto anula la prioridad calculada. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Operation** | `set` | `set`, `add`, `subtract`, `multiply`, `divide`. | +| **Value** | ninguno | La prioridad que se establecerá, o la cantidad por la que ajustar. | + +### Establecer riesgo + +`finding.set_risk` + +Establece el riesgo, anulando el calculado. + +| Setting | Options | +|---------|---------| +| **Risk** | `Low`, `Medium`, `Needs Action`, `Urgent` | + +## Salida + +Los nodos de salida son los nodos que salen de DefectDojo. Cada uno de ellos registra una [Delivery](../deliveries/) antes de que se envíe nada, y cada uno respeta el modo **Simulate** o **Live** de la regla. + +Varios de ellos ofrecen la misma opción **Un mensaje por hallazgo**. Desactivada, el nodo envía un mensaje que describe todo el lote, con un desglose por severidad y una lista limitada de Hallazgos. Activada, envía un mensaje por Hallazgo. + +Un nodo que envía un mensaje por Hallazgo se detiene después de 1000 envíos en una sola ejecución de forma predeterminada, y registra una omisión visible que indica cuántos Hallazgos quedaron sin enviar. Consulte [Configuration](../configuration/#per-finding-send-ceiling). + +### Cuando un canal no está disponible + +Un nodo de salida depende de algo externo a la regla: un token de Slack, un webhook de Microsoft Teams, una configuración de JIRA, un conector con licencia. Cuando eso falta o está desactivado, el nodo no puede funcionar, y Rules Engine 2.0 lo indica en tres momentos distintos en lugar de fallar en silencio: + +* **En la paleta**, un nodo no disponible se marca como tal, con el motivo, antes de que se arrastre al lienzo. +* **Al guardar**, se rechaza un grafo que contenga un nodo no disponible. Ese es el momento en que alguien está presente para elegir uno diferente. +* **En tiempo de ejecución**, la entrega se **omite** con el motivo adjunto, no falla. Una regla guardada mientras Slack estaba activo no debería empezar a generar errores el día que alguien desactive Slack. El registro honesto es una entrega omitida que indica que Slack está desactivado. + +### Crear una incidencia de JIRA + +`ticket.jira` + +Crea o actualiza la incidencia de JIRA para el Hallazgo. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Skip Findings That Already Have an Issue** | activado | Deja intactos los Hallazgos que ya tienen una incidencia de JIRA. | +| **Update an Existing Issue** | desactivado | Se muestra cuando la opción anterior está desactivada. Envía los Hallazgos que ya tienen una incidencia, de modo que JIRA se actualiza. | + +El resumen, la descripción y la prioridad provienen de la configuración de JIRA del producto, no de este nodo. Por lo tanto, un ticket creado por una regla es idéntico a uno creado por push all issues. + +### Crear un ticket downstream + +`ticket.downstream` + +Crea o actualiza un ticket mediante un [Downstream Connector](/connectors/downstream/about/). + +| Setting | Default | Notes | +|---------|---------|-------| +| **Issue Trackers** | `auto` | `auto` usa los rastreadores de incidencias asignados al Compromiso o al Producto. `mapping` apunta a una asignación específica. | +| **Issue Tracker Mapping** | ninguno | Se muestra para `mapping`. A qué asignación enviar. | +| **Operation** | `create` | `create` un ticket, o `update` el que ya existe. Una actualización sin ticket existente lo crea. | +| **Skip Findings That Already Have a Ticket** | activado | Deja intactos los Hallazgos que ya tienen un ticket en la asignación de destino. | + +La regla reemplaza los ajustes automáticos de envío de la asignación: los filtros de severidad y de solo activos no se aplican una segunda vez aquí. Un Hallazgo cuyo ticket ya existe se omite sin importar cómo se haya creado ese ticket. + +### Enviar un mensaje de Slack + +`notify.slack` + +Publica en un canal de Slack a través de un Messaging Connector. La conexión lleva el token del bot; los ajustes de Slack a nivel de instancia en **System Settings** no se usan y no sirven como respaldo. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Connection** | ninguno | Un [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) de este tipo. Obligatorio. | +| **Destination** | vacío | Se muestra una vez elegida una conexión. Los campos dependen del proveedor de la conexión. | +| **One Message per Finding** | desactivado | Desactivado envía un mensaje sobre el lote. | +| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Se renderiza por Hallazgo. | +| **Findings Listed in the Digest** | `10` | Se muestra para mensajes por lote. Cuántos Hallazgos enumera el mensaje antes de indicar cuántos más había. | + +### Enviar un mensaje de Microsoft Teams + +`notify.msteams` + +Publica una tarjeta a través de un Messaging Connector. La conexión lleva la URL del flujo de trabajo de Power Automate; el webhook de Teams a nivel de instancia en **System Settings** no se usa y no sirve como respaldo. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Connection** | ninguno | Un [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) de este tipo. Obligatorio. | +| **Destination** | vacío | Se muestra una vez elegida una conexión. Los campos dependen del proveedor de la conexión. | +| **One Message per Finding** | desactivado | Desactivado envía una tarjeta sobre el lote. | +| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Se renderiza por Hallazgo. | +| **Findings Listed in the Digest** | `10` | Se muestra para mensajes por lote. | + +### Enviar un correo electrónico + +`notify.email` + +Envía un correo electrónico a una lista fija de direcciones a través de un Messaging Connector. Los destinatarios son el destino de la conexión. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Connection** | ninguno | Un [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) de este tipo. Obligatorio. | +| **Destination** | vacío | Se muestra una vez elegida una conexión. Los campos dependen del proveedor de la conexión. | + +| **Subject** | `[DefectDojo] {{ctx.count}} finding(s) from rule {{ctx.rule_name}}` | Se renderiza una vez por mensaje. | +| **Body** | un cuerpo HTML que contiene `{{ctx.findings_html}}` | HTML. `{{ctx.findings_html}}` renderiza la lista de Hallazgos. | +| **One Message per Finding** | desactivado | Desactivado envía un correo electrónico sobre el lote. | +| **Findings Listed in the Body** | `25` | Cuántos Hallazgos enumera `{{ctx.findings_html}}` antes de indicar cuántos más había. | + +### Llamar a un webhook + +`notify.webhook` + +Envía un POST con JSON a un endpoint de webhook. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Webhook Endpoint** | ninguno | Un [notification webhook](/automation/api/notification_webhooks/) configurado. Su encabezado personalizado se envía con la solicitud. | +| **URL** | vacío | Se muestra cuando no se selecciona ningún endpoint. Adónde enviar el POST. | +| | | Se requiere uno de los dos anteriores. | +| **Signing Secret** | vacío | Firma el cuerpo como `X-DefectDojo-Signature: sha256=HMAC`. | +| **One Message per Finding** | desactivado | Desactivado publica todo el lote en una sola solicitud. | + +Dos cosas que conviene saber. Un secreto de firma escrito aquí se almacena junto con la regla, así que para cualquier cosa sensible es preferible un endpoint configurado con su propio encabezado. Y un webhook llamado por una regla nunca cambia el estado de salud propio de ese endpoint, de modo que una regla no puede deshabilitar sus webhooks de notificación al fallar. + +Las URL de texto libre se validan al guardar. Consulte [Configuration](../configuration/#outbound-destination-validation) para saber qué se rechaza y cómo permitir direcciones privadas. + +### Generar una alerta en la aplicación + +`notify.alert` + +Crea una alerta en la aplicación sobre el lote. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Title** | `Rules Engine 2.0: {{ctx.rule_name}}` | Se renderiza una vez para todo el lote. | +| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Se renderiza una vez para todo el lote. | +| **Recipients** | vacío | Nombres de usuario, separados por comas. Vacío alerta a los administradores. | + +Los destinatarios igualmente controlan esto mediante su propio ajuste de notificación **Rules Engine Match**, de modo que una alerta no puede eludir las preferencias de notificación de un usuario. + +### Generar un informe + +`report.generate` + +Genera un informe a partir de una plantilla, limitado a los Hallazgos que llegaron a este nodo, y puede anunciar el enlace de descarga. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Report Template** | ninguno | A partir de qué plantilla generar. Obligatorio. | +| **Format** | `pdf` | `pdf` o `html`. | +| **Findings Included** | `batch_findings` | `batch_findings` limita el informe a los Hallazgos que llegaron a este nodo. `template_default` permite que la plantilla use sus propios filtros. | +| **Announce Over** | ninguno | Un [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) mediante el cual publicar el enlace de descarga una vez generado el informe. Déjelo vacío para no anunciar. | +| **Announce To** | vacío | Se muestra una vez elegida una conexión. Adónde envía esa conexión: un ID de canal de Slack, direcciones de correo electrónico, etcétera. | +| **Announcement** | `Report ready: {{ctx.report_url}}` | Se muestra al anunciar. `{{ctx.report_url}}` es el enlace de descarga. | + +`batch_findings` es lo que una regla puede hacer y un informe programado no: generar un informe exactamente sobre los Hallazgos que acaban de coincidir. + +El anuncio se registra como una entrega propia, separada de la generación del informe, de modo que se puede ver que el informe tuvo éxito y que el anuncio falló de forma independiente. diff --git a/docs/content/automation/rules_engine_2/node_reference.fr.md b/docs/content/automation/rules_engine_2/node_reference.fr.md new file mode 100644 index 00000000000..a8e61a9f7ef --- /dev/null +++ b/docs/content/automation/rules_engine_2/node_reference.fr.md @@ -0,0 +1,347 @@ +--- +title: Référence des nœuds +description: Tous les nœuds fournis avec Rules Engine 2.0, et ce que fait chacun d'eux +weight: 3 +audience: pro +aliases: +- /fr/automation/rules_engine_v2/node_reference/ +--- + +Remarque : Rules Engine 2.0 est une fonctionnalité réservée à DefectDojo Pro. + +Rules Engine 2.0 est fourni avec 25 nœuds répartis en quatre catégories. Cette page les documente tous. + +Sauf indication contraire, un nœud reçoit une entrée, produit une sortie appelée `out`, et transmet à cette sortie chaque élément qu'il a reçu. Cela compte lorsque vous enchaînez des nœuds : un nœud de type Constatations modifie la Constatation puis transmet l'élément à la suite, de sorte que plusieurs nœuds enchaînés s'appliquent tous. + +## Déclencheurs + +Chaque graphe possède exactement un déclencheur, et seul un déclencheur peut démarrer une exécution. Les trois déclencheurs produisent des éléments de type Constatation, et tous trois disposent d'une **Portée** qui restreint les Constatations qu'ils produisent. Voir [Créer des règles](../building_rules/) pour savoir comment fonctionne la portée. + +### Sur un événement de Constatation + +`trigger.finding` + +S'exécute lorsque des Constatations sont créées, mises à jour, clôturées ou rouvertes. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Événement** | `created` | Le changement de Constatation qui déclenche cette règle : `created`, `updated`, `closed`, `reopened`, ou `any` pour les quatre. | +| **Portée** | vide | Les Constatations que cette règle prend en compte. Vide signifie toutes les Constatations que le propriétaire de la règle peut voir. | + +Les Constatations désignées par l'événement sont comparées à la portée avant d'entrer dans le graphe : l'événement décide *quand*, et la portée décide *lesquelles*. + +### Sur une planification + +`trigger.schedule` + +Balaie toutes les Constatations de la portée selon une planification. Cette planification est configurée sur la règle et se limite à des créneaux au quart d'heure. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Portée** | vide | Les Constatations que cette règle prend en compte. | + +### Exécution manuelle + +`trigger.manual` + +Balaie toutes les Constatations de la portée lorsque vous appuyez sur **Run** pour la règle. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Portée** | vide | Les Constatations que cette règle prend en compte. | + +## Logique + +### Si / Filtre + +`filter.if` + +Oriente chaque élément vers la branche **true** ou la branche **false**, selon des conditions. C'est le seul nœud à posséder deux sorties, et c'est ainsi qu'un graphe se ramifie. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Conditions** | vide | Chaque ligne est un chemin, un opérateur et une valeur. Voir [Conditions](../building_rules/#conditions). | +| **Correspondance** | `all` | Indique si toutes les conditions doivent être vérifiées (`all`), ou une seule d'entre elles (`any`). | + +Une liste de conditions vide fait passer tous les éléments par la branche true. Les deux branches sont facultatives : laisser la branche false non connectée se contente d'écarter les éléments qui ont échoué. + +### Limite + +`flow.limit` + +Laisse passer les N premiers éléments et écarte les autres. Utile comme soupape de sécurité pendant que vous testez une règle, et pour plafonner le nombre de tickets ou de messages qu'une seule exécution peut produire. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Conserver les premiers** | `100` | Le nombre d'éléments à transmettre. | + +### Dédupliquer au sein de l'exécution + +`flow.dedupe_batch` + +Conserve le premier élément par clé et écarte les suivants portant la même clé. Limité à l'exécution en cours, ce nœud déduplique au sein d'une seule exécution et non entre plusieurs exécutions. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Chemin de la clé** | `finding.hash_code` | Le chemin de l'élément dont la valeur identifie un doublon. | + +Un usage courant consiste à utiliser `finding.component_name`, pour notifier une fois par composant affecté plutôt qu'une fois par Constatation. + +## Constatations + +Ces nœuds modifient des Constatations. Chaque modification est attribuée à la règle, à l'exécution et au nœud qui l'a effectuée, et apparaît dans la chronologie de provenance de la Constatation. + +### Définir la sévérité + +`finding.set_severity` + +Définit la sévérité, et recalcule en conséquence la date de SLA et la priorité. + +| Setting | Options | +|---------|---------| +| **Sévérité** | `Critical`, `High`, `Medium`, `Low`, `Info` | + +### Définir un champ + +`finding.set_field` + +Définit, ajoute à la fin de, ou ajoute au début d'un champ texte. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Champ** | aucun | L'un des suivants : `component_name`, `component_version`, `cvssv3`, `cwe`, `description`, `file_path`, `impact`, `mitigation`, `service`, `title`. | +| **Mode** | `set` | `set`, `append` ou `prepend`. Un vecteur CVSSv3 ne peut être que remplacé. | +| **Valeur** | aucune | Le texte à écrire. Prend en charge les espaces réservés du type `{{finding.title}}`. | + +### Définir le statut + +`finding.set_status` + +Fait passer la Constatation à un statut. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Statut** | aucun | `active`, `inactive`, `verified`, `unverified`, `false_positive`, `mitigated`, `reopen`. | +| **Note** | vide | Une note facultative enregistrée avec le changement de statut. | + +### Ajouter des étiquettes + +`finding.add_tags` + +Ajoute des étiquettes à la Constatation. Les étiquettes existantes sont conservées. + +| Paramètre | Remarques | +|---------|-------| +| **Étiquettes** | Séparées par des virgules. Prend en charge les espaces réservés du type `{{product.name}}`, pour pouvoir étiqueter avec des données de la Constatation. | + +### Ajouter une note + +`finding.add_note` + +Ajoute une note à la Constatation. + +| Paramètre | Remarques | +|---------|-------| +| **Note** | Le texte de la note. Prend en charge les espaces réservés. | + +### Définir les responsables + +`finding.set_owners` + +Rend un groupe responsable de la Constatation. + +| Paramètre | Remarques | +|---------|-------| +| **Groupe** | Le groupe responsable de ces Constatations. | + +### Définir les réviseurs + +`finding.set_reviewers` + +Soumet la Constatation à la revue des utilisateurs sélectionnés. + +| Paramètre | Remarques | +|---------|-------| +| **Réviseurs** | Un ou plusieurs utilisateurs devant réviser ces Constatations. | + +### Accepter le risque + +`finding.risk_accept` + +Applique une acceptation de risque simple à la Constatation, ou l'ajoute à une fiche d'acceptation du risque. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Méthode** | `simple` | `simple` applique une acceptation de risque simple à la Constatation. `acceptance` l'ajoute à une fiche d'acceptation du risque. | +| **Accepté** | activé | Affiché pour `simple`. Désactivez pour annuler l'acceptation du risque. | +| **Acceptation du risque** | aucune | Affiché pour `acceptance`. La fiche d'acceptation du risque à laquelle ajouter ces Constatations. | + +### Définir la politique d'atténuation + +`finding.set_mitigation_policy` + +Définit la politique d'atténuation sous laquelle la Constatation est corrigée. + +| Paramètre | Remarques | +|---------|-------| +| **Politique d'atténuation** | La politique à appliquer. | + +### Modifier la priorité + +`finding.set_priority` + +Définit la priorité, ou l'ajuste arithmétiquement. Cela remplace la priorité calculée. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Opération** | `set` | `set`, `add`, `subtract`, `multiply`, `divide`. | +| **Valeur** | aucune | La priorité à définir, ou la quantité de l'ajustement. | + +### Définir le risque + +`finding.set_risk` + +Définit le risque, en remplaçant celui calculé. + +| Setting | Options | +|---------|---------| +| **Risque** | `Low`, `Medium`, `Needs Action`, `Urgent` | + +## Sorties + +Les nœuds de sortie sont les nœuds qui quittent DefectDojo. Chacun d'eux enregistre une [Livraison](../deliveries/) avant tout envoi, et chacun d'eux respecte le mode **Simulate** ou **Live** de la règle. + +Plusieurs d'entre eux proposent le même choix **Un message par Constatation**. Désactivé, le nœud envoie un seul message décrivant l'ensemble du lot, avec une répartition par sévérité et une liste plafonnée de Constatations. Activé, il envoie un message par Constatation. + +Un nœud envoyant un message par Constatation s'arrête par défaut après 1 000 envois au cours d'une même exécution, et enregistre une omission visible indiquant le nombre de Constatations pour lesquelles il n'a pas envoyé de message. Voir [Configuration](../configuration/#per-finding-send-ceiling). + +### Lorsqu'un canal est indisponible + +Un nœud de sortie dépend de quelque chose d'extérieur à la règle : un jeton Slack, un webhook Microsoft Teams, une configuration JIRA, un connecteur sous licence. Lorsque cet élément est manquant ou désactivé, le nœud ne peut pas fonctionner, et Rules Engine 2.0 le signale à trois moments différents plutôt que d'échouer silencieusement : + +* **Dans la palette**, un nœud indisponible est marqué comme tel, avec la raison, avant même que vous ne le glissiez sur le canevas. +* **À l'enregistrement**, un graphe contenant un nœud indisponible est refusé. C'est le moment où quelqu'un est présent pour en choisir un autre. +* **À l'exécution**, la livraison est **omise**, sans être mise en échec. Une règle enregistrée alors que Slack était actif ne doit pas se mettre à générer des erreurs le jour où quelqu'un désactive Slack. L'enregistrement honnête est une livraison omise indiquant que Slack est désactivé. + +### Créer un ticket JIRA + +`ticket.jira` + +Crée ou met à jour le ticket JIRA de la Constatation. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Ignorer les Constatations ayant déjà un ticket** | activé | Laisse inchangées les Constatations qui ont déjà un ticket JIRA. | +| **Mettre à jour un ticket existant** | désactivé | Affiché lorsque l'option ci-dessus est désactivée. Pousse les Constatations qui ont déjà un ticket, afin que JIRA soit mis à jour. | + +Le résumé, la description et la priorité proviennent de la configuration JIRA du produit, et non de ce nœud. Un ticket créé par une règle est donc identique à celui créé par push all issues. + +### Créer un ticket en aval + +`ticket.downstream` + +Crée ou met à jour un ticket via un [connecteur en aval](/connectors/downstream/about/). + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Systèmes de tickets** | `auto` | `auto` utilise les systèmes de tickets affectés à l'engagement ou au produit. `mapping` cible un mappage spécifique. | +| **Mappage de système de tickets** | aucun | Affiché pour `mapping`. Le mappage vers lequel pousser. | +| **Opération** | `create` | `create` un ticket, ou `update` celui qui existe déjà. Une mise à jour sans ticket existant le crée. | +| **Ignorer les Constatations ayant déjà un ticket** | activé | Laisse inchangées les Constatations qui ont déjà un ticket dans le mappage cible. | + +La règle remplace les paramètres de poussée automatique de l'affectation : les filtres de sévérité et « actif uniquement » ne sont pas réappliqués ici. Une Constatation dont le ticket existe déjà est ignorée, quelle que soit la manière dont ce ticket a été créé. + +### Envoyer un message Slack + +`notify.slack` + +Publie dans un canal Slack via un connecteur de messagerie. La connexion porte le jeton du bot ; les paramètres Slack globaux de l'instance, sous **System Settings**, ne sont pas utilisés et ne servent pas de repli. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Connexion** | aucune | Un [connecteur de messagerie](/issue_tracking/pro_integration/messaging_connectors/) de ce type. Obligatoire. | +| **Destination** | vide | Affiché une fois une connexion choisie. Les champs dépendent du fournisseur de la connexion. | +| **Un message par Constatation** | désactivé | Désactivé envoie un seul message pour le lot. | +| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Généré pour chaque Constatation. | +| **Constatations répertoriées dans la synthèse** | `10` | Affiché pour les messages groupés. Le nombre de Constatations que le message liste avant d'indiquer combien il y en avait de plus. | + +### Envoyer un message Microsoft Teams + +`notify.msteams` + +Publie une carte via un connecteur de messagerie. La connexion porte l'URL du workflow Power Automate ; le webhook Teams global de l'instance, sous **System Settings**, n'est pas utilisé et ne sert pas de repli. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Connexion** | aucune | Un [connecteur de messagerie](/issue_tracking/pro_integration/messaging_connectors/) de ce type. Obligatoire. | +| **Destination** | vide | Affiché une fois une connexion choisie. Les champs dépendent du fournisseur de la connexion. | +| **Un message par Constatation** | désactivé | Désactivé envoie une seule carte pour le lot. | +| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Généré pour chaque Constatation. | +| **Constatations répertoriées dans la synthèse** | `10` | Affiché pour les messages groupés. | + +### Envoyer un e-mail + +`notify.email` + +Envoie un e-mail à une liste fixe d'adresses via un connecteur de messagerie. Les destinataires correspondent à la destination de la connexion. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Connexion** | aucune | Un [connecteur de messagerie](/issue_tracking/pro_integration/messaging_connectors/) de ce type. Obligatoire. | +| **Destination** | vide | Affiché une fois une connexion choisie. Les champs dépendent du fournisseur de la connexion. | + +| **Objet** | `[DefectDojo] {{ctx.count}} finding(s) from rule {{ctx.rule_name}}` | Généré une fois par message. | +| **Corps** | un corps HTML contenant `{{ctx.findings_html}}` | HTML. `{{ctx.findings_html}}` génère la liste des Constatations. | +| **Un message par Constatation** | désactivé | Désactivé envoie un seul e-mail pour le lot. | +| **Constatations répertoriées dans le corps** | `25` | Le nombre de Constatations que `{{ctx.findings_html}}` liste avant d'indiquer combien il y en avait de plus. | + +### Appeler un webhook + +`notify.webhook` + +Envoie une requête POST JSON vers un point de terminaison webhook. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Point de terminaison du webhook** | aucun | Un [webhook de notification](/automation/api/notification_webhooks/) configuré. Son en-tête personnalisé est envoyé avec la requête. | +| **URL** | vide | Affiché lorsqu'aucun point de terminaison n'est sélectionné. Où envoyer le POST. | +| | | L'un des deux paramètres ci-dessus est requis. | +| **Secret de signature** | vide | Signe le corps sous la forme `X-DefectDojo-Signature: sha256=HMAC`. | +| **Un message par Constatation** | désactivé | Désactivé envoie le lot entier en une seule requête. | + +Deux choses à savoir. Un secret de signature saisi ici est stocké avec la règle ; pour tout élément sensible, préférez donc un point de terminaison configuré avec son propre en-tête. Et un webhook appelé par une règle ne modifie jamais l'état de santé propre de ce point de terminaison, si bien qu'une règle ne peut pas désactiver vos webhooks de notification en échouant. + +Les URL en texte libre sont validées à l'enregistrement. Voir [Configuration](../configuration/#outbound-destination-validation) pour savoir ce qui est rejeté et comment autoriser les adresses privées. + +### Déclencher une alerte intégrée + +`notify.alert` + +Crée une alerte intégrée à propos du lot. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Titre** | `Rules Engine 2.0: {{ctx.rule_name}}` | Généré une fois pour l'ensemble du lot. | +| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Généré une fois pour l'ensemble du lot. | +| **Destinataires** | vide | Noms d'utilisateur, séparés par des virgules. Vide alerte les administrateurs. | + +Les destinataires gardent le contrôle via leur propre paramètre de notification **Rules Engine Match**, de sorte qu'une alerte ne peut pas contourner les préférences de notification d'un utilisateur. + +### Générer un rapport + +`report.generate` + +Génère un rapport à partir d'un modèle, limité aux Constatations ayant atteint ce nœud, et peut annoncer le lien de téléchargement. + +| Paramètre | Valeur par défaut | Remarques | +|---------|---------|-------| +| **Modèle de rapport** | aucun | Le modèle à partir duquel générer le rapport. Obligatoire. | +| **Format** | `pdf` | `pdf` ou `html`. | +| **Constatations incluses** | `batch_findings` | `batch_findings` limite le rapport aux Constatations ayant atteint ce nœud. `template_default` laisse le modèle utiliser ses propres filtres. | +| **Annoncer via** | aucun | Un [connecteur de messagerie](/issue_tracking/pro_integration/messaging_connectors/) via lequel publier le lien de téléchargement une fois le rapport généré. Laisser vide pour ne pas annoncer. | +| **Annoncer à** | vide | Affiché une fois une connexion choisie. Où cette connexion envoie : un identifiant de canal Slack, des adresses e-mail, etc. | +| **Annonce** | `Report ready: {{ctx.report_url}}` | Affiché lors de l'annonce. `{{ctx.report_url}}` est le lien de téléchargement. | + +`batch_findings` représente ce qu'une règle peut faire et qu'un rapport planifié ne peut pas : produire un rapport sur exactement les Constatations qui viennent de correspondre. + +L'annonce est enregistrée comme une livraison à part entière, distincte de la génération du rapport, de sorte que vous pouvez voir le rapport réussir et l'annonce échouer indépendamment l'une de l'autre. diff --git a/docs/content/automation/rules_engine_2/node_reference.ja.md b/docs/content/automation/rules_engine_2/node_reference.ja.md new file mode 100644 index 00000000000..b9d0fcaa3f8 --- /dev/null +++ b/docs/content/automation/rules_engine_2/node_reference.ja.md @@ -0,0 +1,347 @@ +--- +title: ノードリファレンス +description: Rules Engine 2.0に搭載されているすべてのノードと、それぞれの機能 +weight: 3 +audience: pro +aliases: +- /ja/automation/rules_engine_v2/node_reference/ +--- + +注: Rules Engine 2.0 は DefectDojo Pro 限定の機能です。 + +Rules Engine 2.0には、4つのカテゴリにわたって25個のノードが搭載されています。このページではそのすべてを解説します。 + +特に断りがない限り、ノードは1つの入力を受け取り、`out` と呼ばれる1つの出力を生成し、受け取ったすべてのアイテムをその出力へと渡します。これはノードを連結する際に重要です。検出事項ノードは検出事項を変更してからアイテムを次へ渡すため、連続して並んだ複数のノードがすべて適用されます。 + +## トリガー + +すべてのグラフにはトリガーがちょうど1つあり、実行を開始できるのはトリガーだけです。3種類のトリガーはすべて検出事項アイテムを生成し、いずれも生成する検出事項を絞り込む**Scope**を持ちます。スコープの仕組みについては[ルールの作成](../building_rules/)を参照してください。 + +### 検出事項イベント時 + +`trigger.finding` + +検出事項が作成、更新、クローズ、または再オープンされたときに実行されます。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Event** | `created` | このルールを起動させる検出事項の変更種別: `created`、`updated`、`closed`、`reopened`、またはこの4つすべてを対象とする `any`。 | +| **Scope** | 空 | このルールが対象とする検出事項。空の場合は、ルールの所有者が閲覧できるすべての検出事項が対象になります。 | + +イベントによって指定された検出事項は、グラフに入る前にスコープと照合されます。つまりイベントが*いつ*を決定し、スコープが*どれを*決定します。 + +### スケジュールで実行 + +`trigger.schedule` + +スケジュールに従い、スコープ内のすべての検出事項を走査します。スケジュールはルール上で設定し、15分刻みの時刻に限定されます。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Scope** | 空 | このルールが対象とする検出事項。 | + +### 手動実行 + +`trigger.manual` + +ルール上で**Run**を押すと、スコープ内のすべての検出事項を走査します。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Scope** | 空 | このルールが対象とする検出事項。 | + +## ロジック + +### If / フィルター + +`filter.if` + +条件に基づいて、各アイテムを**true**または**false**の分岐へ振り分けます。これは出力を2つ持つ唯一のノードであり、グラフを分岐させる手段です。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Conditions** | 空 | 各行はパス、演算子、値で構成されます。[条件](../building_rules/#conditions)を参照してください。 | +| **Match** | `all` | すべての条件を満たす必要があるか(`all`)、いずれか1つで良いか(`any`)。 | + +条件リストが空の場合、すべてのアイテムがtrue分岐へ渡されます。どちらの分岐も接続は任意です。false分岐を未接続のままにすると、条件を満たさなかったアイテムは単に破棄されます。 + +### 上限 + +`flow.limit` + +最初のN件のアイテムを通過させ、残りを破棄します。ルールをテストする際の安全弁として、また1回の実行で生成できるチケットやメッセージの件数に上限を設けるために便利です。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Keep First** | `100` | 通過させるアイテムの件数。 | + +### 実行内で重複排除 + +`flow.dedupe_batch` + +キーごとに最初のアイテムを保持し、同じキーを持つ後続のアイテムを破棄します。この処理は実行単位でスコープされるため、1回の実行内でのみ重複排除が行われ、実行をまたいだ重複排除は行われません。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Key Path** | `finding.hash_code` | 重複を識別する値を持つアイテムパス。 | + +よくある使い方は `finding.component_name` を指定し、検出事項ごとではなく影響を受けたコンポーネントごとに1回だけ通知することです。 + +## 検出事項 + +これらのノードは検出事項を変更します。すべての変更は、それを行ったルール、実行、ノードに紐付けられ、検出事項の来歴(provenance)タイムラインに表示されます。 + +### 深刻度を設定 + +`finding.set_severity` + +深刻度を設定し、それに合わせてSLA日付と優先度を再計算します。 + +| 設定 | 選択肢 | +|---------|---------| +| **Severity** | `Critical`, `High`, `Medium`, `Low`, `Info` | + +### フィールドを設定 + +`finding.set_field` + +テキストフィールドに値を設定、追記、または先頭に追加します。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Field** | なし | `component_name`、`component_version`、`cvssv3`、`cwe`、`description`、`file_path`、`impact`、`mitigation`、`service`、`title` のいずれか。 | +| **Mode** | `set` | `set`、`append`、または `prepend`。CVSSv3ベクターは置き換えのみ可能です。 | +| **Value** | なし | 書き込むテキスト。`{{finding.title}}` のようなプレースホルダーに対応しています。 | + +### ステータスを設定 + +`finding.set_status` + +検出事項を指定したステータスに移行します。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Status** | なし | `active`, `inactive`, `verified`, `unverified`, `false_positive`, `mitigated`, `reopen`。 | +| **Note** | 空 | ステータス変更に合わせて記録される任意のメモ。 | + +### タグを追加 + +`finding.add_tags` + +検出事項にタグを追加します。既存のタグはそのまま保持されます。 + +| 設定 | 備考 | +|---------|-------| +| **Tags** | カンマ区切り。`{{product.name}}` のようなプレースホルダーに対応しているため、検出事項のデータを使ってタグ付けできます。 | + +### メモを追加 + +`finding.add_note` + +検出事項にメモを追加します。 + +| 設定 | 備考 | +|---------|-------| +| **Note** | メモの本文。プレースホルダーに対応しています。 | + +### 所有者を設定 + +`finding.set_owners` + +グループを検出事項の担当にします。 + +| 設定 | 備考 | +|---------|-------| +| **Group** | これらの検出事項を所有するグループ。 | + +### レビュアーを設定 + +`finding.set_reviewers` + +選択したユーザーによる検出事項のレビューを開始します。 + +| 設定 | 備考 | +|---------|-------| +| **Reviewers** | これらの検出事項をレビューすべき1人以上のユーザー。 | + +### リスクを受容 + +`finding.risk_accept` + +検出事項をシンプルリスク受容するか、リスク受容レコードに追加します。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **How** | `simple` | `simple` は検出事項にシンプルリスク受容を設定します。`acceptance` はリスク受容レコードに追加します。 | +| **Accepted** | オン | `simple` の場合に表示されます。オフにするとリスク受容を解除します。 | +| **Risk Acceptance** | なし | `acceptance` の場合に表示されます。これらの検出事項をどのリスク受容に追加するか。 | + +### 緩和ポリシーを設定 + +`finding.set_mitigation_policy` + +検出事項が是正される際の緩和ポリシーを設定します。 + +| 設定 | 備考 | +|---------|-------| +| **Mitigation Policy** | 適用するポリシー。 | + +### 優先度を変更 + +`finding.set_priority` + +優先度を設定するか、算術的に調整します。これは計算された優先度を上書きします。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Operation** | `set` | `set`、`add`、`subtract`、`multiply`、`divide`。 | +| **Value** | なし | 設定する優先度、または調整量。 | + +### リスクを設定 + +`finding.set_risk` + +計算されたリスクを上書きして設定します。 + +| 設定 | 選択肢 | +|---------|---------| +| **Risk** | `Low`, `Medium`, `Needs Action`, `Urgent` | + +## 送信(Egress) + +送信ノードは、DefectDojoの外へ出ていくノードです。いずれも何かを送信する前に[配信](../deliveries/)を記録し、いずれもルールの**Simulate**または**Live**モードに従います。 + +このうちいくつかは同じ**One Message per Finding**の選択肢を提供します。オフの場合、ノードはバッチ全体を説明する1件のメッセージを、深刻度の内訳と件数上限付きの検出事項一覧とともに送信します。オンの場合、検出事項ごとに1件のメッセージを送信します。 + +検出事項ごとに1件のメッセージを送信するノードは、デフォルトでは1回の実行につき1,000件の送信で停止し、送信されなかった検出事項の件数を記した、目に見えるスキップを記録します。[設定](../configuration/#per-finding-send-ceiling)を参照してください。 + +### チャネルが利用できない場合 + +送信ノードは、Slackトークン、Microsoft Teams Webhook、JIRA設定、ライセンス済みコネクタなど、ルールの外部にある何かに依存しています。それが欠けているか無効化されている場合、ノードは動作できません。Rules Engine 2.0は黙って失敗するのではなく、3つの異なるタイミングでそれを知らせます。 + +* **パレット内**では、利用できないノードはキャンバスにドラッグする前に、その旨と理由がマークされています。 +* **保存時**には、利用できないノードを含むグラフは拒否されます。これは、誰かがその場にいて別のノードを選び直せるタイミングです。 +* **実行時**には、配信は失敗ではなく、理由が添えられた**スキップ**になります。Slackが有効な状態で保存されたルールは、誰かがSlackを無効化した日にエラーを出し始めるべきではありません。正直な記録とは、Slackが無効であることを伝えるスキップされた配信のことです。 + +### JIRA課題を作成 + +`ticket.jira` + +検出事項に対応するJIRA課題を作成または更新します。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Skip Findings That Already Have an Issue** | オン | 既にJIRA課題を持つ検出事項はそのままにします。 | +| **Update an Existing Issue** | オフ | 上記のスキップがオフの場合に表示されます。既に課題を持つ検出事項もプッシュされ、JIRAが更新されます。 | + +サマリー、説明、優先度はこのノードではなく、製品のJIRA設定から取得されます。そのため、ルールが作成するチケットは、push all issuesによって作成されるものと同一です。 + +### ダウンストリームチケットを作成 + +`ticket.downstream` + +[ダウンストリームコネクタ](/connectors/downstream/about/)を通じてチケットを作成または更新します。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Issue Trackers** | `auto` | `auto` はエンゲージメントまたは製品に割り当てられた課題トラッカーを使用します。`mapping` は特定の1つのマッピングを対象にします。 | +| **Issue Tracker Mapping** | なし | `mapping` の場合に表示されます。どのマッピングへプッシュするか。 | +| **Operation** | `create` | チケットを`create`するか、既存のものを`update`するか。既存のチケットがない状態でのupdateは、新規作成になります。 | +| **Skip Findings That Already Have a Ticket** | オン | 対象のマッピングに既にチケットを持つ検出事項はそのままにします。 | + +このルールは、割り当ての自動プッシュ設定を置き換えます。深刻度やアクティブのみのフィルターはここでは再適用されません。既にチケットが存在する検出事項は、そのチケットがどのように作成されたかにかかわらずスキップされます。 + +### Slackメッセージを送信 + +`notify.slack` + +メッセージングコネクタを介してSlackチャネルに投稿します。接続情報にはボットトークンが含まれます。**System Settings**配下のインスタンス全体のSlack設定は使用されず、フォールバックにもなりません。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Connection** | なし | この種類の[メッセージングコネクタ](/issue_tracking/pro_integration/messaging_connectors/)。必須。 | +| **Destination** | 空 | 接続が選択されると表示されます。フィールドは接続先のベンダーによって異なります。 | +| **One Message per Finding** | オフ | オフの場合、バッチ全体について1件のメッセージを送信します。 | +| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | 検出事項ごとにレンダリングされます。 | +| **Findings Listed in the Digest** | `10` | バッチメッセージの場合に表示されます。メッセージが「他に何件あるか」を示す前に列挙する検出事項の件数。 | + +### Microsoft Teamsメッセージを送信 + +`notify.msteams` + +メッセージングコネクタを介してカードを投稿します。接続情報にはPower AutomateのワークフローURLが含まれます。**System Settings**配下のインスタンス全体のTeams Webhookは使用されず、フォールバックにもなりません。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Connection** | なし | この種類の[メッセージングコネクタ](/issue_tracking/pro_integration/messaging_connectors/)。必須。 | +| **Destination** | 空 | 接続が選択されると表示されます。フィールドは接続先のベンダーによって異なります。 | +| **One Message per Finding** | オフ | オフの場合、バッチ全体について1件のカードを送信します。 | +| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | 検出事項ごとにレンダリングされます。 | +| **Findings Listed in the Digest** | `10` | バッチメッセージの場合に表示されます。 | + +### メールを送信 + +`notify.email` + +メッセージングコネクタを介して、固定のアドレスリストにメールを送信します。宛先は接続先のDestinationです。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Connection** | なし | この種類の[メッセージングコネクタ](/issue_tracking/pro_integration/messaging_connectors/)。必須。 | +| **Destination** | 空 | 接続が選択されると表示されます。フィールドは接続先のベンダーによって異なります。 | + +| **Subject** | `[DefectDojo] {{ctx.count}} finding(s) from rule {{ctx.rule_name}}` | メッセージごとに1回レンダリングされます。 | +| **Body** | `{{ctx.findings_html}}` を含むHTML本文 | HTML形式。`{{ctx.findings_html}}` が検出事項の一覧をレンダリングします。 | +| **One Message per Finding** | オフ | オフの場合、バッチ全体について1件のメールを送信します。 | +| **Findings Listed in the Body** | `25` | `{{ctx.findings_html}}` が「他に何件あるか」を示す前に列挙する検出事項の件数。 | + +### Webhookを呼び出す + +`notify.webhook` + +Webhookエンドポイントに対してJSONをPOSTします。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Webhook Endpoint** | なし | 設定済みの[通知Webhook](/automation/api/notification_webhooks/)。そのカスタムヘッダーがリクエストとともに送信されます。 | +| **URL** | 空 | エンドポイントが選択されていない場合に表示されます。POST先。 | +| | | 上記のいずれか一方が必須です。 | +| **Signing Secret** | 空 | 本文に `X-DefectDojo-Signature: sha256=HMAC` として署名します。 | +| **One Message per Finding** | オフ | オフの場合、バッチ全体を1回のリクエストでPOSTします。 | + +知っておくべきことが2つあります。ここに入力した署名シークレットはルールとともに保存されるため、機密性の高いものについては設定済みのエンドポイントとその専用ヘッダーを使うことをお勧めします。また、ルールによって呼び出されたWebhookは、そのエンドポイント自体のヘルスステータスを変更することはないため、ルールが失敗しても通知Webhookが無効化されることはありません。 + +自由入力のURLは保存時に検証されます。何が拒否されるか、またプライベートアドレスを許可する方法については[設定](../configuration/#outbound-destination-validation)を参照してください。 + +### アプリ内アラートを発行 + +`notify.alert` + +バッチに関するアプリ内アラートを作成します。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Title** | `Rules Engine 2.0: {{ctx.rule_name}}` | バッチ全体について1回レンダリングされます。 | +| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | バッチ全体について1回レンダリングされます。 | +| **Recipients** | 空 | ユーザー名をカンマ区切りで指定します。空の場合は管理者にアラートが送られます。 | + +受信者は自身の**Rules Engine Match**通知設定を通じて、これを引き続き制御できます。そのため、アラートがユーザーの通知設定を回避することはありません。 + +### レポートを生成 + +`report.generate` + +テンプレートからレポートを生成します。このノードに到達した検出事項に範囲が限定され、ダウンロードリンクをアナウンスすることもできます。 + +| 設定 | デフォルト | 備考 | +|---------|---------|-------| +| **Report Template** | なし | どのテンプレートから生成するか。必須。 | +| **Format** | `pdf` | `pdf` または `html`。 | +| **Findings Included** | `batch_findings` | `batch_findings` は、このノードに到達した検出事項にレポートを限定します。`template_default` はテンプレート自身のフィルターを使用させます。 | +| **Announce Over** | なし | レポート生成後にダウンロードリンクを投稿する[メッセージングコネクタ](/issue_tracking/pro_integration/messaging_connectors/)。アナウンスしない場合は空のままにします。 | +| **Announce To** | 空 | 接続が選択されると表示されます。その接続の送信先(Slackチャネル ID、メールアドレスなど)。 | +| **Announcement** | `Report ready: {{ctx.report_url}}` | アナウンスする場合に表示されます。`{{ctx.report_url}}` がダウンロードリンクです。 | + +`batch_findings` は、スケジュール実行のレポートにはできない、ルールならではのことです。まさに今マッチした検出事項についてレポートできます。 + +アナウンスはレポート生成とは別の、独自の配信として記録されるため、レポートの生成は成功しつつアナウンスだけが失敗した、という状況も個別に確認できます。 diff --git a/docs/content/automation/rules_engine_2/runs.de.md b/docs/content/automation/rules_engine_2/runs.de.md new file mode 100644 index 00000000000..f80ab302c02 --- /dev/null +++ b/docs/content/automation/rules_engine_2/runs.de.md @@ -0,0 +1,133 @@ +--- +title: Läufe +description: Wie eine Regel ausgeführt wird, was ein Lauf aufzeichnet und wie die + Kaskadierung begrenzt wird +weight: 4 +audience: pro +aliases: +- /de/automation/rules_engine_v2/runs/ +--- + +Hinweis: Rules Engine 2.0 ist eine reine DefectDojo-Pro-Funktion. + +Ein **Lauf** ist eine Ausführung einer Regel. Jeder Lauf wird aufgezeichnet, unabhängig davon, ob er erfolgreich war oder fehlgeschlagen ist, und jeder Knoten darin hinterlässt eine Spur. **Rules Engine 2.0 > Läufe** listet sie auf. + +## Was ein Lauf aufzeichnet + +| Feld | Bedeutung | +|-------|---------| +| **Regel** | Die Regel, die ausgeführt wurde. | +| **Auslöser** | Das Ereignis, das den Lauf gestartet hat, zum Beispiel `finding.created`, `schedule` oder `manual`. | +| **Ausgelöst von** | Die Person, die den Lauf gestartet hat, sofern es eine Person war: wer auf Run geklickt hat, oder wer den Befund gespeichert hat, der den Lauf ausgelöst hat. Leer bei einem Zeitplan und bei einer Änderung, bei der niemand anwesend war, etwa ein Import oder ein API-Aufruf ohne Benutzer. Dies unterscheidet sich vom Eigentümer der Regel, der angibt, **als wer** der Lauf ausgeführt wurde. | +| **Status** | `Running`, `Success` oder `Error`. | +| **Gestartet** und **Beendet** | Wann der Lauf ausgeführt wurde. Beendet ist nur leer, solange der Lauf noch läuft. | +| **Fehler** | Der Fehler, der den Lauf beendet hat, falls er fehlgeschlagen ist. | +| **Statistiken** | Summen pro Knoten, kaskadierte Ereignisse und aufgeschobene Arbeit. | +| **Tiefe** | Wie viele Kaskadierungsschritte dieser Lauf vom auslösenden Ereignis entfernt ist. | +| **Quell-Lauf** | Der Lauf, dessen ausgelöstes Ereignis diesen Lauf bei einem kaskadierten Lauf gestartet hat. | + +### Die Knoten-Spur + +Innerhalb eines Laufs zeichnet jeder Knoten seine eigene Zeile auf: + +| Feld | Bedeutung | +|-------|---------| +| **Reihenfolge** | Wo der Knoten in der Ausführungsreihenfolge stand. | +| **Knoten** | Seine ID, sein Typ und, falls vergeben, seine Bezeichnung. | +| **Status** | Ob der Knoten erfolgreich abgeschlossen wurde oder einen Fehler ausgelöst hat. | +| **Eingehende Elemente** | Wie viele Elemente eingegangen sind. | +| **Ausgehende Elemente** | Wie viele Elemente den Knoten verlassen haben, aufgeschlüsselt nach Ausgabe-Handle, sodass ein If/Filter-Knoten seine True- und False-Zähler getrennt anzeigt. | +| **Zusammenfassung** | Welche Zähler der Knoten gemeldet hat, zum Beispiel wie viele Befunde er geändert hat. | +| **Fehler** | Der Fehler, den er ausgelöst hat, falls er fehlgeschlagen ist. | + +Die Spur ist das, was Sie lesen, wenn eine Regel nicht das getan hat, was Sie erwartet haben. Ein If/Filter-Knoten, der 400 eingehende Elemente und 0 im True-Zweig meldet, zeigt Ihnen, dass die Bedingungen falsch sind, ohne dass Sie raten müssen. + +## Ausführungsmodell + +Knoten werden in topologischer Reihenfolge ausgeführt: Ein Knoten läuft erst, wenn alles, was in ihn einfließt, bereits gelaufen ist. Ein Knoten mit mehreren eingehenden Kanten erhält alle deren Ausgaben zusammengeführt. Ein Knoten, in den nichts einfließt, läuft trotzdem, mit einer leeren Eingabeliste. + +### Ein fehlgeschlagener Lauf ändert nichts + +Ein Lauf ist atomar. Wenn ein Knoten einen Fehler auslöst, wird jede Befundänderung, die der Lauf vorgenommen hat, zurückgerollt. + +Die Spur wird dabei nicht zurückgerollt. Die Knotenzeilen und der `Error`-Status werden im Nachhinein geschrieben, sodass ein fehlgeschlagener Lauf Ihnen genau zeigt, welcher Knoten kaputt war, ohne halb angewendete Änderungen zu hinterlassen. Das ist die wichtigste Garantie, die Sie beim Lesen der Läufe-Seite im Hinterkopf behalten sollten: Ein fehlerhafter Lauf ist ein Lauf, der nichts bewirkt hat. + +Der Egress folgt derselben Regel. Zustellungen werden innerhalb der Transaktion des Laufs aufgezeichnet und erst nach deren Commit versendet, sodass ein Lauf, der zurückgerollt wird, nichts versendet. + +### Immer nur ein Lauf pro Regel + +Eine Regel kann immer nur einen laufenden Lauf haben. Ein zweiter Auslöser für dieselbe Regel, während sie noch läuft, tritt nicht in Konkurrenz dazu. Er wartet und versucht es erneut. + +Unterschiedliche Regeln laufen vollständig parallel, sodass eine langsame Regel ihre Geschwisterregeln nie aufhält. + +Wenn ein Lauf auf irgendeine Weise verwaist, zum Beispiel weil der ausführende Worker beendet wurde, wird seine Sperre nach einem Stillstandsfenster (standardmäßig 30 Minuten) freigegeben, damit die Regel nicht für immer blockiert bleibt. Ein Lauf, der sich diesem Fenster nähert, stoppt sich zuerst selbst und wickelt sich sauber ab, sodass ein lediglich langsamer Lauf niemals gleichzeitig mit seinem eigenen Ersatz laufen kann. + +## Kaskadierung + +Eine Regel, die einen Befund ändert, erzeugt genau die Art von Ereignis, auf das eine andere Regel reagieren kann. Rules Engine 2.0 erlaubt das, sodass Ketten wie `A -> B -> C` funktionieren, und begrenzt dies auf zwei unabhängige Arten: + +* **Tiefe.** Ein Ereignis darf höchstens **3** Kaskadierungsschritte von der Änderung entfernt zurücklegen, die es ausgelöst hat. +* **Ketten-Zugehörigkeit.** Jedes Ereignis trägt die Liste der Regeln, die in seiner Kette bereits durchlaufen wurden, und eine Regel läuft nie zweimal in derselben Kette. Eine Regel kann sich also nicht selbst erneut auslösen, und zwei Regeln können nicht hin- und herspielen. + +Die Felder **Tiefe** und **Quell-Lauf** eines Laufs erlauben es Ihnen, eine Kette bis zu der Änderung zurückzuverfolgen, die sie gestartet hat. **Ausgelöst von** wird durch die gesamte Kette weitergegeben, sodass eine Kaskade, die eine Person ausgelöst hat, bei jedem Schritt dieser Person zuordenbar bleibt. + +Änderungen, die *von* einer laufenden Regel vorgenommen werden, werden der eigenen Kaskade dieser Regel zugeordnet, statt wie neue Benutzeraktivität auszusehen, sodass eine Regel, die Arbeit intern delegiert, die Kette nicht aufbläht. + +## Umfang und Grenzwerte + +**Ein Lauf ist nicht begrenzt.** Eine Regel verarbeitet alles, worauf ihr Geltungsbereich zutrifft, egal wie groß das ist. Eine Regel, die bei den ersten N Befunden stillschweigend anhält, wäre eine Regel, der Sie nicht vertrauen könnten. + +Stattdessen wird ein Lauf in **Chunks** verarbeitet, standardmäßig 1.000 Befunde auf einmal. Nur der Chunk wird im Speicher gehalten, sodass ein Durchlauf über einen sehr großen Geltungsbereich im Speicherverbrauch begrenzt ist, nicht in der Abdeckung. Die einzige Ausnahme ist die **Vorschau**, die tatsächlich begrenzt ist und dies in ihrer Spur angibt, wenn sie kürzt. + +Zwei weitere Zahlen bestimmen, wie die Arbeit aufgeteilt wird: + +* **Befunde pro Ereignis**, standardmäßig 500. Eine Massenänderung wird auf mehrere Ereignisse aufgeteilt, von denen jedes zu einem eigenen Lauf wird. Der praktische Effekt bei einem großen Import ist eine überschaubare Anzahl von Läufen statt eines Laufs pro Befund. +* **Sendeobergrenze pro Befund**, standardmäßig 1.000. Ein Egress-Knoten, der so eingestellt ist, dass er eine Nachricht pro Befund sendet, hält bei dieser Anzahl in einem einzelnen Lauf an und protokolliert ein sichtbares Überspringen mit der Anzahl der nicht gesendeten Nachrichten. Dies begrenzt Zustellungszeilen und wartende Aufgaben, was ein in Chunks verarbeiteter Lauf allein nicht mehr begrenzt. + +Alle drei sind Deployment-Einstellungen, dokumentiert unter [Configuration](../configuration/). + +### Wie lange ein Lauf dauern darf + +Ein Lauf setzt nach jedem Chunk einen **Heartbeat**. Die Stillstandserkennung liest diesen Heartbeat statt der Startzeit, sodass ein langer Durchlauf, der noch Fortschritte macht, niemals mit einem abgestürzten Worker verwechselt wird. + +Zwei Zeitfenster gelten, beide konfigurierbar: + +* Ein Lauf, der 30 Minuten ohne Heartbeat bleibt, wird als verwaist behandelt, auf Fehler gesetzt, und seine Sperre wird freigegeben. +* Ein Lauf wird nach sechs Stunden zwangsweise beendet, als Schutz gegen einen Lauf, der niemals fertig würde. + +## Aufbewahrung + +Läufe werden standardmäßig **180 Tage** lang aufbewahrt, zusammen mit ihren Zeilen pro Knoten und ihrer Befund-Herkunft. Zustellungen werden separat 180 Tage lang aufbewahrt. + +Das Produkt teilt Ihnen dies mit, statt es implizit zu lassen: Die Detailansicht eines Laufs zeigt das Aufbewahrungsfenster und das Datum, an dem der Lauf gelöscht wird. Ein Lauf, der noch Zustellungen enthält, wird aufbewahrt, bis diese bereinigt sind. + +Beide Zeitfenster sind konfigurierbar, und beide können so eingestellt werden, dass Datensätze unbegrenzt aufbewahrt werden. Siehe [Configuration](../configuration/#retention). + +## Eine Regel manuell ausführen + +Eine Regel, deren Auslöser **Manueller Lauf** ist, wird über die Aktion **Ausführen** in der Regelliste gestartet. Regeln mit anderen Auslösern laufen, wenn ihr Auslöser eintritt. + +**Vorschau**, im Editor, ist die andere Möglichkeit, einen Graphen auszuführen. Sie führt die echte Engine aus und rollt anschließend alles zurück, zeichnet keinen Lauf auf und zwingt den Egress zur Simulation. Nutzen Sie die Vorschau während der Erstellung und Läufe, um zu sehen, was tatsächlich passiert ist. + +## Herkunft an einem Befund + +Läufe beantworten die Frage „Was hat diese Regel getan?“. Herkunft beantwortet die entgegengesetzte Frage: „Warum hat sich dieser Befund geändert?“. + +Jede Änderung, die eine Regel vornimmt, wird am Befund zusammen mit der verantwortlichen Regel, dem Lauf und dem Knoten aufgezeichnet und erscheint als Zeitleiste am Befund selbst. Die aufgezeichneten Aktionen sind: + +| Aktion | Bedeutung | +|--------|---------| +| `created`, `updated`, `closed`, `reopened` | Der Lebenszyklus des Befunds hat sich geändert. | +| `duplicate`, `status_change` | Seine Duplikat- oder Status-Flags haben sich geändert. | +| `notified` | Eine Benachrichtigung wurde dazu versendet. | +| `delivered` | Eine ausgehende Zustellung hat ihn abgedeckt. | + +Feldbearbeitungen zeichnen auf, was sich geändert hat, einschließlich des Werts jedes Feldes vor und nach der Änderung. Sehr lange Werte werden im Datensatz gekürzt, sodass die Zeitleiste ein Protokoll der Änderung bleibt und keine zweite Kopie des Befunds. + +Benachrichtigungen und Zustellungen werden ebenfalls hier aufgezeichnet. Das ist beabsichtigt: Eine Regel, die eine Nachricht gesendet, aber kein Feld geändert hat, würde sonst überhaupt keine Spur am Befund hinterlassen. + +Die Herkunft überdauert die Regel. Das Löschen einer Regel oder eines Laufs behält die Zeitleisteneinträge bei und verknüpft sie lediglich neu, sodass der Verlauf nicht verschwindet, wenn jemand aufräumt. + +## Regeln mit Verlauf löschen + +Eine Regel, die Zustellungen erzeugt hat, kann nicht gelöscht werden, solange diese noch bestehen. Löschen Sie zuerst die Zustellungen, oder behalten Sie die Regel und deaktivieren Sie sie. Dies ist beabsichtigt: Zustellungen enthalten das Protokoll dessen, was tatsächlich an externe Systeme gesendet wurde, und ein kaskadierendes Löschen würde laufende Sendungen mit sich reißen. diff --git a/docs/content/automation/rules_engine_2/runs.es.md b/docs/content/automation/rules_engine_2/runs.es.md new file mode 100644 index 00000000000..cc68f5b61df --- /dev/null +++ b/docs/content/automation/rules_engine_2/runs.es.md @@ -0,0 +1,136 @@ +--- +title: Ejecuciones +description: Cómo se ejecuta una regla, qué registra una ejecución y cómo se limita + el encadenamiento +weight: 4 +audience: pro +aliases: +- /es/automation/rules_engine_v2/runs/ +--- + +Nota: Rules Engine 2.0 es una función exclusiva de DefectDojo Pro. + +Una **ejecución** es una instancia de ejecución de una regla. Cada ejecución se registra, tanto si tuvo éxito como si falló, y cada nodo dentro de ella deja un rastro. **Rules Engine 2.0 > Runs** las enumera. + +## Qué registra una ejecución + +| Field | Meaning | +|-------|---------| +| **Rule** | La regla que se ejecutó. | +| **Trigger** | El evento que la inició, por ejemplo `finding.created`, `schedule` o `manual`. | +| **Triggered by** | La persona que la desencadenó, cuando fue una persona: quien presionó Run, o quien guardó el Hallazgo que la disparó. Vacío en el caso de una programación, y en el de un cambio en el que no hubo nadie presente, como una importación o una llamada a la API sin usuario. Esto es distinto del propietario de la regla, que es la identidad **con la que** se ejecutó la ejecución. | +| **Status** | `Running`, `Success` o `Error`. | +| **Started** y **Finished** | Cuándo se ejecutó. Finished solo está vacío mientras sigue en ejecución. | +| **Error** | El error que la finalizó, si falló. | +| **Stats** | Totales por nodo, eventos en cascada y trabajo diferido. | +| **Depth** | A cuántos saltos de cascada está esta ejecución del evento de origen. | +| **Source run** | La ejecución cuyo evento emitido disparó esta, en el caso de una ejecución en cascada. | + +### El rastro del nodo + +Dentro de una ejecución, cada nodo registra su propia fila: + +| Field | Meaning | +|-------|---------| +| **Order** | La posición del nodo en el orden de ejecución. | +| **Node** | Su id, su tipo y su etiqueta, si le asignó una. | +| **Status** | Si el nodo se completó o generó un error. | +| **Items in** | Cuántos elementos entraron. | +| **Items out** | Cuántos salieron, desglosados por controlador de salida, de modo que un nodo If / Filter muestra sus recuentos de verdadero y falso por separado. | +| **Summary** | Los contadores que reportó el nodo, por ejemplo cuántos Hallazgos cambió. | +| **Error** | El error que generó, si falló. | + +El rastro es lo que se lee cuando una regla no hizo lo que se esperaba. Un nodo If / Filter que reporta 400 elementos de entrada y 0 por la rama verdadera indica que las condiciones están mal, sin necesidad de adivinar. + +## Modelo de ejecución + +Los nodos se ejecutan en orden topológico: un nodo se ejecuta una vez que todo lo que lo alimenta se ha ejecutado. Un nodo con varios bordes entrantes recibe todas sus salidas concatenadas. Un nodo sin nada que lo alimente igual se ejecuta, con una lista de entrada vacía. + +### Una ejecución fallida no cambia nada + +Una ejecución es atómica. Si algún nodo genera un error, se revierten todos los cambios de Hallazgos que hizo la ejecución. + +El rastro no se revierte junto con ella. Las filas de nodos y el estado `Error` se escriben después, de modo que una ejecución fallida indica exactamente qué nodo falló sin dejar ediciones aplicadas a medias. Esta es la garantía más importante a tener en cuenta al leer la página de Runs: una ejecución con error es una ejecución que no hizo nada. + +La salida (egress) sigue la misma regla. Las entregas se registran dentro de la transacción de la ejecución y solo se despachan después de que esta se confirme, de modo que una ejecución que se revierte no envía nada. + +### Una ejecución por regla a la vez + +Una regla solo puede tener una ejecución en curso. Un segundo disparador para la misma regla mientras aún está en ejecución no compite con ella. Espera y reintenta. + +Las reglas diferentes se ejecutan de forma totalmente concurrente, de modo que una regla lenta nunca retrasa a las demás. + +Si una ejecución queda abandonada de alguna forma, por ejemplo porque se mató al worker que la ejecutaba, su bloqueo se libera tras una ventana de estancamiento (30 minutos de forma predeterminada) para que la regla no quede atascada para siempre. Una ejecución que se acerca a esa ventana se detiene primero por sí sola, desenrollándose de forma limpia, de modo que una ejecución simplemente lenta nunca termina ejecutándose junto con su propio reemplazo. + +## Encadenamiento + +Una regla que cambia un Hallazgo produce exactamente el tipo de evento sobre el que otra regla puede activarse. Rules Engine 2.0 permite esto, de modo que las cadenas `A -> B -> C` funcionan, y lo limita de dos formas independientes: + +* **Depth.** Un evento puede viajar como máximo **3** saltos en cascada desde el cambio que lo originó. + +* **Chain membership.** Cada evento lleva la lista de reglas ya recorridas en su cadena, y una regla nunca se ejecuta dos veces en la misma cadena. Así, una regla no puede volver a activarse a sí misma, y dos reglas no pueden rebotar entre sí. + +Los campos **Depth** y **Source run** de una ejecución permiten rastrear una cadena hasta el cambio que la inició. **Triggered by** se traslada a lo largo de toda la cadena, de modo que una cascada que una persona inició sigue siéndole atribuible en cada salto. + +Los cambios hechos *por* una regla en ejecución se atribuyen a la propia cascada de esa regla en lugar de parecer actividad nueva de un usuario, de modo que una regla que delega trabajo internamente no infla la cadena. + +## Escala y límites + +**Una ejecución no tiene un tope.** Una regla procesa todo lo que coincide con su alcance, sin importar cuán grande sea. Una regla que se detuviera silenciosamente en los primeros N Hallazgos sería una regla en la que no se podría confiar. + +En cambio, una ejecución se procesa en **bloques (chunks)**, de 1000 Hallazgos a la vez de forma predeterminada. Solo el bloque se mantiene en memoria, de modo que un barrido sobre un alcance muy grande está limitado por la memoria y no por la cobertura. La única excepción es **Preview**, que sí tiene un tope, y lo indica en su rastro cuando trunca. + +Otros dos números determinan cómo se divide el trabajo: + +* **Findings per event**, 500 de forma predeterminada. Un cambio masivo se divide en varios eventos, cada uno convirtiéndose en su propia ejecución. El efecto práctico para una importación grande es un número manejable de ejecuciones en lugar de una ejecución por Hallazgo. + +* **Per-Finding send ceiling**, 1000 de forma predeterminada. Un nodo de salida configurado para enviar un mensaje por Hallazgo se detiene en esta cantidad dentro de una sola ejecución y registra una omisión visible que indica cuántos no se enviaron. Esto limita las filas de entregas y las tareas en cola, algo que una ejecución dividida en bloques ya no limita por sí sola. + +Los tres son parámetros de implementación, documentados en [Configuration](../configuration/). + +### Cuánto puede durar una ejecución + +Una ejecución registra un **heartbeat** (latido) después de cada bloque. La detección de estancamiento lee ese heartbeat en lugar de la hora de inicio, de modo que un barrido largo que sigue avanzando nunca se confunde con un worker caído. + +Se aplican dos ventanas, ambas configurables: + +* Una ejecución que pasa 30 minutos sin un heartbeat se trata como abandonada, se marca con error y se libera su bloqueo. + +* Una ejecución se termina directamente después de seis horas, como resguardo contra una que nunca terminaría. + +## Retención + +Las ejecuciones se conservan durante **180 días** de forma predeterminada, junto con sus filas por nodo y su procedencia de Hallazgos. Las entregas se conservan durante 180 días por separado. + +El producto lo indica en lugar de dejarlo implícito: el detalle de una ejecución muestra la ventana de retención y la fecha en que esa ejecución se eliminará. Una ejecución que todavía contiene entregas se conserva hasta que estas se depuran. + +Ambas ventanas son configurables, y cualquiera de las dos puede establecerse para conservar los registros indefinidamente. Consulte [Configuration](../configuration/#retention). + +## Ejecutar una regla manualmente + +Una regla cuyo disparador es **Manual Run** se ejecuta con la acción **Run** en la lista de reglas. Las reglas con otros disparadores se ejecutan cuando su disparador se activa. + +**Preview**, en el editor, es la otra forma de ejecutar un grafo. Ejecuta el motor real y luego revierte todo, no registra ninguna ejecución y fuerza a la salida a simular. Use preview mientras construye, y runs para ver qué ocurrió realmente. + +## Procedencia en un Hallazgo + +Las ejecuciones responden "¿qué hizo esta regla?". La procedencia responde la pregunta opuesta: "¿por qué cambió este Hallazgo?". + +Cada cambio que hace una regla se registra contra el Hallazgo junto con la regla, la ejecución y el nodo responsables, y aparece como una línea de tiempo en el propio Hallazgo. Las acciones registradas son: + +| Action | Meaning | +|--------|---------| +| `created`, `updated`, `closed`, `reopened` | Cambió el ciclo de vida del Hallazgo. | +| `duplicate`, `status_change` | Cambiaron sus indicadores de duplicado o de estado. | +| `notified` | Se envió una notificación sobre él. | +| `delivered` | Una entrega saliente lo cubrió. | + +Las ediciones de campos registran lo que cambió, incluido el valor anterior y posterior de cada campo. Los valores muy largos se truncan en el registro, de modo que la línea de tiempo sigue siendo un registro del cambio y no una segunda copia del Hallazgo. + +Las notificaciones y las entregas también se registran aquí. Esto es intencional: una regla que enviara un mensaje pero no cambiara ningún campo, de lo contrario, no dejaría ningún rastro en el Hallazgo. + +La procedencia sobrevive a la regla. Eliminar una regla o una ejecución conserva las entradas de la línea de tiempo y simplemente las desvincula, de modo que el historial no desaparece cuando alguien hace limpieza. + +## Eliminar reglas con historial + +Una regla que ha producido entregas no se puede eliminar dejándolas huérfanas. Elimine primero las entregas, o conserve la regla y desactívela. Esto es intencional: las entregas contienen el registro de lo que realmente se envió a sistemas externos, y una eliminación en cascada se llevaría consigo los envíos en curso. diff --git a/docs/content/automation/rules_engine_2/runs.fr.md b/docs/content/automation/rules_engine_2/runs.fr.md new file mode 100644 index 00000000000..6663a3dbc31 --- /dev/null +++ b/docs/content/automation/rules_engine_2/runs.fr.md @@ -0,0 +1,133 @@ +--- +title: Exécutions +description: Comment une règle s'exécute, ce qu'une exécution enregistre, et comment + l'enchaînement est limité +weight: 4 +audience: pro +aliases: +- /fr/automation/rules_engine_v2/runs/ +--- + +Remarque : le Moteur de règles 2.0 est une fonctionnalité réservée à DefectDojo Pro. + +Une **exécution** correspond à un déclenchement d'une règle. Chaque exécution est enregistrée, qu'elle ait réussi ou échoué, et chaque nœud qui la compose laisse une trace. **Moteur de règles 2.0 > Exécutions** les répertorie. + +## Ce qu'une exécution enregistre + +| Field | Meaning | +|-------|---------| +| **Règle** | La règle qui a été exécutée. | +| **Déclencheur** | L'événement qui l'a démarrée, par exemple `finding.created`, `schedule` ou `manual`. | +| **Déclenchée par** | La personne à l'origine du déclenchement, quand une personne en est à l'origine : celle qui a cliqué sur Exécuter, ou celle qui a enregistré la Constatation qui l'a déclenchée. Vide pour une planification, et pour un changement effectué sans intervention humaine, comme un import ou un appel API sans utilisateur. Ceci est distinct du propriétaire de la règle, qui est l'identité **au nom de laquelle** l'exécution s'est déroulée. | +| **Statut** | `Running`, `Success` ou `Error`. | +| **Démarrée** et **Terminée** | Quand elle s'est exécutée. Terminée reste vide uniquement tant qu'elle est encore en cours. | +| **Erreur** | L'erreur qui y a mis fin, en cas d'échec. | +| **Statistiques** | Totaux par nœud, événements enchaînés et travail différé. | +| **Profondeur** | Le nombre de sauts d'enchaînement séparant cette exécution de l'événement d'origine. | +| **Exécution source** | L'exécution dont l'événement émis a déclenché celle-ci, dans le cas d'une exécution enchaînée. | + +### La trace des nœuds + +Au sein d'une exécution, chaque nœud enregistre sa propre ligne : + +| Field | Meaning | +|-------|---------| +| **Ordre** | La position du nœud dans l'ordre d'exécution. | +| **Nœud** | Son identifiant, son type, et son libellé si vous lui en avez donné un. | +| **Statut** | Si le nœud s'est terminé normalement ou a levé une erreur. | +| **Éléments entrants** | Le nombre d'éléments entrés. | +| **Éléments sortants** | Le nombre d'éléments sortis, ventilé par sortie, de sorte qu'un nœud If / Filter affiche séparément ses décomptes vrai et faux. | +| **Résumé** | Les compteurs rapportés par le nœud, par exemple le nombre de Constatations qu'il a modifiées. | +| **Erreur** | L'erreur levée, en cas d'échec. | + +La trace est ce que vous consultez lorsqu'une règle n'a pas fait ce que vous attendiez. Un nœud If / Filter signalant 400 éléments entrants et 0 vers la branche vraie vous indique que les conditions sont erronées, sans que vous ayez à le deviner. + +## Modèle d'exécution + +Les nœuds s'exécutent dans un ordre topologique : un nœud s'exécute une fois que tout ce qui l'alimente s'est exécuté. Un nœud possédant plusieurs arêtes entrantes reçoit l'ensemble de leurs sorties concaténées. Un nœud sans rien qui l'alimente s'exécute quand même, avec une liste d'entrée vide. + +### Une exécution échouée ne change rien + +Une exécution est atomique. Si un nœud lève une erreur, chaque modification de Constatation effectuée par l'exécution est annulée. + +La trace, elle, n'est pas annulée. Les lignes des nœuds et le statut `Error` sont écrits après coup, si bien qu'une exécution échouée vous indique exactement quel nœud a posé problème, sans laisser de modifications partiellement appliquées. C'est la garantie la plus importante à garder à l'esprit en lisant la page Exécutions : une exécution en erreur est une exécution qui n'a rien fait. + +La sortie (egress) suit la même règle. Les livraisons sont enregistrées au sein de la transaction de l'exécution et ne sont envoyées qu'une fois celle-ci validée, de sorte qu'une exécution annulée n'envoie rien. + +### Une seule exécution par règle à la fois + +Une règle ne peut avoir qu'une seule exécution en cours. Un second déclenchement de la même règle pendant qu'elle est encore en cours ne se produit pas en concurrence avec elle. Il attend et réessaie. + +Des règles différentes s'exécutent en parallèle complet, de sorte qu'une règle lente ne bloque jamais les autres. + +Si une exécution se retrouve abandonnée, par exemple parce que le worker qui l'exécutait a été tué, son verrou est libéré après une fenêtre d'inactivité (30 minutes par défaut) afin que la règle ne reste pas bloquée indéfiniment. Une exécution qui approche de cette fenêtre s'arrête elle-même en premier, en se désengageant proprement, de sorte qu'une exécution simplement lente ne peut jamais finir par s'exécuter en même temps que son propre remplacement. + +## Enchaînement + +Une règle qui modifie une Constatation produit exactement le type d'événement sur lequel une autre règle peut se déclencher. Le Moteur de règles 2.0 l'autorise, de sorte que des chaînes `A -> B -> C` fonctionnent, et le limite de deux façons indépendantes : + +* **Profondeur.** Un événement peut parcourir au maximum **3** sauts d'enchaînement depuis le changement qui l'a produit. +* **Appartenance à la chaîne.** Chaque événement porte la liste des règles déjà traversées dans sa chaîne, et une règle ne s'exécute jamais deux fois dans la même chaîne. Une règle ne peut donc pas se redéclencher elle-même, et deux règles ne peuvent pas se relancer mutuellement en boucle. + +Les champs **Profondeur** et **Exécution source** d'une exécution permettent de remonter une chaîne jusqu'au changement qui l'a déclenchée. **Déclenchée par** est propagé tout au long de la chaîne, de sorte qu'un enchaînement déclenché par une personne lui reste attribuable à chaque saut. + +Les changements effectués *par* une règle en cours d'exécution sont attribués à l'enchaînement propre de cette règle plutôt que de ressembler à une nouvelle activité utilisateur, de sorte qu'une règle déléguant du travail en interne ne gonfle pas la chaîne. + +## Échelle et limites + +**Une exécution n'est pas plafonnée.** Une règle traite tout ce que son périmètre couvre, quelle que soit son ampleur. Une règle qui s'arrêterait silencieusement aux N premières Constatations serait une règle à laquelle on ne pourrait pas faire confiance. + +À la place, une exécution est traitée par **lots**, 1 000 Constatations à la fois par défaut. Seul le lot est conservé en mémoire, de sorte qu'un balayage sur un très large périmètre est borné en mémoire plutôt qu'en couverture. La seule exception est **Aperçu**, qui plafonne bel et bien, et l'indique dans sa trace lorsqu'il tronque. + +Deux autres nombres déterminent la façon dont le travail est réparti : + +* **Constatations par événement**, 500 par défaut. Un changement en masse est réparti sur plusieurs événements, chacun devenant sa propre exécution. L'effet pratique pour un import volumineux est un nombre gérable d'exécutions plutôt qu'une exécution par Constatation. +* **Plafond d'envoi par Constatation**, 1 000 par défaut. Un nœud de sortie configuré pour envoyer un message par Constatation s'arrête à ce nombre au sein d'une même exécution et enregistre un rejet visible indiquant combien de Constatations n'ont pas fait l'objet d'un envoi. Cela borne les lignes de livraison et les tâches en file d'attente, que le traitement par lots ne borne plus à lui seul. + +Ces trois paramètres sont des réglages de déploiement, documentés dans [Configuration](../configuration/). + +### Combien de temps une exécution peut durer + +Une exécution horodate un **signal de vie** (heartbeat) après chaque lot. La détection de blocage lit ce signal de vie plutôt que l'heure de démarrage, de sorte qu'un long balayage encore en progression n'est jamais confondu avec un worker planté. + +Deux fenêtres s'appliquent, toutes deux configurables : + +* Une exécution qui reste 30 minutes sans signal de vie est considérée comme abandonnée, passe en erreur, et son verrou est libéré. +* Une exécution est purement et simplement arrêtée au bout de six heures, en garde-fou contre une exécution qui ne se terminerait jamais. + +## Rétention + +Les exécutions sont conservées **180 jours** par défaut, ainsi que leurs lignes par nœud et leur provenance de Constatation. Les livraisons sont conservées 180 jours séparément. + +Le produit vous l'indique plutôt que de le laisser implicite : le détail d'une exécution affiche la fenêtre de rétention et la date à laquelle cette exécution sera supprimée. Une exécution qui détient encore des livraisons est conservée jusqu'à ce que celles-ci soient purgées. + +Les deux fenêtres sont configurables, et chacune peut être réglée pour conserver les enregistrements indéfiniment. Voir [Configuration](../configuration/#retention). + +## Exécuter une règle manuellement + +Une règle dont le déclencheur est **Exécution manuelle** s'exécute via l'action **Exécuter** sur la liste des règles. Les règles ayant d'autres déclencheurs s'exécutent quand leur déclencheur se produit. + +**Aperçu**, dans l'éditeur, est l'autre façon d'exécuter un graphe. Il fait tourner le véritable moteur puis annule tout, n'enregistre aucune exécution, et force la sortie à simuler. Utilisez l'aperçu pendant la construction, et les exécutions pour voir ce qui s'est réellement passé. + +## Provenance sur une Constatation + +Les exécutions répondent à la question « qu'a fait cette règle ? ». La provenance répond à la question inverse : « pourquoi cette Constatation a-t-elle changé ? ». + +Chaque changement effectué par une règle est enregistré sur la Constatation avec la règle, l'exécution et le nœud responsables, et apparaît sous forme de chronologie sur la Constatation elle-même. Les actions enregistrées sont : + +| Action | Meaning | +|--------|---------| +| `created`, `updated`, `closed`, `reopened` | Le cycle de vie de la Constatation a changé. | +| `duplicate`, `status_change` | Ses indicateurs de doublon ou de statut ont changé. | +| `notified` | Une notification a été envoyée à son sujet. | +| `delivered` | Une livraison sortante l'a couverte. | + +Les modifications de champs enregistrent ce qui a changé, y compris la valeur avant et après de chaque champ. Les valeurs très longues sont tronquées dans l'enregistrement, de sorte que la chronologie reste un historique du changement plutôt qu'une seconde copie de la Constatation. + +Les notifications et les livraisons sont également enregistrées ici. C'est voulu : une règle qui envoie un message sans modifier aucun champ ne laisserait sinon aucune trace sur la Constatation. + +La provenance survit à la règle. La suppression d'une règle ou d'une exécution conserve les entrées de la chronologie et se contente de les dissocier, de sorte que l'historique ne disparaît pas lorsque quelqu'un fait du ménage. + +## Supprimer des règles ayant un historique + +Une règle ayant produit des livraisons ne peut pas être supprimée tant que celles-ci existent encore. Supprimez d'abord les livraisons, ou conservez la règle et désactivez-la. C'est intentionnel : les livraisons conservent la trace de ce qui a réellement été envoyé aux systèmes externes, et une suppression en cascade emporterait avec elle les envois en cours. diff --git a/docs/content/automation/rules_engine_2/runs.ja.md b/docs/content/automation/rules_engine_2/runs.ja.md new file mode 100644 index 00000000000..011147733ce --- /dev/null +++ b/docs/content/automation/rules_engine_2/runs.ja.md @@ -0,0 +1,132 @@ +--- +title: 実行 +description: ルールがどのように実行されるか、実行が何を記録するか、カスケードがどのように制限されるか +weight: 4 +audience: pro +aliases: +- /ja/automation/rules_engine_v2/runs/ +--- + +注: Rules Engine 2.0はDefectDojo Pro限定機能です。 + +**実行（run）**とは、1つのルールの1回分の実行のことです。成功したか失敗したかにかかわらず、すべての実行が記録され、その内部の各ノードも痕跡を残します。**Rules Engine 2.0 > Runs**にその一覧が表示されます。 + +## 実行が記録する内容 + +| Field | Meaning | +|-------|---------| +| **Rule** | 実行されたルール。 | +| **Trigger** | 実行を開始したイベント。例えば`finding.created`、`schedule`、`manual`など。 | +| **Triggered by** | 実行を発生させた人物（人が関与していた場合）。Runボタンを押した人、またはトリガーとなったFindingを保存した人です。スケジュール実行の場合や、インポートやユーザーの関与しないAPI呼び出しなど誰も関与していない変更の場合は空欄になります。これはルールの所有者（実行が**誰として**実行されたか）とは別のものです。 | +| **Status** | `Running`、`Success`、`Error`のいずれか。 | +| **Started** と **Finished** | 実行された日時。Finishedは実行中の間のみ空欄です。 | +| **Error** | 失敗した場合、実行を終了させたエラー。 | +| **Stats** | ノードごとの合計、カスケードされたイベント、保留中の作業。 | +| **Depth** | この実行が発生元のイベントから何回のカスケードホップ離れているか。 | +| **Source run** | カスケードされた実行の場合、発行したイベントによってこの実行をトリガーした実行。 | + +### ノードトレース + +実行内では、各ノードが自身の行を記録します。 + +| Field | Meaning | +|-------|---------| +| **Order** | 実行順序におけるそのノードの位置。 | +| **Node** | そのID、タイプ、および付けていればラベル。 | +| **Status** | ノードが完了したか、エラーを発生させたか。 | +| **Items in** | 入力されたアイテムの数。 | +| **Items out** | 出力ハンドルごとに内訳された出力アイテムの数。そのため、If / Filterノードではtrueとfalseのカウントが別々に表示されます。 | +| **Summary** | ノードが報告したカウンター（例えば変更したFindingの数など）。 | +| **Error** | 失敗した場合に発生させたエラー。 | + +トレースは、ルールが期待通りに動作しなかったときに確認するものです。If / Filterノードが400件のitems inを報告し、trueブランチへの出力が0件であれば、推測することなく条件が誤っていることが分かります。 + +## 実行モデル + +ノードはトポロジカル順序で実行されます。あるノードは、そこに入力を供給するすべてのノードが実行を終えた時点で実行されます。複数の入力エッジを持つノードは、それらすべての出力を連結して受け取ります。何も入力を供給されないノードも、空の入力リストで実行されます。 + +### 失敗した実行は何も変更しない + +実行はアトミックです。いずれかのノードがエラーを発生させた場合、その実行が行ったFindingへの変更はすべてロールバックされます。 + +トレースはロールバックの対象にはなりません。ノードの行と`Error`ステータスは事後に書き込まれるため、失敗した実行は、中途半端に適用された変更を一切残すことなく、どのノードが壊れたのかを正確に伝えてくれます。これは、Runsページを読む際に念頭に置くべき最も重要な保証です。エラーになった実行とは、何も行わなかった実行のことです。 + +Egress（送出）についても同じ規則が適用されます。配信は実行のトランザクション内で記録され、コミット後にのみディスパッチされるため、ロールバックされた実行は何も送信しません。 + +### 1ルールにつき同時に実行できるのは1件のみ + +1つのルールが進行中に持てる実行は1件のみです。同じルールに対して実行中に2回目のトリガーが発生しても、競合することはありません。待機してからリトライします。 + +異なるルール同士は完全に並行して実行されるため、動作の遅いルールが他のルールを妨げることはありません。 + +実行を行っていたワーカーが強制終了されるなどして実行が放棄された場合、ルールが永久に止まったままにならないよう、停滞ウィンドウ（デフォルトで30分）の経過後にロックが解放されます。このウィンドウに近づいた実行はその前に自ら停止し、正しく巻き戻しを行うため、単に遅いだけの実行がその後継の実行と同時に動いてしまうことは決してありません。 + +## カスケード + +Findingを変更するルールは、まさに他のルールがトリガーとして利用できる種類のイベントを生成します。Rules Engine 2.0はこれを許可しており、`A -> B -> C`のような連鎖が機能します。ただし、これを2つの独立した方法で制限しています。 + +* **Depth（深さ）。** イベントは、それを発生させた変更から最大**3**回のカスケードホップまでしか伝播できません。 +* **Chain membership（チェーン所属）。** すべてのイベントは、そのチェーン内で既に通過したルールの一覧を保持しており、同じルールが同じチェーン内で2回実行されることはありません。そのため、ルールが自分自身を再トリガーすることも、2つのルールが互いにやり取りを繰り返すこと（ピンポン）もできません。 + +実行の**Depth**フィールドと**Source run**フィールドを使うと、チェーンを遡ってそれを開始した変更まで追跡できます。**Triggered by**はチェーン全体を通じて引き継がれるため、ある人が発生させたカスケードは、どのホップにおいてもその人物に帰属したままになります。 + +実行中のルール*によって*行われた変更は、新規のユーザー操作のように見えるのではなく、そのルール自身のカスケードに帰属します。そのため、内部的に作業を委譲するルールがチェーンを膨張させることはありません。 + +## スケールと制限 + +**実行には上限がありません。** ルールは、そのスコープに一致するものをすべて処理します。どれほど件数が多くてもです。最初のN件のFindingで黙って処理を止めてしまうルールは、信頼できるルールとは言えません。 + +その代わりに、実行はデフォルトで一度に1,000件のFinding単位の**チャンク**で処理されます。メモリ上に保持されるのはそのチャンクのみであるため、非常に大きなスコープに対する処理も、カバー範囲ではなくメモリ使用量の面で制限されます。唯一の例外は**Preview**で、こちらは件数に上限があり、切り詰めが発生した場合はトレースにその旨が表示されます。 + +作業の分割方法を決める他の2つの数値があります。 + +* **イベントあたりのFinding数**、デフォルトで500件。一括変更は複数のイベントに分割され、それぞれが独自の実行になります。大規模なインポートにおける実際の効果は、Finding1件ごとに実行が1件発生するのではなく、管理可能な件数の実行に収まることです。 +* **Findingごとの送信上限**、デフォルトで1,000件。Finding1件につき1件のメッセージを送信するよう設定されたegressノードは、1回の実行につきこの件数で停止し、何件を送信しなかったかを示す明示的なスキップを記録します。これにより、チャンク処理された実行だけではもはや制限されなくなった配信の行数とキュー投入されたタスクの数が制限されます。 + +これら3つはいずれもデプロイメント設定であり、[Configuration](../configuration/)に記載されています。 + +### 実行にかかる時間の上限 + +実行は各チャンクの後に**ハートビート**を記録します。停滞検出は開始時刻ではなくこのハートビートを参照するため、進捗し続けている長時間のスイープがクラッシュしたワーカーと誤認されることはありません。 + +2つのウィンドウが適用され、どちらも設定可能です。 + +* ハートビートが30分間ない実行は放棄されたものとみなされ、エラー扱いとなり、ロックが解放されます。 +* 決して終わらない実行に対する保護として、実行は6時間経過すると強制終了されます。 + +## 保持期間 + +実行は、そのノードごとの行やFindingの来歴とともに、デフォルトで**180日間**保持されます。配信は別途180日間保持されます。 + +この点は暗黙のままにせず、製品側が明示します。実行の詳細には保持期間と、その実行が削除される日付が表示されます。配信をまだ保持している実行は、それらが削除されるまで保持されます。 + +どちらのウィンドウも設定可能で、いずれも無期限に記録を保持するよう設定できます。[Configuration](../configuration/#retention)を参照してください。 + +## ルールを手動で実行する + +トリガーが**Manual Run**であるルールは、ルール一覧の**Run**アクションで実行されます。それ以外のトリガーを持つルールは、そのトリガーが発生したときに実行されます。 + +エディタ内の**Preview**は、グラフを実行するもう一つの方法です。実際のエンジンを実行した上ですべてをロールバックし、実行の記録は残さず、egressはシミュレーションを強制されます。作成中はPreviewを使用し、実際に何が起きたかを確認する際は実行（run）を使用してください。 + +## Findingの来歴 + +実行（Runs）は「このルールは何をしたのか」という問いに答えます。来歴（Provenance）は、その逆の問い、「このFindingはなぜ変更されたのか」に答えます。 + +ルールが行うすべての変更は、責任を持つルール、実行、ノードとともにFindingに対して記録され、Finding自体のタイムラインとして表示されます。記録されるアクションは次のとおりです。 + +| Action | Meaning | +|--------|---------| +| `created`, `updated`, `closed`, `reopened` | Findingのライフサイクルが変化した。 | +| `duplicate`, `status_change` | 重複フラグまたはステータスフラグが変化した。 | +| `notified` | それに関する通知が送信された。 | +| `delivered` | それが送出配信の対象となった。 | + +フィールドの編集では、各フィールドの変更前と変更後の値を含め、何が変更されたかが記録されます。非常に長い値は記録内で切り詰められるため、タイムラインはFindingの複製ではなく、あくまで変更の記録として保たれます。 + +通知や配信もここに記録されます。これは意図的なものです。メッセージを送信したもののフィールドを何も変更しなかったルールが、そうしなければFindingに何の痕跡も残さないことになってしまうためです。 + +来歴はルールが削除された後も残ります。ルールや実行を削除しても、タイムラインの項目は保持されたまま単にリンクが解除されるだけなので、誰かが整理を行っても履歴が消えることはありません。 + +## 履歴を持つルールの削除 + +配信を生成したルールは、その配信を残したまま削除することはできません。先に配信を削除するか、ルールをそのまま残して無効化してください。これは意図的な仕様です。配信は外部システムに実際に何が送信されたかの記録を保持しており、カスケード削除を行うと進行中の送信までも失われてしまうためです。 diff --git a/docs/content/connectors/_index.de.md b/docs/content/connectors/_index.de.md new file mode 100644 index 00000000000..893fc51d2e8 --- /dev/null +++ b/docs/content/connectors/_index.de.md @@ -0,0 +1,17 @@ +--- +title: Connectors +description: Verbinden Sie DefectDojo mit Ihren Scannern und Issue-Trackern +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/_index.es.md b/docs/content/connectors/_index.es.md new file mode 100644 index 00000000000..0e23e21f5b8 --- /dev/null +++ b/docs/content/connectors/_index.es.md @@ -0,0 +1,17 @@ +--- +title: Conectores +description: Conecte DefectDojo con sus escáneres y rastreadores de incidencias +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/_index.fr.md b/docs/content/connectors/_index.fr.md new file mode 100644 index 00000000000..cbba34d1020 --- /dev/null +++ b/docs/content/connectors/_index.fr.md @@ -0,0 +1,17 @@ +--- +title: Connecteurs +description: Connectez DefectDojo à vos scanners et vos outils de suivi des problèmes +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/_index.ja.md b/docs/content/connectors/_index.ja.md new file mode 100644 index 00000000000..acbcd010c1f --- /dev/null +++ b/docs/content/connectors/_index.ja.md @@ -0,0 +1,17 @@ +--- +title: コネクタ +description: DefectDojoをスキャナーやIssueトラッカーに接続します +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +audience: pro +exclude_search: true +--- diff --git a/docs/content/connectors/about.de.md b/docs/content/connectors/about.de.md new file mode 100644 index 00000000000..d441e505be6 --- /dev/null +++ b/docs/content/connectors/about.de.md @@ -0,0 +1,66 @@ +--- +title: Über Connectors +description: Die zentrale Anlaufstelle für Upstream- und Downstream-Connectors in + der Pro-UI +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 1 +chapter: true +sidebar: + collapsed: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +--- + +Hinweis: Connectors sind eine Funktion, die nur in DefectDojo Pro verfügbar ist. + +**Connectors** ist die zentrale Anlaufstelle in der DefectDojo Pro-UI für jedes Tool, mit dem DefectDojo in beide Richtungen kommuniziert. Sie vereint zwei Funktionen, die zuvor an getrennten Stellen konfiguriert wurden: + +* **Upstream Connectors** (früher **API Connectors**) ziehen Findings und Asset-Inventar *ein* aus Ihren Scannern und Sicherheitstools. +* **Downstream Connectors** (früher **Integrations**) senden Findings *heraus* an Ihre Issue-Tracker und Ticketing-Systeme. + +Wenn Sie sich DefectDojo als Drehscheibe Ihrer Sicherheitsdaten vorstellen, sind Upstream Connectors der Weg, auf dem Daten eintreffen, und Downstream Connectors der Weg, auf dem die Behebungsarbeit hinausgeht. + +## Wo Sie Connectors finden + +Öffnen Sie in der Seitenleiste der Pro-UI die Gruppe **Connectors** unter der Überschrift **Import**: + +* **Connectors > Upstream Connectors** — ersetzt den alten Eintrag **API Connectors** (zuvor unter Import). +* **Connectors > Downstream Connectors** — ersetzt den alten Eintrag **Integrations** (zuvor unter Settings). Diese Richtung befindet sich derzeit in der **Beta**-Phase. + +Alte Lesezeichen und Deep Links funktionieren weiterhin: Die alten URLs für **API Connectors** und **Integrations** leiten automatisch auf die neuen Seiten **Upstream Connectors** und **Downstream Connectors** weiter. + +## Wer was sehen kann + +* **Upstream Connectors** ist für Benutzer mit einer Global Role von Reader oder höher sichtbar. +* **Downstream Connectors** ist nur für Superuser sichtbar und befindet sich für Cloud-gehostete DefectDojo Pro-Instanzen derzeit in der **Beta**-Phase. + +Die Gruppe **Connectors** erscheint in der Seitenleiste, wenn mindestens eine der beiden Seiten für Sie sichtbar ist. + +## Die Connectors-Seiten + +Beide Richtungen verwenden dasselbe überarbeitete Layout: + +* Jedes Tool wird als **Kachel** in voller Breite dargestellt — Logo links, der Tool-Name und eine kurze Beschreibung in der Mitte sowie eine Aktionsschaltfläche rechts. +* Jeder Abschnitt verfügt über ein **Suchfeld**, das Kacheln beim Eingeben nach Tool-Namen filtert. + +Auf der Seite **Upstream Connectors**: + +* **Configured Connectors** listet die Connectors auf, die Sie bereits eingerichtet haben. Jede Kachel zeigt eine Zusammenfassung des Betriebszustands (Health-Status, letzter Vorgang sowie Gesamt- / gemappte Datensatzanzahl) und ein Menü **Manage Configuration** mit den Aktionen **Manage Records & Operations**, **Edit Configuration** und **Delete Configuration**. +* **Available Connectors** listet die unterstützten Tools auf, die Sie noch nicht konfiguriert haben, jeweils mit einer Schaltfläche **Add Configuration**. +* Ein Filter in der Seitenkopfzeile grenzt beide Abschnitte nach Connector-Typ ein: **All**, **Asset** (oder **Product**, je nach Terminologie Ihrer Instanz) für Connectors, die Asset-Inventar importieren, und **Finding** für Connectors, die Schwachstellendaten importieren. + +Auf der Seite **Downstream Connectors**: + +* **Available Integrations** listet jeden unterstützten Issue-Tracker auf. Kacheln für bereits konfigurierte Integrations zeigen die Anzahl vorhandener Integration Instances. + +## Nächste Schritte + +* Lesen Sie [About Upstream Connectors](/connectors/upstream/about/) und [fügen Sie Ihren ersten Upstream Connector hinzu](/connectors/upstream/add_edit/), um automatisch mit dem Import von Findings zu beginnen. +* Lesen Sie den [Downstream Connectors guide](/connectors/downstream/about/), um Findings an Ihre Issue-Tracker zu senden. diff --git a/docs/content/connectors/about.es.md b/docs/content/connectors/about.es.md new file mode 100644 index 00000000000..332da01a8b6 --- /dev/null +++ b/docs/content/connectors/about.es.md @@ -0,0 +1,66 @@ +--- +title: Acerca de los Conectores +description: El hogar unificado para los Conectores Upstream y Downstream en la interfaz + de Pro +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 1 +chapter: true +sidebar: + collapsed: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +--- + +Nota: Los Conectores son una función exclusiva de DefectDojo Pro. + +**Conectores** es el único lugar en la interfaz de DefectDojo Pro para todas las herramientas con las que DefectDojo se comunica, en cualquier dirección. Combina dos funciones que antes se configuraban en lugares separados: + +* Los **Conectores Upstream** (antes **Conectores API**) traen hallazgos e inventario de activos *hacia* DefectDojo desde sus escáneres y herramientas de seguridad. +* Los **Conectores Downstream** (antes **Integraciones**) envían hallazgos *hacia fuera*, a sus sistemas de seguimiento de incidencias y de tickets. + +Si piensa en DefectDojo como el centro de sus datos de seguridad, los Conectores Upstream son la forma en que llegan los datos, y los Conectores Downstream son la forma en que sale el trabajo de remediación. + +## Dónde encontrar los Conectores + +En la barra lateral de la interfaz de Pro, abra el grupo **Conectores** bajo el encabezado **Importar**: + +* **Conectores > Conectores Upstream** — reemplaza la antigua entrada **Conectores API** (anteriormente bajo Importar). +* **Conectores > Conectores Downstream** — reemplaza la antigua entrada **Integraciones** (anteriormente bajo Configuración). Esta dirección está actualmente en **Beta**. + +Los marcadores y enlaces directos antiguos siguen funcionando: las URL heredadas de **Conectores API** e **Integraciones** redirigen automáticamente a las nuevas páginas **Conectores Upstream** y **Conectores Downstream**. + +## Quién puede ver qué + +* **Conectores Upstream** es visible para los usuarios con un Rol Global de Lector o superior. +* **Conectores Downstream** es visible solo para los superusuarios, y actualmente está en **Beta** para las instancias de DefectDojo Pro alojadas en la nube. + +El grupo **Conectores** aparece en la barra lateral si al menos una de las dos páginas es visible para usted. + +## Las páginas de Conectores + +Ambas direcciones comparten el mismo diseño renovado: + +* Cada herramienta se muestra como un **mosaico** de ancho completo: el logotipo a la izquierda, el nombre de la herramienta y una breve descripción en el medio, y un botón de acción a la derecha. +* Cada sección tiene un **cuadro de búsqueda** que filtra los mosaicos por nombre de herramienta a medida que escribe. + +En la página de **Conectores Upstream**: + +* **Conectores configurados** enumera los conectores que ya ha configurado. Cada mosaico muestra un resumen del estado operativo (estado de salud, última operación y recuentos totales / de registros asignados) y un menú **Administrar configuración** con las acciones **Administrar registros y operaciones**, **Editar configuración** y **Eliminar configuración**. +* **Conectores disponibles** enumera las herramientas compatibles que aún no ha configurado, cada una con un botón **Agregar configuración**. +* Un filtro en el encabezado de la página reduce ambas secciones por tipo de conector: **Todos**, **Activo** (o **Producto**, según el vocabulario de su instancia) para los conectores que importan inventario de activos, y **Hallazgo** para los conectores que importan datos de vulnerabilidades. + +En la página de **Conectores Downstream**: + +* **Integraciones disponibles** enumera todos los sistemas de seguimiento de incidencias compatibles. Los mosaicos de las integraciones que ha configurado muestran un recuento de las instancias de integración existentes. + +## Próximos pasos + +* Lea [Acerca de los Conectores Upstream](/connectors/upstream/about/) y [agregue su primer Conector Upstream](/connectors/upstream/add_edit/) para empezar a importar hallazgos automáticamente. +* Lea la [guía de Conectores Downstream](/connectors/downstream/about/) para enviar hallazgos a sus sistemas de seguimiento de incidencias. diff --git a/docs/content/connectors/about.fr.md b/docs/content/connectors/about.fr.md new file mode 100644 index 00000000000..e213b028deb --- /dev/null +++ b/docs/content/connectors/about.fr.md @@ -0,0 +1,65 @@ +--- +title: À propos des connecteurs +description: L'espace unifié pour les connecteurs amont et aval dans l'interface Pro +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 1 +chapter: true +sidebar: + collapsed: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +--- + +Remarque : les connecteurs sont une fonctionnalité réservée à DefectDojo Pro. + +**Connecteurs** est l'espace unique de l'interface DefectDojo Pro pour tous les outils avec lesquels DefectDojo communique, dans les deux sens. Il regroupe deux fonctionnalités auparavant configurées séparément : + +* Les **Connecteurs Amont** (**Upstream Connectors**, anciennement **Connecteurs API**) importent les constatations et l'inventaire des actifs *depuis* vos scanners et outils de sécurité. +* Les **Connecteurs Aval** (**Downstream Connectors**, anciennement **Intégrations**) exportent les constatations *vers* vos gestionnaires de tickets et systèmes de suivi. + +Si vous considérez DefectDojo comme le point central de vos données de sécurité, les Connecteurs Amont sont la façon dont les données arrivent, et les Connecteurs Aval la façon dont le travail de remédiation repart. + +## Où trouver les connecteurs + +Dans la barre latérale de l'interface Pro, ouvrez le groupe **Connectors** sous l'en-tête **Import** : + +* **Connectors > Upstream Connectors** — remplace l'ancienne entrée **API Connectors** (auparavant sous Import). +* **Connectors > Downstream Connectors** — remplace l'ancienne entrée **Integrations** (auparavant sous Settings). Ce sens est actuellement en **version bêta**. + +Les anciens favoris et liens profonds continuent de fonctionner : les URL historiques **API Connectors** et **Integrations** redirigent automatiquement vers les nouvelles pages **Upstream Connectors** et **Downstream Connectors**. + +## Qui peut voir quoi + +* Les **Upstream Connectors** sont visibles par les utilisateurs disposant d'un rôle global Lecteur ou supérieur. +* Les **Downstream Connectors** sont visibles uniquement par les superutilisateurs, et sont actuellement en **version bêta** pour les instances DefectDojo Pro hébergées dans le Cloud. + +Le groupe **Connectors** apparaît dans la barre latérale si au moins l'une des deux pages vous est visible. + +## Les pages Connectors + +Les deux sens partagent la même présentation actualisée : + +* Chaque outil est présenté sous forme de **vignette** pleine largeur — le logo à gauche, le nom de l'outil et une courte description au centre, et un bouton d'action à droite. +* Chaque section dispose d'une **zone de recherche** qui filtre les vignettes par nom d'outil au fur et à mesure de la saisie. + +Sur la page **Upstream Connectors** : + +* **Configured Connectors** répertorie les connecteurs que vous avez déjà configurés. Chaque vignette affiche un résumé de l'état de santé opérationnel (statut de santé, dernière opération, et nombre total / d'enregistrements mappés) ainsi qu'un menu **Manage Configuration** proposant les actions **Manage Records & Operations**, **Edit Configuration** et **Delete Configuration**. +* **Available Connectors** répertorie les outils pris en charge que vous n'avez pas encore configurés, chacun avec un bouton **Add Configuration**. +* Un filtre dans l'en-tête de la page réduit les deux sections par type de connecteur : **All**, **Asset** (ou **Product**, selon le vocabulaire de votre instance) pour les connecteurs qui importent l'inventaire des actifs, et **Finding** pour les connecteurs qui importent des données de vulnérabilité. + +Sur la page **Downstream Connectors** : + +* **Available Integrations** répertorie tous les gestionnaires de tickets pris en charge. Les vignettes des intégrations que vous avez configurées affichent un nombre d'instances d'intégration existantes. + +## Prochaines étapes + +* Consultez [À propos des connecteurs amont](/connectors/upstream/about/) et [ajoutez votre premier connecteur amont](/connectors/upstream/add_edit/) pour commencer à importer automatiquement des constatations. +* Consultez le [guide des connecteurs aval](/connectors/downstream/about/) pour envoyer des constatations vers vos gestionnaires de tickets. diff --git a/docs/content/connectors/about.ja.md b/docs/content/connectors/about.ja.md new file mode 100644 index 00000000000..b92b5e1646d --- /dev/null +++ b/docs/content/connectors/about.ja.md @@ -0,0 +1,65 @@ +--- +title: コネクタについて +description: Pro UI におけるアップストリームおよびダウンストリームコネクタの統合ホーム +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 1 +chapter: true +sidebar: + collapsed: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +--- + +Note: Connectors are a DefectDojo Pro-only feature. + +**コネクタ**は、DefectDojo が双方向でやり取りするすべてのツールのための、DefectDojo Pro UI 上の単一のホームです。これは、これまで別々の場所で設定されていた2つの機能を統合したものです。 + +* **アップストリームコネクタ**(旧称 **API Connectors**)は、スキャナーやセキュリティツールから検出事項とアセットインベントリを*取り込み*ます。 +* **ダウンストリームコネクタ**(旧称 **Integrations**)は、検出事項を課題管理システムやチケッティングシステムに*送信*します。 + +DefectDojo をセキュリティデータのハブと考えると、アップストリームコネクタはデータが到着する経路であり、ダウンストリームコネクタは修復作業が出ていく経路です。 + +## コネクタの場所 + +Pro UI のサイドバーで、**Import** ヘッダーの下にある **Connectors** グループを開きます。 + +* **Connectors > Upstream Connectors** — 旧 **API Connectors** エントリ(以前は Import の下にありました)を置き換えます。 +* **Connectors > Downstream Connectors** — 旧 **Integrations** エントリ(以前は Settings の下にありました)を置き換えます。この方向は現在 **ベータ版** です。 + +古いブックマークやディープリンクは引き続き機能します。従来の **API Connectors** および **Integrations** の URL は、新しい **Upstream Connectors** および **Downstream Connectors** ページへ自動的にリダイレクトされます。 + +## 閲覧できるユーザー + +* **Upstream Connectors** は、グローバルロールが Reader 以上のユーザーに表示されます。 +* **Downstream Connectors** はスーパーユーザーのみに表示され、現在クラウドホスト型の DefectDojo Pro インスタンスでは **ベータ版** です。 + +**Connectors** グループは、2つのページのうち少なくとも一方があなたに表示される場合にサイドバーに表示されます。 + +## コネクタページについて + +両方向とも、同じ刷新されたレイアウトを共有しています。 + +* 各ツールは全幅の **タイル** として表示されます。左側にロゴ、中央にツール名と簡単な説明、右側にアクションボタンがあります。 +* 各セクションには、入力に応じてツール名でタイルを絞り込む **検索ボックス** があります。 + +**Upstream Connectors** ページでは、 + +* **Configured Connectors** に、すでに設定済みのコネクタが一覧表示されます。各タイルには稼働状況の概要(ヘルスステータス、最終オペレーション、合計/マッピング済みレコード数)と、**Manage Records & Operations**、**Edit Configuration**、**Delete Configuration** の各アクションを含む **Manage Configuration** メニューが表示されます。 +* **Available Connectors** に、まだ設定されていない対応ツールが一覧表示され、それぞれに **Add Configuration** ボタンがあります。 +* ページヘッダーのフィルターにより、両方のセクションをコネクタの種類で絞り込めます。**All**、アセットインベントリを取り込むコネクタ向けの **Asset**(インスタンスの用語によっては **Product**)、脆弱性データを取り込むコネクタ向けの **Finding** です。 + +**Downstream Connectors** ページでは、 + +* **Available Integrations** に、対応するすべての課題管理ツールが一覧表示されます。設定済みの Integrations のタイルには、既存の Integration Instances の件数が表示されます。 + +## 次のステップ + +* [About Upstream Connectors](/connectors/upstream/about/) を読み、[最初のアップストリームコネクタを追加](/connectors/upstream/add_edit/)して検出事項の自動取り込みを開始しましょう。 +* [Downstream Connectors guide](/connectors/downstream/about/) を読み、検出事項を課題管理ツールに送信しましょう。 diff --git a/docs/content/connectors/downstream/PRO__jira_guide.de.md b/docs/content/connectors/downstream/PRO__jira_guide.de.md new file mode 100644 index 00000000000..4cccb5279b6 --- /dev/null +++ b/docs/content/connectors/downstream/PRO__jira_guide.de.md @@ -0,0 +1,786 @@ +--- +title: Jira (Legacy) +description: Mit der Jira-Integration arbeiten +weight: 1 +audience: pro +aliases: +- /de/issue_tracking/jira/pro__jira_guide/ +- /de/en/share_your_findings/jira_guide +--- + +> **Diese Seite dokumentiert die veraltete Jira-Integration.** Die hier beschriebene produktbezogene Jira-Integration wurde durch den **[Jira Downstream Connector](/connectors/downstream/about/)** abgelöst, der auf jeder DefectDojo-Pro-Instanz allgemein verfügbar ist und die empfohlene Methode darstellt, um Befunde an Jira zu übertragen. In der Pro-Seitenleiste trägt **Connect > Jira** aus diesem Grund ein `LEGACY`-Abzeichen — siehe [Menu Badges](/navigation/pro__menu_badges/). +> +> **Wenn Sie Jira zum ersten Mal einrichten, beginnen Sie mit dem [Downstream Connector](/connectors/downstream/about/) anstelle dieser Anleitung.** +> +> **Nutzen Sie bereits die veraltete Integration?** DefectDojo Pro enthält eine integrierte Migration, die Ihre bestehende klassische Jira-Konfiguration auf Downstream Connectors überführt, einschließlich der bereits übertragenen Tickets — siehe [Migration zum Jira Downstream Connector](#migrating-to-the-jira-downstream-connector) unten. +> +> Die veraltete Integration funktioniert weiterhin, und diese Anleitung bleibt dafür gültig. + +Die Jira-Integration von DefectDojo kann verwendet werden, um Befund-Daten an einen oder mehrere Jira-Bereiche zu übertragen. Auf diese Weise können Sie DefectDojo in Ihren Standard-Entwicklungsworkflow integrieren. Hier einige Beispiele, wie das funktionieren kann: + +* Das AppSec-Team kann Befunde selektiv an einen von Entwicklern genutzten Jira-Bereich übertragen, sodass die Behebung von Problemen angemessen neben der regulären Entwicklung priorisiert werden kann. Entwickler in diesem Board müssen nicht auf DefectDojo zugreifen - sie können ihre gesamte Arbeit an einem Ort behalten. +* DefectDojo kann ALLE Befunde an einen bidirektionalen Jira-Bereich übertragen, den das AppSec-Team nutzt, wodurch die Validierung von Problemen aufgeteilt werden kann. Dieses Board bleibt mit DefectDojo synchron und ermöglicht komplexe Behebungs-Workflows. +* DefectDojo kann Befunde selektiv aus separaten Produkten und/oder Engagements an separate Jira-Bereiche übertragen, um alles im richtigen Kontext zu halten. + +## Migration zum Jira Downstream Connector + +DefectDojo Pro kann eine bestehende klassische Jira-Einrichtung für Sie in eine Downstream-Connector-Konfiguration umwandeln, anstatt Sie zum manuellen Neuaufbau zu zwingen. + +**Wo Sie es finden:** Gehen Sie zu **Connect \> Downstream**, um die Seite **Downstream Connectors** zu öffnen, und verwenden Sie die Karte **Classic Jira Migration**. Klicken Sie auf **Migrate from classic Jira** und bestätigen Sie anschließend. + +Die Karte erscheint nur, wenn eine klassische Jira-Konfiguration zum Migrieren vorhanden ist oder ein vorheriger Lauf zu melden ist — eine Instanz, die nie klassisches Jira verwendet hat, sieht sie also nicht. Sobald alles migriert wurde, bleibt die Karte bestehen, aber die Schaltfläche ist deaktiviert, da nichts mehr zu tun ist. + +Das Ausführen der Migration erfordert **globale Maintainer-Berechtigungen** (genauer gesagt die Berechtigung, Integrationen zu bearbeiten), und sie muss aus einer angemeldeten Browsersitzung heraus ausgeführt werden — sie kann nicht über ein API-Token gesteuert werden. + +### Was mit bereits übertragenen Tickets geschieht + +**Ihre bestehenden Jira-Tickets werden beibehalten und neu verknüpft — sie werden nicht verwaist, und der Connector öffnet keine Duplikate.** Jeder Befund, den das klassische Jira bereits übertragen hatte, behält sein Ticket, und der Connector übernimmt die Aktualisierung dieses gleichen Tickets vor Ort. Links auf Befundgruppen werden auf dieselbe Weise übernommen. + +Die einzige Ausnahme sind **Engagement-Epics**. Der Downstream Connector kennt kein Epic-Konzept, daher werden Epic-Issues in den Warnungen der Migration gemeldet und unangetastet gelassen. + +### Was migriert wird + +* Ihre Jira-**Instanz**-Verbindung — URL und Zugangsdaten — wird zu einer Downstream-Connector-Integrationsinstanz und behält ihren Namen bei. +* **Schweregrad-Zuordnungen** und **Status-Zuordnungen** (Ihre Schlüssel für Öffnen- und Schließen-Übergänge) werden übernommen. +* Jede **Jira-Projekt**-Konfiguration wird zu einer Issue-Tracker-Zuordnung, behält ihren Projektschlüssel und Issue-Typ bei und bleibt demselben Produkt oder Engagement zugewiesen. +* **Push All Issues** wird beibehalten: Projekte, bei denen es aktiviert war, übertragen weiterhin automatisch. +* **Benutzerdefinierte Felder**, **Felder für Schließen/Wiedereröffnen-Übergänge**, **Komponente**, **Standard-Zuweisung** und **Labels** werden in Feldzuordnungen umgewandelt. Wo Sie *Vulnerability Id als Jira-Label hinzufügen* verwendet haben, wird dies ebenfalls zu einer Label-Zuordnung. +* Ein Verzeichnis mit **benutzerdefinierten Issue-Vorlagen** wird zu einer Ticket-Vorlage. Die Standardvorlagen werden nicht kopiert, da der Connector bereits Entsprechungen mitbringt. + +### Was nicht übernommen wird + +Diese werden als Warnungen beim Migrationslauf gemeldet — sie stoppen ihn nicht. Achten Sie in den Ergebnissen auf die Liste *"Dinge, die der Connector nicht übernehmen kann"*. + +* **Jira → DefectDojo Rücksynchronisation.** Dies ist der wichtige Punkt. Der Downstream Connector synchronisiert keine Änderungen *zurück* von Jira, daher werden Auflösungs-Zuordnungen, die Risikoakzeptanz oder Falsch-positiv aus einer Jira-Auflösung anwenden, nicht migriert. **Wenn Sie auf Rücksynchronisation angewiesen sind, lassen Sie die klassische Jira-Instanz konfiguriert** — die Migration entfernt sie nicht. +* **Engagement Epic Mapping** — der Connector kennt kein Epic-Konzept. +* **Push Notes**, **SLA-Benachrichtigungskommentare** und **Kommentare zum Ablauf der Risikoakzeptanz** — der Connector postet diese nicht an Jira. +* Benutzerdefinierte Felder mit den Namen `summary`, `description`, `project`, `issuetype` oder `status` — diese sind für den Connector reserviert, und eine Feldzuordnung, die eines davon verwendet, wird übersprungen. +* Werte benutzerdefinierter Felder mit mehr als 512 Zeichen — werden übersprungen statt abgeschnitten. +* Ein Jira-Projekt, das weder einem Produkt noch einem Engagement zugeordnet ist, erzeugt keine Zuweisung. + +### Was danach mit der klassischen Integration geschieht + +**Nichts wird doppelt übertragen.** Für jedes migrierte Projekt schaltet die Migration das klassische Jira-Projekt ab, sodass ab diesem Zeitpunkt nur noch der Connector überträgt. Sie müssen nichts manuell deaktivieren. + +Ihre klassische Konfiguration wird **beibehalten, nicht gelöscht** — die Instanz-, Projekt- und Issue-Datensätze bleiben alle erhalten, nur die Übertragungseinstellungen werden abgeschaltet. Das ist beabsichtigt: Es macht die Änderung rückgängig machbar und hält die Rücksynchronisation funktionsfähig, falls Sie darauf angewiesen sind. + +**Um zurückzurollen**, aktivieren Sie die klassischen Jira-Projekteinstellungen erneut und entfernen Sie die von der Migration erstellte Connector-Konfiguration. Es gibt kein Ein-Klick-Rückgängig. + +**Erneutes Ausführen ist sicher.** Die Migration protokolliert, was sie bereits konvertiert hat, und überspringt dies bei einem zweiten Lauf, sodass nichts doppelt entsteht. Wenn ein Projekt oder eine Instanz fehlschlägt, wird der Rest trotzdem migriert — ein fehlgeschlagenes Projekt bleibt auf der klassischen Integration aktiv, statt abgeschaltet zu werden, sodass es weiter funktioniert, während Sie die Ursache untersuchen. + +### Während des Laufs + +Die Migration läuft im Hintergrund und meldet laufend den Fortschritt. Nach Abschluss erhalten Sie eine Zusammenfassung — wie viele Connectors, Zuordnungen, Zuweisungen, Vorlagen und Ticket-Links erstellt wurden, wie viele klassische Projekte abgeschaltet wurden und was übersprungen wurde — zusammen mit den oben beschriebenen Warnungen. Es läuft jeweils nur eine Migration gleichzeitig. + +# Jira einrichten + +Das Einrichten von Jira erfordert folgende Schritte: +1. Aktivieren Sie die Jira-Integration in den Systemeinstellungen. Bis Sie das tun, sind die übrigen Jira-Einstellungen in DefectDojo überall ausgeblendet. +2. Verbinden Sie eine Jira-Instanz, entweder mit Benutzername/Passwort oder einem API-Token. Mehrere Instanzen können verknüpft werden. +3. Fügen Sie diese Jira-Instanz einem oder mehreren Produkten oder Engagements innerhalb von DefectDojo hinzu. +4. Wenn Sie bidirektionale Synchronisation nutzen möchten, erstellen Sie einen Jira-Webhook, der Updates an DefectDojo sendet. + +## Schritt 1: Aktivieren Sie die Jira-Integration in den Systemeinstellungen + +Die Jira-Integration ist standardmäßig deaktiviert, und solange sie deaktiviert ist, blendet DefectDojo jede andere Jira-Steuerung in der Oberfläche aus. Dies ist als Erstes zu konfigurieren: Keiner der folgenden Schritte ist verfügbar, bevor sie aktiviert ist. + +Während die Integration deaktiviert ist, gibt es keinen Eintrag **Jira Instances** in der Seitenleiste, sodass es keine Möglichkeit gibt, eine Jira-Instanz hinzuzufügen: + +![image](images/jira-menu-hidden-pro.png) + +### Integration aktivieren + +1. Navigieren Sie in der DefectDojo-Seitenleiste zu **Settings \> System \> System Settings**. Auf Instanzen, die noch das vorherige Menülayout verwenden, befindet sich dies unter einer nach Ihrem Lizenzpaket benannten Gruppe — **Pro Settings** oder **Enterprise Settings**. Siehe [Das Einstellungsmenü](/navigation/pro__settings_menu/). +​ +2. Aktivieren Sie im Abschnitt **Jira Integration Settings** die Option **Enable Jira Integration**. +​ +3. Klicken Sie auf **Submit**. **Jira Instances** erscheint sofort in der Seitenleiste, ohne dass die Seite neu geladen werden muss: + +![image](images/jira-enable-system-settings-pro.png) + +### Was diese Einstellung steuert + +Das Aktivieren von **Enable Jira Integration** bewirkt, dass der Rest der Jira-Oberfläche erscheint. Mit aktivierter Einstellung erhalten Sie: + +* das Menü **Jira Instances**, in dem Jira-Instanzen hinzugefügt und bearbeitet werden +* die Seite **Jira Project Settings** im ⚙️-Menü der Assets sowie die Jira-Einstellungen bei Engagements +* die Aktionen **Push to Jira** bei Befunden und Befundgruppen, die Jira-Felder in den Formularen für Befunde und Massenbearbeitung sowie die Jira-Spalten in den Listen für Assets, Engagements, Befunde und Befundgruppen (einschließlich CSV-Exporte) + +Die Einstellung steuert die Integration auch außerhalb der Oberfläche: Solange sie deaktiviert ist, überträgt DefectDojo keine Befunde an Jira (einschließlich `push_to_jira`-Anfragen über die API), und eingehende Jira-Webhooks werden ignoriert. + +Die übrigen Jira-Felder in **Jira Integration Settings** (**Add Vulnerability ID as Jira Label**, **Enable Jira Web Hook**, **Disable Jira Web Hook Secret**, **Jira Web Hook Secret**, **Jira Minimum Severity**) bleiben unabhängig davon sichtbar, ob die Integration aktiviert ist oder nicht, haben aber keine Wirkung, bevor sie aktiviert ist. + +## Schritt 2: Verbinden Sie eine Jira-Instanz + +Nachdem die Integration aktiviert ist, ist das Verbinden einer Jira-Instanz der nächste Schritt bei der Einrichtung der Jira-Integration von DefectDojo. Bitte beachten Sie, dass Jira Service Management derzeit nicht unterstützt wird. + +#### Von Jira benötigte Informationen + +Atlassian verwendet unterschiedliche Authentifizierungsmethoden für Jira Cloud und Jira Data Center. + +Für **Jira Cloud** benötigen Sie: +* eine Jira-URL, z. B. https://yourcompany.atlassian.net/ +* ein Konto mit Berechtigungen zum Erstellen und Aktualisieren von Issues in Ihrer Jira-Instanz. Dies kann sein: + * eine Standard-**Benutzername/Passwort**-Kombination + * eine **Benutzername/API-Token**-Kombination + +Für **Jira Data Center (oder Server)** benötigen Sie: +* eine Jira-URL, z. B. https://jira.yourcompany.com +* ein Konto mit Berechtigungen zum Erstellen und Aktualisieren von Issues in Ihrer Jira-Instanz. Dies kann sein: + * eine Standard-**Benutzername/Passwort**-Kombination + * eine **E-Mail-Adresse/Personal Access Token**-Kombination + +Optional können Sie zuordnen: +* Jira-Übergänge, die das Wiedereröffnen und Schließen von Befunden auslösen +* Jira-Auflösungen, die Risikoakzeptanz- und Falsch-positiv-Status auf Befunde anwenden können (optional) + +Mehrere Jira-Bereiche können von einer einzigen Jira-Instanzverbindung verwaltet werden, solange das von DefectDojo verwendete Jira-Konto/-Token die Berechtigung hat, Issues im zugehörigen Jira-Bereich zu erstellen. + +### Eine Jira-Instanz hinzufügen + +1. Stellen Sie sicher, dass **Enable Jira Integration** in den Systemeinstellungen aktiviert ist, wie in [Schritt 1](#step-1-enable-the-jira-integration-in-system-settings) beschrieben. Das Menü **Jira Instances** erscheint erst dann in der Seitenleiste. + +2. Navigieren Sie in der DefectDojo-Seitenleiste zur Seite **Enterprise Settings \> Jira Instances \> + New Jira Instance**. + +![image](images/jira-instance-beta.png) + +3. Wählen Sie einen **Configuration Name** für die Verwendung dieser Jira-Instanz in DefectDojo. Dieser Name ist lediglich eine Bezeichnung für die Instanzverbindung in DefectDojo und muss keinen Bezug zu Jira-Daten haben. + +4. Wählen Sie die URL Ihrer Unternehmens-Jira-Instanz \- wahrscheinlich ähnlich zu `https://**yourcompany**.atlassian.net`, wenn Sie eine Jira-Cloud-Installation verwenden. + +5. Geben Sie eine geeignete Authentifizierungsmethode in die Felder Username/Password für Jira ein: + * Für standardmäßige **Benutzername/Passwort-Jira-Authentifizierung** geben Sie einen Jira-Benutzernamen und das zugehörige Passwort in diese Felder ein. + * Für die Authentifizierung mit dem **API-Token eines Benutzers (Jira Cloud)** geben Sie den Benutzernamen mit dem zugehörigen **API-Token** im Passwortfeld ein. + * Für die Authentifizierung mit einem **Personal Access Token von Jira (auch PAT genannt, nur bei Jira Data Center und Jira Server verwendet)** geben Sie den PAT im Passwortfeld ein. Der Benutzername wird für die Authentifizierung mit einem Jira-PAT nicht verwendet, das Feld ist in diesem Formular jedoch weiterhin erforderlich, sodass Sie hier einen Platzhalterwert zur Identifizierung Ihres PAT verwenden können. + +Beachten Sie, dass der mit dieser Verbindung verknüpfte Benutzer berechtigt sein muss, Issues zu erstellen und auf Daten in Ihrer Jira-Instanz zuzugreifen. + +6. Sie müssen Werte für eine Epic Name ID, eine Re-open Transition ID und eine Close Transition ID angeben. Diese Werte können später geändert werden. Während Sie bei Jira angemeldet sind, können Sie diese Werte über folgende URLs abrufen: +- **Epic Name ID**: Besuchen Sie `https:///rest/api/2/field` und suchen Sie nach Epic Name. Kopieren Sie die Zahl aus `number` und fügen Sie sie hier ein. Wenn Sie keine Epic Name ID haben, die Ihrem Bereich in Jira zugeordnet ist (z. B. weil Sie einen team-verwalteten Bereich verwenden), geben Sie in diesem Feld 0 ein. +- **Re-open Transition ID**: Besuchen Sie `https:///rest/api/latest/issue//transitions?expand-transitions.fields`, um die ID für Ihre Jira-Instanz zu finden. Fügen Sie sie in das Feld Reopen Transition ID ein. +- **Close Transition ID**: Besuchen Sie `https:///rest/api/latest/issue//transitions?expand-transitions.fields`, um die ID für Ihre Jira-Instanz zu finden. Fügen Sie sie in das Feld Close Transition ID ein. + +7. Wählen Sie den Standard-Issue-Typ, mit dem Sie Issues in Jira erstellen möchten. Die Optionen dafür sind **Bug, Task, Story** und **Epic** (die Standard-Jira-Issue-Typen) sowie **Spike** und **Security**, welche benutzerdefinierte Issue-Typen sind. Wenn Sie einen anderen Issue-Typ verwenden möchten, wenden Sie sich bitte an [support@defectdojo.com](mailto:support@defectdojo.com). + +8. Wählen Sie Ihre Issue-Vorlage, welche die Issue-Beschreibung bestimmt, wenn Issues in Jira erstellt werden. + +Die beiden Typen sind: +- **Jira\_full**, das alle Befund-Informationen in Jira-Issues einschließt +- **Jira\_limited**, das eine geringere Menge an Befund-Informationen und Metadaten einschließt. + +Wenn Sie dieses Feld leer lassen, wird standardmäßig **Jira\_full** verwendet. Wenn Sie eine andere Art von Vorlage benötigen, wenden Sie sich an [support@defectdojo.com](mailto:support@defectdojo.com). + +9. Geben Sie bei Bedarf den Namen einer Jira-Auflösung ein, die den Status eines Befunds auf Akzeptiert oder Falsch-positiv ändert (wenn die Auflösung beim Issue ausgelöst wird). + +Das Formular kann von hier aus übermittelt werden. Wenn Sie möchten, können Sie Ihre Jira-Integration unter Optional Fields weiter anpassen. Ein Klick auf diese Schaltfläche ermöglicht es Ihnen, generischen Text auf Jira-Issues anzuwenden oder die Zuordnung der Jira Severity Mappings zu ändern. + +## Schritt 3: Verbinden Sie ein Produkt oder Engagement mit Jira + +Jedes Produkt oder Engagement in DefectDojo hat eigene Einstellungen, die bestimmen, wie Befunde in JIRA-Issues umgewandelt werden. Von hier aus können Sie den zugehörigen Jira-Bereich festlegen und das Standardverhalten für das Erstellen von Issues, Epics, Labels und anderen JIRA-Metadaten einstellen. + +### Jira zu einem Produkt hinzufügen + +Sie finden diese Seite, indem Sie auf das Zahnrad-Menü bei einem Produkt ⚙️ klicken und die Seite **Jira Project Settings** öffnen. + +![image](images/jira-project-settings.png) + +#### Jira-Instanz + +Wenn Sie mehrere Jira-Instanzen für separate Produkte oder Teams innerhalb Ihrer Organisation eingerichtet haben, können Sie angeben, in welchem Jira-Bereich DefectDojo Issues erstellen soll. Wählen Sie einen Bereich aus dem Dropdown-Menü. + +Wenn dieses Menü keine Jira-Instanzen auflistet, bestätigen Sie, dass diese Bereiche in Ihrer globalen Jira-Konfiguration für DefectDojo verbunden sind \- yourcompany.defectdojo.com/jira. + +#### Projektschlüssel + +Dies ist der Schlüssel des Bereichs, den Sie mit DefectDojo verwenden möchten. Der Bereichsschlüssel für einen bestimmten Bereich findet sich in der URL. (Dies wurde zuvor als **Jira Project Key** bezeichnet, wird aber seit September 2025 in Jira als **Space Key** bezeichnet). + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_3.png) + +#### Epic Issue Type Name + +Der Name des Epic-Issue-Typs in Jira. Standardmäßig "Epic", kann aber geändert werden, wenn Ihre Jira-Instanz einen anderen Namen verwendet. + +#### Issue-Vorlage + +Hier können Sie festlegen, wie viele DefectDojo-Metadaten Sie an Jira senden möchten. Wählen Sie eine der beiden Optionen: + +* **jira\_full**: Issues erfassen alle Parameter aus DefectDojo \- eine vollständige Beschreibung, CVE, Schweregrad usw. Nützlich, wenn Sie den vollständigen Befund-Kontext in Jira benötigen (zum Beispiel, wenn jemand an diesem Issue arbeitet, der keinen Zugriff auf DefectDojo hat). + +Hier ist ein Beispiel für ein **jira\_full**-Issue: +​ +![image](images/Add_a_Connected_Jira_Project_to_a_Product_4.png) + +* **Jira\_limited:** Issues erfassen nur den DefectDojo-Link, die Links zu Produkt/Engagement/Test, den Reporter und die Environment-Felder. Alle anderen Felder werden nur in DefectDojo erfasst. Nützlich, wenn Sie in Jira keinen vollständigen Befund-Kontext benötigen (zum Beispiel, wenn jemand an diesem Issue arbeitet, der hauptsächlich in DefectDojo arbeitet und nicht auch das vollständige Bild in JIRA benötigt.) + +​Hier ist ein Beispiel für ein **jira\_limited**-Issue: + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_5.png) + +#### Komponente + +Wenn Sie Ihren Jira-Bereich mit Komponenten verwalten, können Sie hier die passende Komponente für DefectDojo zuweisen. Um mehr als eine Komponente zuzuweisen, geben Sie eine durch Kommas getrennte Liste ein (zum Beispiel `Security, DevSecOps`); jeder Wert wird als separate Komponente an Jira gesendet. + +#### Benutzerdefinierte Felder + +Wenn Sie keine benutzerdefinierten Felder mit DefectDojo-Issues verwenden müssen, können Sie dieses Feld auf 'null' belassen. + +Wenn Ihre Jira-Bereichseinstellungen jedoch **erfordern**, dass Sie benutzerdefinierte Felder bei neuen Issues verwenden, müssen Sie diese Zuordnungen fest codieren. + +Beachten Sie, dass DefectDojo keine Issue-spezifischen Metadaten als benutzerdefinierte Felder senden kann, sondern nur einen Standardwert. Dieser Abschnitt sollte nur eingerichtet werden, wenn Ihr Jira-Bereich **erfordert, dass diese benutzerdefinierten Felder** in jedem Issue in Ihrem Bereich existieren. + +Folgen Sie **[dieser Anleitung](#custom-fields-in-jira)**, um mit benutzerdefinierten Feldern zu arbeiten. + +#### Felder für Schließen-/Wiedereröffnen-Übergänge + +Manche Jira-Workflows **erfordern**, dass bestimmte Felder als Teil eines Übergangs gesetzt werden — zum Beispiel ein Workflow, der sich weigert, ein Issue zu schließen, sofern nicht auf dem Schließen-Bildschirm ein Auflösungs- und ein Begründungsfeld angegeben werden. Die obige Einstellung für benutzerdefinierte Felder gilt nur, wenn ein Issue *erstellt* wird, sie kann diese Workflows also nicht erfüllen. + +Ohne diese Einstellungen sendet DefectDojo Schließen-/Wiedereröffnen-Übergänge ohne Felder. Ein Workflow, der Felder erfordert, lehnt diesen Übergang ab, und der Befund und das Jira-Issue geraten außer Sync: Der Befund wird in DefectDojo als Behoben angezeigt, während das Issue in Jira offen bleibt. + +Die Einstellungen **Close Transition fields** und **Reopen Transition fields** akzeptieren ein JSON-Objekt, das als `fields`-Payload des Schließen-/Wiedereröffnen-Übergangsaufrufs gesendet wird. Um zum Beispiel Issues mit einer Auflösung von *Won't Fix* zusammen mit einem Begründungswert zu schließen: + +```json +{ + "resolution": {"name": "Won't Fix"}, + "customfield_10200": "Risk accepted by security team #report-false-positive" +} +``` + +Lassen Sie diese Einstellungen auf 'null', wenn Ihr Jira-Workflow keine Felder bei Übergängen erfordert. + +**Welche Felder benötigen Sie?** + +* Fragen Sie Ihren Jira-Administrator, welche Felder sich auf den **Übergangsbildschirmen** für Schließen/Wiedereröffnen befinden und welche davon von einem Validator erzwungen werden. Das konfigurierte JSON muss **jedes** erforderliche Feld erfüllen: Fehlt ein erforderliches Feld im Payload, lehnt Jira den gesamten Übergang ab und setzt nichts — nur einen Teil der erforderlichen Felder anzugeben, hilft nicht. +* Umgekehrt müssen Felder **auf dem Übergangsbildschirm** vorhanden sein, um überhaupt gesendet zu werden: Jira lehnt Übergänge ab, die versuchen, Felder zu setzen, die für diesen Übergang nicht auf dem Bildschirm vorhanden sind. +* Bei Workflows, die mit dem aktuellen Workflow-Editor von Jira Cloud erstellt wurden, füllt Jira automatisch die Standard-Auflösung der Site aus, wenn ein Issue in einen Status der Kategorie "Erledigt" wechselt. Eine erforderliche Auflösung allein blockiert dort also keinen einfachen Übergang, und der praktische Nutzen von `"resolution"` in diesem Payload besteht darin, einen *aussagekräftigen* Wert zu wählen (zum Beispiel *False Positive*) anstelle des Site-Standards. Workflows, die mit dem klassischen Editor oder mit Marketplace-Validator-Apps erstellt wurden, können die Auflösung weiterhin fest erfordern. +* Wiedereröffnen-Übergänge löschen die Auflösung typischerweise über den Workflow selbst, daher benötigen **Reopen Transition fields** in der Regel nur die von Ihrem Workflow erforderlichen benutzerdefinierten Felder. + +**Hinweise:** + +* Dasselbe JSON wird für *jeden* Schließen- (oder Wiedereröffnen-)Übergang für das Produkt oder Engagement gesendet — die Werte sind statisch und variieren nicht pro Befund. Wenn Sie unterschiedliche Felder je nach Disposition benötigen (zum Beispiel eine andere Auflösung für Falsch-positiv-Befunde als für behobene Befunde), verwenden Sie den DefectDojo Pro Jira Integrator, der pro-Status-Übergangsfeldzuordnungen unterstützt. +* Werte verwenden dasselbe Format wie die REST-API von Jira: Zeichenketten für Textfelder, `{"name": ...}` für Auflösungen, `[{"name": ...}]` für Mehrfachauswahlfelder usw. +* Wenn Übergänge abgelehnt wurden, während diese Einstellungen fehlten oder unvollständig waren, behebt eine Korrektur der Einstellungen die Abweichung: Der nächste Statuspush für den Befund versucht den Übergang mit den konfigurierten Feldern erneut. +* Beide Einstellungen sind auch über den REST-Endpunkt `/api/v2/jira_projects/` verfügbar (`close_transition_fields` / `reopen_transition_fields`), sodass sie über die API verwaltet werden können. +* Diese Felder werden auch angewendet, wenn DefectDojo ein Issue schließt, weil dessen Befund **gelöscht** wurde — die Werte werden zum Zeitpunkt erfasst, an dem das Schließen eingereiht wird. + +#### Jira-Labels + +Wählen Sie die relevanten Labels aus, mit denen das Issue in Jira erstellt werden soll, z. B. **DefectDojo**, **YourProductName..** + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_6.png) + +#### Standard-Zuweisung + +Der Name der Standard-Zuweisung in Jira. Wenn leer gelassen, folgt DefectDojo dem Standardverhalten Ihres Jira-Bereichs beim Erstellen von Issues. + +### Jira-Projekteinstellungen + +#### Enabled + +Dieser Schalter steuert, ob DefectDojo Befunde für dieses Produkt an Jira überträgt. Das Deaktivieren löscht oder ändert keine vorhandenen, von DefectDojo erstellten Jira-Tickets, verhindert aber weitere Updates oder das Erstellen neuer Issues. + +Jira-Integrationen können nur dann von Ihrer Instanz entfernt werden, wenn keine zugehörigen Issues erstellt wurden. Wenn Issues erstellt wurden, gibt es keine Möglichkeit, eine Jira-Instanz vollständig aus DefectDojo zu entfernen. + +#### Vulnerability Id als Jira-Label hinzufügen + +Dies ermöglicht es Ihnen, die Vulnerability-ID-Daten automatisch als Jira-Label hinzuzufügen. Vulnerability-IDs werden Befunden von einzelnen Sicherheitstools hinzugefügt \- dies können Common Vulnerabilities and Exposures (CVE)-IDs oder ein anderes, für das meldende Tool spezifisches Format sein. + +#### Push All Issues + +Wenn aktiviert, überträgt DefectDojo automatisch alle Aktiven und Verifizierten Befunde als Issues an Jira. Wenn nicht aktiviert, müssen alle Befunde manuell an Jira übertragen werden (einzeln oder per Massenübertragung). + +Wenn diese Einstellung aktiviert ist, bleiben Jira-Issues auch dann mit DefectDojo synchron, wenn sich der Status des Befunds ändert. + +#### Enable Engagement Epic Mapping + +In DefectDojo repräsentieren Engagements eine Ansammlung von Arbeit. Jedes Engagement enthält einen oder mehrere Tests, die einen oder mehrere zu behebende Befunde enthalten. Epics in Jira funktionieren ähnlich, und dieses Kontrollkästchen ermöglicht es Ihnen, Engagements als Epics an Jira zu übertragen. + +* Ein Engagement in DefectDojo \- beachten Sie die drei unten aufgeführten Befunde. +​ +![image](images/Add_a_Connected_Jira_Project_to_a_Product_8.png) +* Wie dasselbe Engagement zu einem Epic wird, wenn es an JIRA übertragen wird \- die Befunde des Engagements werden ebenfalls übertragen und leben innerhalb des Epics als untergeordnete Issues. + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_9.png) + +#### Push Notes + +Wenn aktiviert, werden Jira-Kommentare beim zugehörigen Befund in DefectDojo unter Notizen angezeigt, und umgekehrt; Notizen zu Befunden werden dem zugehörigen Jira-Issue als Kommentare hinzugefügt. + +#### SLA-Benachrichtigungen als Kommentare senden + +Wenn aktiviert, erhalten alle Issues, die gegen die Service Level Agreement-Regeln von DefectDojo verstoßen, entsprechende Kommentare im Jira-Issue. Diese Kommentare werden täglich gepostet, bis das Issue gelöst ist. + +Service Level Agreements können in DefectDojo unter **Configuration \> SLA Configuration** konfiguriert und jedem Produkt zugewiesen werden. + +#### Benachrichtigungen zum Ablauf der Risikoakzeptanz als Kommentar senden + +Wenn aktiviert, erhält jedes Issue, bei dem die zugehörige DefectDojo-Risikoakzeptanz abläuft, einen entsprechenden Kommentar im Jira-Issue. Diese Kommentare werden täglich gepostet, bis das Issue gelöst ist. + +### Jira-Einstellungen auf Engagement-Ebene + +Standardmäßig **übernehmen Engagements die Jira-Einstellungen von ihrem Produkt**. Sie können die Jira-Einstellungen jedoch für einzelne Engagements überschreiben. + +Um auf die Jira-Einstellungen auf Engagement-Ebene zuzugreifen, klicken Sie auf das Zahnrad-Menü ⚙️ bei einem Engagement und öffnen Sie die Seite **Jira Project Settings**. + +Von hier aus können Sie **Inherit from Product** deaktivieren und Engagement-spezifische Werte für **Project Key**, **Issue Template, Custom Fields, Jira Labels, Default Assignee** und andere Einstellungen angeben. + +Beachten Sie, dass ein Engagement, sobald ihm ein eigenes Jira-Projekt zugewiesen ist, nicht mehr vom Produkt erben kann. + +![image](images/Creating_Issues_in_Jira_5.png) + +## Schritt 4: Bidirektionale Synchronisation konfigurieren: Jira-Webhook + +Die Jira-Integration ermöglicht bidirektionale Synchronisation über Webhook. DefectDojo empfängt Jira-Benachrichtigungen an einer eindeutigen Adresse, wodurch je nach Konfiguration Jira-Kommentare bei Befunden empfangen werden können oder Befunde über Jira aufgelöst werden können. + +### Ihre Jira-Webhook-URL finden + +Ihr Jira-Webhook befindet sich im Formular System Settings unter **Jira Integration Settings**: **Enterprise Settings \> System Settings** in der Seitenleiste. + +Sie müssen außerdem auf derselben Seite **Enable Jira Web Hook** aktivieren, bevor DefectDojo eingehende Jira-Benachrichtigungen verarbeitet. Eingehende Webhooks werden ignoriert, wenn entweder dieses Kästchen oder **Enable Jira Integration** (siehe [Schritt 1](#step-1-enable-the-jira-integration-in-system-settings)) deaktiviert ist. + +![image](images/Configuring_the_Jira_DefectDojo_Webhook.png) + +### Den Jira-Webhook erstellen + +1. Besuchen Sie `**https:// \ /plugins/servlet/webhooks**` +2. Klicken Sie auf 'Create a Webhook'. +3. Geben Sie für das Feld mit der Bezeichnung 'URL' ein: `https:// \<**YOUR DOJO DOMAIN**\> /jira/webhook/ \<**YOUR GENERATED WEBHOOK SECRET**\>`. Das Web Hook Secret ist unter den oben genannten Jira Integration Settings aufgeführt. +4. Aktivieren Sie unter 'Comments' die Option 'Created'. Aktivieren Sie unter Issue die Option 'Updated'. +5. Stellen Sie sicher, dass Ihre JIRA-Instanz dem von Ihrer DefectDojo-Instanz verwendeten SSL-Zertifikat vertraut. Für JIRA Cloud muss DefectDojo [ein gültiges SSL/TLS-Zertifikat verwenden, das von einer global vertrauenswürdigen Zertifizierungsstelle signiert wurde](https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-registering-webhooks-with-non-secure-urls/) + +Beachten Sie, dass Sie kein Secret innerhalb von Jira erstellen müssen, um diesen Webhook zu verwenden. Das Secret ist in die URL von DefectDojo eingebaut, daher genügt es, einfach die vollständige URL in das Jira-Webhook-Formular einzutragen. + +Eingehende Webhook-Anfragen werden über das Secret in dieser URL authentifiziert, behandeln Sie die vollständige URL daher als Zugangsdaten und halten Sie sie geheim. + +#### Den Webhook testen + +Sobald Sie ein oder mehrere Issues aus DefectDojo-Befunden erstellt haben, können Sie den Webhook testen, indem Sie einem dieser Befunde eine Notiz hinzufügen. Die Notiz sollte vom Jira-Webhook als Notiz empfangen werden. + +Wenn dies nicht korrekt funktioniert, könnte dies an einem Firewall-Problem auf Ihrer Jira-Instanz liegen, das den Webhook blockiert. + +* Die Firewall-Regeln von DefectDojo enthalten ein Kontrollkästchen für **Jira Cloud**, das aktiviert werden muss, bevor DefectDojo Webhook-Nachrichten von Jira empfangen kann. + +### Alternative: Jira Automation verwenden (Send web request) + +Manche Jira-Instanzen erlauben keine System-Webhooks unter `/plugins/servlet/webhooks` — zum Beispiel, wenn dieser Verwaltungsbereich eingeschränkt ist und nur **Jira Automation**-Regeln erlaubt sind. In diesem Fall können Sie dieselbe bidirektionale Synchronisation über die Aktion **Send web request** von Automation steuern, die an denselben DefectDojo-Webhook-Endpunkt postet. + +Der Webhook-Endpunkt von DefectDojo akzeptiert jede HTTP-`POST`-Anfrage mit `Content-Type: application/json` und einem gültigen Secret im URL-Pfad. Es ist **nicht** erforderlich, dass die Anfrage vom System-Webhook-Mechanismus von Jira stammt, daher funktioniert die Aktion "Send web request" von Automation als direkter Ersatz. + +#### Voraussetzungen + +Es gelten dieselben Voraussetzungen wie beim System-Webhook: + +* **Enable JIRA integration** und **Enable JIRA web hook** sind beide auf der Seite ⚙️ **Configuration \> System Settings** aktiviert. +* Ein nicht-leeres **Jira webhook secret** ist auf dieser Seite gesetzt. Das Secret darf nur die Zeichen `A-Z`, `a-z`, `0-9`, `_` und `-` enthalten. +* Der Befund (oder die Befundgruppe) ist bereits mit dem Jira-Issue verknüpft. Wenn das Issue nicht mit einem DefectDojo-Befund verknüpft ist, wird die Anfrage trotzdem akzeptiert (HTTP `200`), aber es wird keine Aktion ausgeführt. + +#### Wie DefectDojo die Anfrage verarbeitet + +* DefectDojo verzweigt anhand eines Feldes `webhookEvent` auf oberster Ebene. Nur `"jira:issue_updated"` und `"comment_created"` werden verarbeitet; jeder andere Wert wird akzeptiert und ignoriert. Automation fügt dieses Feld nicht von sich aus hinzu, Sie müssen es also selbst in den Anfragetext aufnehmen. +* Setzen Sie den Anfrage-**Body** deshalb auf **Custom data** und geben Sie das untenstehende JSON an. Die Body-Optionen **Empty** und **Jira issue data** enthalten das erforderliche Feld `webhookEvent` nicht, DefectDojo wird sie daher ignorieren. +* Der Endpunkt gibt immer HTTP `200` zurück, unabhängig davon, ob ein Update angewendet wurde. Erfolg oder Misserfolg sind nur im Antworttext und in den DefectDojo-Protokollen sichtbar — ein `200` im Audit-Log von Automation bestätigt für sich allein nicht, dass das Update einen Befund erreicht hat. + +#### Regel 1 — Issue aktualisiert + +Erstellen Sie eine Automation-Regel mit: + +* **Trigger:** *Issue transitioned* (oder ein anderer Trigger, der auslöst, wenn sich die von Ihnen synchronisierten Felder ändern, z. B. *Field value changed* bei Status). +* **Aktion:** *Send web request* + * **Web request URL:** `https:///jira/webhook/` + * **HTTP method:** `POST` + * **Web request body:** *Custom data* + * **Headers:** `Content-Type: application/json` + * **Custom data:** + +```json +{ + "webhookEvent": "jira:issue_updated", + "issue": { + "id": "{{issue.id}}", + "fields": { + "updated": "{{issue.updated}}", + "resolution": null, + "status": { "statusCategory": { "key": "{{issue.status.statusCategory.key}}" } }, + "assignee": { "name": "{{issue.assignee.accountId}}", "displayName": "{{issue.assignee.displayName}}" } + } + } +} +``` + +Einschränkungen für Issue-Updates: + +* `issue.id` muss die **numerische interne Jira-Issue-ID** (`{{issue.id}}`) sein, nicht der Issue-Schlüssel (z. B. `PROJ-123`). DefectDojo ordnet das Update anhand dieser numerischen ID einem Befund zu. +* Die Felder `resolution` und `updated` müssen immer vorhanden sein. `resolution` darf `null` sein, aber wenn eines der beiden Felder fehlt, wird die Anfrage akzeptiert (`200`) und stillschweigend nicht verarbeitet. +* Statussynchronisation und automatische Behebung werden durch `status.statusCategory.key` gesteuert, dessen Jira-Werte `new` (To Do), `indeterminate` (In Progress) und `done` (Done) sind. Ein Befund wird nur dann als behoben markiert, wenn das Issue tatsächlich geschlossen wurde, nicht schon deshalb, weil zufällig ein Auflösungswert vorhanden ist. + +#### Regel 2 — Issue kommentiert + +Erstellen Sie eine zweite Automation-Regel mit: + +* **Trigger:** *Issue commented* +* **Aktion:** *Send web request* — dieselbe URL, Methode, denselben Header und dieselbe Body-Option *Custom data* wie bei Regel 1, mit folgendem Body: + +```json +{ + "webhookEvent": "comment_created", + "comment": { + "self": "https:///rest/api/2/issue/{{issue.id}}/comment/{{comment.id}}", + "body": "{{comment.body}}", + "updateAuthor": { "name": "{{comment.author.accountId}}", "displayName": "{{comment.author.displayName}}" } + } +} +``` + +Einschränkungen für Kommentare: + +* Sowohl `body` als auch `updateAuthor` müssen vorhanden sein. +* DefectDojo leitet das Ziel-Issue aus der URL `comment.self` ab — genauer gesagt aus der `` im Segment `.../issue//comment/...` — daher muss `{{issue.id}}` (die numerische ID) dort erscheinen. +* **Schleifenvermeidung:** Wenn der Kommentarautor mit dem Jira-Konto übereinstimmt, das DefectDojo zum Posten eigener Kommentare verwendet, überspringt DefectDojo den Kommentar, um eine Echo-Schleife zu vermeiden. Wenn Sie möchten, dass *alle* Kommentare eingelesen werden, führen Sie die Automation-Regel als **anderen** Jira-Benutzer aus als den, der in der Jira-Instanz von DefectDojo konfiguriert ist. + +#### Ein Hinweis zu Smart Values + +Die oben gezeigten Smart Values (`{{issue.id}}`, `{{issue.status.statusCategory.key}}`, `{{comment.author.accountId}}` usw.) sind die Standardnamen von Jira Cloud, können jedoch zwischen Instanzen variieren. Verwenden Sie vor dem Live-Gang die Payload-Vorschau von Automation, um zu bestätigen, dass jeder Smart Value zu dem aufgelöst wird, was Sie erwarten. + +## Die Jira-Integration testen + +#### Test 1: Werden Befunde erfolgreich an Jira übertragen? + +Um zu testen, ob die Jira-Integration ordnungsgemäß funktioniert, können Sie dem mit Jira verknüpften Produkt in DefectDojo einen neuen leeren Befund hinzufügen. **Product \> Findings \> Add New Finding.** + +Geben Sie beliebigen Titel, Schweregrad und Beschreibung ein und klicken Sie dann auf "Finished". Der Befund sollte mit allen relevanten Metadaten als Issue in Jira erscheinen. + +Wenn Jira-Issues nicht korrekt erstellt werden, prüfen Sie Ihre Notifications auf Fehlercodes. + +* Bestätigen Sie, dass der mit der Jira-Konfiguration von DefectDojo verknüpfte Jira-Benutzer die Berechtigung hat, Issues in diesem bestimmten Jira-Bereich zu erstellen und zu aktualisieren. + +#### Test 2: Jira-Webhooks senden an DefectDojo + +Um die Jira-Webhooks zu testen, fügen Sie einem Befund, der auch in JIRA als Issue existiert (zum Beispiel dem Test-Issue im obigen Abschnitt), eine Notiz hinzu. + +Wenn die Webhooks korrekt konfiguriert sind, sollten Sie die Notiz in Jira als Kommentar zum Issue sehen. + +Wenn dies nicht korrekt funktioniert, könnte dies an einem Firewall-Problem auf Ihrer Jira-Instanz liegen, das den Webhook blockiert. + +* Die Firewall-Regeln von DefectDojo enthalten ein Kontrollkästchen für **Jira Cloud**, das aktiviert werden muss, bevor DefectDojo Webhook-Nachrichten von Jira empfangen kann. + +## Die Verbindung zu Jira trennen + +Jira-Integrationen können nur dann von Ihrer Instanz entfernt werden, wenn keine zugehörigen Issues erstellt wurden. Wenn Issues erstellt wurden, gibt es keine Möglichkeit, eine Jira-Instanz vollständig aus DefectDojo zu entfernen. + +Sie können Ihre Jira-Integration jedoch deaktivieren, indem Sie sie auf Produktebene deaktivieren. Deaktivieren Sie auf der Seite **Jira Project Settings** (zugänglich über das ⚙️-Zahnrad-Menü bei einem Produkt) den Schalter **Enabled**. Dies löscht oder ändert keine vorhandenen, von DefectDojo erstellten Jira-Tickets, deaktiviert aber weitere Updates. + +# Befunde an Jira übertragen + +Ein Produkt mit einer JIRA-Zuordnung kann Befunde über mehrere Methoden als Issues an Jira übertragen. Sie können Befunde einzeln, in Massen, als Befundgruppen oder automatisch übertragen. + +## Einen einzelnen Befund übertragen + +1. Öffnen Sie den Befund, den Sie übertragen möchten. +2. Klicken Sie auf das **☰ Finding Menu** und wählen Sie **Push to Jira**. +3. Bestätigen Sie die Übertragung bei entsprechender Aufforderung. DefectDojo erstellt ein Jira-Issue und verknüpft es mit dem Befund. + +Sobald das Issue erstellt wurde, zeigt DefectDojo auf der Befund-Seite einen Link zum Jira-Issue an. + +![image](images/Creating_Issues_in_Jira_2.png) + +Sie können auch das Kontrollkästchen **Push to Jira** aktivieren, wenn Sie einen Befund über das Formular **Edit Finding** bearbeiten. Wenn der Befund gespeichert wird, wird er an Jira übertragen. + +### Ein verknüpftes Jira-Issue aktualisieren + +Wenn ein Befund bereits ein verknüpftes Jira-Issue hat, aktualisiert das erneute Auswählen von **Push to Jira** das vorhandene Jira-Issue mit allen in DefectDojo vorgenommenen Änderungen. Wenn **Push All Issues** für das Produkt aktiviert ist, geschieht diese Synchronisation automatisch. + +### Einen Befund von Jira trennen + +Um die Verknüpfung zwischen einem Befund und seinem Jira-Issue zu entfernen, klicken Sie auf das **☰ Finding Menu** und wählen Sie **Unlink From Jira**. Dies entfernt die Verknüpfung in DefectDojo, löscht aber nicht das Jira-Issue selbst. + +## Befunde in Massen übertragen + +Sie können mehrere Befunde gleichzeitig mit dem Formular Bulk Update an Jira übertragen: + +1. Wählen Sie in einer Befundliste über die Kontrollkästchen die Befunde aus, die Sie übertragen möchten. +2. Öffnen Sie das Formular **Bulk Update**. +3. Aktivieren Sie unter **Jira Settings** das Kontrollkästchen **Push to Jira**. +4. Klicken Sie auf **Submit**. + +Die ausgewählten Befunde werden für die Übertragung an Jira eingereiht. DefectDojo zeigt eine Bestätigungsmeldung an, wie viele Befunde eingereiht wurden. + +## Engagements als Epics übertragen + +Wenn **Enable Engagement Epic Mapping** in Ihren Jira Project Settings aktiviert ist, können Sie ein Engagement als Epic an Jira übertragen. Die Befunde des Engagements werden als untergeordnete Issues innerhalb dieses Epics übertragen. + +Um ein Engagement als Epic zu übertragen: + +1. Öffnen Sie das Engagement, das Sie übertragen möchten. +2. Klicken Sie auf das **☰ Engagement Menu** und wählen Sie **Push to Jira**. +3. Geben Sie optional einen **Epic Name** (standardmäßig der Engagement-Name, falls leer gelassen) und eine **Epic Priority** an. +4. Aktivieren Sie **Push to Jira (Create Epic)** und übermitteln Sie das Formular. + +## Befundgruppen als Jira-Issues übertragen + +Wenn Sie Befundgruppen aktiviert haben, können Sie eine Gruppe von Befunden als ein einzelnes Issue statt als separate Issues für jeden Befund an Jira übertragen. + +Um eine Befundgruppe zu übertragen: + +1. Öffnen Sie die Befundgruppe. +2. Klicken Sie auf das **☰ Finding Group Menu** und wählen Sie **Push to Jira**, oder aktivieren Sie das Kontrollkästchen **Push to Jira** beim Bearbeiten der Befundgruppe. + +Das mit einer Befundgruppe verknüpfte Jira-Issue muss bei Bedarf direkt aus der Jira-Instanz gelöscht werden. + +### Befundgruppen automatisch erstellen und übertragen + +Bei aktiviertem **Push All Issues** für das Produkt und einer beim Import ausgewählten **Group By**-Option: + +Solange die Befundgruppen erfolgreich erstellt werden, wird die Befundgruppe automatisch als Issue an Jira übertragen, nicht die einzelnen Befunde. + +![image](images/Creating_Issues_in_Jira_4.png) + +## Automatisches Übertragungsverhalten + +DefectDojo kann Befunde und Updates in mehreren Szenarien automatisch an Jira übertragen: + +### Push All Issues + +Wenn die Einstellung **Push All Issues** in den Jira Project Settings eines Produkts aktiviert ist, erstellt DefectDojo automatisch Jira-Issues für alle Aktiven und Verifizierten Befunde. Dies schließt Befunde ein, die per Scan-Import erstellt wurden. Sobald ein Jira-Issue erstellt wurde, bleibt es auch dann mit DefectDojo synchron, wenn sich der Status des Befunds ändert. + +### Automatische Synchronisation bei Statusänderungen + +Wenn **Push All Issues** oder die systemweite Einstellung **Finding Jira Sync** aktiviert ist, aktualisiert DefectDojo automatisch verknüpfte Jira-Issues, wenn bestimmte Aktionen an Befunden durchgeführt werden: + +* **Request Review** \- Ein Kommentar wird zum verknüpften Jira-Issue hinzugefügt (oder zum Jira-Issue der Befundgruppe, wenn der Befund zu einer Gruppe gehört). +* **Clear Review** \- Ein Kommentar wird zum verknüpften Jira-Issue hinzugefügt. +* **Close Finding** \- Das verknüpfte Jira-Issue wird aktualisiert, um die Schließung widerzuspiegeln. Wenn **Push Notes** aktiviert ist, wird auch ein Kommentar hinzugefügt. + +## Jira-Kommentare und Notizen + +Wenn **Push Notes** in den Jira Project Settings aktiviert ist: + +* Wenn ein Kommentar zu einem Jira-Issue hinzugefügt wird, wird derselbe Kommentar dem Befund unter dem Abschnitt **Notes** hinzugefügt. +* Wird umgekehrt eine Notiz zu einem Befund hinzugefügt, wird die Notiz dem Jira-Issue als Kommentar hinzugefügt. + +## Jira-Statusänderungen + +Die Konfiguration der Jira-Instanz enthält Einträge für zwei Jira-Übergänge, die eine Statusänderung bei einem Befund auslösen. + +* Wenn der **'Close'-Übergang** bei Jira durchgeführt wird, wird auch der zugehörige Befund geschlossen und in DefectDojo als **Inaktiv** und **Behoben** markiert. DefectDojo protokolliert diese Änderung auf der Befund-Seite unter der Überschrift **Mitigated By**. +​ +![image](images/Creating_Issues_in_Jira_3.png) + +* Wenn der **'Reopen'-Übergang** beim Jira-Issue durchgeführt wird, wird der zugehörige Befund in DefectDojo auf **Aktiv** gesetzt und verliert seinen **Behoben**-Status. + +## Jira-Auflösungen auf Risikoakzeptanz/Falsch-positiv zuordnen + +Die Konfiguration der Jira-Instanz enthält zwei optionale Felder, mit denen Sie eine Jira-**Auflösung** einem DefectDojo-Befundstatus zuordnen können: + +* **Risk Accepted Finding Mapping Resolution** — wenn ein Jira-Issue mit dieser Auflösung geschlossen wird, wird der verknüpfte Befund in DefectDojo zu Risiko akzeptiert. +* **False Positive Finding Mapping Resolution** — wenn ein Jira-Issue mit dieser Auflösung geschlossen wird, wird der verknüpfte Befund in DefectDojo zu Falsch-positiv. + +### Status vs. Auflösung: Eine häufige Verwechslung + +Diese Felder ordnen die Jira-**Auflösung** zu, nicht den Jira-**Status**. Status und Auflösung sind zwei unabhängige Jira-Konzepte: Der Status beschreibt, wo sich das Issue im Workflow befindet (Open, In Progress, Done), während die Auflösung beschreibt, wie es gelöst wurde (Fixed, Won't Do, Duplicate, False Positive usw.). + +### Voraussetzung: Eine "Set issue resolution"-Post-Funktion beim Jira-Workflow-Übergang + +Die Workflow-Engine von Jira füllt das Auflösungsfeld nicht automatisch aus. Jeder Übergang, der ein Issue mit einer bestimmten Auflösung schließen soll, benötigt eine am Übergang selbst konfigurierte **Set issue resolution**-Post-Funktion. Ohne diese Post-Funktion wechselt das Issue zwar in den neuen Status, aber die Auflösung bleibt leer, und die Zuordnung von DefectDojo hat nichts, womit sie abgleichen kann. + +Ein Jira-Administrator kann diese Post-Funktion über **Project Settings → Workflows → (Workflow bearbeiten) → (den Schließen-Übergang auswählen) → Post Functions → Add post function → Set issue resolution** hinzufügen. + +# Benutzerdefinierte Felder in Jira + +DefectDojo unterstützt derzeit nicht die Übergabe von Issue-spezifischen Informationen in diese benutzerdefinierten Felder \- diese Felder müssen nach der Erstellung des Issues manuell in Jira aktualisiert werden. Jedes benutzerdefinierte Feld wird von DefectDojo nur mit einem Standardwert erstellt. + + Jira Cloud ermöglicht es Ihnen nun, einen Standardwert für benutzerdefinierte Felder direkt in der App zu erstellen. [Siehe die Dokumentation von Atlassian zu benutzerdefinierten Feldern](https://support.atlassian.com/jira-cloud-administration/docs/configure-a-custom-field/) für weitere Informationen zur Konfiguration. + +Die integrierten Jira-Issue-Typen von DefectDojo (**Bug, Task, Story** und **Epic**) sind so eingerichtet, dass sie 'von Haus aus' funktionieren. Datenfelder in DefectDojo werden automatisch den entsprechenden Feldern in Jira zugeordnet. Standardmäßig weist DefectDojo jedem neu erstellten Issue Priority, Labels und einen Reporter zu. + +Manche Jira-Konfigurationen erfordern die Berücksichtigung zusätzlicher benutzerdefinierter Felder, bevor ein Issue erstellt werden kann. Dieser Prozess ermöglicht es Ihnen, diese benutzerdefinierten Felder in Ihrer DefectDojo \-\> Jira-Integration zu berücksichtigen und sicherzustellen, dass Issues erfolgreich erstellt werden. Diese benutzerdefinierten Felder werden jedem API-Aufruf hinzugefügt, der von DefectDojo an eine verknüpfte Jira-Instanz gesendet wird. + +Wenn Sie in Jira noch keine benutzerdefinierten Felder verwenden, müssen Sie diesem Prozess nicht folgen. + +1. Die Namen Ihrer benutzerdefinierten Felder in Jira erfassen (**Jira UI**) +2. Die Key-Werte für die neuen benutzerdefinierten Felder ermitteln (Jira Field Spec Endpoint) +3. Die zulässigen Daten für jedes benutzerdefinierte Feld anhand der Key-Werte als Referenz ermitteln (Jira Issue Endpoint) +4. Einen JSON-Feldreferenzblock erstellen, um alle Keys benutzerdefinierter Felder und zulässigen Daten zu verfolgen (Jira Issue Endpoint) +5. Den JSON-Block im zugehörigen DefectDojo-Produkt speichern, um die Erstellung benutzerdefinierter Felder aus Jira zu ermöglichen (DefectDojo UI) +6. Ihre Arbeit testen und sicherstellen, dass alle erforderlichen Daten korrekt von Jira fließen + +#### Schritt 1: Die Namen Ihrer benutzerdefinierten Felder in Jira erfassen + +Jira unterstützt eine Vielzahl unterschiedlicher Kontextfelder, einschließlich Date Pickers, benutzerdefinierter Labels und Radio Buttons. Jedes dieser Kontextfelder hat einen anderen Key-Wert, der in der Jira-API zu finden ist. + +Notieren Sie sich die Namen jedes erforderlichen benutzerdefinierten Feldes, da Sie im nächsten Schritt die Jira-API danach durchsuchen müssen. + +**Beispiel einer Liste benutzerdefinierter Felder (Ihre Namen für benutzerdefinierte Felder werden anders lauten):** + +* DefectDojo Custom URL Field +* Ein weiteres Beispiel für ein benutzerdefiniertes Feld +* ... + +#### Schritt 2: Ihre Jira Custom Field Key-Werte finden + +Beginnen Sie diesen Prozess, indem Sie zur Field Spec URL für Ihre gesamte Jira-Instanz navigieren. + +Hier ist ein Beispiel für eine Field Spec URL: + +`https://yourcompany-example.atlassian.net/rest/api/2/field` + +Die API gibt eine lange JSON-Zeichenkette zurück, die in lesbaren Text formatiert werden sollte (mit einem Code-Editor, einer Browser-Erweiterung oder ). + +Das von dieser URL zurückgegebene JSON enthält alle Ihre benutzerdefinierten Jira-Felder, von denen die meisten für DefectDojo irrelevant sind und Werte von `"Null"` haben. Jedes Objekt in dieser API-Antwort entspricht einem anderen Feld in Jira. Sie müssen nach den Objekten suchen, deren `"name"`-Attribute mit den Namen der von Ihnen in der Jira-UI erstellten benutzerdefinierten Felder übereinstimmen, und dann den Wert ihres "key"-Attributs notieren. + +![image](images/Using_Custom_Fields.png) + +Sobald Sie das passende Objekt in der JSON-Ausgabe gefunden haben, können Sie den "key"-Wert bestimmen \- in diesem Fall ist es `customfield_10050`. + +Jira generiert für jedes benutzerdefinierte Feld unterschiedliche Key-Werte, aber diese Key-Werte ändern sich nach der Erstellung nicht mehr. Wenn Sie in Zukunft ein weiteres benutzerdefiniertes Feld erstellen, erhält es einen neuen Key-Wert. + +**Unsere Liste benutzerdefinierter Felder erweitern:** + +* "DefectDojo Custom URL Field" \= customfield\_10050 +* "Ein weiteres Beispiel für ein benutzerdefiniertes Feld" \= customfield\_12345 +* ... + +#### Schritt 3 \- Die benutzerdefinierten Felder bei einem Jira-Issue finden + +Finden Sie ein Issue in Jira, das die in Schritt 2 erfassten benutzerdefinierten Felder enthält. Kopieren Sie den Issue-Schlüssel für den Titel (sollte ähnlich aussehen wie "`EXAMPLE-123`") und navigieren Sie zu folgender URL: + +`https://yourcompany-example.atlassian.net/rest/api/2/issue/EXAMPLE-123` + +Dies liefert eine weitere JSON-Zeichenkette. + +Wie zuvor enthält die API-Ausgabe viele `customfield_##`-Objektparameter mit `null`-Werten \- dies sind benutzerdefinierte Felder, die Jira standardmäßig hinzufügt und die für dieses Issue nicht relevant sind. Sie enthält außerdem `customfield_##`-Werte, die den im vorherigen Schritt gefundenen Key-Werten benutzerdefinierter Felder entsprechen. Im Gegensatz zur Field-Spec-Ausgabe sehen Sie hier keine Namen, die diese benutzerdefinierten Felder identifizieren, weshalb Sie die Key-Werte in Schritt 2 notieren mussten. + +![image](images/Using_Custom_Fields_2.png) + +**Beispiel:** +Wir wissen, dass `customfield_10050` das DefectDojo Custom URL Field repräsentiert, da wir es in Schritt 2 notiert haben. Wir können nun sehen, dass `customfield_10050` im Issue `EXAMPLE-123` den Wert `"https://google.com"` enthält. + +#### Schritt 4 \- Eine JSON-Feldreferenz aus jedem Jira Custom Field Key erstellen + +Sie müssen nun den Wert jedes benutzerdefinierten Feldes aus Ihrer Liste nehmen und in einem JSON-Objekt speichern (zur Verwendung als Referenz). Sie können alle benutzerdefinierten Felder ignorieren, die nicht in Ihrer Liste vorkommen. + +Dieses JSON-Objekt enthält alle Standardwerte für neue Jira-Issues. Wir empfehlen, Namen zu verwenden, die Ihr Team leicht als 'Standard'-Werte erkennt, die geändert werden müssen: '`change-me.com`', '`Change this paragraph.`' usw. + +**Beispiel:** + +Aus Schritt 3 wissen wir nun, dass Jira für "`customfield_10050`" eine URL-Zeichenkette erwartet. Wir können dies nutzen, um unser Beispiel-JSON-Objekt zu erstellen. + +Angenommen, wir hätten auch ein DefectDojo-bezogenes Kurztextfeld gefunden, das wir als "`customfield_67890`" identifiziert haben. Wir würden dieses Feld in unserer zweiten API-Ausgabe betrachten, den zugehörigen Wert ansehen und den gespeicherten Wert ebenfalls in unserem Beispiel-JSON-Objekt referenzieren. +​ +Ihr JSON-Objekt beginnt so auszusehen, während Sie weitere benutzerdefinierte Felder hinzufügen. + +``` +{ + "customfield_10050": "https://change-me.com", + "customfield_67890": "This is the short text custom field." +} +``` + +Wiederholen Sie diesen Prozess, bis alle für DefectDojo relevanten benutzerdefinierten Felder aus Jira zu Ihrer JSON-Feldreferenz hinzugefügt wurden. + +#### Datentypen \& Jira-Syntax + +Manche Felder, wie zum Beispiel Datumsfelder, können sich auf mehrere benutzerdefinierte Felder in Jira beziehen. In diesem Fall müssen Sie beide Felder zu Ihrer JSON-Feldreferenz hinzufügen. + +``` + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", +``` + +Andere Felder, wie zum Beispiel das Label-Feld, werden möglicherweise als Liste von Zeichenketten geführt \- bitte stellen Sie sicher, dass Ihre JSON-Feldreferenz ein Format verwendet, das der API-Ausgabe von Jira entspricht. + +``` +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], +``` + +Andere benutzerdefinierte Felder können zusätzliche, kontextbezogene Informationen enthalten, die aus der Feldreferenz entfernt werden sollten. Zum Beispiel enthält das Feld Custom Multichoice in der API-Ausgabe einen zusätzlichen Block, den Sie entfernen müssen, da dieser Block den aktuellen Wert des Feldes speichert. + +* Sie sollten das zusätzliche Objekt aus diesem Feld entfernen: + +``` +"customfield_10047": [ + { + "value": "A" + }, + { + "self": "example.url...", + "value": "C", + "id": "example ID" + } +] +``` +* stattdessen können Sie dies wie folgt kürzen und den zweiten Teil ignorieren: + +``` +"customfield_10047": [ + { + "value": "A" + } +] +``` + +#### Beispiel für eine vollständige Feldreferenz + +Hier ist eine vollständige JSON-Feldreferenz mit Inline-Kommentaren, die erklären, wozu jedes benutzerdefinierte Feld gehört. Dies ist als umfassendes Beispiel gedacht. Ihr JSON wird je nach den benutzerdefinierten Werten, die Sie bei der Issue-Erstellung verwenden möchten, unterschiedliche Key-Werte und Datenpunkte enthalten. + +``` +{ + "customfield_10050": "https://change-me.com", + + "customfield_10049": "This is a short text custom field", + +// two different fields, but both correspond to the same custom date attribute + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", + +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], + +// custom number field + "customfield_10043": 0, + +// custom paragraph field + "customfield_10044": "This is a very long winded way to say CHANGE ME PLEASE", + +// custom radio button field + "customfield_10045": { + "value": "radio button option" + }, + +// custom multichoice field + "customfield_10047": [ + { + "value": "A" + } + ], + +// custom checkbox field + "customfield_10039": [ + { + "value": "A" + } + ], + +// custom select list (singlechoice) field + "customfield_10048": { + "value": "1" + } +} +``` + +#### Schritt 5 \- Die benutzerdefinierten Felder zu einem DefectDojo-Produkt hinzufügen + +Sie können diese benutzerdefinierten Felder nun dem zugehörigen DefectDojo-Produkt auf der Seite Jira Project Settings hinzufügen (zugänglich über das ⚙️-Zahnrad-Menü beim Produkt). Fügen Sie die JSON-Feldreferenz als reinen Text in das Feld **Custom Fields** ein und speichern Sie. + +#### Schritt 6 \- Ihre Jira Custom Fields anhand eines neuen Befunds testen: + +Wenn Sie nun einen neuen Befund im mit Jira verknüpften Produkt erstellen, erstellt Jira automatisch all diese benutzerdefinierten Felder in Jira gemäß dem darin enthaltenen JSON-Block. Diese benutzerdefinierten Felder werden mit den Standardwerten ("change\-me\-please" usw.) erstellt. + +Navigieren Sie innerhalb des Produkts in DefectDojo zur Seite Findings \> Add New Finding. Stellen Sie sicher, dass der Befund sowohl Aktiv als auch Verifiziert ist, um sicherzustellen, dass er an Jira übertragen wird, und bestätigen Sie dann auf der Jira-Seite, dass die benutzerdefinierten Felder ohne Inkonsistenzen erfolgreich erstellt wurden. diff --git a/docs/content/connectors/downstream/PRO__jira_guide.es.md b/docs/content/connectors/downstream/PRO__jira_guide.es.md new file mode 100644 index 00000000000..25a272f1d1c --- /dev/null +++ b/docs/content/connectors/downstream/PRO__jira_guide.es.md @@ -0,0 +1,786 @@ +--- +title: Jira (Legacy) +description: Trabaje con la integración de Jira +weight: 1 +audience: pro +aliases: +- /es/issue_tracking/jira/pro__jira_guide/ +- /es/en/share_your_findings/jira_guide +--- + +> **Esta página documenta la integración legacy de Jira.** La integración de Jira por producto descrita aquí ha sido reemplazada por el **[Conector descendente de Jira](/connectors/downstream/about/)**, que está disponible de forma general en todas las instancias de DefectDojo Pro y es la forma recomendada de enviar Hallazgos a Jira. En la barra lateral de Pro, **Connect > Jira** muestra una insignia `LEGACY` por este motivo — consulte [Insignias de menú](/navigation/pro__menu_badges/). +> +> **Si está configurando Jira por primera vez, comience con el [Conector descendente](/connectors/downstream/about/) en lugar de esta guía.** +> +> **¿Ya utiliza la integración legacy?** DefectDojo Pro incluye una migración integrada que traslada su configuración clásica existente de Jira a los Conectores descendentes, incluidos los tickets que ya ha enviado — consulte [Migración al conector descendente de Jira](#migrating-to-the-jira-downstream-connector) más abajo. +> +> La integración legacy sigue funcionando, y esta guía sigue siendo precisa para ella. + +La integración de Jira de DefectDojo se puede utilizar para enviar datos de Hallazgos a uno o más Espacios de Jira. De este modo, puede integrar DefectDojo en su flujo de trabajo de desarrollo habitual. Estos son algunos ejemplos de cómo puede funcionar esto: + +* El equipo de AppSec puede enviar Hallazgos de forma selectiva a un Espacio de Jira utilizado por los desarrolladores, de modo que la remediación de incidencias pueda priorizarse adecuadamente junto con el desarrollo habitual. Los desarrolladores de ese tablero no necesitan acceder a DefectDojo: pueden mantener todo su trabajo en un solo lugar. +* DefectDojo puede enviar TODOS los Hallazgos a un Espacio de Jira bidireccional que utiliza el equipo de AppSec, lo que les permite repartirse la validación de incidencias. Este tablero se mantiene sincronizado con DefectDojo y permite flujos de trabajo de remediación complejos. +* DefectDojo puede enviar Hallazgos de forma selectiva desde Productos y/o Compromisos independientes a Espacios de Jira independientes, para mantener cada cosa en su contexto adecuado. + +## Migración al conector descendente de Jira + +DefectDojo Pro puede convertir por usted una configuración clásica de Jira existente en una configuración de Conector descendente, en lugar de obligarle a reconstruirla manualmente. + +**Dónde encontrarlo:** vaya a **Connect \> Downstream** para abrir la página **Downstream Connectors**, y use la tarjeta **Classic Jira Migration**. Haga clic en **Migrate from classic Jira** y luego confirme. + +La tarjeta solo aparece si hay una configuración clásica de Jira que migrar, o una ejecución anterior que reportar — por lo que una instancia que nunca usó Jira clásico no la verá. Una vez que todo se ha migrado, la tarjeta permanece pero el botón queda deshabilitado, porque ya no queda nada por hacer. + +Ejecutar la migración requiere **permisos de nivel Maintainer globales** (concretamente, permiso para editar integraciones), y debe ejecutarse desde una sesión de navegador con la sesión iniciada — no se puede realizar con un token de API. + +### Qué sucede con los tickets que ya ha enviado + +**Sus tickets de Jira existentes se conservan y se vuelven a enlazar — no quedan huérfanos, y el conector no abre duplicados.** Cada Hallazgo que Jira clásico ya había enviado conserva su ticket, y el conector pasa a actualizar ese mismo ticket en el mismo lugar. Los enlaces en los Grupos de hallazgos se trasladan de la misma manera. + +La única excepción son los **épicos de Compromiso**. El Conector descendente no tiene el concepto de épicos, por lo que las incidencias de tipo épico se reportan en las advertencias de la migración y se dejan sin modificar. + +### Qué se migra + +* Su conexión de **instancia** de Jira — URL y credenciales — se convierte en una instancia de integración de Conector descendente, conservando su nombre. +* Las **asignaciones de severidad** y las **asignaciones de estado** (sus claves de transición de apertura y cierre) se trasladan. +* Cada configuración de **Proyecto de Jira** se convierte en una asignación de rastreador de incidencias, conservando su clave de proyecto y su tipo de incidencia, y permanece asignada al mismo Producto o Compromiso. +* **Push All Issues** se conserva: los proyectos que lo tenían habilitado siguen enviando automáticamente. +* Los **campos personalizados**, los **campos de transición de cierre/reapertura**, el **componente**, el **responsable predeterminado** y las **etiquetas** se convierten en asignaciones de campos. Donde usaba *Add Vulnerability Id as a Jira label*, eso también se convierte en una asignación de etiqueta. +* Un directorio de **plantilla de incidencia personalizada** se convierte en una plantilla de ticket. Las plantillas estándar no se copian, porque el conector ya incluye sus equivalentes. + +### Qué no se traslada + +Esto se reporta como advertencias en la ejecución de la migración — no la detienen. Busque la lista *"things the connector cannot carry over"* en los resultados. + +* **Sincronización inversa de Jira → DefectDojo.** Este es el importante. El Conector descendente no sincroniza cambios *de vuelta* desde Jira, por lo que las asignaciones de resolución que aplican Riesgo aceptado o Falso positivo a partir de una resolución de Jira no se migran. **Si depende de la sincronización inversa, deje configurada la instancia clásica de Jira** — la migración no la elimina. +* **Engagement Epic Mapping** — el conector no tiene concepto de épicos. +* **Push Notes**, los **comentarios de notificación de SLA** y los **comentarios de expiración de aceptación de riesgo** — el conector no los publica en Jira. +* Campos personalizados llamados `summary`, `description`, `project`, `issuetype` o `status` — están reservados por el conector, y una asignación de campo que use alguno de ellos se omite. +* Valores de campo personalizado de más de 512 caracteres — se omiten en lugar de truncarse. +* Un Proyecto de Jira que no está vinculado ni a un Producto ni a un Compromiso no produce ninguna asignación. + +### Qué sucede después con la integración clásica + +**Nada se envía dos veces.** Por cada proyecto que migra, la migración desactiva el proyecto clásico de Jira, de modo que a partir de ese momento solo envía el conector. No es necesario deshabilitar nada manualmente. + +Su configuración clásica se **conserva, no se elimina** — la instancia, el proyecto y los registros de incidencias permanecen todos, y solo se desactivan los ajustes de envío. Esto es intencionado: es lo que hace que el cambio sea reversible, y es lo que mantiene funcionando la sincronización inversa si depende de ella. + +**Para revertir**, vuelva a habilitar los ajustes del proyecto clásico de Jira y elimine la configuración del conector creada por la migración. No existe una opción de deshacer con un solo clic. + +**Volver a ejecutarla es seguro.** La migración registra lo que ya ha convertido y lo omite en una segunda ejecución, por lo que nada se duplica. Si un proyecto o una instancia falla, el resto se sigue migrando — un proyecto fallido se deja funcionando en la integración clásica en lugar de desactivarse, de modo que sigue funcionando mientras usted investiga. + +### Mientras se ejecuta + +La migración se ejecuta en segundo plano e informa del progreso a medida que avanza. Cuando termina, obtiene un resumen — cuántos conectores, asignaciones, asignaciones de destino, plantillas y enlaces de tickets se crearon, cuántos proyectos clásicos se desactivaron y qué se omitió — junto con las advertencias descritas anteriormente. Solo se ejecuta una migración a la vez. + +# Configuración de Jira + +Configurar Jira requiere los siguientes pasos: +1. Habilitar la integración de Jira en la Configuración del sistema. Hasta que lo haga, el resto de los ajustes de Jira permanecen ocultos en todo DefectDojo. +2. Conectar una Instancia de Jira, ya sea con un usuario/contraseña o con un token de API. Se pueden vincular varias instancias. +3. Añadir esa Instancia de Jira a uno o más Productos o Compromisos dentro de DefectDojo. +4. Si desea usar sincronización bidireccional, crear un Webhook de Jira que enviará actualizaciones a DefectDojo. + +## Paso 1: Habilitar la integración de Jira en la Configuración del sistema + +La integración de Jira está desactivada de forma predeterminada, y mientras lo está, DefectDojo oculta el resto de los controles de Jira en la interfaz. Esto es lo primero que hay que configurar: ninguno de los pasos siguientes está disponible hasta que se habilita. + +Mientras la integración está deshabilitada, no hay ninguna entrada de **Jira Instances** en la barra lateral, por lo que no hay dónde añadir una Instancia de Jira: + +![imagen](images/jira-menu-hidden-pro.png) + +### Habilitar la integración + +1. Vaya a **Settings \> System \> System Settings** desde la barra lateral de DefectDojo. En las instancias que todavía usan el diseño de menú anterior, esto se encuentra bajo un grupo con el nombre de su paquete de licencia — **Pro Settings** o **Enterprise Settings**. Consulte [El menú de Configuración](/navigation/pro__settings_menu/). +​ +2. En la sección **Jira Integration Settings**, marque **Enable Jira Integration**. +​ +3. Haga clic en **Submit**. **Jira Instances** aparece en la barra lateral inmediatamente, sin necesidad de recargar la página: + +![imagen](images/jira-enable-system-settings-pro.png) + +### Qué controla este ajuste + +Habilitar **Enable Jira Integration** es lo que hace que aparezca el resto de la interfaz de Jira. Con él activado, obtiene: + +* el menú **Jira Instances**, donde se añaden y editan las Instancias de Jira +* la página **Jira Project Settings** en el menú ⚙️ del Activo, y los ajustes de Jira en los Compromisos +* las acciones **Push to Jira** en Hallazgos y Grupos de hallazgos, los campos de Jira en los formularios de Hallazgo y de edición masiva, y las columnas de Jira en las listas de Activos, Compromisos, Hallazgos y Grupos de hallazgos (incluidas las exportaciones a CSV) + +El ajuste también controla la integración fuera de la interfaz: mientras está desactivado, DefectDojo no enviará Hallazgos a Jira (incluidas las solicitudes `push_to_jira` enviadas a través de la API), y los webhooks entrantes de Jira se ignoran. + +El resto de los campos de Jira en **Jira Integration Settings** (**Add Vulnerability ID as Jira Label**, **Enable Jira Web Hook**, **Disable Jira Web Hook Secret**, **Jira Web Hook Secret**, **Jira Minimum Severity**) permanecen visibles tanto si la integración está activada como si no, pero no tienen ningún efecto hasta que se habilita. + +## Paso 2: Conectar una Instancia de Jira + +Con la integración habilitada, conectar una Instancia de Jira es el siguiente paso para configurar la integración de Jira de DefectDojo. Tenga en cuenta que Jira Service Management no es compatible actualmente. + +#### Información necesaria de Jira + +Atlassian utiliza formas de autenticación distintas entre Jira Cloud y Jira Data Center. + +para **Jira Cloud**, necesitará: +* una URL de Jira, por ejemplo https://yourcompany.atlassian.net/ +* una cuenta con permisos para crear y actualizar incidencias en su instancia de Jira. Puede ser: + * Una combinación estándar de **usuario/contraseña** + * Una combinación de **usuario/token de API** + +para **Jira Data Center (o Server)**, necesitará: +* una URL de Jira, por ejemplo https://jira.yourcompany.com +* una cuenta con permisos para crear y actualizar incidencias en su instancia de Jira. Puede ser: + * Una combinación estándar de **usuario/contraseña** + * Una combinación de **dirección de correo/Token de acceso personal** + +Opcionalmente, puede asignar: +* Transiciones de Jira para activar la Reapertura y el Cierre de Hallazgos +* Resoluciones de Jira que puedan aplicar los estados Riesgo aceptado y Falso positivo a los Hallazgos (opcional) + +Una única conexión de Instancia de Jira puede gestionar varios Espacios de Jira, siempre que la cuenta/token de Jira que use DefectDojo tenga permiso para crear Incidencias en el Espacio de Jira asociado. + +### Añadir una Instancia de Jira + +1. Asegúrese de que **Enable Jira Integration** esté marcado en la Configuración del sistema, como se describe en el [Paso 1](#step-1-enable-the-jira-integration-in-system-settings). El menú **Jira Instances** no aparece en la barra lateral hasta entonces. + +2. Vaya a la página **Enterprise Settings \> Jira Instances \> + New Jira Instance** desde la barra lateral de DefectDojo. + +![imagen](images/jira-instance-beta.png) + +3. Seleccione un **Configuration Name** para que esta Instancia de Jira lo use en DefectDojo. Este nombre es simplemente una etiqueta para la conexión de la Instancia en DefectDojo, y no necesita estar relacionado con ningún dato de Jira. + +4. Seleccione la URL de la instancia de Jira de su empresa, probablemente similar a `https://**yourcompany**.atlassian.net` si utiliza una instalación de Jira Cloud. + +5. Introduzca un método de autenticación adecuado en los campos Username/Password de Jira: + * Para la **autenticación estándar de usuario/contraseña de Jira**, introduzca un nombre de usuario de Jira y la contraseña correspondiente en estos campos. + * Para la autenticación con un **token de API de usuario (Jira Cloud)**, introduzca el nombre de usuario junto con el **token de API** correspondiente en el campo de contraseña. + * Para la autenticación con un **Token de acceso personal de Jira (también llamado PAT, usado solo en Jira Data Center y Jira Server)**, introduzca el PAT en el campo de contraseña. El nombre de usuario no se utiliza para la autenticación con un PAT de Jira, pero el campo sigue siendo obligatorio en este formulario, así que puede usar un valor de marcador de posición aquí para identificar su PAT. + +Tenga en cuenta que el usuario asociado a esta conexión debe tener permiso para crear Incidencias y acceder a los datos de su instancia de Jira. + +6. Deberá proporcionar valores para un Epic Name ID, un Re-open Transition ID y un Close Transition ID. Estos valores se pueden cambiar más adelante. Con la sesión iniciada en Jira, puede acceder a estos valores desde las siguientes URL: +- **Epic Name ID**: visite `https:///rest/api/2/field` y busque Epic Name. Copie el número que aparece en `number` y péguelo aquí. Si no tiene un Epic Name ID asociado a su Espacio en Jira (por usar, por ejemplo, un Espacio gestionado por el equipo), introduzca 0 en este campo. +- **Re-open Transition ID**: visite `https:///rest/api/latest/issue//transitions?expand-transitions.fields` para encontrar el ID de su instancia de Jira. Péguelo en el campo Reopen Transition ID. +- **Close Transition ID**: visite `https:///rest/api/latest/issue//transitions?expand-transitions.fields` para encontrar el ID de su instancia de Jira. Péguelo en el campo Close Transition ID. + +7. Seleccione el tipo de incidencia predeterminado con el que desea crear las Incidencias en Jira. Las opciones son **Bug, Task, Story** y **Epic** (que son tipos de incidencia estándar de Jira), así como **Spike** y **Security**, que son tipos de incidencia personalizados. Si tiene un tipo de incidencia distinto que desee usar, póngase en contacto con [support@defectdojo.com](mailto:support@defectdojo.com) para obtener ayuda. + +8. Seleccione su Plantilla de incidencia, que determinará la Descripción de la incidencia cuando se creen Incidencias en Jira. + +Los dos tipos son: +- **Jira\_full**, que incluirá toda la información del Hallazgo en las Incidencias de Jira +- **Jira\_limited**, que incluirá una cantidad menor de información y metadatos del Hallazgo. + +Si deja este campo en blanco, se usará de forma predeterminada **Jira\_full.** Si necesita otro tipo de plantilla, póngase en contacto con [support@defectdojo.com](mailto:support@defectdojo.com). + +9. Si lo desea, introduzca el nombre de una Resolución de Jira que cambiará el estado de un Hallazgo a Aceptado o a Falso positivo (cuando se active la Resolución en la Incidencia). + +El formulario se puede enviar desde aquí. Si lo desea, puede personalizar aún más su integración de Jira en Optional Fields. Al hacer clic en este botón podrá aplicar texto genérico a las Incidencias de Jira o cambiar la asignación de Jira Severity Mappings. + +## Paso 3: Conectar un Producto o Compromiso a Jira + +Cada Producto o Compromiso en DefectDojo tiene sus propios ajustes que rigen cómo se convierten los Hallazgos en Incidencias de JIRA. Desde aquí, puede decidir el Espacio de Jira asociado y establecer el comportamiento predeterminado para crear Incidencias, Épicos, Etiquetas y otros metadatos de JIRA. + +### Añadir Jira a un Producto + +Puede encontrar esta página haciendo clic en el menú de engranaje de un Producto ⚙️ y abriendo la página **Jira Project Settings**. + +![imagen](images/jira-project-settings.png) + +#### Instancia de Jira + +Si tiene configuradas varias instancias de Jira, para productos o equipos distintos dentro de su organización, puede indicar en qué Espacio de Jira desea que DefectDojo cree Incidencias. Seleccione un Espacio en el menú desplegable. + +Si este menú no lista ninguna instancia de Jira, confirme que esos Espacios están conectados en su Configuración global de Jira para DefectDojo — yourcompany.defectdojo.com/jira. + +#### Clave de proyecto + +Esta es la clave del Espacio que desea usar con DefectDojo. La Space Key de un Espacio determinado se puede encontrar en la URL. (Anteriormente esto se conocía como **Jira Project Key**, pero desde septiembre de 2025 Jira lo denomina **Space Key**). + +![imagen](images/Add_a_Connected_Jira_Project_to_a_Product_3.png) + +#### Nombre del tipo de incidencia Epic + +El nombre del tipo de incidencia Epic en Jira. Este valor es "Epic" de forma predeterminada, pero se puede cambiar si su instancia de Jira usa un nombre distinto. + +#### Plantilla de incidencia + +Aquí puede determinar cuántos metadatos de DefectDojo desea enviar a Jira. Seleccione una de las dos opciones: + +* **jira\_full**: las Incidencias registrarán todos los parámetros de DefectDojo — una Descripción completa, CVE, Severidad, etc. Útil si necesita el contexto completo del Hallazgo en Jira (por ejemplo, si alguien que trabaja en esta Incidencia no tiene acceso a DefectDojo). + +Aquí tiene un ejemplo de una Incidencia **jira\_full**: +​ +![imagen](images/Add_a_Connected_Jira_Project_to_a_Product_4.png) + +* **Jira\_limited:** las Incidencias solo registrarán el enlace a DefectDojo, los enlaces de Producto/Compromiso/Test, y los campos Reporter y Environment. El resto de los campos se registran únicamente en DefectDojo. Útil si no necesita el contexto completo del Hallazgo en Jira (por ejemplo, si alguien que trabaja en esta Incidencia trabaja principalmente en DefectDojo y no necesita también toda la información en JIRA). + +​Aquí tiene un ejemplo de una Incidencia **jira\_limited**: + +![imagen](images/Add_a_Connected_Jira_Project_to_a_Product_5.png) + +#### Componente + +Si gestiona su Espacio de Jira mediante Componentes, aquí puede asignar el Componente adecuado para DefectDojo. Para asignar más de un Componente, introduzca una lista separada por comas (por ejemplo, `Security, DevSecOps`); cada valor se envía a Jira como un componente independiente. + +#### Campos personalizados + +Si no necesita usar Campos personalizados con las incidencias de DefectDojo, puede dejar este campo como 'null'. + +Sin embargo, si la configuración de su Espacio de Jira **le obliga** a usar Campos personalizados en las Incidencias nuevas, deberá codificar directamente estas asignaciones. + +Tenga en cuenta que DefectDojo no puede enviar ningún metadato específico de la Incidencia como Campo personalizado, solo un valor predeterminado. Esta sección solo debería configurarse si su Espacio de Jira **requiere que existan estos Campos personalizados** en cada Incidencia de su Espacio. + +Siga **[esta guía](#custom-fields-in-jira)** para empezar a trabajar con Campos personalizados. + +#### Campos de transición de cierre/reapertura + +Algunos flujos de trabajo de Jira **requieren** que se establezcan ciertos campos como parte de una transición — por ejemplo, un flujo de trabajo que se niega a cerrar una Incidencia a menos que se proporcionen los campos Resolution y Justification en la pantalla de cierre. El ajuste de Campos personalizados anterior solo se aplica cuando se *crea* una Incidencia, por lo que no puede satisfacer estos flujos de trabajo. + +Sin estos ajustes, DefectDojo envía las transiciones de cierre/reapertura sin campos. Un flujo de trabajo que requiera campos rechazará esa transición, y el Hallazgo y la Incidencia de Jira quedarán desincronizados: el Hallazgo aparece como Mitigado en DefectDojo mientras la Incidencia sigue abierta en Jira. + +Los ajustes **Close Transition fields** y **Reopen Transition fields** aceptan un objeto JSON que se envía como el payload `fields` de la llamada de transición de cierre/reapertura. Por ejemplo, para cerrar Incidencias con una Resolution de *Won't Fix* más un valor de justificación: + +```json +{ + "resolution": {"name": "Won't Fix"}, + "customfield_10200": "Risk accepted by security team #report-false-positive" +} +``` + +Deje estos ajustes como 'null' si el flujo de trabajo de su Jira no requiere campos en las transiciones. + +**¿Qué campos necesita?** + +* Pregunte a su administrador de Jira qué campos aparecen en las **pantallas de transición** de cierre/reapertura, y cuáles de ellos son obligatorios según un validador. El JSON configurado debe satisfacer **todos** los campos obligatorios: si falta en el payload algún campo obligatorio, Jira rechaza toda la transición y no establece nada — proporcionar solo algunos de los campos obligatorios no sirve de nada. +* A la inversa, los campos deben estar presentes **en la pantalla de transición** para poder enviarse: Jira rechaza las transiciones que intentan establecer campos que no están en la pantalla de esa transición. +* En los flujos de trabajo creados con el editor de flujos de trabajo actual de Jira Cloud, Jira completa automáticamente la Resolution predeterminada del sitio cuando una Incidencia pasa a un estado de la categoría "hecho". Por lo tanto, una Resolution obligatoria por sí sola no bloqueará ahí una transición sin campos, y el uso práctico de `"resolution"` en este payload es elegir un valor *significativo* (por ejemplo, *False Positive*) en lugar del valor predeterminado del sitio. Los flujos de trabajo creados con el editor clásico, o con aplicaciones de validación del marketplace, todavía pueden exigir obligatoriamente la Resolution. +* Las transiciones de reapertura normalmente borran la Resolution mediante el propio flujo de trabajo, por lo que **Reopen Transition fields** suele necesitar solo los campos personalizados que requiera su flujo de trabajo. + +**Notas:** + +* Se envía el mismo JSON para *cada* transición de cierre (o reapertura) del Producto o Compromiso — los valores son estáticos y no varían según el Hallazgo. Si necesita campos distintos según la disposición (por ejemplo, una Resolution distinta para los hallazgos de Falso positivo que para los remediados), use el Jira Integrator de DefectDojo Pro, que admite asignaciones de campos de transición por estado. +* Los valores usan el mismo formato que la API REST de Jira: cadenas de texto para los campos de texto, `{"name": ...}` para las resoluciones, `[{"name": ...}]` para los campos de selección múltiple, y así sucesivamente. +* Si las transiciones se rechazaron mientras estos ajustes estaban ausentes o incompletos, corregir los ajustes repara el desfase: el siguiente envío de estado del Hallazgo reintenta la transición con los campos configurados. +* Ambos ajustes también están disponibles en el endpoint REST `/api/v2/jira_projects/` (`close_transition_fields`/`reopen_transition_fields`), por lo que se pueden gestionar mediante la API. +* Estos campos también se aplican cuando DefectDojo cierra una Incidencia porque su Hallazgo fue **eliminado** — los valores se capturan en el momento en que se pone en cola el cierre. + +#### Etiquetas de Jira + +Seleccione las etiquetas pertinentes con las que desea que se cree la Incidencia en Jira, por ejemplo **DefectDojo**, **YourProductName..** + +![imagen](images/Add_a_Connected_Jira_Project_to_a_Product_6.png) + +#### Responsable predeterminado + +El nombre del responsable predeterminado en Jira. Si se deja en blanco, DefectDojo seguirá el comportamiento predeterminado de su Espacio de Jira al crear Incidencias. + +### Jira Project Settings + +#### Habilitado + +Este interruptor controla si DefectDojo envía Hallazgos a Jira para este Producto. Deshabilitarlo no eliminará ni modificará ningún ticket de Jira existente creado por DefectDojo, pero impedirá cualquier actualización posterior o la creación de nuevas Incidencias. + +Las integraciones de Jira solo se pueden eliminar de su instancia si no se ha creado ninguna Incidencia relacionada. Si ya se han creado Incidencias, no hay forma de eliminar por completo una Instancia de Jira de DefectDojo. + +#### Añadir Vulnerability Id como etiqueta de Jira + +Esto le permite añadir automáticamente los datos de Vulnerability ID como una etiqueta de Jira. Los Vulnerability ID se añaden a los Hallazgos a partir de herramientas de seguridad individuales — pueden ser identificadores de Common Vulnerabilities and Exposures (CVE) o un formato distinto, específico de la herramienta que reporta el Hallazgo. + +#### Push All Issues + +Si está marcado, DefectDojo enviará automáticamente a Jira como Incidencias cualquier Hallazgo Activo y Verificado. Si se deja sin marcar, todos los Hallazgos deberán enviarse a Jira manualmente (de forma individual o mediante envío masivo). + +Cuando este ajuste está habilitado, las Incidencias de Jira seguirán sincronizándose con DefectDojo aunque cambie el estado del Hallazgo. + +#### Enable Engagement Epic Mapping + +En DefectDojo, los Compromisos representan un conjunto de trabajo. Cada Compromiso contiene uno o más tests, que contienen uno o más Hallazgos que deben mitigarse. Los Épicos en Jira funcionan de forma similar, y esta casilla le permite enviar Compromisos a Jira como Épicos. + +* Un Compromiso en DefectDojo — observe los tres hallazgos listados en la parte inferior. +​ +![imagen](images/Add_a_Connected_Jira_Project_to_a_Product_8.png) +* Cómo el mismo Compromiso se convierte en un Épico al enviarse a JIRA — los Hallazgos del Compromiso también se envían, y quedan dentro del Épico como Incidencias hijas. + +![imagen](images/Add_a_Connected_Jira_Project_to_a_Product_9.png) + +#### Push Notes + +Si está habilitado, los comentarios de Jira se reflejarán en el Hallazgo asociado en DefectDojo, en Notas, y viceversa; las Notas de los Hallazgos se añadirán a la Incidencia de Jira asociada como Comentarios. + +#### Send SLA Notifications As Comments + +Si está habilitado, cualquier Incidencia que incumpla las reglas del Acuerdo de nivel de servicio de DefectDojo tendrá comentarios añadidos en la incidencia de Jira indicándolo. Estos comentarios se publicarán a diario hasta que se resuelva la Incidencia. + +Los Acuerdos de nivel de servicio se pueden configurar en **Configuration \> SLA Configuration** en DefectDojo y asignarse a cada Producto. + +#### Send Risk Acceptance Expiration Notifications As Comment + +Si está habilitado, cualquier Incidencia cuya Aceptación de riesgo asociada de DefectDojo expire tendrá un comentario añadido en la incidencia de Jira indicándolo. Estos comentarios se publicarán a diario hasta que se resuelva la Incidencia. + +### Ajustes de Jira a nivel de Compromiso + +De forma predeterminada, los Compromisos **heredan los ajustes de Jira de su Producto**. Sin embargo, puede anular los ajustes de Jira para Compromisos individuales. + +Para acceder a los ajustes de Jira a nivel de Compromiso, haga clic en el menú de engranaje ⚙️ de un Compromiso y abra la página **Jira Project Settings**. + +Desde aquí, puede desmarcar **Inherit from Product** y proporcionar valores específicos del Compromiso para: **Project Key**, **Issue Template, Custom Fields, Jira Labels, Default Assignee**, y otros ajustes. + +Tenga en cuenta que, una vez que un Compromiso tiene asignado su propio proyecto de Jira, ya no puede heredar del Producto. + +![imagen](images/Creating_Issues_in_Jira_5.png) + +## Paso 4: Configurar la sincronización bidireccional: webhook de Jira + +La integración con Jira permite la sincronización bidireccional mediante un webhook. DefectDojo recibe notificaciones de Jira en una dirección única, lo que permite que los comentarios de Jira se reciban en los Hallazgos, o que los Hallazgos se resuelvan a través de Jira, según su configuración. + +### Cómo localizar la URL de su webhook de Jira + +Su webhook de Jira se encuentra en el formulario de configuración del sistema, en **Jira Integration Settings**: **Enterprise Settings \> System Settings** en la barra lateral. + +También debe marcar **Enable Jira Web Hook** en la misma página para que DefectDojo procese las notificaciones entrantes de Jira. Los webhooks entrantes se ignoran si esa casilla o **Enable Jira Integration** (consulte el [Paso 1](#step-1-enable-the-jira-integration-in-system-settings)) no están marcadas. + +![image](images/Configuring_the_Jira_DefectDojo_Webhook.png) + +### Cómo crear el webhook de Jira + +1. Visite `**https:// \ /plugins/servlet/webhooks**` +2. Haga clic en 'Create a Webhook'. +3. En el campo denominado 'URL', ingrese: `https:// \<**YOUR DOJO DOMAIN**\> /jira/webhook/ \<**YOUR GENERATED WEBHOOK SECRET**\>`. El Web Hook Secret aparece en Jira Integration Settings, como se indicó anteriormente. +4. En 'Comments', habilite 'Created'. En Issue, habilite 'Updated'. +5. Asegúrese de que su instancia de JIRA confíe en el certificado SSL utilizado por su instancia de DefectDojo. Para JIRA Cloud, DefectDojo debe usar [un certificado SSL/TLS válido, firmado por una autoridad certificadora globalmente confiable](https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-registering-webhooks-with-non-secure-urls/) + +Tenga en cuenta que no es necesario crear un Secret dentro de Jira para usar este webhook. El Secret está integrado en la URL de DefectDojo, por lo que basta con agregar la URL completa al formulario de webhook de Jira. + +Las solicitudes de webhook entrantes se autentican mediante el secreto incluido en esa URL, así que trate la URL completa como una credencial y manténgala privada. + +#### Cómo probar el webhook + +Una vez que tenga uno o más Issues creados a partir de Hallazgos de DefectDojo, puede probar el webhook agregando una nota a uno de esos Hallazgos. La nota debería recibirse en el webhook de Jira como un comentario. + +Si esto no funciona correctamente, podría deberse a un problema de firewall en su instancia de Jira que esté bloqueando el webhook. + +* Las reglas de firewall de DefectDojo incluyen una casilla para **Jira Cloud,** que debe habilitarse antes de que DefectDojo pueda recibir mensajes de webhook desde Jira. + +### Alternativa: usar Jira Automation (Send web request) + +Algunas instancias de Jira no permiten webhooks del sistema en `/plugins/servlet/webhooks` — por ejemplo, cuando esa área de administración está restringida y solo se permiten reglas de **Jira Automation**. En ese caso, puede lograr la misma sincronización bidireccional utilizando la acción **Send web request** de Automation, que envía datos al mismo endpoint de webhook de DefectDojo. + +El endpoint de webhook de DefectDojo acepta cualquier `POST` HTTP con `Content-Type: application/json` y un secreto válido en la ruta de la URL. No requiere que la solicitud se origine en el mecanismo de webhook del sistema de Jira, por lo que la acción "Send web request" de Automation funciona como una alternativa directa. + +#### Requisitos previos + +Se aplican los mismos requisitos previos que para el webhook del sistema: + +* **Enable JIRA integration** y **Enable JIRA web hook** están ambas marcadas en la página ⚙️ **Configuration \> System Settings**. +* Se ha configurado un **Jira webhook secret** no vacío en esa página. El secreto solo puede contener los caracteres `A-Z`, `a-z`, `0-9`, `_` y `-`. +* El Hallazgo (o Grupo de hallazgos) ya está vinculado al issue de Jira. Si el issue no está vinculado a un Hallazgo de DefectDojo, la solicitud igualmente se acepta (HTTP `200`), pero no se realiza ninguna acción. + +#### Cómo procesa DefectDojo la solicitud + +* DefectDojo se ramifica según un campo de nivel superior llamado `webhookEvent`. Solo se procesan `"jira:issue_updated"` y `"comment_created"`; cualquier otro valor se acepta pero se ignora. Automation no agrega este campo por sí sola, por lo que debe incluirlo usted mismo en el cuerpo de la solicitud. +* Por ese motivo, configure el **Body** de la solicitud como **Custom data** y proporcione el JSON que se muestra a continuación. Las opciones de cuerpo **Empty** y **Jira issue data** no incluyen el campo obligatorio `webhookEvent`, por lo que DefectDojo las ignorará. +* El endpoint siempre devuelve HTTP `200`, sin importar si se aplicó una actualización. El éxito o el fracaso solo son visibles en el cuerpo de la respuesta y en los registros de DefectDojo; un `200` en el registro de auditoría de Automation no confirma por sí solo que la actualización llegó a un Hallazgo. + +#### Regla 1 — Issue actualizado + +Cree una regla de Automation con: + +* **Trigger:** *Issue transitioned* (u otro disparador que se active cuando cambien los campos que sincroniza, por ejemplo *Field value changed* en Status). +* **Action:** *Send web request* + * **Web request URL:** `https:///jira/webhook/` + * **HTTP method:** `POST` + * **Web request body:** *Custom data* + * **Headers:** `Content-Type: application/json` + * **Custom data:** + +```json +{ + "webhookEvent": "jira:issue_updated", + "issue": { + "id": "{{issue.id}}", + "fields": { + "updated": "{{issue.updated}}", + "resolution": null, + "status": { "statusCategory": { "key": "{{issue.status.statusCategory.key}}" } }, + "assignee": { "name": "{{issue.assignee.accountId}}", "displayName": "{{issue.assignee.displayName}}" } + } + } +} +``` + +Restricciones para las actualizaciones de issues: + +* `issue.id` debe ser el **ID numérico interno del issue de Jira** (`{{issue.id}}`), no la clave del issue (por ejemplo, `PROJ-123`). DefectDojo relaciona la actualización con un Hallazgo mediante este ID numérico. +* Los campos `resolution` y `updated` deben estar siempre presentes. `resolution` puede ser `null`, pero si falta alguno de los dos campos, la solicitud se acepta (`200`) y no se procesa, sin ningún aviso. +* La sincronización de estado y la auto-mitigación se basan en `status.statusCategory.key`, cuyos valores en Jira son `new` (To Do), `indeterminate` (In Progress) y `done` (Done). Un Hallazgo solo se mitiga cuando el issue está realmente cerrado, no simplemente porque exista un valor de resolution. + +#### Regla 2 — Comentario en un issue + +Cree una segunda regla de Automation con: + +* **Trigger:** *Issue commented* +* **Action:** *Send web request* — misma URL, método, encabezado y opción de cuerpo *Custom data* que en la Regla 1, con este cuerpo: + +```json +{ + "webhookEvent": "comment_created", + "comment": { + "self": "https:///rest/api/2/issue/{{issue.id}}/comment/{{comment.id}}", + "body": "{{comment.body}}", + "updateAuthor": { "name": "{{comment.author.accountId}}", "displayName": "{{comment.author.displayName}}" } + } +} +``` + +Restricciones para los comentarios: + +* Deben estar presentes tanto `body` como `updateAuthor`. +* DefectDojo obtiene el issue de destino a partir de la URL de `comment.self` — específicamente el `` en el segmento `.../issue//comment/...` — por lo que `{{issue.id}}` (el ID numérico) debe aparecer allí. +* **Prevención de bucles:** si el autor del comentario coincide con la cuenta de Jira que usa DefectDojo para publicar sus propios comentarios, DefectDojo omite el comentario para evitar un bucle de eco. Si desea que se ingieran *todos* los comentarios, ejecute la regla de Automation como un usuario de Jira **distinto** del configurado en la instancia de Jira de DefectDojo. + +#### Nota sobre los smart values + +Los smart values mostrados arriba (`{{issue.id}}`, `{{issue.status.statusCategory.key}}`, `{{comment.author.accountId}}`, etc.) son los nombres estándar de Jira Cloud, pero pueden variar entre instancias. Antes de pasar a producción, use la vista previa del payload de Automation para confirmar que cada smart value se resuelve como espera. + +## Cómo probar la integración con Jira + +#### Prueba 1: ¿los Hallazgos se envían correctamente a Jira? + +Para comprobar que la integración con Jira funciona correctamente, puede agregar un nuevo Hallazgo en blanco al Producto asociado con Jira en DefectDojo. **Product \> Findings \> Add New Finding.** + +Agregue el título, la severidad y la descripción que desee, y luego haga clic en "Finished". El Hallazgo debería aparecer como un Issue en Jira con todos los metadatos correspondientes. + +Si los issues de Jira no se están creando correctamente, revise sus notificaciones en busca de códigos de error. + +* Confirme que el usuario de Jira asociado con la configuración de Jira de DefectDojo tenga permisos para crear y actualizar issues en ese espacio de Jira en particular. + +#### Prueba 2: los webhooks de Jira envían datos a DefectDojo + +Para probar los webhooks de Jira, agregue una nota a un Hallazgo que también exista en JIRA como Issue (por ejemplo, el issue de prueba de la sección anterior). + +Si los webhooks están configurados correctamente, debería ver la nota en Jira como un comentario en el issue. + +Si esto no funciona correctamente, podría deberse a un problema de firewall en su instancia de Jira que esté bloqueando el webhook. + +* Las reglas de firewall de DefectDojo incluyen una casilla para **Jira Cloud,** que debe habilitarse antes de que DefectDojo pueda recibir mensajes de webhook desde Jira. + +## Cómo desconectarse de Jira + +Las integraciones con Jira solo pueden eliminarse de su instancia si no se han creado issues relacionados. Si se han creado issues, no hay forma de eliminar por completo una instancia de Jira de DefectDojo. + +Sin embargo, puede desactivar su integración con Jira desactivándola a nivel de Producto. En la página **Jira Project Settings** (accesible desde el menú ⚙️ Gear de un Producto), desmarque el interruptor **Enabled**. Esto no eliminará ni modificará ningún ticket de Jira existente creado por DefectDojo, pero desactivará cualquier actualización futura. + +# Cómo enviar Hallazgos a Jira + +Un Producto con una asignación de JIRA puede enviar Hallazgos a Jira como Issues mediante varios métodos. Puede enviar Hallazgos de forma individual, en bloque, como Grupos de hallazgos o automáticamente. + +## Cómo enviar un solo Hallazgo + +1. Abra el Hallazgo que desea enviar. +2. Haga clic en el **☰ Finding Menu** y seleccione **Push to Jira**. +3. Confirme el envío cuando se le solicite. DefectDojo creará un Issue de Jira y lo vinculará al Hallazgo. + +Una vez creado el Issue, DefectDojo mostrará un enlace al Issue de Jira en la página del Hallazgo. + +![image](images/Creating_Issues_in_Jira_2.png) + +También puede marcar la casilla **Push to Jira** al editar un Hallazgo mediante el formulario **Edit Finding**. Cuando se guarde el Hallazgo, se enviará a Jira. + +### Cómo actualizar un Issue de Jira vinculado + +Si un Hallazgo ya tiene un Issue de Jira vinculado, al volver a seleccionar **Push to Jira** se actualizará el Issue de Jira existente con los cambios realizados en DefectDojo. Si **Push All Issues** está habilitado en el Producto, esta sincronización ocurre automáticamente. + +### Cómo desvincular un Hallazgo de Jira + +Para eliminar la asociación entre un Hallazgo y su Issue de Jira, haga clic en el **☰ Finding Menu** y seleccione **Unlink From Jira**. Esto elimina el vínculo en DefectDojo, pero no elimina el Issue de Jira en sí. + +## Cómo enviar Hallazgos en bloque + +Puede enviar varios Hallazgos a Jira a la vez mediante el formulario Bulk Update: + +1. En una lista de Hallazgos, seleccione los Hallazgos que desea enviar usando las casillas de verificación. +2. Abra el formulario **Bulk Update**. +3. En **Jira Settings**, marque la casilla **Push to Jira**. +4. Haga clic en **Submit**. + +Los Hallazgos seleccionados se pondrán en cola para enviarse a Jira. DefectDojo mostrará un mensaje de confirmación que indica cuántos Hallazgos se pusieron en cola. + +## Cómo enviar Compromisos como Epics + +Si **Enable Engagement Epic Mapping** está activado en Jira Project Settings, puede enviar un Compromiso a Jira como un Epic. Los Hallazgos del Compromiso se enviarán como Child Issues dentro de ese Epic. + +Para enviar un Compromiso como Epic: + +1. Abra el Compromiso que desea enviar. +2. Haga clic en el **☰ Engagement Menu** y seleccione **Push to Jira**. +3. Opcionalmente, proporcione un **Epic Name** (por defecto, el nombre del Compromiso si se deja en blanco) y una **Epic Priority**. +4. Marque **Push to Jira (Create Epic)** y envíe el formulario. + +## Cómo enviar Grupos de hallazgos como Issues de Jira + +Si tiene habilitados los Grupos de hallazgos, puede enviar un Grupo de Hallazgos a Jira como un único Issue en lugar de Issues separados para cada Hallazgo. + +Para enviar un Grupo de hallazgos: + +1. Abra el Grupo de hallazgos. +2. Haga clic en el **☰ Finding Group Menu** y seleccione **Push to Jira**, o marque la casilla **Push to Jira** al editar el Grupo de hallazgos. + +Si es necesario eliminarlo, el Issue de Jira asociado con un Grupo de hallazgos debe eliminarse directamente desde la instancia de Jira. + +### Cómo crear y enviar Grupos de hallazgos automáticamente + +Con **Push All Issues** habilitado en el Producto, y una opción **Group By** seleccionada durante la importación: + +Siempre que los Grupos de hallazgos se creen correctamente, será el Grupo de hallazgos el que se envíe automáticamente a Jira como Issue, y no los Hallazgos individuales. + +![image](images/Creating_Issues_in_Jira_4.png) + +## Comportamiento del envío automático + +DefectDojo puede enviar Hallazgos y actualizaciones a Jira automáticamente en varios escenarios: + +### Push All Issues + +Cuando la opción **Push All Issues** está habilitada en Jira Project Settings de un Producto, DefectDojo creará automáticamente Issues de Jira para todos los Hallazgos Activos y Verificados. Esto incluye los Hallazgos creados mediante la importación de escaneos. Una vez creado un Issue de Jira, seguirá sincronizándose con DefectDojo aunque cambie el estado del Hallazgo. + +### Sincronización automática ante cambios de estado + +Cuando **Push All Issues** o la opción de nivel de sistema **Finding Jira Sync** está habilitada, DefectDojo actualizará automáticamente los Issues de Jira vinculados al realizar ciertas acciones sobre los Hallazgos: + +* **Request Review** \- Se agrega un comentario al Issue de Jira vinculado (o al Issue de Jira del Grupo de hallazgos, si el Hallazgo pertenece a un grupo). +* **Clear Review** \- Se agrega un comentario al Issue de Jira vinculado. +* **Close Finding** \- El Issue de Jira vinculado se actualiza para reflejar el cierre. Si **Push Notes** está habilitado, también se agrega un comentario. + +## Comentarios y notas de Jira + +Cuando **Push Notes** está habilitado en Jira Project Settings: + +* Si se agrega un comentario a un Issue de Jira, el mismo comentario se agregará al Hallazgo, en la sección **Notes**. +* Del mismo modo, si se agrega una nota a un Hallazgo, la nota se agregará al issue de Jira como un comentario. + +## Cambios de estado en Jira + +La configuración de la instancia de Jira incluye entradas para dos Transiciones de Jira que activarán un cambio de estado en un Hallazgo. + +* Cuando se realiza la **'Close' Transition** en Jira, el Hallazgo asociado también se cerrará y se marcará como **Inactivo** y **Mitigado** en DefectDojo. DefectDojo registrará este cambio en la página del Hallazgo, bajo el encabezado **Mitigated By**. +​ +![image](images/Creating_Issues_in_Jira_3.png) + +* Cuando se realiza la **'Reopen' Transition** en el Issue de Jira, el Hallazgo asociado se establecerá como **Activo** en DefectDojo y perderá su estado **Mitigado**. + +## Cómo asignar resoluciones de Jira a Riesgo aceptado / Falso positivo + +La configuración de la instancia de Jira incluye dos campos opcionales que permiten asignar una **Resolution** de Jira a un estado de Hallazgo de DefectDojo: + +* **Risk Accepted Finding Mapping Resolution** — cuando un issue de Jira se cierra con esta Resolution, el Hallazgo vinculado pasa a Riesgo aceptado en DefectDojo. +* **False Positive Finding Mapping Resolution** — cuando un issue de Jira se cierra con esta Resolution, el Hallazgo vinculado pasa a Falso positivo en DefectDojo. + +### Status frente a Resolution: una fuente habitual de confusión + +Estos campos asignan la **Resolution** de Jira, no el **Status** de Jira. Status y Resolution son dos conceptos independientes en Jira: Status describe en qué punto del flujo de trabajo se encuentra el issue (Open, In Progress, Done), mientras que Resolution describe cómo se resolvió (Fixed, Won't Do, Duplicate, False Positive, etc.). + +### Requisito previo: una post-function "Set issue resolution" en la transición del flujo de trabajo de Jira + +El motor de flujo de trabajo de Jira no completa el campo Resolution automáticamente. Cada transición que deba cerrar un issue con una Resolution específica necesita una post-function **Set issue resolution** configurada en la propia transición. Sin esa post-function, el issue pasa al nuevo Status, pero Resolution permanece en blanco, y la asignación de DefectDojo no tiene nada con qué coincidir. + +Un administrador de Jira puede agregar esta post-function desde **Project Settings → Workflows → (edit workflow) → (select the closing transition) → Post Functions → Add post function → Set issue resolution**. + +# Campos personalizados en Jira + +Actualmente, DefectDojo no admite pasar información específica del Issue a estos Custom Fields \- estos campos deberán actualizarse manualmente en Jira después de crear el issue. Cada Custom Field solo se creará desde DefectDojo con un valor predeterminado. + + Jira Cloud ahora le permite crear un valor predeterminado para un Custom Field directamente desde la aplicación. [Consulte la documentación de Atlassian sobre Custom Fields](https://support.atlassian.com/jira-cloud-administration/docs/configure-a-custom-field/) para obtener más información sobre cómo configurarlo. + +Los Jira Issue Types integrados de DefectDojo (**Bug, Task, Story** y **Epic)** están configurados para funcionar "de fábrica". Los campos de datos de DefectDojo se asignarán automáticamente a los campos correspondientes en Jira. De forma predeterminada, DefectDojo asignará Priority, Labels y un Reporter a cualquier Issue nuevo que cree. + +Algunas configuraciones de Jira requieren tener en cuenta campos personalizados adicionales antes de poder crear un issue. Este proceso le permitirá tener en cuenta estos campos personalizados en su integración DefectDojo \-\> Jira, garantizando que los issues se creen correctamente. Estos campos personalizados se agregarán a todas las llamadas a la API enviadas desde DefectDojo a una instancia de Jira vinculada. + +Si aún no utiliza Custom Fields en Jira, no es necesario seguir este proceso. + +1. Registrar los nombres de sus Custom Fields en Jira (**Jira UI**) +2. Determinar los valores de Key para los nuevos Custom Fields (Jira Field Spec Endpoint) +3. Localizar los datos aceptables para cada Custom Field, usando los valores de Key como referencia (Jira Issue Endpoint) +4. Crear un bloque JSON de referencia de campos para registrar todas las Keys de Custom Fields y los datos aceptables (Jira Issue Endpoint) +5. Guardar el bloque JSON en el Producto de DefectDojo asociado, para permitir que los Custom Fields se creen desde Jira (DefectDojo UI) +6. Probar su trabajo y asegurarse de que todos los datos requeridos fluyan correctamente desde Jira + +#### Paso 1: registrar los nombres de sus Custom Fields en Jira + +Jira admite una variedad de Context Fields diferentes, incluidos Date Pickers, Custom Labels y Radio Buttons. Cada uno de estos Context Fields tendrá un valor de Key diferente que se puede encontrar en la API de Jira. + +Anote los nombres de cada Custom Field requerido, ya que deberá buscarlos en la API de Jira en el siguiente paso. + +**Ejemplo de una lista de Custom Fields (los nombres de sus Custom Fields serán diferentes):** + +* DefectDojo Custom URL Field +* Another example of a Custom Field +* ... + +#### Paso 2: encontrar los valores de Key de sus Custom Fields de Jira + +Comience este proceso navegando a la URL de Field Spec de toda su instancia de Jira. + +Aquí tiene un ejemplo de una URL de Field Spec: + +`https://yourcompany-example.atlassian.net/rest/api/2/field` + +La API devolverá una larga cadena de JSON, que debe formatearse como texto legible (usando un editor de código, una extensión de navegador o ). + +El JSON devuelto desde esta URL contendrá todos sus custom fields de Jira, la mayoría de los cuales son irrelevantes para DefectDojo y tienen valores de `"Null"`. Cada objeto de esta respuesta de la API corresponde a un campo distinto en Jira. Deberá buscar los objetos cuyo atributo `"name"` coincida con los nombres de cada Custom Field que creó en la Jira UI, y luego anotar el valor de su atributo "key". + +![image](images/Using_Custom_Fields.png) + +Una vez que haya encontrado el objeto correspondiente en la salida JSON, podrá determinar el valor de "key" \- en este caso, es `customfield_10050`. + +Jira genera valores de key diferentes para cada Custom Field, pero estos valores de key no cambian una vez creados. Si crea otro Custom Field en el futuro, tendrá un nuevo valor de key. + +**Ampliando nuestra lista de Custom Fields:** + +* "DefectDojo Custom URL Field" \= customfield\_10050 +* "Another example of a Custom Field" \= customfield\_12345 +* ... + +#### Paso 3 \- encontrar los Custom Fields en un Issue de Jira + +Localice un Issue en Jira que contenga los Custom Fields que registró en el Paso 2\. Copie la Issue Key del título (debería verse similar a "`EXAMPLE-123`") y navegue a la siguiente URL: + +`https://yourcompany-example.atlassian.net/rest/api/2/issue/EXAMPLE-123` + +Esto devolverá otra cadena de JSON. + +Como antes, la salida de la API contendrá muchos parámetros de objeto `customfield_##` con valores `null` \- estos son custom fields que Jira agrega de forma predeterminada, que no son relevantes para este issue. También contendrá valores `customfield_##` que coinciden con los valores de Key de Custom Field que encontró en el paso anterior. A diferencia de la salida de Field Spec, no verá nombres que identifiquen a ninguno de estos custom fields, por lo que necesitaba registrar los valores de key en el Paso 2\. + +![image](images/Using_Custom_Fields_2.png) + +**Ejemplo:** +Sabemos que `customfield_10050` representa el DefectDojo Custom URL Field porque lo registramos en el Paso 2\. Ahora podemos ver que `customfield_10050` contiene un valor de `"https://google.com"` en el issue `EXAMPLE-123`. + +#### Paso 4 \- crear una referencia de campos JSON a partir de cada Key de Custom Field de Jira + +Ahora deberá tomar el valor de cada uno de los Custom Fields de su lista y guardarlos en un objeto JSON (para usarlo como referencia). Puede ignorar cualquier Custom Field que no corresponda a su lista. + +Este objeto JSON contendrá todos los valores predeterminados para los nuevos Issues de Jira. Recomendamos usar nombres que su equipo pueda reconocer fácilmente como valores 'predeterminados' que deben cambiarse: '`change-me.com`', '`Change this paragraph.`' etc. + +**Ejemplo:** + +Del paso 3, ahora sabemos que Jira espera una cadena de URL para "`customfield_10050`". Podemos usar esto para construir nuestro objeto JSON de ejemplo. + +Supongamos que también hemos localizado un campo de texto corto relacionado con DefectDojo, que identificamos como "`customfield_67890`". Buscaríamos este campo en nuestra segunda salida de la API, veríamos el valor asociado y también haríamos referencia al valor guardado en nuestro objeto JSON de ejemplo. +​ +Su objeto JSON comenzará a verse así a medida que agregue más Custom Fields. + +``` +{ + "customfield_10050": "https://change-me.com", + "customfield_67890": "This is the short text custom field." +} +``` + +Repita este proceso hasta que se hayan agregado a su referencia de campos JSON todos los custom fields de Jira relevantes para DefectDojo. + +#### Tipos de datos y sintaxis de Jira + +Algunos campos, como los campos de fecha, pueden relacionarse con varios custom fields en Jira. Si es así, deberá agregar ambos campos a su referencia de campos JSON. + +``` + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", +``` + +Otros campos, como el campo Label, pueden registrarse como una lista de cadenas \- asegúrese de que su referencia de campos JSON use un formato que coincida con la salida de la API de Jira. + +``` +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], +``` + +Otros custom fields pueden contener información contextual adicional que debe eliminarse de la referencia de campos. Por ejemplo, el Custom Multichoice Field contiene un bloque adicional en la salida de la API, que deberá eliminar, ya que ese bloque almacena el valor actual del campo. + +* debe eliminar el objeto adicional de este campo: + +``` +"customfield_10047": [ + { + "value": "A" + }, + { + "self": "example.url...", + "value": "C", + "id": "example ID" + } +] +``` +* en su lugar, puede acortarlo de la siguiente manera y descartar la segunda parte: + +``` +"customfield_10047": [ + { + "value": "A" + } +] +``` + +#### Ejemplo de referencia de campos completa + +Aquí tiene una referencia de campos JSON completa, con comentarios en línea que explican a qué corresponde cada custom field. Esto pretende ser un ejemplo integral. Su JSON contendrá valores de key y datos diferentes según los Custom Values que desee usar durante la creación del issue. + +``` +{ + "customfield_10050": "https://change-me.com", + + "customfield_10049": "This is a short text custom field", + +// two different fields, but both correspond to the same custom date attribute + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", + +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], + +// custom number field + "customfield_10043": 0, + +// custom paragraph field + "customfield_10044": "This is a very long winded way to say CHANGE ME PLEASE", + +// custom radio button field + "customfield_10045": { + "value": "radio button option" + }, + +// custom multichoice field + "customfield_10047": [ + { + "value": "A" + } + ], + +// custom checkbox field + "customfield_10039": [ + { + "value": "A" + } + ], + +// custom select list (singlechoice) field + "customfield_10048": { + "value": "1" + } +} +``` + +#### Paso 5 \- agregar los Custom Fields a un Producto de DefectDojo + +Ahora puede agregar estos custom fields al Producto de DefectDojo asociado, en la página Jira Project Settings (accesible desde el menú ⚙️ Gear del Producto). Pegue la referencia de campos JSON como texto sin formato en el cuadro **Custom Fields** y guarde. + +#### Paso 6 \- probar sus Custom Fields de Jira desde un nuevo Hallazgo: + +Ahora, cuando cree un nuevo Hallazgo en el Producto asociado con Jira, Jira creará automáticamente todos estos Custom Fields según el bloque JSON contenido allí. Estos Custom Fields se crearán con los valores predeterminados ("change\-me\-please", etc.). + +Dentro del Producto en DefectDojo, navegue a la página Findings \> Add New Finding. Asegúrese de que el Hallazgo esté tanto Activo como Verificado para garantizar que se envíe a Jira, y luego confirme del lado de Jira que los Custom Fields se crearon correctamente sin inconsistencias. diff --git a/docs/content/connectors/downstream/PRO__jira_guide.fr.md b/docs/content/connectors/downstream/PRO__jira_guide.fr.md new file mode 100644 index 00000000000..bfd47038713 --- /dev/null +++ b/docs/content/connectors/downstream/PRO__jira_guide.fr.md @@ -0,0 +1,786 @@ +--- +title: Jira (historique) +description: Travailler avec l'intégration Jira +weight: 1 +audience: pro +aliases: +- /fr/issue_tracking/jira/pro__jira_guide/ +- /fr/en/share_your_findings/jira_guide +--- + +> **Cette page documente l'intégration Jira historique.** L'intégration Jira par produit décrite ici a été remplacée par le **[Connecteur Downstream Jira](/connectors/downstream/about/)**, qui est disponible en version généralement disponible sur toutes les instances DefectDojo Pro et constitue la méthode recommandée pour transmettre les Constatations à Jira. Dans la barre latérale Pro, **Connect > Jira** porte pour cette raison un badge `LEGACY` — voir [Badges de menu](/navigation/pro__menu_badges/). +> +> **Si vous configurez Jira pour la première fois, commencez par le [Connecteur Downstream](/connectors/downstream/about/) plutôt que par ce guide.** +> +> **Vous utilisez déjà l'intégration historique ?** DefectDojo Pro inclut une migration intégrée qui transfère votre configuration Jira classique existante vers les Connecteurs Downstream, y compris les tickets déjà transmis — voir [Migrer vers le connecteur Downstream Jira](#migrating-to-the-jira-downstream-connector) ci-dessous. +> +> L'intégration historique continue de fonctionner, et ce guide reste valable pour celle-ci. + +L'intégration Jira de DefectDojo permet de transmettre les données de Constatations à un ou plusieurs espaces Jira. Cela vous permet d'intégrer DefectDojo à votre flux de développement standard. Voici quelques exemples de fonctionnement possible : + +* L'équipe AppSec peut transmettre sélectivement des Constatations à un espace Jira utilisé par les développeurs, afin que la résolution des tickets puisse être hiérarchisée de manière appropriée aux côtés du développement habituel. Les développeurs présents sur ce tableau n'ont pas besoin d'accéder à DefectDojo : ils peuvent conserver tout leur travail au même endroit. +* DefectDojo peut transmettre TOUTES les Constatations à un espace Jira bidirectionnel utilisé par l'équipe AppSec, ce qui lui permet de répartir la validation des tickets. Ce tableau reste synchronisé avec DefectDojo et permet des flux de résolution complexes. +* DefectDojo peut transmettre sélectivement des Constatations provenant de Produits et/ou d'Engagements distincts vers des espaces Jira distincts, afin de conserver chaque élément dans son contexte propre. + +## Migration vers le connecteur Downstream Jira + +DefectDojo Pro peut convertir pour vous une configuration Jira classique existante en configuration de Connecteur Downstream, plutôt que de vous obliger à la reconstruire manuellement. + +**Où le trouver :** accédez à **Connect \> Downstream** pour ouvrir la page **Downstream Connectors**, puis utilisez la carte **Classic Jira Migration**. Cliquez sur **Migrate from classic Jira**, puis confirmez. + +La carte n'apparaît que s'il existe une configuration Jira classique à migrer, ou une exécution précédente à signaler — une instance n'ayant jamais utilisé Jira classique ne la verra donc pas. Une fois que tout a été migré, la carte reste visible mais le bouton est désactivé, car il n'y a plus rien à faire. + +L'exécution de la migration nécessite des **permissions globales de niveau Maintainer** (plus précisément, la permission de modifier les intégrations), et elle doit être lancée depuis une session de navigateur connectée — elle ne peut pas être déclenchée via un jeton API. + +### Que deviennent les tickets déjà transmis + +**Vos tickets Jira existants sont conservés et reliés à nouveau — ils ne se retrouvent pas orphelins, et le connecteur n'ouvre pas de doublons.** Chaque Constatation déjà transmise par Jira classique conserve son ticket, et le connecteur prend le relais pour mettre à jour ce même ticket en place. Les liens sur les groupes de Constatations sont conservés de la même manière. + +La seule exception concerne les **epics d'Engagement**. Le Connecteur Downstream n'a pas de notion d'epic ; les tickets epic sont donc signalés dans les avertissements de la migration et laissés tels quels. + +### Ce qui est migré + +* Votre connexion d'**instance** Jira — URL et identifiants — devient une instance d'intégration de Connecteur Downstream, en conservant son nom. +* Les **mappages de sévérité** et les **mappages de statut** (vos clés de transition d'ouverture et de fermeture) sont transférés. +* Chaque configuration de **Jira Project** devient un mappage de suivi de tickets, en conservant sa clé de projet et son type de ticket, et reste associée au même Produit ou Engagement. +* **Push All Issues** est conservé : les projets qui l'avaient activé continuent de transmettre automatiquement. +* Les **champs personnalisés**, les **champs de transition de fermeture/réouverture**, le **composant**, l'**assigné par défaut** et les **étiquettes** sont convertis en mappages de champs. Si vous utilisiez *Add Vulnerability Id as a Jira label*, cela devient également un mappage d'étiquette. +* Un répertoire de **modèle de ticket personnalisé** devient un modèle de ticket. Les modèles standard ne sont pas copiés, car le connecteur fournit déjà des équivalents. + +### Ce qui n'est pas transféré + +Ces éléments sont signalés sous forme d'avertissements lors de l'exécution de la migration — ils ne l'interrompent pas. Recherchez la liste *"things the connector cannot carry over"* dans les résultats. + +* **La synchronisation inverse Jira → DefectDojo.** C'est le point le plus important. Le Connecteur Downstream ne synchronise pas les changements *en provenance* de Jira, si bien que les mappages de résolution qui appliquent le statut Risque accepté ou Faux positif à partir d'une résolution Jira ne sont pas migrés. **Si vous dépendez de la synchronisation inverse, laissez l'instance Jira classique configurée** — la migration ne la supprime pas. +* **Engagement Epic Mapping** — le connecteur n'a pas de notion d'epic. +* **Push Notes**, les **commentaires de notification SLA** et les **commentaires d'expiration d'acceptation du risque** — le connecteur ne les publie pas dans Jira. +* Les champs personnalisés nommés `summary`, `description`, `project`, `issuetype` ou `status` — ils sont réservés par le connecteur, et tout mappage de champ qui en utilise un est ignoré. +* Les valeurs de champ personnalisé de plus de 512 caractères — ignorées plutôt que tronquées. +* Un Jira Project qui n'est rattaché ni à un Produit ni à un Engagement ne produit aucune association. + +### Que devient l'intégration classique par la suite + +**Rien n'est transmis deux fois.** Pour chaque projet qu'elle migre, la migration désactive le projet Jira classique, de sorte que seul le connecteur transmet des données à partir de ce moment. Vous n'avez rien à désactiver manuellement. + +Votre configuration classique est **conservée, et non supprimée** — l'instance, le projet et les enregistrements de tickets restent tous en place, seuls les paramètres de transmission sont désactivés. Ceci est délibéré : c'est ce qui rend le changement réversible, et ce qui permet à la synchronisation inverse de continuer à fonctionner si vous en dépendez. + +**Pour revenir en arrière**, réactivez les paramètres du projet Jira classique et supprimez la configuration de connecteur créée par la migration. Il n'existe pas d'annulation en un clic. + +**Relancer la migration est sans risque.** Elle enregistre ce qu'elle a déjà converti et l'ignore lors d'une seconde exécution, de sorte que rien n'est dupliqué. Si un projet ou une instance échoue, le reste de la migration se poursuit — un projet en échec reste actif sur l'intégration classique plutôt que d'être désactivé, afin de continuer à fonctionner pendant que vous investiguez. + +### Pendant l'exécution + +La migration s'exécute en arrière-plan et signale sa progression au fur et à mesure. À la fin, vous obtenez un résumé — le nombre de connecteurs, de mappages, d'associations, de modèles et de liens de tickets créés, le nombre de projets classiques désactivés, et tout ce qui a été ignoré — accompagné des avertissements décrits ci-dessus. Une seule migration s'exécute à la fois. + +# Configuration de Jira + +La configuration de Jira nécessite les étapes suivantes : +1. Activez l'intégration Jira dans les Paramètres système. Tant que ce n'est pas fait, le reste des paramètres Jira reste masqué dans DefectDojo. +2. Connectez une instance Jira, avec un nom d'utilisateur / mot de passe ou un jeton API. Plusieurs instances peuvent être liées. +3. Ajoutez cette instance Jira à un ou plusieurs Produits ou Engagements dans DefectDojo. +4. Si vous souhaitez utiliser la synchronisation bidirectionnelle, créez un Webhook Jira qui enverra les mises à jour à DefectDojo. + +## Étape 1 : activer l'intégration Jira dans les paramètres système + +L'intégration Jira est désactivée par défaut, et tant qu'elle l'est, DefectDojo masque tous les autres contrôles Jira de l'interface. C'est la première chose à configurer : aucune des étapes ci-dessous n'est disponible tant qu'elle n'est pas activée. + +Tant que l'intégration est désactivée, il n'y a pas d'entrée **Jira Instances** dans la barre latérale, il n'y a donc aucun endroit où ajouter une instance Jira : + +![image](images/jira-menu-hidden-pro.png) + +### Activer l'intégration + +1. Accédez à **Settings \> System \> System Settings** depuis la barre latérale de DefectDojo. Sur les instances utilisant encore l'ancienne disposition de menu, cela se trouve sous un groupe nommé d'après votre offre de licence — **Pro Settings** ou **Enterprise Settings**. Voir [Le menu Paramètres](/navigation/pro__settings_menu/). +​ +2. Dans la section **Jira Integration Settings**, cochez **Enable Jira Integration**. +​ +3. Cliquez sur **Submit**. **Jira Instances** apparaît immédiatement dans la barre latérale, sans recharger la page : + +![image](images/jira-enable-system-settings-pro.png) + +### Ce que contrôle ce paramètre + +Activer **Enable Jira Integration** est ce qui fait apparaître le reste de l'interface Jira. Une fois activé, vous obtenez : + +* le menu **Jira Instances**, où les instances Jira sont ajoutées et modifiées +* la page **Jira Project Settings** dans le menu ⚙️ de l'Asset, et les paramètres Jira sur les Engagements +* les actions **Push to Jira** sur les Constatations et les groupes de Constatations, les champs Jira sur les formulaires de Constatation et d'édition en masse, et les colonnes Jira sur les listes Asset, Engagement, Constatation et Groupe de Constatations (y compris les exports CSV) + +Ce paramètre contrôle également l'intégration en dehors de l'interface utilisateur : tant qu'il est désactivé, DefectDojo ne transmet pas les Constatations à Jira (y compris les requêtes `push_to_jira` envoyées via l'API), et les webhooks Jira entrants sont ignorés. + +Les champs Jira restants dans **Jira Integration Settings** (**Add Vulnerability ID as Jira Label**, **Enable Jira Web Hook**, **Disable Jira Web Hook Secret**, **Jira Web Hook Secret**, **Jira Minimum Severity**) restent visibles que l'intégration soit activée ou non, mais ils n'ont aucun effet tant qu'elle n'est pas activée. + +## Étape 2 : connecter une instance Jira + +Une fois l'intégration activée, la connexion d'une instance Jira est l'étape suivante de la configuration de l'intégration Jira de DefectDojo. Notez que Jira Service Management n'est actuellement pas pris en charge. + +#### Informations requises depuis Jira + +Atlassian utilise des méthodes d'authentification différentes entre Jira Cloud et Jira Data Center. + +pour **Jira Cloud**, vous aurez besoin de : +* une URL Jira, par ex. https://yourcompany.atlassian.net/ +* un compte disposant des permissions nécessaires pour créer et mettre à jour des tickets dans votre instance Jira. Cela peut être : + * Une combinaison standard **nom d'utilisateur / mot de passe** + * Une combinaison **nom d'utilisateur / jeton API** + +pour **Jira Data Center (ou Server)**, vous aurez besoin de : +* une URL Jira, par ex. https://jira.yourcompany.com +* un compte disposant des permissions nécessaires pour créer et mettre à jour des tickets dans votre instance Jira. Cela peut être : + * Une combinaison standard **nom d'utilisateur / mot de passe** + * Une combinaison **adresse e-mail / jeton d'accès personnel** + +Vous pouvez éventuellement mapper : +* Les transitions Jira pour déclencher la réouverture et la fermeture des Constatations +* Les résolutions Jira pouvant appliquer les statuts Risque accepté et Faux positif aux Constatations (optionnel) + +Une seule connexion d'instance Jira peut gérer plusieurs espaces Jira, tant que le compte / jeton Jira utilisé par DefectDojo dispose de la permission de créer des tickets dans l'espace Jira associé. + +### Ajouter une instance Jira + +1. Assurez-vous que **Enable Jira Integration** est coché dans les Paramètres système, comme décrit à l'[Étape 1](#step-1-enable-the-jira-integration-in-system-settings). Le menu **Jira Instances** n'apparaît dans la barre latérale que lorsque c'est le cas. + +2. Accédez à la page **Enterprise Settings \> Jira Instances \> + New Jira Instance** depuis la barre latérale de DefectDojo. + +![image](images/jira-instance-beta.png) + +3. Sélectionnez un **Configuration Name** pour cette instance Jira à utiliser dans DefectDojo. Ce nom est simplement une étiquette pour la connexion d'instance dans DefectDojo, et n'a pas besoin d'être lié à des données Jira. + +4. Sélectionnez l'URL de l'instance Jira de votre entreprise \- probablement similaire à `https://**yourcompany**.atlassian.net` si vous utilisez une installation Jira Cloud. + +5. Saisissez une méthode d'authentification appropriée dans les champs Nom d'utilisateur / Mot de passe pour Jira : + * Pour une **authentification Jira standard par nom d'utilisateur / mot de passe**, saisissez un nom d'utilisateur Jira et le mot de passe correspondant dans ces champs. + * Pour une authentification avec le **jeton API d'un utilisateur (Jira Cloud)**, saisissez le nom d'utilisateur avec le **jeton API** correspondant dans le champ mot de passe. + * Pour une authentification avec un **jeton d'accès personnel Jira (PAT, utilisé uniquement avec Jira Data Center et Jira Server)**, saisissez le PAT dans le champ mot de passe. Le nom d'utilisateur n'est pas utilisé pour l'authentification avec un PAT Jira, mais le champ reste obligatoire dans ce formulaire ; vous pouvez donc y saisir une valeur de substitution pour identifier votre PAT. + +Notez que l'utilisateur associé à cette connexion doit disposer de la permission de créer des tickets et d'accéder aux données de votre instance Jira. + +6. Vous devrez fournir des valeurs pour Epic Name ID, Re-open Transition ID et Close Transition ID. Ces valeurs peuvent être modifiées ultérieurement. Une fois connecté à Jira, vous pouvez récupérer ces valeurs à partir des URL suivantes : +- **Epic Name ID** : accédez à `https:///rest/api/2/field` et recherchez Epic Name. Copiez le nombre présent dans `number` et collez-le ici. Si vous n'avez pas d'Epic Name ID associé à votre espace dans Jira (par exemple parce que vous utilisez un espace géré par l'équipe), saisissez 0 dans ce champ. +- **Re-open Transition ID** : accédez à `https:///rest/api/latest/issue//transitions?expand-transitions.fields` pour trouver l'ID correspondant à votre instance Jira. Collez-le dans le champ Reopen Transition ID. +- **Close Transition ID** : accédez à `https:///rest/api/latest/issue//transitions?expand-transitions.fields` pour trouver l'ID correspondant à votre instance Jira. Collez-le dans le champ Close Transition ID. + +7. Sélectionnez le type de ticket par défaut que vous souhaitez utiliser pour créer des tickets dans Jira. Les options disponibles sont **Bug, Task, Story** et **Epic** (types de ticket Jira standard), ainsi que **Spike** et **Security**, qui sont des types de ticket personnalisés. Si vous souhaitez utiliser un type de ticket différent, contactez [support@defectdojo.com](mailto:support@defectdojo.com) pour obtenir de l'aide. + +8. Sélectionnez votre modèle de ticket (Issue Template), qui déterminera la description du ticket lors de la création des tickets dans Jira. + +Les deux types sont : +- **Jira\_full**, qui inclut toutes les informations de la Constatation dans les tickets Jira +- **Jira\_limited**, qui inclut une quantité réduite d'informations et de métadonnées de la Constatation. + +Si vous laissez ce champ vide, la valeur par défaut sera **Jira\_full.** Si vous avez besoin d'un autre type de modèle, contactez [support@defectdojo.com](mailto:support@defectdojo.com). + +9. Si vous le souhaitez, saisissez le nom d'une résolution Jira qui changera le statut d'une Constatation en Risque accepté ou en Faux positif (lorsque la résolution est déclenchée sur le ticket). + +Le formulaire peut être soumis à partir d'ici. Si vous le souhaitez, vous pouvez personnaliser davantage votre intégration Jira dans Optional Fields. Cliquer sur ce bouton vous permettra d'appliquer du texte générique aux tickets Jira ou de modifier le mappage des Jira Severity Mappings. + +## Étape 3 : connecter un Produit ou un Engagement à Jira + +Chaque Produit ou Engagement dans DefectDojo dispose de ses propres paramètres qui déterminent comment les Constatations sont converties en tickets JIRA. Depuis cet écran, vous pouvez choisir l'espace Jira associé et définir le comportement par défaut pour la création des tickets, des epics, des étiquettes et d'autres métadonnées JIRA. + +### Ajouter Jira à un Produit + +Vous pouvez trouver cette page en cliquant sur le menu ⚙️ (Gear) d'un Produit et en ouvrant la page **Jira Project Settings**. + +![image](images/jira-project-settings.png) + +#### Instance Jira + +Si vous avez configuré plusieurs instances de Jira, pour des produits ou des équipes distincts au sein de votre organisation, vous pouvez indiquer dans quel espace Jira vous souhaitez que DefectDojo crée des tickets. Sélectionnez un espace dans le menu déroulant. + +Si ce menu ne liste aucune instance Jira, vérifiez que ces espaces sont connectés dans votre configuration Jira globale pour DefectDojo \- yourcompany.defectdojo.com/jira. + +#### Clé de projet + +Il s'agit de la clé de l'espace que vous souhaitez utiliser avec DefectDojo. La Space Key d'un espace donné se trouve dans l'URL. (Ceci était auparavant appelé **Jira Project Key**, mais depuis septembre 2025, Jira l'appelle désormais **Space Key**). + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_3.png) + +#### Nom du type de ticket Epic + +Le nom du type de ticket Epic dans Jira. La valeur par défaut est "Epic", mais elle peut être modifiée si votre instance Jira utilise un nom différent. + +#### Modèle de ticket + +Vous pouvez ici déterminer la quantité de métadonnées DefectDojo que vous souhaitez envoyer à Jira. Sélectionnez l'une des deux options : + +* **jira\_full** : les tickets suivront tous les paramètres de DefectDojo \- une Description complète, le CVE, la Sévérité, etc. Utile si vous avez besoin du contexte complet de la Constatation dans Jira (par exemple, si une personne travaillant sur ce ticket n'a pas accès à DefectDojo). + +Voici un exemple de ticket **jira\_full** : +​ +![image](images/Add_a_Connected_Jira_Project_to_a_Product_4.png) + +* **Jira\_limited :** les tickets ne suivront que le lien DefectDojo, les liens Produit/Engagement/Test, ainsi que les champs Reporter et Environment. Tous les autres champs sont suivis uniquement dans DefectDojo. Utile si vous n'avez pas besoin du contexte complet de la Constatation dans Jira (par exemple, si une personne travaillant sur ce ticket travaille principalement dans DefectDojo et n'a pas besoin d'avoir également la vue complète dans JIRA.) + +​Voici un exemple de ticket **jira\_limited** : + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_5.png) + +#### Composant + +Si vous gérez votre espace Jira à l'aide de Components, vous pouvez lui attribuer ici le Component approprié pour DefectDojo. Pour attribuer plusieurs Components, saisissez une liste séparée par des virgules (par exemple, `Security, DevSecOps`) ; chaque valeur est envoyée à Jira comme un composant distinct. + +#### Champs personnalisés + +Si vous n'avez pas besoin d'utiliser de champs personnalisés avec les tickets DefectDojo, vous pouvez laisser ce champ à 'null'. + +Cependant, si les paramètres de votre espace Jira **vous obligent** à utiliser des champs personnalisés sur les nouveaux tickets, vous devrez coder ces mappages en dur. + +Notez que DefectDojo ne peut pas envoyer de métadonnées spécifiques à un ticket en tant que champs personnalisés, seulement une valeur par défaut. Cette section ne doit être configurée que si votre espace Jira **exige que ces champs personnalisés existent** dans chaque ticket de votre espace. + +Suivez **[ce guide](#custom-fields-in-jira)** pour commencer à travailler avec les champs personnalisés. + +#### Champs de transition de fermeture / réouverture + +Certains workflows Jira **exigent** que certains champs soient renseignés dans le cadre d'une transition — par exemple, un workflow qui refuse de fermer un ticket tant qu'un champ Resolution et un champ Justification ne sont pas renseignés sur l'écran de fermeture. Le paramètre Champs personnalisés ci-dessus ne s'applique que lors de la *création* d'un ticket, il ne peut donc pas satisfaire ces workflows. + +Sans ces paramètres, DefectDojo envoie les transitions de fermeture / réouverture sans aucun champ. Un workflow qui exige des champs rejettera cette transition, et la Constatation et le ticket Jira se désynchronisent : la Constatation apparaît comme Atténuée dans DefectDojo alors que le ticket reste ouvert dans Jira. + +Les paramètres **Close Transition fields** et **Reopen Transition fields** acceptent un objet JSON envoyé comme charge utile `fields` de l'appel de transition de fermeture / réouverture. Par exemple, pour fermer des tickets avec une Resolution *Won't Fix* et une valeur de justification : + +```json +{ + "resolution": {"name": "Won't Fix"}, + "customfield_10200": "Risk accepted by security team #report-false-positive" +} +``` + +Laissez ces paramètres à 'null' si votre workflow Jira n'exige pas de champs sur les transitions. + +**De quels champs avez-vous besoin ?** + +* Demandez à votre administrateur Jira quels champs figurent sur les **écrans de transition** de fermeture / réouverture, et lesquels sont imposés par un validateur. Le JSON configuré doit satisfaire **tous** les champs requis : si un champ requis est absent de la charge utile, Jira rejette l'intégralité de la transition et ne définit rien — fournir seulement une partie des champs requis ne suffit pas. +* À l'inverse, les champs doivent être présents **sur l'écran de transition** pour pouvoir être envoyés : Jira rejette les transitions qui tentent de définir des champs absents de l'écran de cette transition. +* Sur les workflows créés avec l'éditeur de workflow actuel de Jira Cloud, Jira renseigne automatiquement la Resolution par défaut du site lorsqu'un ticket passe à un statut de catégorie "terminé". Ainsi, une Resolution requise ne bloquera pas à elle seule une transition simple dans ce cas, et l'utilité pratique de `"resolution"` dans cette charge utile est de choisir une valeur *significative* (par exemple *False Positive*) plutôt que la valeur par défaut du site. Les workflows créés avec l'éditeur classique, ou avec des applications de validation du marketplace, peuvent quant à eux exiger la Resolution de manière stricte. +* Les transitions de réouverture réinitialisent généralement la Resolution via le workflow lui-même, donc **Reopen Transition fields** n'a en général besoin que des champs personnalisés exigés par votre workflow. + +**Notes :** + +* Le même JSON est envoyé pour *chaque* transition de fermeture (ou de réouverture) du Produit ou de l'Engagement — les valeurs sont statiques et ne varient pas selon la Constatation. Si vous avez besoin de champs différents selon la disposition (par exemple, une Resolution différente pour les Constatations Faux positif que pour les Constatations corrigées), utilisez le DefectDojo Pro Jira Integrator, qui prend en charge des mappages de champs de transition par statut. +* Les valeurs utilisent le même format que l'API REST de Jira : des chaînes pour les champs texte, `{"name": ...}` pour les résolutions, `[{"name": ...}]` pour les champs à sélection multiple, etc. +* Si des transitions ont été rejetées alors que ces paramètres étaient absents ou incomplets, corriger les paramètres répare la dérive : la prochaine transmission de statut pour la Constatation retente la transition avec les champs configurés. +* Ces deux paramètres sont également disponibles sur le point de terminaison REST `/api/v2/jira_projects/` (`close_transition_fields` / `reopen_transition_fields`), et peuvent donc être gérés via l'API. +* Ces champs sont également appliqués lorsque DefectDojo ferme un ticket parce que sa Constatation a été **supprimée** — les valeurs sont capturées au moment où la fermeture est mise en file d'attente. + +#### Étiquettes Jira + +Sélectionnez les étiquettes pertinentes avec lesquelles vous souhaitez que le ticket soit créé dans Jira, par ex. **DefectDojo**, **YourProductName..** + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_6.png) + +#### Assigné par défaut + +Le nom de l'assigné par défaut dans Jira. Si ce champ est laissé vide, DefectDojo suivra le comportement par défaut de votre espace Jira lors de la création des tickets. + +### Jira Project Settings + +#### Enabled + +Ce bouton bascule contrôle si DefectDojo transmet les Constatations à Jira pour ce Produit. Le désactiver ne supprimera ni ne modifiera les tickets Jira existants créés par DefectDojo, mais empêchera toute mise à jour supplémentaire ou création de nouveau ticket. + +Les intégrations Jira ne peuvent être supprimées de votre instance que si aucun ticket associé n'a été créé. Si des tickets ont été créés, il n'existe aucun moyen de supprimer complètement une instance Jira de DefectDojo. + +#### Add Vulnerability Id as a Jira label + +Cela vous permet d'ajouter automatiquement l'ID de vulnérabilité comme étiquette Jira. Les ID de vulnérabilité sont ajoutés aux Constatations par les outils de sécurité individuels \- il peut s'agir d'ID CVE (Common Vulnerabilities and Exposures) ou d'un format différent, propre à l'outil ayant signalé la Constatation. + +#### Push All Issues + +Si cette case est cochée, DefectDojo transmettra automatiquement à Jira, sous forme de tickets, toutes les Constatations Actives et Vérifiées. Si elle est décochée, toutes les Constatations devront être transmises manuellement à Jira (individuellement ou via une transmission en masse). + +Lorsque ce paramètre est activé, les tickets Jira continuent de se synchroniser avec DefectDojo même si le statut de la Constatation change. + +#### Enable Engagement Epic Mapping + +Dans DefectDojo, les Engagements représentent un ensemble de travaux. Chaque Engagement contient un ou plusieurs Tests, qui contiennent une ou plusieurs Constatations à corriger. Les epics dans Jira fonctionnent de manière similaire, et cette case à cocher vous permet de transmettre les Engagements à Jira sous forme d'epics. + +* Un Engagement dans DefectDojo \- notez les trois constatations listées en bas. +​ +![image](images/Add_a_Connected_Jira_Project_to_a_Product_8.png) +* Comment le même Engagement devient un Epic une fois transmis à JIRA \- les Constatations de l'Engagement sont également transmises et apparaissent à l'intérieur de l'Engagement en tant que tickets enfants (Child Issues). + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_9.png) + +#### Push Notes + +Si cette option est activée, les commentaires Jira apparaîtront sur la Constatation associée dans DefectDojo, sous Notes, et inversement ; les Notes sur les Constatations seront ajoutées au ticket Jira associé sous forme de commentaires. + +#### Send SLA Notifications As Comments + +Si cette option est activée, tout ticket qui enfreint les règles de l'accord de niveau de service (SLA) de DefectDojo recevra des commentaires sur le ticket Jira l'indiquant. Ces commentaires seront publiés quotidiennement jusqu'à ce que le ticket soit résolu. + +Les accords de niveau de service peuvent être configurés sous **Configuration \> SLA Configuration** dans DefectDojo et affectés à chaque Produit. + +#### Send Risk Acceptance Expiration Notifications As Comment + +Si cette option est activée, tout ticket dont l'Acceptation du risque DefectDojo associée expire recevra un commentaire sur le ticket Jira l'indiquant. Ces commentaires seront publiés quotidiennement jusqu'à ce que le ticket soit résolu. + +### Paramètres Jira au niveau de l'Engagement + +Par défaut, les Engagements **héritent des paramètres Jira de leur Produit**. Vous pouvez toutefois remplacer les paramètres Jira pour des Engagements individuels. + +Pour accéder aux paramètres Jira au niveau de l'Engagement, cliquez sur le menu ⚙️ (Gear) d'un Engagement et ouvrez la page **Jira Project Settings**. + +Depuis cet écran, vous pouvez décocher **Inherit from Product** et fournir des valeurs spécifiques à l'Engagement pour : **Project Key**, **Issue Template, Custom Fields, Jira Labels, Default Assignee**, ainsi que d'autres paramètres. + +Notez qu'une fois qu'un Engagement dispose de son propre projet Jira assigné, il ne peut plus hériter du Produit. + +![image](images/Creating_Issues_in_Jira_5.png) + +## Étape 4 : Configurer la synchronisation bidirectionnelle : Webhook Jira + +L'intégration Jira permet une synchronisation bidirectionnelle via webhook. DefectDojo reçoit les notifications Jira à une adresse unique, ce qui permet de recevoir des commentaires Jira sur les Constatations, ou de résoudre des Constatations via Jira selon votre configuration. + +### Localiser votre URL de webhook Jira + +Votre webhook Jira se trouve sur le formulaire des paramètres système, sous **Jira Integration Settings** : **Enterprise Settings \> System Settings** depuis la barre latérale. + +Vous devez également cocher **Enable Jira Web Hook** sur la même page pour que DefectDojo traite les notifications Jira entrantes. Les webhooks entrants sont ignorés si cette case ou **Enable Jira Integration** (voir [Étape 1](#step-1-enable-the-jira-integration-in-system-settings)) n'est pas cochée. + +![image](images/Configuring_the_Jira_DefectDojo_Webhook.png) + +### Créer le webhook Jira + +1. Rendez-vous sur `**https:// \ /plugins/servlet/webhooks**` +2. Cliquez sur « Create a Webhook ». +3. Dans le champ intitulé « URL », saisissez : `https:// \<**YOUR DOJO DOMAIN**\> /jira/webhook/ \<**YOUR GENERATED WEBHOOK SECRET**\>`. Le secret du webhook figure sous Jira Integration Settings comme indiqué ci-dessus. +4. Sous « Comments », activez « Created ». Sous « Issue », activez « Updated ». +5. Assurez-vous que votre instance JIRA fait confiance au certificat SSL utilisé par votre instance DefectDojo. Pour JIRA Cloud, DefectDojo doit utiliser [un certificat SSL/TLS valide, signé par une autorité de certification mondialement reconnue](https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-registering-webhooks-with-non-secure-urls/) + +Notez que vous n'avez pas besoin de créer un secret dans Jira pour utiliser ce webhook. Le secret est intégré à l'URL de DefectDojo ; il suffit donc d'ajouter l'URL complète au formulaire de webhook Jira. + +Les requêtes de webhook entrantes sont authentifiées par le secret contenu dans cette URL : traitez donc l'URL complète comme une donnée d'identification et gardez-la confidentielle. + +#### Tester le webhook + +Une fois que vous avez une ou plusieurs Issues créées à partir de Constatations DefectDojo, vous pouvez tester le webhook en ajoutant une note à l'une de ces Constatations. La note devrait être reçue par le webhook Jira sous forme de commentaire. + +Si cela ne fonctionne pas correctement, cela peut être dû à un problème de pare-feu sur votre instance Jira bloquant le webhook. + +* Les règles de pare-feu de DefectDojo incluent une case à cocher pour **Jira Cloud**, qui doit être activée pour que DefectDojo puisse recevoir les messages de webhook provenant de Jira. + +### Alternative : utiliser Jira Automation (Send web request) + +Certaines instances Jira n'autorisent pas les webhooks système sous `/plugins/servlet/webhooks` — par exemple lorsque cette zone d'administration est restreinte et que seules les règles **Jira Automation** sont autorisées. Dans ce cas, vous pouvez piloter la même synchronisation bidirectionnelle à l'aide de l'action **Send web request** d'Automation, qui envoie une requête vers le même point de terminaison webhook DefectDojo. + +Le point de terminaison webhook de DefectDojo accepte toute requête HTTP `POST` avec `Content-Type: application/json` et un secret valide dans le chemin de l'URL. Il n'exige **pas** que la requête provienne du mécanisme de webhook système de Jira ; l'action « Send web request » d'Automation fonctionne donc comme une alternative directe. + +#### Prérequis + +Les mêmes prérequis que pour le webhook système s'appliquent : + +* **Enable JIRA integration** et **Enable JIRA web hook** sont tous deux cochés sur la page ⚙️ **Configuration \> System Settings**. +* Un **Jira webhook secret** non vide est défini sur cette page. Le secret ne peut contenir que les caractères `A-Z`, `a-z`, `0-9`, `_` et `-`. +* La Constatation (ou le Groupe de constatations) est déjà liée à l'Issue Jira. Si l'issue n'est pas liée à une Constatation DefectDojo, la requête est tout de même acceptée (HTTP `200`) mais aucune action n'est effectuée. + +#### Comment DefectDojo traite la requête + +* DefectDojo se base sur un champ de premier niveau `webhookEvent`. Seuls `"jira:issue_updated"` et `"comment_created"` sont traités ; toute autre valeur est acceptée mais ignorée. Automation n'ajoute pas ce champ de lui-même, vous devez donc l'inclure vous-même dans le corps de la requête. +* Pour cette raison, réglez le **Body** de la requête sur **Custom data** et fournissez le JSON ci-dessous. Les options de corps **Empty** et **Jira issue data** n'incluent pas le champ `webhookEvent` requis, DefectDojo les ignorera donc. +* Le point de terminaison renvoie toujours HTTP `200`, qu'une mise à jour ait été appliquée ou non. La réussite ou l'échec n'est visible que dans le corps de la réponse et dans les journaux DefectDojo — un `200` dans le journal d'audit d'Automation ne confirme pas à lui seul que la mise à jour a bien atteint une Constatation. + +#### Règle 1 — Issue mise à jour + +Créez une règle Automation avec : + +* **Déclencheur (Trigger) :** *Issue transitioned* (ou tout autre déclencheur qui se déclenche lorsque les champs que vous synchronisez changent, par exemple *Field value changed* sur Status). +* **Action :** *Send web request* + * **Web request URL :** `https:///jira/webhook/` + * **Méthode HTTP :** `POST` + * **Web request body :** *Custom data* + * **En-têtes (Headers) :** `Content-Type: application/json` + * **Custom data :** + +```json +{ + "webhookEvent": "jira:issue_updated", + "issue": { + "id": "{{issue.id}}", + "fields": { + "updated": "{{issue.updated}}", + "resolution": null, + "status": { "statusCategory": { "key": "{{issue.status.statusCategory.key}}" } }, + "assignee": { "name": "{{issue.assignee.accountId}}", "displayName": "{{issue.assignee.displayName}}" } + } + } +} +``` + +Contraintes pour les mises à jour d'issue : + +* `issue.id` doit être l'**ID interne numérique de l'issue Jira** (`{{issue.id}}`), et non la clé de l'issue (par ex. `PROJ-123`). DefectDojo fait correspondre la mise à jour à une Constatation à l'aide de cet ID numérique. +* Les champs `resolution` et `updated` doivent toujours être présents. `resolution` peut être `null`, mais si l'un des deux champs est absent, la requête est acceptée (`200`) mais n'est pas traitée, silencieusement. +* La synchronisation de statut et l'atténuation automatique sont pilotées par `status.statusCategory.key`, dont les valeurs Jira sont `new` (To Do), `indeterminate` (In Progress) et `done` (Done). Une Constatation n'est atténuée que lorsque l'issue est réellement fermée, et non simplement parce qu'une valeur de résolution est présente. + +#### Règle 2 — Issue commentée + +Créez une seconde règle Automation avec : + +* **Déclencheur (Trigger) :** *Issue commented* +* **Action :** *Send web request* — même URL, méthode, en-tête et option de corps *Custom data* que pour la Règle 1, avec ce corps : + +```json +{ + "webhookEvent": "comment_created", + "comment": { + "self": "https:///rest/api/2/issue/{{issue.id}}/comment/{{comment.id}}", + "body": "{{comment.body}}", + "updateAuthor": { "name": "{{comment.author.accountId}}", "displayName": "{{comment.author.displayName}}" } + } +} +``` + +Contraintes pour les commentaires : + +* `body` et `updateAuthor` doivent tous deux être présents. +* DefectDojo détermine l'issue cible à partir de l'URL `comment.self` — plus précisément le `` dans le segment `.../issue//comment/...` — `{{issue.id}}` (l'ID numérique) doit donc y figurer. +* **Prévention des boucles :** si l'auteur du commentaire correspond au compte Jira que DefectDojo utilise pour publier ses propres commentaires, DefectDojo ignore le commentaire afin d'éviter une boucle d'écho. Si vous souhaitez que *tous* les commentaires soient ingérés, exécutez la règle Automation avec un utilisateur Jira **différent** de celui configuré dans l'instance Jira de DefectDojo. + +#### Remarque sur les smart values + +Les smart values indiquées ci-dessus (`{{issue.id}}`, `{{issue.status.statusCategory.key}}`, `{{comment.author.accountId}}`, etc.) sont les noms standard de Jira Cloud, mais ils peuvent varier d'une instance à l'autre. Avant la mise en production, utilisez l'aperçu de charge utile (payload preview) d'Automation pour vérifier que chaque smart value se résout comme attendu. + +## Tester l'intégration Jira + +#### Test 1 : les Constatations sont-elles bien envoyées vers Jira ? + +Pour vérifier que l'intégration Jira fonctionne correctement, vous pouvez ajouter une nouvelle Constatation vierge au Produit associé à Jira dans DefectDojo. **Produit \> Findings \> Add New Finding.** + +Ajoutez le titre, la sévérité et la description de votre choix, puis cliquez sur « Finished ». La Constatation doit apparaître comme une Issue dans Jira avec toutes les métadonnées pertinentes. + +Si les Issues Jira ne sont pas créées correctement, vérifiez vos notifications pour les codes d'erreur. + +* Vérifiez que l'utilisateur Jira associé à la configuration Jira de DefectDojo dispose des permissions nécessaires pour créer et mettre à jour des issues sur cet espace Jira en particulier. + +#### Test 2 : les webhooks Jira sont bien envoyés vers DefectDojo + +Pour tester les webhooks Jira, ajoutez une note à une Constatation qui existe également dans JIRA en tant qu'Issue (par exemple, l'issue de test de la section précédente). + +Si les webhooks sont configurés correctement, vous devriez voir la note apparaître dans Jira sous forme de commentaire sur l'issue. + +Si cela ne fonctionne pas correctement, cela peut être dû à un problème de pare-feu sur votre instance Jira bloquant le webhook. + +* Les règles de pare-feu de DefectDojo incluent une case à cocher pour **Jira Cloud**, qui doit être activée pour que DefectDojo puisse recevoir les messages de webhook provenant de Jira. + +## Se déconnecter de Jira + +Les intégrations Jira ne peuvent être supprimées de votre instance que si aucune Issue associée n'a été créée. Si des Issues ont été créées, il n'existe aucun moyen de supprimer complètement une instance Jira de DefectDojo. + +Toutefois, vous pouvez désactiver votre intégration Jira en la désactivant au niveau du Produit. Depuis la page **Jira Project Settings** (accessible via le menu ⚙️ Gear sur un Produit), décochez le bouton **Enabled**. Cela ne supprimera ni ne modifiera aucun ticket Jira existant créé par DefectDojo, mais désactivera toute mise à jour ultérieure. + +# Pousser des Constatations vers Jira + +Un Produit disposant d'un mapping JIRA peut pousser des Constatations vers Jira en tant qu'Issues via plusieurs méthodes. Vous pouvez pousser les Constatations individuellement, en masse, en tant que Groupes de constatations, ou automatiquement. + +## Pousser une Constatation unique + +1. Ouvrez la Constatation que vous souhaitez pousser. +2. Cliquez sur le **☰ Finding Menu** et sélectionnez **Push to Jira**. +3. Confirmez l'envoi lorsque vous y êtes invité. DefectDojo créera une Issue Jira et la liera à la Constatation. + +Une fois l'Issue créée, DefectDojo affichera un lien vers l'Issue Jira sur la page de la Constatation. + +![image](images/Creating_Issues_in_Jira_2.png) + +Vous pouvez également cocher la case **Push to Jira** lors de la modification d'une Constatation via le formulaire **Edit Finding**. Lorsque la Constatation est enregistrée, elle sera poussée vers Jira. + +### Mettre à jour une Issue Jira liée + +Si une Constatation a déjà une Issue Jira liée, sélectionner à nouveau **Push to Jira** mettra à jour l'Issue Jira existante avec les modifications apportées dans DefectDojo. Si **Push All Issues** est activé sur le Produit, cette synchronisation se fait automatiquement. + +### Délier une Constatation de Jira + +Pour supprimer l'association entre une Constatation et son Issue Jira, cliquez sur le **☰ Finding Menu** et sélectionnez **Unlink From Jira**. Cela supprime le lien dans DefectDojo mais ne supprime pas l'Issue Jira elle-même. + +## Pousser des Constatations en masse + +Vous pouvez pousser plusieurs Constatations vers Jira en une seule fois à l'aide du formulaire Bulk Update : + +1. Depuis une liste de Constatations, sélectionnez les Constatations que vous souhaitez pousser à l'aide des cases à cocher. +2. Ouvrez le formulaire **Bulk Update**. +3. Sous **Jira Settings**, cochez la case **Push to Jira**. +4. Cliquez sur **Submit**. + +Les Constatations sélectionnées seront placées dans la file d'attente pour être poussées vers Jira. DefectDojo affichera un message de confirmation indiquant le nombre de Constatations mises en file d'attente. + +## Pousser des Engagements en tant qu'Épics + +Si **Enable Engagement Epic Mapping** est activé dans vos Jira Project Settings, vous pouvez pousser un Engagement vers Jira en tant qu'Épic. Les Constatations de l'Engagement seront poussées en tant qu'Issues enfants au sein de cet Épic. + +Pour pousser un Engagement en tant qu'Épic : + +1. Ouvrez l'Engagement que vous souhaitez pousser. +2. Cliquez sur le **☰ Engagement Menu** et sélectionnez **Push to Jira**. +3. Éventuellement, indiquez un **Epic Name** (par défaut, le nom de l'Engagement si laissé vide) et une **Epic Priority**. +4. Cochez **Push to Jira (Create Epic)** et validez le formulaire. + +## Pousser des Groupes de constatations en tant qu'Issues Jira + +Si les Groupes de constatations sont activés, vous pouvez pousser un Groupe de constatations vers Jira en tant qu'Issue unique plutôt que des Issues séparées pour chaque Constatation. + +Pour pousser un Groupe de constatations : + +1. Ouvrez le Groupe de constatations. +2. Cliquez sur le **☰ Finding Group Menu** et sélectionnez **Push to Jira**, ou cochez la case **Push to Jira** lors de la modification du Groupe de constatations. + +L'Issue Jira associée à un Groupe de constatations doit être supprimée directement depuis l'instance Jira si une suppression est nécessaire. + +### Créer et pousser automatiquement des Groupes de constatations + +Avec **Push All Issues** activé sur le Produit, et une option **Group By** sélectionnée lors de l'import : + +Tant que les Groupes de constatations sont créés avec succès, c'est le Groupe de constatations qui sera automatiquement poussé vers Jira en tant qu'Issue, et non les Constatations individuelles. + +![image](images/Creating_Issues_in_Jira_4.png) + +## Comportement de l'envoi automatique + +DefectDojo peut automatiquement pousser des Constatations et des mises à jour vers Jira dans plusieurs scénarios : + +### Push All Issues + +Lorsque le paramètre **Push All Issues** est activé dans les Jira Project Settings d'un Produit, DefectDojo créera automatiquement des Issues Jira pour toutes les Constatations Actives et Vérifiées. Cela inclut les Constatations créées via un import de scan. Une fois qu'une Issue Jira est créée, elle continuera à se synchroniser avec DefectDojo même si le statut de la Constatation change. + +### Synchronisation automatique lors des changements de statut + +Lorsque **Push All Issues** ou le paramètre système **Finding Jira Sync** est activé, DefectDojo mettra automatiquement à jour les Issues Jira liées lorsque certaines actions sont effectuées sur les Constatations : + +* **Request Review** \- Un commentaire est ajouté à l'Issue Jira liée (ou à l'Issue Jira du Groupe de constatations si la Constatation appartient à un groupe). +* **Clear Review** \- Un commentaire est ajouté à l'Issue Jira liée. +* **Close Finding** \- L'Issue Jira liée est mise à jour pour refléter la fermeture. Si **Push Notes** est activé, un commentaire est également ajouté. + +## Commentaires et notes Jira + +Lorsque **Push Notes** est activé dans les Jira Project Settings : + +* Si un commentaire est ajouté à une Issue Jira, le même commentaire sera ajouté à la Constatation, sous la section **Notes**. +* De même, si une note est ajoutée à une Constatation, la note sera ajoutée à l'issue Jira en tant que commentaire. + +## Changements de statut Jira + +La configuration de l'instance Jira comporte des entrées pour deux transitions Jira qui déclenchent un changement de statut sur une Constatation. + +* Lorsque la **transition « Close »** est effectuée sur Jira, la Constatation associée se ferme également et devient marquée comme **Inactive** et **Atténué** dans DefectDojo. DefectDojo enregistrera ce changement sur la page de la Constatation, sous l'en-tête **Mitigated By**. +​ +![image](images/Creating_Issues_in_Jira_3.png) + +* Lorsque la **transition « Reopen »** est effectuée sur l'Issue Jira, la Constatation associée sera définie comme **Actif** dans DefectDojo, et perdra son statut **Atténué**. + +## Mapper les résolutions Jira vers Risque accepté / Faux positif + +La configuration de l'instance Jira comporte deux champs optionnels qui vous permettent de mapper une **Resolution** Jira à un statut de Constatation DefectDojo : + +* **Risk Accepted Finding Mapping Resolution** — lorsqu'une issue Jira est fermée avec cette Resolution, la Constatation liée devient Risque accepté dans DefectDojo. +* **False Positive Finding Mapping Resolution** — lorsqu'une issue Jira est fermée avec cette Resolution, la Constatation liée devient Faux positif dans DefectDojo. + +### Statut contre Résolution : une source de confusion fréquente + +Ces champs mappent la **Resolution** Jira, et non le **Status** Jira. Status et Resolution sont deux concepts Jira indépendants : le Status décrit où en est l'issue dans le workflow (Open, In Progress, Done), tandis que la Resolution décrit comment elle a été résolue (Fixed, Won't Do, Duplicate, False Positive, etc.). + +### Prérequis : une post-fonction « Set issue resolution » sur la transition de workflow Jira + +Le moteur de workflow de Jira ne remplit pas automatiquement le champ Resolution. Chaque transition qui doit fermer une issue avec une Resolution spécifique nécessite une post-fonction **Set issue resolution** configurée sur la transition elle-même. Sans cette post-fonction, l'issue passe au nouveau Status mais la Resolution reste vide, et le mapping de DefectDojo n'a rien à quoi se comparer. + +Un administrateur Jira peut ajouter cette post-fonction depuis **Project Settings → Workflows → (edit workflow) → (select the closing transition) → Post Functions → Add post function → Set issue resolution**. + +# Champs personnalisés dans Jira + +DefectDojo ne prend actuellement pas en charge le passage d'informations spécifiques à une Issue dans ces champs personnalisés \- ces champs devront être mis à jour manuellement dans Jira après la création de l'issue. Chaque champ personnalisé ne sera créé par DefectDojo qu'avec une valeur par défaut. + + Jira Cloud vous permet désormais de créer une valeur par défaut de champ personnalisé directement dans l'application. [Consultez la documentation d'Atlassian sur les champs personnalisés](https://support.atlassian.com/jira-cloud-administration/docs/configure-a-custom-field/) pour en savoir plus sur la configuration de cette fonctionnalité. + +Les types d'Issue Jira intégrés à DefectDojo (**Bug, Task, Story** et **Epic)** sont configurés pour fonctionner « prêts à l'emploi ». Les champs de données de DefectDojo se mapperont automatiquement aux champs correspondants dans Jira. Par défaut, DefectDojo attribuera une Priority, des Labels et un Reporter à toute nouvelle Issue qu'il crée. + +Certaines configurations Jira nécessitent la prise en compte de champs personnalisés supplémentaires avant qu'une issue puisse être créée. Ce processus vous permettra de prendre en compte ces champs personnalisés dans votre intégration DefectDojo \-\> Jira, garantissant que les issues sont créées avec succès. Ces champs personnalisés seront ajoutés à tous les appels API envoyés depuis DefectDojo vers une instance Jira liée. + +Si vous n'utilisez pas déjà de champs personnalisés dans Jira, il n'est pas nécessaire de suivre ce processus. + +1. Enregistrer les noms de vos champs personnalisés dans Jira (**interface Jira**) +2. Déterminer les valeurs de clé (Key) des nouveaux champs personnalisés (point de terminaison Jira Field Spec) +3. Localiser les données acceptables pour chaque champ personnalisé, en utilisant les valeurs de clé comme référence (point de terminaison Jira Issue) +4. Créer un bloc JSON de référence de champs pour suivre toutes les clés de champs personnalisés et les données acceptables (point de terminaison Jira Issue) +5. Stocker le bloc JSON dans le Produit DefectDojo associé, pour permettre la création des champs personnalisés depuis Jira (interface DefectDojo) +6. Tester votre travail et vous assurer que toutes les données requises circulent correctement depuis Jira + +#### Étape 1 : Enregistrer les noms de vos champs personnalisés dans Jira + +Jira prend en charge une variété de Context Fields différents, notamment des sélecteurs de date, des labels personnalisés, des boutons radio. Chacun de ces Context Fields aura une valeur de clé différente, que l'on peut trouver dans l'API Jira. + +Notez les noms de chaque champ personnalisé requis, car vous devrez parcourir l'API Jira pour les retrouver à l'étape suivante. + +**Exemple de liste de champs personnalisés (les noms de vos champs personnalisés seront différents) :** + +* DefectDojo Custom URL Field +* Un autre exemple de champ personnalisé +* ... + +#### Étape 2 : Trouver les valeurs de clé de vos champs personnalisés Jira + +Commencez ce processus en accédant à l'URL Field Spec de l'ensemble de votre instance Jira. + +Voici un exemple d'URL Field Spec : + +`https://yourcompany-example.atlassian.net/rest/api/2/field` + +L'API renverra une longue chaîne JSON, qu'il conviendra de formater en texte lisible (à l'aide d'un éditeur de code, d'une extension de navigateur ou de ). + +Le JSON renvoyé par cette URL contiendra tous vos champs personnalisés Jira, dont la plupart ne concernent pas DefectDojo et ont des valeurs `"Null"`. Chaque objet de cette réponse d'API correspond à un champ différent dans Jira. Vous devrez rechercher les objets dont les attributs `"name"` correspondent aux noms de chaque champ personnalisé que vous avez créé dans l'interface Jira, puis noter la valeur de leur attribut « key ». + +![image](images/Using_Custom_Fields.png) + +Une fois que vous avez trouvé l'objet correspondant dans la sortie JSON, vous pouvez déterminer la valeur « key » \- dans ce cas, il s'agit de `customfield_10050`. + +Jira génère des valeurs de clé différentes pour chaque champ personnalisé, mais ces valeurs de clé ne changent pas une fois créées. Si vous créez un autre champ personnalisé à l'avenir, il aura une nouvelle valeur de clé. + +**Extension de notre liste de champs personnalisés :** + +* « DefectDojo Custom URL Field » \= customfield\_10050 +* « Un autre exemple de champ personnalisé » \= customfield\_12345 +* ... + +#### Étape 3 \- Trouver les champs personnalisés sur une Issue Jira + +Localisez une Issue dans Jira qui contient les champs personnalisés que vous avez enregistrés à l'étape 2\. Copiez la clé de l'issue depuis le titre (elle devrait ressembler à « `EXAMPLE-123` ») et accédez à l'URL suivante : + +`https://yourcompany-example.atlassian.net/rest/api/2/issue/EXAMPLE-123` + +Cela renverra une autre chaîne JSON. + +Comme précédemment, la sortie de l'API contiendra de nombreux paramètres d'objet `customfield_##` avec des valeurs `null` \- ce sont des champs personnalisés que Jira ajoute par défaut, qui ne concernent pas cette issue. Elle contiendra également des valeurs `customfield_##` qui correspondent aux valeurs de clé de champ personnalisé que vous avez trouvées à l'étape précédente. Contrairement à la sortie Field Spec, vous ne verrez pas de noms identifiant ces champs personnalisés, c'est pourquoi vous deviez enregistrer les valeurs de clé à l'étape 2\. + +![image](images/Using_Custom_Fields_2.png) + +**Exemple :** +Nous savons que `customfield_10050` représente le DefectDojo Custom URL Field car nous l'avons noté à l'étape 2\. Nous pouvons maintenant voir que `customfield_10050` contient une valeur de `"https://google.com"` dans l'issue `EXAMPLE-123`. + +#### Étape 4 \- Créer une référence de champs JSON à partir de chaque clé de champ personnalisé Jira + +Vous devrez maintenant prendre la valeur de chacun des champs personnalisés de votre liste et les stocker dans un objet JSON (à utiliser comme référence). Vous pouvez ignorer tout champ personnalisé qui ne correspond pas à votre liste. + +Cet objet JSON contiendra toutes les valeurs par défaut pour les nouvelles Issues Jira. Nous recommandons d'utiliser des noms faciles à reconnaître par votre équipe comme des valeurs « par défaut » à modifier : « `change-me.com` », « `Change this paragraph.` », etc. + +**Exemple :** + +À partir de l'étape 3, nous savons maintenant que Jira attend une chaîne d'URL pour « `customfield_10050` ». Nous pouvons utiliser cela pour construire notre exemple d'objet JSON. + +Supposons que nous ayons également localisé un champ de texte court lié à DefectDojo, identifié comme « `customfield_67890` ». Nous examinerions ce champ dans notre seconde sortie d'API, regarderions la valeur associée, et référencerions la valeur stockée dans notre exemple d'objet JSON également. +​ +Votre objet JSON commencera à ressembler à ceci à mesure que vous y ajoutez d'autres champs personnalisés. + +``` +{ + "customfield_10050": "https://change-me.com", + "customfield_67890": "This is the short text custom field." +} +``` + +Répétez ce processus jusqu'à ce que tous les champs personnalisés pertinents pour DefectDojo issus de Jira aient été ajoutés à votre référence de champs JSON. + +#### Types de données \& syntaxe Jira + +Certains champs, tels que les champs de date, peuvent concerner plusieurs champs personnalisés dans Jira. Si c'est le cas, vous devrez ajouter les deux champs à votre référence de champs JSON. + +``` + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", +``` + +D'autres champs, comme le champ Label, peuvent être suivis sous forme d'une liste de chaînes \- assurez-vous que votre référence de champs JSON utilise un format correspondant à la sortie d'API de Jira. + +``` +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], +``` + +D'autres champs personnalisés peuvent contenir des informations contextuelles supplémentaires qui doivent être retirées de la référence de champs. Par exemple, le champ Custom Multichoice contient un bloc supplémentaire dans la sortie de l'API, que vous devrez retirer, car ce bloc stocke la valeur actuelle du champ. + +* vous devez retirer l'objet supplémentaire de ce champ : + +``` +"customfield_10047": [ + { + "value": "A" + }, + { + "self": "example.url...", + "value": "C", + "id": "example ID" + } +] +``` +* vous pouvez plutôt le raccourcir comme suit et ignorer la seconde partie : + +``` +"customfield_10047": [ + { + "value": "A" + } +] +``` + +#### Exemple de référence de champs complète + +Voici une référence de champs JSON complète, avec des commentaires en ligne expliquant à quoi correspond chaque champ personnalisé. Ceci est un exemple englobant l'ensemble des cas. Votre JSON contiendra des valeurs de clé et des données différentes selon les valeurs personnalisées que vous souhaitez utiliser lors de la création d'issue. + +``` +{ + "customfield_10050": "https://change-me.com", + + "customfield_10049": "This is a short text custom field", + +// two different fields, but both correspond to the same custom date attribute + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", + +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], + +// custom number field + "customfield_10043": 0, + +// custom paragraph field + "customfield_10044": "This is a very long winded way to say CHANGE ME PLEASE", + +// custom radio button field + "customfield_10045": { + "value": "radio button option" + }, + +// custom multichoice field + "customfield_10047": [ + { + "value": "A" + } + ], + +// custom checkbox field + "customfield_10039": [ + { + "value": "A" + } + ], + +// custom select list (singlechoice) field + "customfield_10048": { + "value": "1" + } +} +``` + +#### Étape 5 \- Ajouter les champs personnalisés à un Produit DefectDojo + +Vous pouvez maintenant ajouter ces champs personnalisés au Produit DefectDojo associé, sur la page Jira Project Settings (accessible via le menu ⚙️ Gear sur le Produit). Collez la référence de champs JSON en texte brut dans la zone **Custom Fields** et enregistrez. + +#### Étape 6 \- Tester vos champs personnalisés Jira à partir d'une nouvelle Constatation : + +Désormais, lorsque vous créez une nouvelle Constatation dans le Produit associé à Jira, Jira créera automatiquement tous ces champs personnalisés dans Jira selon le bloc JSON qu'il contient. Ces champs personnalisés seront créés avec les valeurs par défaut (« change\-me\-please », etc.). + +Au sein du Produit sur DefectDojo, accédez à la page Findings \> Add New Finding. Assurez-vous que la Constatation est à la fois Active et Vérifiée pour garantir qu'elle sera poussée vers Jira, puis vérifiez côté Jira que les champs personnalisés ont été créés avec succès et sans incohérence. diff --git a/docs/content/connectors/downstream/PRO__jira_guide.ja.md b/docs/content/connectors/downstream/PRO__jira_guide.ja.md new file mode 100644 index 00000000000..9f1f8a50f4d --- /dev/null +++ b/docs/content/connectors/downstream/PRO__jira_guide.ja.md @@ -0,0 +1,786 @@ +--- +title: Jira(レガシー) +description: Jira 連携を利用する +weight: 1 +audience: pro +aliases: +- /ja/issue_tracking/jira/pro__jira_guide/ +- /ja/en/share_your_findings/jira_guide +--- + +> **このページはレガシーな Jira 連携について説明しています。** ここで説明している製品単位の Jira 連携は、**[Jira ダウンストリームコネクタ](/connectors/downstream/about/)** に置き換えられました。このコネクタはすべての DefectDojo Pro インスタンスで一般提供されており、検出事項を Jira にプッシュする際の推奨方法です。Pro のサイドバーでは、この理由から **Connect > Jira** に `LEGACY` バッジが表示されます — 詳細は [メニューバッジ](/navigation/pro__menu_badges/) を参照してください。 +> +> **Jira を初めて設定する場合は、このガイドではなく [ダウンストリームコネクタ](/connectors/downstream/about/) から始めてください。** +> +> **すでにレガシー連携を使用していますか?** DefectDojo Pro には、既存のクラシック Jira 設定を、すでにプッシュ済みのチケットも含めてダウンストリームコネクタに移行する組み込みの移行機能があります — 詳細は後述の [Jira ダウンストリームコネクタへの移行](#migrating-to-the-jira-downstream-connector) を参照してください。 +> +> レガシー連携は引き続き動作し、このガイドはレガシー連携について正確な内容のままです。 + +DefectDojo の Jira 連携を使用すると、検出事項のデータを1つ以上の Jira スペースにプッシュできます。これにより、DefectDojo を標準的な開発ワークフローに組み込むことができます。以下はその活用例です。 + +* AppSec チームは、開発者が使用する Jira スペースへ検出事項を選択的にプッシュできるため、通常の開発作業と並行してイシューの修正を適切に優先順位付けできます。このボードを使う開発者は DefectDojo にアクセスする必要がなく、すべての作業を1か所にまとめておけます。 +* DefectDojo は、AppSec チームが使用する双方向の Jira スペースにすべての検出事項をプッシュできるため、イシューの検証作業を分担できます。このボードは DefectDojo と同期を保ち、複雑な修正ワークフローにも対応できます。 +* DefectDojo は、個別の製品やエンゲージメントから検出事項を選択的に、それぞれ別の Jira スペースにプッシュできるため、内容を適切なコンテキストに保つことができます。 + +## Jira ダウンストリームコネクタへの移行 + +DefectDojo Pro は、既存のクラシック Jira 設定を手作業で再構築する代わりに、ダウンストリームコネクタの設定へ変換できます。 + +**操作場所:** **Connect \> Downstream** に移動して **Downstream Connectors** ページを開き、**Classic Jira Migration** カードを使用します。**Migrate from classic Jira** をクリックし、確認してください。 + +このカードは、移行対象のクラシック Jira 設定がある場合、または報告すべき過去の実行結果がある場合にのみ表示されます。そのため、クラシック Jira を一度も使用したことのないインスタンスには表示されません。すべての移行が完了した後もカード自体は残りますが、それ以上行うことがないためボタンは無効化されます。 + +移行の実行には**グローバルの Maintainer レベルの権限**(具体的には連携編集の権限)が必要であり、ログイン済みのブラウザセッションから実行する必要があります。API トークンで実行することはできません。 + +### すでにプッシュ済みのチケットはどうなるか + +**既存の Jira チケットはそのまま保持され、再度リンクされます。孤立することはなく、コネクタが重複してチケットを開くこともありません。** クラシック Jira によってすでにプッシュされていた検出事項はそれぞれチケットを保持したままとなり、以後はコネクタが同じチケットをその場で更新するようになります。検出事項グループのリンクについても同様に引き継がれます。 + +唯一の例外は**エンゲージメントのエピック**です。ダウンストリームコネクタにはエピックという概念がないため、エピックのイシューは移行の警告として報告されるのみで、変更されずそのまま残ります。 + +### 移行される内容 + +* Jira の**インスタンス**接続(URL と認証情報)は、名前を保ったままダウンストリームコネクタの連携インスタンスになります。 +* **深刻度のマッピング**と**ステータスのマッピング**(オープン・クローズの遷移キー)は引き継がれます。 +* 各 **Jira プロジェクト**の設定は、プロジェクトキーとイシュータイプを保ったままイシュートラッカーのマッピングになり、同じ製品またはエンゲージメントに割り当てられたままになります。 +* **Push All Issues** の設定は維持されます。有効になっていたプロジェクトは、引き続き自動的にプッシュされます。 +* **カスタムフィールド**、**クローズ/再オープン遷移フィールド**、**コンポーネント**、**デフォルトの担当者**、**ラベル**はフィールドマッピングに変換されます。*Add Vulnerability Id as a Jira label* を使用していた場合、これもラベルマッピングになります。 +* **カスタムイシューテンプレート**のディレクトリはチケットテンプレートになります。標準テンプレートはコピーされません。コネクタにはすでに同等のテンプレートが同梱されているためです。 + +### 引き継がれない内容 + +これらは移行実行時の警告として報告されますが、移行を止めることはありません。結果の中にある*「コネクタが引き継げないもの」*のリストを確認してください。 + +* **Jira → DefectDojo の逆方向同期。** これが最も重要な点です。ダウンストリームコネクタは Jira からの変更を*逆方向に*同期しないため、Jira の解決状況からリスク受容済みや誤検知を適用する解決マッピングは移行されません。**逆方向同期に依存している場合は、クラシック Jira インスタンスの設定をそのまま残してください。** 移行によって削除されることはありません。 +* **エンゲージメントのエピックマッピング** — コネクタにはエピックという概念がありません。 +* **メモのプッシュ**、**SLA 通知コメント**、**リスク受容期限切れコメント** — これらはコネクタから Jira には投稿されません。 +* `summary`、`description`、`project`、`issuetype`、`status` という名前のカスタムフィールド — これらはコネクタによって予約されているため、これらを使用するフィールドマッピングはスキップされます。 +* 512文字を超えるカスタムフィールドの値 — 切り詰められるのではなくスキップされます。 +* 製品にもエンゲージメントにも紐づいていない Jira プロジェクトは、割り当てが作成されません。 + +### 移行後にクラシック連携はどうなるか + +**二重にプッシュされることはありません。** 移行対象となった各プロジェクトについて、移行処理はクラシック Jira プロジェクトを無効化するため、それ以降はコネクタのみがプッシュを行います。手動で何かを無効化する必要はありません。 + +クラシックの設定は**削除されず、そのまま保持されます** — インスタンス、プロジェクト、イシューの記録はすべて残り、プッシュ設定のみが無効化されます。これは意図的な仕様です。これにより変更を元に戻せるようになっており、また逆方向同期に依存している場合でもそれが機能し続けます。 + +**ロールバックするには**、クラシック Jira プロジェクトの設定を再度有効化し、移行によって作成されたコネクタの設定を削除してください。ワンクリックで元に戻す機能はありません。 + +**再実行しても安全です。** 移行処理はすでに変換した内容を記録しており、2回目の実行時にはそれをスキップするため、重複が発生することはありません。あるプロジェクトやインスタンスで失敗しても、残りは移行が続行されます。失敗したプロジェクトは無効化されずクラシック連携のまま動作し続けるため、調査している間も引き続き機能します。 + +### 実行中の挙動 + +移行はバックグラウンドで実行され、進行状況が随時報告されます。完了すると、作成されたコネクタ、マッピング、割り当て、テンプレート、チケットリンクの数、無効化されたクラシックプロジェクトの数、スキップされた内容などのサマリーが、前述の警告とともに表示されます。移行は同時に1つしか実行できません。 + +# Jira の設定 + +Jira の設定には、次の手順が必要です。 +1. System Settings で Jira 連携を有効化します。有効化するまでは、他の Jira 設定は DefectDojo 全体で非表示になります。 +2. ユーザー名/パスワードまたは API トークンを使用して Jira インスタンスを接続します。複数のインスタンスを連携できます。 +3. その Jira インスタンスを、DefectDojo 内の1つ以上の製品またはエンゲージメントに追加します。 +4. 双方向同期を利用したい場合は、DefectDojo に更新を送信する Jira Webhook を作成します。 + +## ステップ1: System Settings で Jira 連携を有効化する + +Jira 連携はデフォルトで無効になっており、無効な間は他のすべての Jira 関連のコントロールが DefectDojo のインターフェース上で非表示になります。これが最初に設定すべき項目であり、これを有効化するまで以下の手順はいずれも利用できません。 + +連携が無効な間は、サイドバーに **Jira Instances** の項目が表示されないため、Jira インスタンスを追加する場所がありません。 + +![image](images/jira-menu-hidden-pro.png) + +### 連携を有効化する + +1. DefectDojo のサイドバーから **Settings \> System \> System Settings** に移動します。以前のメニューレイアウトを使用しているインスタンスでは、この項目はライセンスパッケージ名にちなんだグループ(**Pro Settings** または **Enterprise Settings**)の下にあります。詳細は [設定メニュー](/navigation/pro__settings_menu/) を参照してください。 +​ +2. **Jira Integration Settings** セクションで **Enable Jira Integration** にチェックを入れます。 +​ +3. **Submit** をクリックします。ページを再読み込みしなくても、**Jira Instances** がサイドバーにすぐに表示されます。 + +![image](images/jira-enable-system-settings-pro.png) + +### この設定が制御する内容 + +**Enable Jira Integration** を有効にすることで、その他の Jira 関連のインターフェースが表示されるようになります。これをオンにすると、次のものが利用可能になります。 + +* Jira インスタンスの追加・編集を行う **Jira Instances** メニュー +* アセットの ⚙️ メニューにある **Jira Project Settings** ページ、およびエンゲージメントの Jira 設定 +* 検出事項および検出事項グループの **Push to Jira** アクション、検出事項フォームおよび一括編集フォームの Jira 関連フィールド、アセット・エンゲージメント・検出事項・検出事項グループの一覧(CSV エクスポートを含む)にある Jira 列 + +この設定は UI の外でも連携全体を制御します。オフの間は、DefectDojo は(API 経由で送信される `push_to_jira` リクエストを含め)検出事項を Jira にプッシュせず、受信した Jira の Webhook も無視されます。 + +**Jira Integration Settings** 内の残りの Jira 関連フィールド(**Add Vulnerability ID as Jira Label**、**Enable Jira Web Hook**、**Disable Jira Web Hook Secret**、**Jira Web Hook Secret**、**Jira Minimum Severity**)は、連携がオンかオフかにかかわらず表示されますが、連携が有効になるまでは効果がありません。 + +## ステップ2: Jira インスタンスを接続する + +連携を有効化したら、次のステップは DefectDojo の Jira 連携における Jira インスタンスの接続です。なお、Jira Service Management は現在サポートされていません。 + +#### Jira から必要な情報 + +Atlassian では、Jira Cloud と Jira Data Center とで認証方法が異なります。 + +**Jira Cloud** の場合、次のものが必要です。 +* Jira の URL(例: https://yourcompany.atlassian.net/) +* Jira インスタンスでイシューの作成・更新権限を持つアカウント。以下のいずれかが使用できます。 + * 標準の**ユーザー名/パスワード**の組み合わせ + * **ユーザー名/API トークン**の組み合わせ + +**Jira Data Center(または Server)** の場合、次のものが必要です。 +* Jira の URL(例: https://jira.yourcompany.com) +* Jira インスタンスでイシューの作成・更新権限を持つアカウント。以下のいずれかが使用できます。 + * 標準の**ユーザー名/パスワード**の組み合わせ + * **メールアドレス/パーソナルアクセストークン**の組み合わせ + +任意で、次のマッピングを設定できます。 +* 検出事項の再オープンとクローズをトリガーする Jira の遷移(Transitions) +* 検出事項にリスク受容済みや誤検知のステータスを適用できる Jira の解決状況(Resolutions)(任意) + +DefectDojo が使用する Jira アカウント/トークンが対象の Jira スペースでイシューを作成する権限を持っている限り、1つの Jira インスタンス接続で複数の Jira スペースを扱うことができます。 + +### Jira インスタンスを追加する + +1. [ステップ1](#step-1-enable-the-jira-integration-in-system-settings)で説明したとおり、System Settings で **Enable Jira Integration** にチェックが入っていることを確認します。有効にするまで、サイドバーに **Jira Instances** メニューは表示されません。 + +2. DefectDojo のサイドバーから **Enterprise Settings \> Jira Instances \> + New Jira Instance** ページに移動します。 + +![image](images/jira-instance-beta.png) + +3. この Jira インスタンスが DefectDojo 内で使用する **Configuration Name** を選択します。この名前は DefectDojo 内でのインスタンス接続を示すラベルにすぎず、Jira 側のデータと関連づける必要はありません。 + +4. 自社の Jira インスタンスの URL を入力します。Jira Cloud を使用している場合、`https://**yourcompany**.atlassian.net` のような形式になります。 + +5. Jira 用の Username / Password フィールドに、適切な認証方法を入力します。 + * 標準の**ユーザー名/パスワードによる Jira 認証**の場合、これらのフィールドに Jira のユーザー名と対応するパスワードを入力します。 + * **ユーザーの API トークン(Jira Cloud)**による認証の場合、ユーザー名を入力し、パスワードフィールドには対応する **API トークン**を入力します。 + * Jira の**パーソナルアクセストークン(PAT。Jira Data Center および Jira Server でのみ使用)**による認証の場合、パスワードフィールドに PAT を入力します。Jira PAT による認証ではユーザー名は使用されませんが、このフォームでは依然として必須項目のため、PAT を識別するためのプレースホルダー値を入力しておくことができます。 + +この接続に紐づくユーザーは、Jira インスタンス内でイシューを作成しデータにアクセスする権限を持っている必要があります。 + +6. Epic Name ID、Re-open Transition ID、Close Transition ID の値を入力する必要があります。これらの値は後から変更できます。Jira にログインした状態で、以下の URL からこれらの値を確認できます。 +- **Epic Name ID**: `https:///rest/api/2/field` にアクセスし、Epic Name を検索します。`number` の中にある番号をコピーしてここに貼り付けます。(Team-Managed Space を使用しているなどの理由で)スペースに Epic Name ID が関連付けられていない場合は、このフィールドに 0 を入力します。 +- **Re-open Transition ID**: `https:///rest/api/latest/issue//transitions?expand-transitions.fields` にアクセスし、Jira インスタンスの ID を確認します。Reopen Transition ID フィールドに貼り付けます。 +- **Close Transition ID**: `https:///rest/api/latest/issue//transitions?expand-transitions.fields` にアクセスし、Jira インスタンスの ID を確認します。Close Transition ID フィールドに貼り付けます。 + +7. Jira でイシューを作成する際の Default issue type を選択します。選択肢には、標準の Jira イシュータイプである **Bug、Task、Story、Epic** に加えて、カスタムイシュータイプの **Spike** と **Security** があります。これら以外のイシュータイプを使用したい場合は、[support@defectdojo.com](mailto:support@defectdojo.com) までお問い合わせください。 + +8. Jira でイシューが作成される際のイシューの説明を決定する Issue Template を選択します。 + +種類は次の2つです。 +- **Jira_full**: すべての検出事項情報を Jira のイシューに含めます +- **Jira_limited**: より少ない検出事項情報とメタデータのみを含めます + +このフィールドを空欄のままにした場合、デフォルトで **Jira_full** になります。別の種類のテンプレートが必要な場合は、[support@defectdojo.com](mailto:support@defectdojo.com) までご連絡ください。 + +9. 必要に応じて、イシュー上でトリガーされたときに検出事項のステータスをリスク受容済みまたは誤検知に変更する Jira の Resolution の名前を入力します。 + +ここでフォームを送信できます。必要であれば、Optional Fields でさらに Jira 連携をカスタマイズすることもできます。このボタンをクリックすると、Jira のイシューに汎用テキストを適用したり、Jira の深刻度マッピングを変更したりできます。 + +## ステップ3: 製品またはエンゲージメントを Jira に接続する + +DefectDojo の各製品・エンゲージメントには、検出事項が Jira のイシューにどのように変換されるかを制御する独自の設定があります。ここから、関連付ける Jira スペースを決定したり、イシュー・エピック・ラベルなどの Jira メタデータを作成する際のデフォルトの動作を設定したりできます。 + +### 製品に Jira を追加する + +このページは、製品の ⚙️(歯車)メニューをクリックし、**Jira Project Settings** ページを開くことで表示できます。 + +![image](images/jira-project-settings.png) + +#### Jira Instance + +組織内の別々の製品やチーム用に複数の Jira インスタンスを設定している場合、DefectDojo がどの Jira スペースにイシューを作成するかを指定できます。ドロップダウンメニューからスペースを選択してください。 + +このメニューに Jira インスタンスが1つも表示されない場合は、DefectDojo のグローバルな Jira 設定(yourcompany.defectdojo.com/jira)でそれらのスペースが接続されていることを確認してください。 + +#### Project key + +これは、DefectDojo で使用したいスペースのキーです。特定のスペースのスペースキーは URL から確認できます。(これは以前は **Jira Project Key** と呼ばれていましたが、2025年9月以降、Jira では **Space Key** と呼ばれるようになりました。) + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_3.png) + +#### Epic Issue Type Name + +Jira での Epic イシュータイプの名前です。デフォルトは "Epic" ですが、Jira インスタンスで別の名前を使用している場合は変更できます。 + +#### Issue template + +ここでは、Jira に送信する DefectDojo のメタデータの量を決定できます。次の2つのオプションから選択します。 + +* **jira_full**: DefectDojo のすべてのパラメータ(完全な説明、CVE、深刻度など)がイシューに反映されます。Jira 上で検出事項の完全なコンテキストが必要な場合(例えば、DefectDojo にアクセスできない担当者がこのイシューに対応する場合)に有用です。 + +以下は **jira_full** イシューの例です。 +​ +![image](images/Add_a_Connected_Jira_Project_to_a_Product_4.png) + +* **Jira_limited:** イシューには DefectDojo へのリンク、製品/エンゲージメント/テストへのリンク、Reporter と Environment のフィールドのみが反映されます。それ以外のフィールドは DefectDojo 側でのみ管理されます。Jira 上で検出事項の完全なコンテキストが不要な場合(例えば、主に DefectDojo 上で作業する担当者がこのイシューに対応しており、Jira 側にも全体像が必要ない場合)に有用です。 + +​以下は **jira_limited** イシューの例です。 + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_5.png) + +#### Component + +Jira スペースを Components で管理している場合、ここで DefectDojo 用の適切な Component を割り当てることができます。複数の Component を割り当てるには、カンマ区切りのリスト(例: `Security, DevSecOps`)を入力します。各値は個別の component として Jira に送信されます。 + +#### Custom fields + +DefectDojo のイシューで Custom Fields を使用する必要がない場合、このフィールドは 'null' のままにしておくことができます。 + +ただし、Jira のスペース設定で新規イシューに Custom Fields の使用が**必須**とされている場合は、これらのマッピングをハードコードする必要があります。 + +DefectDojo はイシュー固有のメタデータを Custom Fields として送信することはできず、送信できるのはデフォルト値のみである点に注意してください。このセクションは、Jira スペース内のすべてのイシューに**これらの Custom Fields が存在することが必須**とされている場合にのみ設定してください。 + +Custom Fields の設定を始めるには、**[こちらのガイド](#custom-fields-in-jira)**を参照してください。 + +#### Close / Reopen Transition fields + +Jira のワークフローの中には、遷移の一部として特定のフィールドの設定を**必須**とするものがあります。例えば、クローズ画面で Resolution と Justification フィールドが入力されない限りイシューのクローズを拒否するワークフローなどです。上記の Custom fields 設定はイシューの*作成時*にのみ適用されるため、こうしたワークフローの要件を満たすことはできません。 + +これらの設定がない場合、DefectDojo はフィールドなしでクローズ/再オープンの遷移を送信します。フィールドを必須とするワークフローはその遷移を拒否するため、検出事項と Jira のイシューが同期しなくなります。DefectDojo 側では検出事項が緩和済みと表示される一方、Jira 側ではイシューがオープンのままになります。 + +**Close Transition fields** および **Reopen Transition fields** の設定には、クローズ/再オープンの遷移呼び出しの `fields` ペイロードとして送信される JSON オブジェクトを指定できます。例えば、*Won't Fix* という Resolution と justification の値を指定してイシューをクローズする場合は、次のようになります。 + +```json +{ + "resolution": {"name": "Won't Fix"}, + "customfield_10200": "Risk accepted by security team #report-false-positive" +} +``` + +Jira のワークフローで遷移時のフィールドが不要な場合は、これらの設定を 'null' のままにしておいてください。 + +**どのフィールドが必要か** + +* Jira の管理者に、クローズ/再オープンの**遷移画面**にどのフィールドがあり、そのうちどれがバリデータによって強制されているかを確認してください。設定する JSON は、必須フィールドの**すべて**を満たしている必要があります。必須フィールドが1つでもペイロードに欠けていると、Jira は遷移全体を拒否し、何も設定されません。必須フィールドの一部だけを指定しても意味がありません。 +* 逆に、フィールドを送信するにはそのフィールドが**遷移画面上に存在している**必要があります。Jira は、その遷移の画面にないフィールドを設定しようとする遷移を拒否します。 +* Jira Cloud の現行のワークフローエディタで構築されたワークフローでは、イシューが完了系のステータスに移行する際、サイトのデフォルトの Resolution が自動的に設定されます。そのため、Resolution が必須であるというだけでは、そこでの単純な遷移がブロックされることはなく、このペイロードで `"resolution"` を指定する実際上の目的は、サイトのデフォルト値の代わりに*意味のある*値(例えば *False Positive*)を選択することにあります。クラシックエディタや Marketplace のバリデータアプリで構築されたワークフローでは、依然として Resolution が厳格に必須とされる場合があります。 +* 再オープンの遷移では、通常ワークフロー自体が Resolution をクリアするため、**Reopen Transition fields** には通常、ワークフローが必要とするカスタムフィールドのみを指定すれば十分です。 + +**注記:** + +* 同じ JSON が、その製品またはエンゲージメントの*すべての*クローズ(または再オープン)の遷移で送信されます。値は固定であり、検出事項ごとに変わることはありません。処理内容ごとに異なるフィールドが必要な場合(例えば、誤検知の検出事項と修正済みの検出事項とで異なる Resolution を使いたい場合)は、ステータスごとの遷移フィールドマッピングに対応した DefectDojo Pro Jira Integrator を使用してください。 +* 値の形式は Jira の REST API と同じです。テキストフィールドには文字列、resolution には `{"name": ...}`、複数選択フィールドには `[{"name": ...}]` などを使用します。 +* これらの設定が未設定または不完全な状態で遷移が拒否されていた場合、設定を修正すればずれは解消されます。次回その検出事項のステータスがプッシュされる際に、設定済みのフィールドで遷移が再試行されます。 +* どちらの設定も `/api/v2/jira_projects/` REST エンドポイント(`close_transition_fields` / `reopen_transition_fields`)から利用できるため、API 経由でも管理できます。 +* これらのフィールドは、検出事項が**削除された**ことにより DefectDojo がイシューをクローズする場合にも適用されます。値は、クローズがキューに入れられた時点で取得されます。 + +#### Jira labels + +イシューが Jira に作成される際に付与したい該当のラベルを選択します(例: **DefectDojo**、**YourProductName** など)。 + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_6.png) + +#### Default assignee + +Jira でのデフォルトの担当者名です。空欄のままにした場合、DefectDojo はイシュー作成時に Jira スペースのデフォルトの動作に従います。 + +### Jira Project Settings + +#### Enabled + +このトグルは、DefectDojo がこの製品の検出事項を Jira にプッシュするかどうかを制御します。無効化しても、DefectDojo によって作成された既存の Jira チケットが削除・変更されることはありませんが、それ以降の更新や新規イシューの作成は行われなくなります。 + +Jira 連携をインスタンスから削除できるのは、関連するイシューが1つも作成されていない場合のみです。イシューがすでに作成されている場合、Jira インスタンスを DefectDojo から完全に削除する方法はありません。 + +#### Add Vulnerability Id as a Jira label + +これを有効にすると、脆弱性 ID のデータを自動的に Jira のラベルとして追加できます。脆弱性 ID は各セキュリティツールから検出事項に追加されるもので、Common Vulnerabilities and Exposures(CVE)ID の場合もあれば、その検出事項を報告したツール固有の別の形式である場合もあります。 + +#### Push All Issues + +チェックすると、DefectDojo はアクティブかつ検証済みの検出事項を自動的に Jira にイシューとしてプッシュします。チェックしない場合、すべての検出事項は(個別または一括プッシュで)手動で Jira にプッシュする必要があります。 + +この設定が有効な場合、検出事項のステータスが変化しても Jira のイシューは DefectDojo と同期し続けます。 + +#### Enable Engagement Epic Mapping + +DefectDojo では、エンゲージメントは一連の作業のまとまりを表します。各エンゲージメントには1つ以上のテストが含まれ、各テストには緩和が必要な1つ以上の検出事項が含まれます。Jira のエピックも同様の考え方であり、このチェックボックスを使うとエンゲージメントを Jira にエピックとしてプッシュできます。 + +* DefectDojo 上のエンゲージメント。下部に3件の検出事項がリストされている点に注目してください。 +​ +![image](images/Add_a_Connected_Jira_Project_to_a_Product_8.png) +* 同じエンゲージメントが Jira にプッシュされるとエピックになる様子。エンゲージメントの検出事項も併せてプッシュされ、エンゲージメント内に子イシューとして存在します。 + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_9.png) + +#### Push Notes + +有効にすると、Jira のコメントが該当する DefectDojo の検出事項の Notes に反映されます。逆に、検出事項のメモは該当する Jira のイシューにコメントとして追加されます。 + +#### Send SLA Notifications As Comments + +有効にすると、DefectDojo の Service Level Agreement のルールに違反したイシューには、その旨を示すコメントが Jira のイシューに追加されます。これらのコメントは、イシューが解決するまで毎日投稿されます。 + +Service Level Agreement は、DefectDojo の **Configuration \> SLA Configuration** で設定し、各製品に割り当てることができます。 + +#### Send Risk Acceptance Expiration Notifications As Comment + +有効にすると、関連する DefectDojo のリスク受容が期限切れになったイシューには、その旨を示すコメントが Jira のイシューに追加されます。これらのコメントは、イシューが解決するまで毎日投稿されます。 + +### Engagement-Level Jira Settings + +デフォルトでは、エンゲージメントは**製品から Jira 設定を継承**します。ただし、個々のエンゲージメントごとに Jira 設定を上書きすることもできます。 + +エンゲージメントレベルの Jira 設定にアクセスするには、エンゲージメントの ⚙️(歯車)メニューをクリックし、**Jira Project Settings** ページを開きます。 + +ここから **Inherit from Product** のチェックを外し、**Project Key**、**Issue Template、Custom Fields、Jira Labels、Default Assignee** などの設定にエンゲージメント固有の値を指定できます。 + +エンゲージメントに独自の Jira プロジェクトが割り当てられると、それ以降は製品から設定を継承できなくなる点に注意してください。 + +![image](images/Creating_Issues_in_Jira_5.png) + +## Step 4: Configure Bidirectional Sync: Jira Webhook + +Jira連携ではWebhookによる双方向同期が可能です。DefectDojoは一意のアドレスでJiraの通知を受信し、設定内容に応じて、検出事項にJiraのコメントを反映したり、Jira経由で検出事項を解決したりできます。 + +### Locating your Jira Webhook URL + +Jira Webhookは、サイドバーの **Enterprise Settings > System Settings** にあるシステム設定フォームの **Jira Integration Settings** に記載されています。 + +DefectDojoが受信したJiraの通知を処理できるようにするには、同じページで **Enable Jira Web Hook** にもチェックを入れる必要があります。このチェックボックス、または **Enable Jira Integration**([Step 1](#step-1-enable-the-jira-integration-in-system-settings)を参照)のいずれかがオフになっている場合、受信したWebhookは無視されます。 + +![image](images/Configuring_the_Jira_DefectDojo_Webhook.png) + +### Creating the Jira Webhook + +1. `**https:// \ /plugins/servlet/webhooks**` にアクセスします。 +2. 「Create a Webhook」をクリックします。 +3. 「URL」というラベルの付いたフィールドに次を入力します: `https:// \<**YOUR DOJO DOMAIN**\> /jira/webhook/ \<**YOUR GENERATED WEBHOOK SECRET**\>`。Web Hook Secretは、上記のJira Integration Settingsに記載されています。 +4. 「Comments」の下で「Created」を有効にします。「Issue」の下で「Updated」を有効にします。 +5. JiraインスタンスがDefectDojoインスタンスの使用するSSL証明書を信頼していることを確認してください。JIRA CloudでDefectDojoを使用する場合、[グローバルに信頼された認証局によって署名された有効なSSL/TLS証明書](https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-registering-webhooks-with-non-secure-urls/)を使用する必要があります。 + +このWebhookを使用するために、Jira側でSecretを作成する必要はありません。SecretはDefectDojoのURLに組み込まれているため、完全なURLをJiraのWebhookフォームに追加するだけで十分です。 + +受信するWebhookリクエストは、そのURLに含まれるSecretによって認証されます。そのため、完全なURLは認証情報として扱い、非公開に保ってください。 + +#### Testing the Webhook + +DefectDojoの検出事項から1つ以上のIssueを作成したら、そのうちの1つの検出事項にメモを追加することでWebhookをテストできます。設定が正しければ、そのメモはJiraのWebhookによってIssueへのコメントとして受信されるはずです。 + +これが正しく機能しない場合、Jiraインスタンス側のファイアウォールがWebhookをブロックしていることが原因である可能性があります。 + +* DefectDojoのFirewall Rulesには **Jira Cloud** 用のチェックボックスがあり、DefectDojoがJiraからのWebhookメッセージを受信できるようにするには、これを有効にする必要があります。 + +### Alternative: Using Jira Automation (Send web request) + +Jiraインスタンスによっては、`/plugins/servlet/webhooks` 以下のシステムWebhookが許可されていない場合があります。たとえば、その管理領域へのアクセスが制限されており、**Jira Automation** のルールのみが許可されている場合です。そのような場合でも、Automationの **Send web request** アクションを使用して、同じDefectDojo Webhookエンドポイントにポストすることで、同じ双方向同期を実現できます。 + +DefectDojoのWebhookエンドポイントは、`Content-Type: application/json` を指定し、URLパスに有効なSecretを含む任意のHTTP `POST` を受け付けます。リクエストがJiraのシステムWebhook機構から送信されたものである必要は**ありません**。そのため、Automationの「Send web request」アクションはそのまま代替手段として機能します。 + +#### Prerequisites + +システムWebhookと同じ前提条件が適用されます。 + +* ⚙️ **Configuration > System Settings** ページで、**Enable JIRA integration** と **Enable JIRA web hook** の両方がチェックされていること。 +* 同じページで、空でない **Jira webhook secret** が設定されていること。このSecretに使用できる文字は `A-Z`、`a-z`、`0-9`、`_`、`-` のみです。 +* 検出事項(またはFinding Group)がすでにJira Issueにリンクされていること。IssueがDefectDojoの検出事項にリンクされていない場合、リクエストは受け付けられます(HTTP `200`)が、何のアクションも行われません。 + +#### How DefectDojo processes the request + +* DefectDojoはトップレベルの `webhookEvent` フィールドによって処理を分岐します。処理されるのは `"jira:issue_updated"` と `"comment_created"` のみで、それ以外の値は受け付けられますが無視されます。Automationはこのフィールドを自動的に追加**しない**ため、リクエストボディに自分で含める必要があります。 +* そのため、リクエストの **Body** を **Custom data** に設定し、以下のJSONを指定してください。**Empty** および **Jira issue data** のBodyオプションには必要な `webhookEvent` フィールドが含まれないため、DefectDojoはそれらを無視します。 +* このエンドポイントは、更新が適用されたかどうかにかかわらず、常にHTTP `200` を返します。成功したか失敗したかはレスポンスボディとDefectDojoのログでのみ確認できます。Automationの監査ログに表示される `200` は、それ単体で更新が検出事項に反映されたことを保証する**ものではありません**。 + +#### Rule 1 — Issue updated + +以下の内容でAutomationルールを作成します。 + +* **Trigger:** *Issue transitioned*(または、同期対象のフィールドが変化したときに発火する別のトリガー。例: StatusでのField value changed)。 +* **Action:** *Send web request* + * **Web request URL:** `https:///jira/webhook/` + * **HTTP method:** `POST` + * **Web request body:** *Custom data* + * **Headers:** `Content-Type: application/json` + * **Custom data:** + +```json +{ + "webhookEvent": "jira:issue_updated", + "issue": { + "id": "{{issue.id}}", + "fields": { + "updated": "{{issue.updated}}", + "resolution": null, + "status": { "statusCategory": { "key": "{{issue.status.statusCategory.key}}" } }, + "assignee": { "name": "{{issue.assignee.accountId}}", "displayName": "{{issue.assignee.displayName}}" } + } + } +} +``` + +Issue更新に関する制約: + +* `issue.id` は、Issueキー(例: `PROJ-123`)ではなく、**数値のJira内部Issue ID**(`{{issue.id}}`)である必要があります。DefectDojoはこの数値IDを使って更新対象の検出事項を照合します。 +* `resolution` と `updated` の両フィールドは常に存在している必要があります。`resolution` は `null` でも構いませんが、どちらかのフィールドが欠けている場合、リクエストは受け付けられ(`200`)ますが、何も処理されずに無視されます。 +* ステータスの同期と自動緩和は `status.statusCategory.key` によって制御されます。Jira側の値は `new`(To Do)、`indeterminate`(In Progress)、`done`(Done)です。検出事項が緩和済みになるのは、Issueが実際にクローズされた場合のみであり、resolutionの値がたまたま存在するというだけでは緩和されません。 + +#### Rule 2 — Issue commented + +2つ目のAutomationルールを以下の内容で作成します。 + +* **Trigger:** *Issue commented* +* **Action:** *Send web request* — ルール1と同じURL、メソッド、ヘッダー、*Custom data* のBodyオプションを使用し、Bodyの内容は以下の通りです。 + +```json +{ + "webhookEvent": "comment_created", + "comment": { + "self": "https:///rest/api/2/issue/{{issue.id}}/comment/{{comment.id}}", + "body": "{{comment.body}}", + "updateAuthor": { "name": "{{comment.author.accountId}}", "displayName": "{{comment.author.displayName}}" } + } +} +``` + +コメントに関する制約: + +* `body` と `updateAuthor` の両方が存在している必要があります。 +* DefectDojoは対象のIssueを `comment.self` のURL、具体的には `.../issue//comment/...` の部分に含まれる `` から特定します。そのため、そこには `{{issue.id}}`(数値ID)を含める必要があります。 +* **Loop prevention:** コメントの投稿者がDefectDojo自身のコメント投稿に使用しているJiraアカウントと一致する場合、DefectDojoはエコーループを防ぐためそのコメントをスキップします。すべてのコメントを取り込みたい場合は、DefectDojoのJiraインスタンス設定で使用しているものとは**異なる**Jiraユーザーとして、Automationルールを実行してください。 + +#### A note on smart values + +上記で示したスマート値(`{{issue.id}}`、`{{issue.status.statusCategory.key}}`、`{{comment.author.accountId}}` など)はJira Cloudの標準的な名称ですが、インスタンスによって異なる場合があります。本番運用を開始する前に、Automationのペイロードプレビュー機能を使って、各スマート値が期待通りに解決されることを確認してください。 + +## Testing the Jira integration + +#### Test 1: Do Findings successfully push to Jira? + +Jira連携が正しく機能しているかをテストするには、DefectDojo上でJiraに関連付けられた製品に新しい空の検出事項を追加します。**Product > Findings > Add New Finding** から行います。 + +任意のタイトル、深刻度、説明を入力し、「Finished」をクリックします。その検出事項は、関連するすべてのメタデータとともにJira上でIssueとして表示されるはずです。 + +Jira Issueが正しく作成されない場合は、Notificationsでエラーコードを確認してください。 + +* DefectDojoのJira設定に関連付けられたJiraユーザーが、該当するJiraスペースでIssueを作成・更新する権限を持っていることを確認してください。 + +#### Test 2: Jira Webhooks send to DefectDojo + +Jira Webhookをテストするには、JIRA上にもIssueとして存在している検出事項(たとえば上のセクションで作成したテスト用Issue)にメモを追加します。 + +Webhookが正しく設定されていれば、そのメモはJira上でIssueへのコメントとして表示されるはずです。 + +これが正しく機能しない場合、Jiraインスタンス側のファイアウォールがWebhookをブロックしていることが原因である可能性があります。 + +* DefectDojoのFirewall Rulesには **Jira Cloud** 用のチェックボックスがあり、DefectDojoがJiraからのWebhookメッセージを受信できるようにするには、これを有効にする必要があります。 + +## Disconnecting from Jira + +Jira連携は、関連するIssueが1つも作成されていない場合にのみ、インスタンスから削除できます。Issueがすでに作成されている場合、DefectDojoからJiraインスタンスを完全に削除する方法はありません。 + +ただし、製品レベルで無効化することでJira連携を停止することはできます。(製品の ⚙️ Gearメニューからアクセスできる)**Jira Project Settings** ページで、**Enabled** トグルのチェックを外してください。これにより、DefectDojoが作成した既存のJiraチケットが削除・変更されることはありませんが、それ以降の更新は無効になります。 + +# Pushing Findings To Jira + +JIRAマッピングが設定された製品では、いくつかの方法で検出事項をJiraへIssueとしてプッシュできます。検出事項は、個別に、一括で、Finding Groupとして、または自動でプッシュすることが可能です。 + +## Push a Single Finding + +1. プッシュしたい検出事項を開きます。 +2. **☰ Finding Menu** をクリックし、**Push to Jira** を選択します。 +3. 確認を求められたらプッシュを確定します。DefectDojoはJira Issueを作成し、その検出事項にリンクします。 + +Issueが作成されると、DefectDojoは検出事項ページにJira Issueへのリンクを表示します。 + +![image](images/Creating_Issues_in_Jira_2.png) + +**Edit Finding** フォームで検出事項を編集する際に、**Push to Jira** チェックボックスをオンにすることもできます。検出事項が保存されると、Jiraへプッシュされます。 + +### Updating a Linked Jira Issue + +検出事項にすでにリンクされたJira Issueがある場合、再度 **Push to Jira** を選択すると、DefectDojo上で行われた変更が既存のJira Issueに反映されます。製品で **Push All Issues** が有効になっている場合、この同期は自動的に行われます。 + +### Unlinking a Finding from Jira + +検出事項とJira Issueの関連付けを解除するには、**☰ Finding Menu** をクリックして **Unlink From Jira** を選択します。これによりDefectDojo側のリンクは削除されますが、Jira Issue自体は削除されません。 + +## Bulk Push Findings + +Bulk Updateフォームを使用すると、複数の検出事項を一度にJiraへプッシュできます。 + +1. 検出事項の一覧で、プッシュしたい検出事項をチェックボックスで選択します。 +2. **Bulk Update** フォームを開きます。 +3. **Jira Settings** の下にある **Push to Jira** チェックボックスをオンにします。 +4. **Submit** をクリックします。 + +選択した検出事項は、Jiraへのプッシュ待ちとしてキューに登録されます。DefectDojoは、何件の検出事項がキューに登録されたかを示す確認メッセージを表示します。 + +## Push Engagements as Epics + +Jira Project Settingsで **Enable Engagement Epic Mapping** がオンになっている場合、エンゲージメントをEpicとしてJiraへプッシュできます。そのエンゲージメントの検出事項は、そのEpic内のChild Issueとしてプッシュされます。 + +エンゲージメントをEpicとしてプッシュする手順: + +1. プッシュしたいエンゲージメントを開きます。 +2. **☰ Engagement Menu** をクリックし、**Push to Jira** を選択します。 +3. 必要に応じて **Epic Name**(空欄の場合はエンゲージメント名がデフォルトで使用されます)と **Epic Priority** を指定します。 +4. **Push to Jira (Create Epic)** をチェックし、フォームを送信します。 + +## Push Finding Groups as Jira Issues + +Finding Groupsが有効になっている場合、複数の検出事項からなるグループを、検出事項ごとに個別のIssueとしてではなく、単一のIssueとしてJiraへプッシュできます。 + +Finding Groupをプッシュする手順: + +1. Finding Groupを開きます。 +2. **☰ Finding Group Menu** をクリックして **Push to Jira** を選択するか、Finding Groupを編集する際に **Push to Jira** チェックボックスをオンにします。 + +Finding Groupに関連付けられたJira Issueを削除する必要がある場合は、Jiraインスタンス側から直接削除する必要があります。 + +### Automatically Create and Push Finding Groups + +製品で **Push All Issues** が有効になっており、インポート時に **Group By** オプションが選択されている場合: + +Finding Groupsが正常に作成されている限り、個々の検出事項ではなくFinding Groupが自動的にIssueとしてJiraへプッシュされます。 + +![image](images/Creating_Issues_in_Jira_4.png) + +## Automatic Push Behaviour + +DefectDojoは、いくつかのシナリオで検出事項とその更新を自動的にJiraへプッシュできます。 + +### Push All Issues + +製品のJira Project Settingsで **Push All Issues** 設定が有効になっている場合、DefectDojoはすべての**アクティブ**かつ**検証済み**の検出事項に対して自動的にJira Issueを作成します。これにはスキャンのインポートによって作成された検出事項も含まれます。Jira Issueが作成されると、検出事項のステータスが変化した後もDefectDojoと同期し続けます。 + +### Auto-Sync on Status Changes + +**Push All Issues**、またはシステムレベルの **Finding Jira Sync** 設定が有効になっている場合、検出事項に対して特定の操作が行われると、DefectDojoはリンクされたJira Issueを自動的に更新します。 + +* **Request Review** - リンクされたJira Issue(検出事項がグループに属している場合はそのFinding GroupのJira Issue)にコメントが追加されます。 +* **Clear Review** - リンクされたJira Issueにコメントが追加されます。 +* **Close Finding** - リンクされたJira Issueがクローズを反映するよう更新されます。**Push Notes** が有効な場合は、コメントも追加されます。 + +## Jira Comments and Notes + +Jira Project Settingsで **Push Notes** が有効になっている場合: + +* Jira Issueにコメントが追加されると、同じ内容が検出事項の **メモ** セクションに追加されます。 +* 同様に、検出事項にメモが追加されると、そのメモはJira Issueにコメントとして追加されます。 + +## Jira Status Changes + +Jira Instanceの設定には、検出事項のステータス変更をトリガーする2つのJira Transitionの項目があります。 + +* Jira上で **'Close' Transition** が実行されると、関連する検出事項もクローズされ、DefectDojo上で**非アクティブ**かつ**緩和済み**とマークされます。DefectDojoはこの変更を検出事項ページの **Mitigated By** の項目に記録します。 +​ +![image](images/Creating_Issues_in_Jira_3.png) + +* Jira Issueで **'Reopen' Transition** が実行されると、関連する検出事項はDefectDojo上で**アクティブ**に設定され、**緩和済み**のステータスは解除されます。 + +## Mapping Jira Resolutions to Risk Acceptance / False Positive + +Jira Instanceの設定には、Jiraの **Resolution** をDefectDojoの検出事項ステータスにマッピングするための、任意設定の2つのフィールドがあります。 + +* **Risk Accepted Finding Mapping Resolution** — Jira Issueがこのresolutionでクローズされると、リンクされた検出事項はDefectDojo上で**リスク受容済み**になります。 +* **False Positive Finding Mapping Resolution** — Jira Issueがこのresolutionでクローズされると、リンクされた検出事項はDefectDojo上で**誤検知**になります。 + +### Status vs Resolution: A Common Point of Confusion + +これらのフィールドがマッピングするのはJiraの **Resolution** であり、Jiraの **Status** ではありません。StatusとResolutionは、Jiraにおける独立した2つの概念です。StatusはIssueがワークフロー上のどこにあるか(Open、In Progress、Doneなど)を表し、Resolutionはどのように解決されたか(Fixed、Won't Do、Duplicate、False Positiveなど)を表します。 + +### Prerequisite: A "Set issue resolution" post-function on the Jira workflow transition + +Jiraのワークフローエンジンは、Resolutionフィールドを自動的には設定しません。特定のResolutionでIssueをクローズすべき各transitionには、そのtransition自体に **Set issue resolution** ポストファンクションを設定する必要があります。このポストファンクションがないと、Issueは新しいStatusに遷移してもResolutionは空のままとなり、DefectDojo側のマッピングは照合対象を得られません。 + +Jiraの管理者は、**Project Settings → Workflows → (edit workflow) → (select the closing transition) → Post Functions → Add post function → Set issue resolution** からこのポストファンクションを追加できます。 + +# Custom Fields in Jira + +DefectDojoは現時点で、Issue固有の情報をこれらのCustom Fieldsに渡すことをサポートしていません。これらのフィールドは、Issue作成後にJira上で手動で更新する必要があります。各Custom Fieldは、DefectDojoからはデフォルト値でのみ作成されます。 + + Jira Cloudでは現在、アプリ内で直接デフォルトのCustom Field値を作成できます。設定方法の詳細は[Atlassianのカスタムフィールドに関するドキュメント](https://support.atlassian.com/jira-cloud-administration/docs/configure-a-custom-field/)を参照してください。 + +DefectDojoに組み込まれているJira Issue Type(**Bug、Task、Story**、**Epic**)は、そのまま使用できるように設定されています。DefectDojoのデータフィールドは、Jiraの対応するフィールドに自動的にマッピングされます。DefectDojoはデフォルトで、新規作成するすべてのIssueにPriority、Labels、Reporterを割り当てます。 + +Jiraの設定によっては、Issueを作成する前に追加のカスタムフィールドを考慮する必要がある場合があります。この手順に従うことで、DefectDojo -> Jira連携でこれらのカスタムフィールドを扱えるようになり、Issueが確実に作成されるようになります。これらのカスタムフィールドは、DefectDojoからリンクされたJiraインスタンスへ送信されるすべてのAPI呼び出しに追加されます。 + +Jiraですでにカスタムフィールドを使用していない場合は、この手順に従う必要はありません。 + +1. Jira内のCustom Fieldsの名前を記録する(**Jira UI**) +2. 新しいCustom FieldsのKey値を特定する(Jira Field Spec Endpoint) +3. Key値を参照として、各Custom Fieldで有効なデータ形式を確認する(Jira Issue Endpoint) +4. すべてのCustom Field Keyと有効なデータを追跡するためのField Reference JSONブロックを作成する(Jira Issue Endpoint) +5. JiraからCustom Fieldsを作成できるように、関連付けられたDefectDojoの製品にJSONブロックを保存する(DefectDojo UI) +6. 作業内容をテストし、必要なデータがすべてJiraから正しく流れていることを確認する + +#### Step 1: Record the names of your Custom Fields in Jira + +Jiraは、Date Picker、Custom Label、Radio Buttonなど、さまざまなContext Fieldsをサポートしています。これらのContext Fieldsはそれぞれ異なるKey値を持っており、Jira APIから確認できます。 + +必要なCustom Fieldの名前をそれぞれ書き出しておいてください。次のステップでJira APIから検索する際に必要になります。 + +**Example of a Custom Field list (your Custom Field names will be different):** + +* DefectDojo Custom URL Field +* Another example of a Custom Field +* ... + +#### Step 2: Finding your Jira Custom Field Key Values + +まず、Jiraインスタンス全体のField Spec URLにアクセスするところから始めます。 + +Field Spec URLの例を以下に示します。 + +`https://yourcompany-example.atlassian.net/rest/api/2/field` + +このAPIは長いJSON文字列を返すので、読みやすいテキストに整形してください(コードエディタ、ブラウザ拡張機能、またはなどを使用します)。 + +このURLから返されるJSONには、Jiraのすべてのカスタムフィールドが含まれていますが、そのほとんどはDefectDojoには関係がなく、値は `"Null"` になっています。このAPIレスポンス内の各オブジェクトは、Jiraの異なるフィールドに対応しています。Jira UIで作成した各Custom Fieldの名前と一致する `"name"` 属性を持つオブジェクトを探し、その「key」属性の値を記録する必要があります。 + +![image](images/Using_Custom_Fields.png) + +JSON出力の中で一致するオブジェクトを見つけたら、「key」の値を特定できます。この例では `customfield_10050` です。 + +Jiraは各Custom Fieldに対して異なるkey値を生成しますが、これらのkey値は一度作成されると変わりません。今後新たにCustom Fieldを作成した場合、そのフィールドには新しいkey値が割り当てられます。 + +**Expanding our Custom Field list:** + +* "DefectDojo Custom URL Field" = customfield_10050 +* "Another example of a Custom Field" = customfield_12345 +* ... + +#### Step 3 - Finding the Custom Fields on a Jira Issue + +ステップ2で記録したCustom Fieldsを含むIssueをJira内で探します。タイトルのIssueキー(「`EXAMPLE-123`」のような形式)をコピーし、次のURLにアクセスします。 + +`https://yourcompany-example.atlassian.net/rest/api/2/issue/EXAMPLE-123` + +これにより、別のJSON文字列が返されます。 + +先ほどと同様に、このAPI出力には `null` 値を持つ多数の `customfield_##` オブジェクトパラメータが含まれています。これらはJiraがデフォルトで追加するカスタムフィールドで、このIssueには関係ありません。また、前のステップで確認したCustom Field Key値と一致する `customfield_##` の値も含まれています。Field Spec出力とは異なり、これらのカスタムフィールドを識別する名前は表示されないため、ステップ2でkey値を記録しておく必要があったのです。 + +![image](images/Using_Custom_Fields_2.png) + +**Example:** +ステップ2で記録した通り、`customfield_10050` はDefectDojo Custom URL Fieldを表しています。`EXAMPLE-123` のIssueでは、`customfield_10050` の値が `"https://google.com"` であることが確認できます。 + +#### Step 4 - Creating a JSON Field Reference from each Jira Custom Field Key + +次に、リストにある各Custom Fieldの値を取得し、(参照用として使う)JSONオブジェクトに格納します。リストに対応しないCustom Fieldは無視して構いません。 + +このJSONオブジェクトには、新規Jira Issueに使用するすべてのデフォルト値が含まれます。チームが「変更が必要なデフォルト値」だとひと目でわかる名前を使うことをお勧めします。例: 「`change-me.com`」「`Change this paragraph.`」など。 + +**Example:** + +ステップ3から、Jiraが「`customfield_10050`」にはURL文字列を期待していることがわかりました。これを使ってJSONオブジェクトの例を作成できます。 + +「`customfield_67890`」として識別された、DefectDojo関連の短いテキストフィールドも見つかったとします。2回目のAPI出力でこのフィールドを確認し、対応する値を見て、そのままJSONオブジェクトの例にも参照値として記載します。 +​ +Custom Fieldsを追加していくと、JSONオブジェクトは次のようになります。 + +``` +{ + "customfield_10050": "https://change-me.com", + "customfield_67890": "This is the short text custom field." +} +``` + +DefectDojoに関係するJiraのカスタムフィールドがすべてJSON Field Referenceに追加されるまで、この手順を繰り返します。 + +#### Data types & Jira Syntax + +Dateフィールドなど、一部のフィールドはJira内の複数のカスタムフィールドに関連している場合があります。その場合は、両方のフィールドをJSON Field Referenceに追加する必要があります。 + +``` + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", +``` + +Labelフィールドなど、他のフィールドは文字列のリストとして管理される場合があります。JSON Field ReferenceがJiraのAPI出力と一致する形式になっていることを確認してください。 + +``` +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], +``` + +他のカスタムフィールドには、Field Referenceから削除すべき追加の文脈情報が含まれる場合があります。たとえば、Custom Multichoice Fieldは、フィールドの現在の値を保持する余分なブロックをAPI出力に含んでいるため、これを削除する必要があります。 + +* このフィールドから余分なオブジェクトを削除する必要があります。 + +``` +"customfield_10047": [ + { + "value": "A" + }, + { + "self": "example.url...", + "value": "C", + "id": "example ID" + } +] +``` +* 代わりに、以下のように短縮し、2番目の部分は無視できます。 + +``` +"customfield_10047": [ + { + "value": "A" + } +] +``` + +#### Example Completed Field Reference + +各カスタムフィールドが何を表すかを説明するインラインコメント付きの、完成したJSON Field Referenceを以下に示します。これはあらゆるケースを網羅する例として示しています。実際のJSONは、Issue作成時に使用したいCustom Valueに応じて、異なるkey値とデータになります。 + +``` +{ + "customfield_10050": "https://change-me.com", + + "customfield_10049": "This is a short text custom field", + +// two different fields, but both correspond to the same custom date attribute + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", + +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], + +// custom number field + "customfield_10043": 0, + +// custom paragraph field + "customfield_10044": "This is a very long winded way to say CHANGE ME PLEASE", + +// custom radio button field + "customfield_10045": { + "value": "radio button option" + }, + +// custom multichoice field + "customfield_10047": [ + { + "value": "A" + } + ], + +// custom checkbox field + "customfield_10039": [ + { + "value": "A" + } + ], + +// custom select list (singlechoice) field + "customfield_10048": { + "value": "1" + } +} +``` + +#### Step 5 - Adding the Custom Fields to a DefectDojo Product + +これで、(製品の ⚙️ Gearメニューからアクセスできる)Jira Project Settingsページで、これらのカスタムフィールドを関連付けられたDefectDojoの製品に追加できます。JSON Field Referenceをプレーンテキストとして **Custom Fields** ボックスに貼り付けて保存してください。 + +#### Step 6 - Testing your Jira Custom Fields from a new Finding: + +これで、Jiraに関連付けられた製品で新しい検出事項を作成すると、含まれるJSONブロックに従って、これらのCustom FieldsがすべてJira上に自動的に作成されます。これらのCustom Fieldsは、デフォルト値(「change-me-please」など)で作成されます。 + +DefectDojoの製品内で、Findings > Add New Findingページに移動します。検出事項がJiraへプッシュされるように、**アクティブ**かつ**検証済み**の両方になっていることを確認し、Jira側でCustom Fieldsが不整合なく正常に作成されていることを確認してください。 diff --git a/docs/content/connectors/downstream/_index.de.md b/docs/content/connectors/downstream/_index.de.md new file mode 100644 index 00000000000..d93abbb7bef --- /dev/null +++ b/docs/content/connectors/downstream/_index.de.md @@ -0,0 +1,19 @@ +--- +title: Downstream Connectors +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +aliases: +- /de/issue_tracking/pro_integration/ +--- diff --git a/docs/content/connectors/downstream/_index.es.md b/docs/content/connectors/downstream/_index.es.md new file mode 100644 index 00000000000..29319eed84b --- /dev/null +++ b/docs/content/connectors/downstream/_index.es.md @@ -0,0 +1,19 @@ +--- +title: Conectores descendentes +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +aliases: +- /es/issue_tracking/pro_integration/ +--- diff --git a/docs/content/connectors/downstream/_index.fr.md b/docs/content/connectors/downstream/_index.fr.md new file mode 100644 index 00000000000..14845fae587 --- /dev/null +++ b/docs/content/connectors/downstream/_index.fr.md @@ -0,0 +1,19 @@ +--- +title: Connecteurs en aval +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +aliases: +- /fr/issue_tracking/pro_integration/ +--- diff --git a/docs/content/connectors/downstream/_index.ja.md b/docs/content/connectors/downstream/_index.ja.md new file mode 100644 index 00000000000..1223814da03 --- /dev/null +++ b/docs/content/connectors/downstream/_index.ja.md @@ -0,0 +1,19 @@ +--- +title: ダウンストリームコネクタ +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 3 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +aliases: +- /ja/issue_tracking/pro_integration/ +--- diff --git a/docs/content/connectors/downstream/about.de.md b/docs/content/connectors/downstream/about.de.md new file mode 100644 index 00000000000..baf49538983 --- /dev/null +++ b/docs/content/connectors/downstream/about.de.md @@ -0,0 +1,137 @@ +--- +title: Downstream Connectors +weight: 1 +audience: pro +aliases: +- /de/en/share_your_findings/integrations +- /de/issue_tracking/pro_integration/integrations/ +--- + +**Verfügbarkeit:** Downstream Connectors sind für jede DefectDojo Pro-Instanz allgemein verfügbar und aktiv, sowohl Cloud als auch On-Premise. Es gibt nichts zu aktivieren, und sie werden auf der Seite „Feature Flags" nicht mehr aufgeführt. + +Mit Downstream Connectors können Sie Ihre Findings und Finding Groups an Ticket-Tracking-Systeme übertragen, um die Behebung von Sicherheitsproblemen einfach in den bestehenden Entwicklungsworkflow Ihres Teams zu integrieren. + +Unterstützte Downstream Connectors: +- Azure Devops +- Bitbucket +- Freshservice +- GitHub +- GitLab Boards +- Jira +- Linear +- Opsgenie +- PagerDuty +- ServiceDesk Plus +- ServiceNow +- ServiceNow SecOps / Vulnerability Response +- Shortcut +- Zendesk + +## Öffnen der Seite „Downstream Connectors" + +Die Seite „Downstream Connectors" finden Sie in der Seitenleiste unter **Import > Connectors > Downstream Connectors**. + +![Bild](images/integrators_3.png) + +## Einrichten eines Downstream Connectors + +Ein Downstream Connector wird mit drei Hauptkomponenten konfiguriert: + +- **Integration Instance**: Dies ist die primäre Verbindungsmethode, die DefectDojo für ein Drittsystem verwendet. Die Instance enthält Angaben wie eine Bezeichnung, einen Speicherort und Zugangsdaten für die Verbindung sowie alle weiteren vom Anbieter benötigten Informationen. +- **Issue Tracker Mapping**: Hier werden die Mapping-Informationen gespeichert - sie legen fest, welche Details für die Verbindung zu einem bestimmten "Projekt" beim Anbieter erforderlich sind. Diese Details umfassen den Namen oder die ID des "Projekts" sowie die Zuordnung von Finding-Schweregrad und -Status zum entsprechenden Feld im "Ticket" des Anbieters. Sie können mehrere Mappings konfigurieren, wenn Sie Findings an mehrere "Projekt"-Standorte übertragen möchten. +- **Issue Tracker Assignment**: Hier werden DefectDojo-Produkte und -Engagements einem bestimmten Issue Tracker Mapping zugewiesen, mit Optionen je Produkt/Engagement, die festlegen, wie ein Finding an ein bestimmtes Anbietersystem übertragen wird. + +Diese Komponenten sind hierarchisch aufgebaut: Jede **Instance** hat eine oder mehrere **Mappings**, die wiederum eine oder mehrere **Tracker Assignments** haben. + +![Bild](images/integrators_2.png) + +## Übertragen von Findings und Finding Groups + +Sobald diese Komponenten konfiguriert sind, können Findings und Finding Groups auf zwei Arten an einen Issue Tracker gesendet werden; manuell oder automatisch. + +- **Manuell**: Findings und Finding Groups in einem Produkt/Engagement mit einem zugewiesenen **Issue Tracker Mapping** verfügen über die Option "Push to Integrator". Dadurch wird im Issue Tracker ein Issue mit den entsprechenden Informationen zum Finding/zur Finding Group erstellt. Push to Integrator kann auch verwendet werden, um ein bestehendes Issue zu aktualisieren. + +### Findings automatisch übertragen + +Findings können auch automatisch übertragen werden, wobei das **Issue Tracker Assignment** bestimmt, wie diese Objekte übertragen werden. Es gibt vier Optionen: + +- **Only Explicitly Publish Changes to Target**: Diese Option deaktiviert jedes automatische Verhalten im zugewiesenen Produkt oder Engagement. Ein Finding oder eine Finding Group kann dann nur wie oben beschrieben explizit übertragen werden. +- **Automatically Link New Finding to Target**: Wenn im zugewiesenen Produkt oder Engagement neue Findings oder Finding Groups **erstellt** werden, überträgt DefectDojo das Objekt automatisch an den Issue Tracker. Nach der Erstellung werden diese Findings oder Finding Groups nur durch eine manuelle Push-to-Integrator-Aktion aktualisiert. +- **Automatically Update Existing Link on Finding Edit**: Wenn Findings oder Finding Groups im zugewiesenen Produkt oder Engagement **aktualisiert** werden, wird das Objekt automatisch an den Issue Tracker übertragen, sofern bereits manuell eine Verknüpfung erstellt wurde. +- **Automatically Link New and Update Existing Link on Finding Edit**: Wenn Findings oder Finding Groups im zugewiesenen Produkt oder Engagement erstellt **oder** aktualisiert werden, wird das Objekt automatisch an den Issue Tracker übertragen. + +#### Push-Filter + +Jedes Issue Tracker Assignment kann optional eingrenzen, welche Findings **automatisch** übertragen werden: + +- **Minimum Severity**: Erstellt automatisch nur Tickets für Findings mit dem ausgewählten Schweregrad oder höher. Leer lassen, um jeden Schweregrad einzubeziehen. +- **Active findings only**: Erstellt automatisch nur Tickets für aktive Findings und überspringt solche, die bereits als Mitigated, False Positive oder Risk Accepted markiert sind, wenn das Assignment sie zum ersten Mal sieht. + +Diese Filter gelten nur für die automatische **Erstellung**. Aktualisierungen an einem Finding, das bereits ein verknüpftes Ticket hat, werden immer gesendet, sodass Statusänderungen (einschließlich Schließungen) weiterhin übertragen werden. Ein manueller **Push to Integrator** ignoriert die Filter immer. Belassen Sie beide bei ihren Standardwerten, bleibt das ursprüngliche Verhalten erhalten, bei dem jedes Finding übertragen wird. + +#### Mehrere Produkte zuweisen + +Ein Issue Tracker Assignment zielt auf ein einzelnes Produkt oder Engagement ab. Um mehrere Assets abzudecken, erstellen Sie ein Assignment pro Produkt (oder Engagement). Wenn zusätzlich anbieterspezifische Felder je Asset unterschiedlich sein sollen — etwa eine abweichende ServiceNow **Assignment group** oder **Assigned to**, oder ein anderes Jira-Projekt — erstellen Sie für jedes Asset ein eigenes Issue Tracker Mapping (mit eigenen Custom Field Mappings) und weisen Sie jedes Assignment dem passenden Mapping zu. + +## Darstellung von Issue-Tracker-Tickets + +Issue-Tracker-Tickets werden beim Anzeigen und Auflisten von +Findings und Finding Groups durch eine Reihe von Symbolen in der Spalte "Integrator Tickets" dargestellt + +Symbole von links nach rechts: + +- **Integration Type**: Der Typ des Issue Trackers, mit dem das Ticket verknüpft ist +- **Ticket ID**: Die ID des Tickets, wie vom Issue Tracker definiert +- **Ticket Link**: Der direkte Link zum Ticket, wie vom Issue Tracker definiert +- **Changelog**: Gibt an, wann das Issue-Tracker-Ticket mit einem Finding oder einer Finding Group verknüpft wurde, sowie den Zeitpunkt der letzten Änderung des Tickets durch DefectDojo + +![Bild](images/integrators_1.png) + +## Anbieterspezifische Anforderungen + +Jeder Anbieter hat unterschiedliche Anforderungen daran, wie DefectDojo mit ihm interagieren muss. Dies kann in Form eines Authentifizierungsmechanismus, zusätzlicher Felder je "Projekt" oder Schweregrad-/Status-Zuordnungen erfolgen. + +Die vollständige Liste der Anforderungen finden Sie auf den folgenden anbieterspezifischen Seiten: + +- [Azure Devops](/connectors/downstream/downstream_toolreference/#azure-devops-boards) +- [Bitbucket](/connectors/downstream/downstream_toolreference/#bitbucket) +- [Freshservice](/connectors/downstream/downstream_toolreference/#freshservice) +- [GitHub](/connectors/downstream/downstream_toolreference/#github) +- [GitLab Boards](/connectors/downstream/downstream_toolreference/#gitlab) +- [Jira](/connectors/downstream/downstream_toolreference/#jira) +- [Linear](/connectors/downstream/downstream_toolreference/#linear) +- [Opsgenie](/connectors/downstream/downstream_toolreference/#opsgenie) +- [PagerDuty](/connectors/downstream/downstream_toolreference/#pagerduty) +- [ServiceDesk Plus](/connectors/downstream/downstream_toolreference/#servicedesk-plus) +- [ServiceNow](/connectors/downstream/downstream_toolreference/#servicenow) +- [ServiceNow SecOps / Vulnerability Response](/connectors/downstream/downstream_toolreference/#servicenow-secops) +- [Shortcut](/connectors/downstream/downstream_toolreference/#shortcut) +- [Zendesk](/connectors/downstream/downstream_toolreference/#zendesk) + +## Fehlerbehandlung und Debugging + +Downstream Connectors können aus verschiedenen Gründen Fehler verursachen, etwa Konnektivität, Authentifizierung, Berechtigungen usw. Um die Fehlersuche +zu erleichtern, verfügt jedes Issue Tracker Mapping über eine Fehlertabelle, die anzeigt, wann der Fehler aufgetreten ist, aus welchem Grund er +aufgetreten ist, und welches Finding oder welche Finding Group nicht übertragen werden konnte. + +Diese Fehler finden Sie auf der Seite „All Issue Tracker Mappings & Assignments" in der Spalte ⚠️ Total Errors. + +![Bild](images/integrators_4.png) + +Ein Klick auf den Eintrag Total Errors führt Sie zu einer Seite mit ausführlicheren Beschreibungen der Fehler zu diesem Downstream Connector. + +### Alle Fehlschläge an einem Ort sehen + +Die Fehlertabelle je Mapping deckt einen Downstream Connector ab. [Diagnostics](/admin/diagnostics/pro__diagnostics/) deckt alle davon ab, zusammen mit jedem anderen Integrationsversuch auf der Instanz — Upstream Connectors, Imports, Jira, SSO und die Rules Engine — mit derselben Filter- und Sortierfunktion über alles hinweg. + +Verwenden Sie sie, wenn die Frage über ein einzelnes Mapping hinausgeht: + +* ein Versuch, der **nie abgeschlossen** wurde statt fehlzuschlagen, was keine Fehlertabelle meldet, weil kein Fehler aufgetreten ist +* ob ein Fehlschlag auf eine Integration beschränkt ist oder gleichzeitig bei mehreren auftritt +* wer oder was einen Versuch ausgelöst hat, und gegen welche Konfiguration + +In einem Fehler zitierte Zugangsdaten werden entfernt, bevor die Zeile gespeichert wird, und die vollständigen technischen Details sind auf Superuser beschränkt. + +## Seitenlayout „Downstream Connectors" + +Downstream Connectors werden in zwei Abschnitten aufgeführt, **Configured Connectors** und **Available Connectors**, jeweils alphabetisch sortiert mit einer Anzahl der angezeigten Einträge neben der Überschrift. Ein Tool kann mehrere Konfigurationen enthalten; jede ist eine eigene Kachel, betitelt mit ` -