From ae50ceb3b8028aeacb54295781bdfc045891b1ed Mon Sep 17 00:00:00 2001 From: Greg Anderson Date: Tue, 11 Aug 2026 23:02:03 -0600 Subject: [PATCH 1/4] docs: add German translations and multilingual support Adds a German locale to the documentation site and the theme plumbing a second language needs. Content: 246 German pages covering the core guides (get started, import data, triage, asset modelling, metrics, issue tracking, admin, automation, connectors, federal compliance, sensei, help, navigation). Changelogs and the supported_tools parser reference are out of scope for this pass. Pages use the filename-suffix layout (page.de.md) so the English tree stays where it is and open pull requests keep applying. Theme: about 60 hardcoded English strings in the layouts move to i18n lookups (navigation, homepage cards, hero, footer, aria labels), with i18n/en.toml and i18n/de.toml holding them and a per-language menu file for the sidebar. Two bugs surfaced while wiring this up and are fixed here: baseof.html emitted a fixed lang attribute and no dir attribute, and the header active-state check matched every navigation item once URLs carried a language prefix. Navigation entries for untranslated sections point at the English pages so nothing 404s. TRANSLATIONS.md documents the layout, the scope, how to add a language, and the quarterly refresh. These are machine translations checked for structural integrity, not reviewed for meaning. A native-speaker pass is recommended before treating the German pages as authoritative. Co-Authored-By: Claude Opus 5 --- docs/TRANSLATIONS.md | 90 + docs/config/_default/hugo.toml | 2 +- docs/config/_default/languages.toml | 19 +- docs/config/_default/menus/menus.de.toml | 93 + docs/config/_default/params.toml | 2 +- docs/content/_index.de.md | 6 + docs/content/admin/admin_intro/_index.de.md | 17 + docs/content/admin/admin_intro/intro.de.md | 10 + .../admin/diagnostics/PRO__diagnostics.de.md | 169 ++ docs/content/admin/diagnostics/_index.de.md | 25 + .../feature_flags/PRO__feature_flags.de.md | 143 + docs/content/admin/feature_flags/_index.de.md | 23 + docs/content/admin/notifications/_index.de.md | 17 + .../notifications/about_notifications.de.md | 103 + .../configure_personal_notifs.de.md | 35 + .../configure_system_notifs.de.md | 44 + .../notifications/email_slack_teams.de.md | 143 + docs/content/admin/sso/PRO__auth0.de.md | 33 + .../sso/PRO__authorization_connectors.de.md | 81 + docs/content/admin/sso/PRO__azure_ad.de.md | 58 + .../admin/sso/PRO__github_enterprise.de.md | 32 + docs/content/admin/sso/PRO__gitlab.de.md | 32 + docs/content/admin/sso/PRO__google.de.md | 38 + docs/content/admin/sso/PRO__keycloak.de.md | 53 + docs/content/admin/sso/PRO__ldap.de.md | 76 + docs/content/admin/sso/PRO__oidc.de.md | 62 + docs/content/admin/sso/PRO__okta.de.md | 46 + docs/content/admin/sso/PRO__saml.de.md | 155 ++ docs/content/admin/sso/PRO__scim.de.md | 148 ++ docs/content/admin/sso/_index.de.md | 76 + .../user_management/OS__audit_logging.de.md | 17 + .../OS__authorized_users.de.md | 61 + .../OS__creating_new_users.de.md | 43 + .../OS__sso_user_local_login_fallback.de.md | 58 + .../PRO__audit_log_index.de.md | 133 + .../user_management/PRO__audit_logging.de.md | 110 + .../PRO__creating_new_users.de.md | 42 + .../PRO__custom_rbac_roles.de.md | 212 ++ .../admin/user_management/PRO__mfa.de.md | 86 + .../PRO__resetting_user_credentials.de.md | 34 + .../admin/user_management/_index.de.md | 43 + .../about_perms_and_roles.de.md | 118 + .../user_management/create_user_group.de.md | 137 + .../pro_permissions_overhaul.de.md | 54 + .../set_user_permissions.de.md | 154 ++ .../user_permission_chart.de.md | 99 + .../OS_hierarchy/OS__asset_health_grade.de.md | 39 + .../OS_hierarchy/OS__asset_hierarchy.de.md | 216 ++ .../OS_hierarchy/OS__sla_configuration.de.md | 79 + .../OS__source-code-repositories.de.md | 59 + .../asset_modelling/OS_hierarchy/_index.de.md | 12 + .../OS_hierarchy/benchmarks.de.md | 39 + .../OS__questionnaires.de.md | 274 ++ .../OS_questionnaires/_index.de.md | 10 + .../PRO_hierarchy/_index.de.md | 12 + .../PRO_hierarchy/asset_hierarchy.de.md | 149 ++ .../PRO_hierarchy/priority_sla.de.md | 268 ++ .../PRO_hierarchy/product_health_grade.de.md | 32 + .../PRO_hierarchy/threat_intelligence.de.md | 78 + .../PRO_surveys/PRO__surveys.de.md | 147 ++ .../asset_modelling/PRO_surveys/_index.de.md | 10 + docs/content/asset_modelling/_index.de.md | 11 + .../components/PRO__components.de.md | 69 + .../asset_modelling/components/_index.de.md | 11 + .../asset_modelling/components/services.de.md | 39 + .../engagements_tests/OS__assets.de.md | 181 ++ .../engagements_tests/OS__calendar.de.md | 61 + .../engagements_tests/OS__engagements.de.md | 182 ++ .../engagements_tests/OS__findings.de.md | 302 +++ .../engagements_tests/OS__organizations.de.md | 139 + .../engagements_tests/OS__tests.de.md | 274 ++ .../engagements_tests/PRO__assets.de.md | 186 ++ .../engagements_tests/PRO__calendar.de.md | 62 + .../engagements_tests/PRO__engagements.de.md | 193 ++ .../engagements_tests/PRO__findings.de.md | 275 ++ .../PRO__organizations.de.md | 140 + .../engagements_tests/PRO__tests.de.md | 285 ++ .../engagements_tests/_index.de.md | 9 + .../locations/PRO__locations_overview.de.md | 80 + .../PRO__migrating_from_endpoints.de.md | 70 + .../PRO__source_code_locations.de.md | 46 + .../locations/PRO__working_with_sboms.de.md | 107 + .../locations/PRO__working_with_urls.de.md | 88 + .../asset_modelling/locations/_index.de.md | 13 + .../tags/OS__tagging_objects.de.md | 150 ++ .../tags/PRO__tagging_objects copy.de.md | 167 ++ .../content/asset_modelling/tags/_index.de.md | 9 + docs/content/automation/api/_index.de.md | 17 + docs/content/automation/api/api-v2-docs.de.md | 419 +++ docs/content/automation/api/languages.de.md | 39 + .../api/notification_webhooks.de.md | 347 +++ .../automation/api/rate_limiting.de.md | 45 + .../automation/rules_engine/_index.de.md | 18 + .../automation/rules_engine/about.de.md | 126 + .../automation/rules_engine/scheduling.de.md | 55 + .../automation/rules_engine_2/_index.de.md | 19 + .../automation/rules_engine_2/about.de.md | 119 + .../rules_engine_2/building_rules.de.md | 197 ++ .../rules_engine_2/configuration.de.md | 141 + .../converting_from_rules_engine.de.md | 89 + .../rules_engine_2/deliveries.de.md | 120 + .../rules_engine_2/node_reference.de.md | 347 +++ .../automation/rules_engine_2/runs.de.md | 133 + docs/content/connectors/_index.de.md | 18 + docs/content/connectors/about.de.md | 66 + .../downstream/PRO__jira_guide.de.md | 786 ++++++ .../connectors/downstream/_index.de.md | 20 + .../content/connectors/downstream/about.de.md | 137 + .../downstream/downstream_toolreference.de.md | 767 ++++++ .../downstream/troubleshooting_jira.de.md | 217 ++ docs/content/connectors/issue_tracking.de.md | 31 + docs/content/connectors/os_jira/_index.de.md | 20 + .../connectors/os_jira/os__jira_guide.de.md | 698 +++++ docs/content/connectors/upstream/_index.de.md | 20 + docs/content/connectors/upstream/about.de.md | 167 ++ .../connectors/upstream/add_edit.de.md | 40 + .../upstream/manage_operations.de.md | 82 + .../connectors/upstream/manage_records.de.md | 158 ++ .../connectors/upstream/toolreference.de.md | 1502 +++++++++++ docs/content/federal_compliance/_index.de.md | 54 + .../federal_compliance/cmmc_assessments.de.md | 66 + .../compliance_profile.de.md | 57 + .../federal_compliance/conmon_snapshots.de.md | 66 + .../federal_compliance/control_coverage.de.md | 61 + .../federal_compliance/poam_ledger.de.md | 77 + .../federal_compliance/remediation_slas.de.md | 51 + docs/content/get_started/_index.de.md | 16 + .../about/OS__new_user_checklist.de.md | 28 + .../about/PRO__new_user_checklist.de.md | 29 + docs/content/get_started/about/_index.de.md | 6 + .../get_started/about/about_defectdojo.de.md | 130 + .../about/defectdojo_versions.de.md | 30 + docs/content/get_started/about/demo.de.md | 21 + docs/content/get_started/about/faq.de.md | 135 + .../get_started/about/ui_pro_vs_os.de.md | 62 + .../get_started/common_use_cases/_index.de.md | 6 + .../common_use_cases/common_use_cases.de.md | 158 ++ .../get_started/contributing/_index.de.md | 11 + .../contributing/branching-model.de.md | 71 + .../contributing/documentation.de.md | 59 + .../contributing/how-to-write-a-parser.de.md | 389 +++ .../parser-documentation-template.de.md | 48 + .../get_started/open_source/_index.de.md | 7 + .../open_source/architecture.de.md | 51 + .../open_source/configuration.de.md | 44 + .../open_source/installation.de.md | 55 + .../open_source/running-in-production.de.md | 96 + .../get_started/pro/cloud/_index.de.md | 8 + .../pro/cloud/additional-cloud-instance.de.md | 63 + .../pro/cloud/cloud-architecture.de.md | 131 + .../cloud/connectivity-troubleshooting.de.md | 58 + .../pro/cloud/egress-ip-addresses.de.md | 92 + .../pro/cloud/using-cloud-manager.de.md | 75 + .../get_started/pro/onprem/_index.de.md | 7 + .../onprem/adding_storage_for_uploads.de.md | 66 + .../pro/onprem/air_gapped_install.de.md | 354 +++ .../get_started/pro/onprem/backing_up.de.md | 84 + .../get_started/pro/onprem/fips_mode.de.md | 576 ++++ .../pro/onprem/hardware_sizing.de.md | 87 + .../pro/onprem/installation_options.de.md | 40 + .../onprem/installing_on_docker_compose.de.md | 254 ++ .../pro/onprem/installing_on_kubernetes.de.md | 2317 +++++++++++++++++ .../onprem/migrating_from_open_source.de.md | 206 ++ .../pro/onprem/openshift_deployment.de.md | 156 ++ .../get_started/pro/onprem/upgrading.de.md | 32 + .../pro/onprem/upgrading_on_kubernetes.de.md | 474 ++++ .../pro/onprem/upload_size_limits.de.md | 92 + .../get_started/pro/pro_features.de.md | 132 + docs/content/help/contact_sales.de.md | 70 + docs/content/help/contact_support.de.md | 47 + docs/content/help/glossary.de.md | 81 + docs/content/import_data/_index.de.md | 18 + .../import_data/import_intro/_index.de.md | 18 + .../import_data/import_intro/comparison.de.md | 41 + .../import_data/import_intro/reimport.de.md | 117 + .../OS__create_findings_manually.de.md | 4 + .../OS__import_scan_ui.de.md | 71 + .../PRO__create_findings_manually.de.md | 4 + .../PRO__import_scan_ui.de.md | 108 + .../import_scan_files/_index.de.md | 18 + .../api_pipeline_modelling.de.md | 53 + .../endpoint_meta_importer.de.md | 40 + .../pro/specialized_import/_index.de.md | 18 + .../specialized_import/external_tools.de.md | 927 +++++++ .../pro/specialized_import/smart_upload.de.md | 59 + .../specialized_import/universal_parser.de.md | 234 ++ .../messaging_connectors.de.md | 233 ++ docs/content/metrics_reports/_index.de.md | 20 + docs/content/metrics_reports/ai/_index.de.md | 18 + .../metrics_reports/ai/mcp_server_pro.de.md | 882 +++++++ .../dashboards/Introduction_dashboard.de.md | 59 + .../dashboards/PRO__custom_dashboards.de.md | 202 ++ .../PRO__custom_dashboards_api.de.md | 489 ++++ .../PRO__custom_dashboards_llm.de.md | 191 ++ .../dashboards/PRO__my_work.de.md | 37 + .../metrics_reports/dashboards/_index.de.md | 43 + .../pro_metrics/PRO__executive_insights.de.md | 18 + .../pro_metrics/PRO__overview.de.md | 56 + .../pro_metrics/PRO__priority_insights.de.md | 19 + .../pro_metrics/PRO__program_insights.de.md | 12 + .../PRO__remediation_insights.de.md | 16 + .../pro_metrics/PRO__tool_insights.de.md | 14 + .../metrics_reports/pro_metrics/_index.de.md | 18 + .../OS__using_the_report_builder.de.md | 163 ++ .../reports/PRO__report_builder.de.md | 218 ++ .../reports/PRO__report_builder_api.de.md | 573 ++++ .../reports/PRO__report_builder_llm.de.md | 400 +++ .../metrics_reports/reports/_index.de.md | 44 + .../navigation/PRO__filter_index.de.md | 122 + .../navigation/PRO__global_search.de.md | 74 + .../content/navigation/PRO__menu_badges.de.md | 56 + .../navigation/PRO__settings_menu.de.md | 81 + .../navigation/PRO__table_customization.de.md | 46 + docs/content/navigation/_index.de.md | 18 + docs/content/sensei/OS__sensei.de.md | 28 + docs/content/sensei/_index.de.md | 20 + docs/content/sensei/about_sensei.de.md | 61 + docs/content/sensei/fixing_findings.de.md | 71 + docs/content/sensei/sensei_reference.de.md | 104 + docs/content/sensei/setup_sensei.de.md | 267 ++ docs/content/sensei/threat_modeling.de.md | 114 + .../PRO__root_cause_correlation.de.md | 290 +++ .../finding_correlation/_index.de.md | 9 + .../OS__deduplication_tuning.de.md | 165 ++ .../OS__similar_findings.de.md | 76 + .../PRO__deduplication_tuning.de.md | 172 ++ .../PRO__global_component_deduplication.de.md | 90 + .../PRO__global_locations_deduplication.de.md | 120 + .../PRO__location_drift_matching.de.md | 136 + .../PRO__similar_findings.de.md | 56 + .../PRO_enabling_product_deduplication.de.md | 56 + .../finding_deduplication/_index.de.md | 9 + .../about_deduplication.de.md | 176 ++ .../avoid_excess_duplicates.de.md | 118 + .../false_positive_history.de.md | 76 + .../finding_scoring/_index.de.md | 9 + .../finding_scoring/cvss_support.de.md | 53 + .../finding_scoring/epss_kev.de.md | 151 ++ .../finding_scoring/reachability.de.md | 123 + .../findings_workflows/OS__add_files.de.md | 73 + .../OS__risk_acceptance.de.md | 140 + .../findings_workflows/PRO__add_files.de.md | 52 + .../PRO__bulk_edit_findings.de.md | 73 + .../findings_workflows/PRO__peer_review.de.md | 73 + .../PRO__risk_acceptance.de.md | 186 ++ .../findings_workflows/_index.de.md | 9 + .../create_findings_manually.de.md | 17 + .../findings_workflows/editing_findings.de.md | 100 + .../findings_workflows/exporting.de.md | 18 + .../finding_status_definitions.de.md | 141 + .../intro_to_findings.de.md | 141 + docs/i18n/de.toml | 185 ++ docs/i18n/en.toml | 185 ++ docs/layouts/_partials/footer/footer.html | 24 +- docs/layouts/_partials/header/header.html | 33 +- docs/layouts/baseof.html | 5 +- docs/layouts/home.html | 53 +- 257 files changed, 32004 insertions(+), 57 deletions(-) create mode 100644 docs/TRANSLATIONS.md create mode 100644 docs/config/_default/menus/menus.de.toml create mode 100644 docs/content/_index.de.md create mode 100644 docs/content/admin/admin_intro/_index.de.md create mode 100644 docs/content/admin/admin_intro/intro.de.md create mode 100644 docs/content/admin/diagnostics/PRO__diagnostics.de.md create mode 100644 docs/content/admin/diagnostics/_index.de.md create mode 100644 docs/content/admin/feature_flags/PRO__feature_flags.de.md create mode 100644 docs/content/admin/feature_flags/_index.de.md create mode 100644 docs/content/admin/notifications/_index.de.md create mode 100644 docs/content/admin/notifications/about_notifications.de.md create mode 100644 docs/content/admin/notifications/configure_personal_notifs.de.md create mode 100644 docs/content/admin/notifications/configure_system_notifs.de.md create mode 100644 docs/content/admin/notifications/email_slack_teams.de.md create mode 100644 docs/content/admin/sso/PRO__auth0.de.md create mode 100644 docs/content/admin/sso/PRO__authorization_connectors.de.md create mode 100644 docs/content/admin/sso/PRO__azure_ad.de.md create mode 100644 docs/content/admin/sso/PRO__github_enterprise.de.md create mode 100644 docs/content/admin/sso/PRO__gitlab.de.md create mode 100644 docs/content/admin/sso/PRO__google.de.md create mode 100644 docs/content/admin/sso/PRO__keycloak.de.md create mode 100644 docs/content/admin/sso/PRO__ldap.de.md create mode 100644 docs/content/admin/sso/PRO__oidc.de.md create mode 100644 docs/content/admin/sso/PRO__okta.de.md create mode 100644 docs/content/admin/sso/PRO__saml.de.md create mode 100644 docs/content/admin/sso/PRO__scim.de.md create mode 100644 docs/content/admin/sso/_index.de.md create mode 100644 docs/content/admin/user_management/OS__audit_logging.de.md create mode 100644 docs/content/admin/user_management/OS__authorized_users.de.md create mode 100644 docs/content/admin/user_management/OS__creating_new_users.de.md create mode 100644 docs/content/admin/user_management/OS__sso_user_local_login_fallback.de.md create mode 100644 docs/content/admin/user_management/PRO__audit_log_index.de.md create mode 100644 docs/content/admin/user_management/PRO__audit_logging.de.md create mode 100644 docs/content/admin/user_management/PRO__creating_new_users.de.md create mode 100644 docs/content/admin/user_management/PRO__custom_rbac_roles.de.md create mode 100644 docs/content/admin/user_management/PRO__mfa.de.md create mode 100644 docs/content/admin/user_management/PRO__resetting_user_credentials.de.md create mode 100644 docs/content/admin/user_management/_index.de.md create mode 100644 docs/content/admin/user_management/about_perms_and_roles.de.md create mode 100644 docs/content/admin/user_management/create_user_group.de.md create mode 100644 docs/content/admin/user_management/pro_permissions_overhaul.de.md create mode 100644 docs/content/admin/user_management/set_user_permissions.de.md create mode 100644 docs/content/admin/user_management/user_permission_chart.de.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.de.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.de.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.de.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.de.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/_index.de.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/benchmarks.de.md create mode 100644 docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.de.md create mode 100644 docs/content/asset_modelling/OS_questionnaires/_index.de.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/_index.de.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.de.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/priority_sla.de.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/product_health_grade.de.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.de.md create mode 100644 docs/content/asset_modelling/PRO_surveys/PRO__surveys.de.md create mode 100644 docs/content/asset_modelling/PRO_surveys/_index.de.md create mode 100644 docs/content/asset_modelling/_index.de.md create mode 100644 docs/content/asset_modelling/components/PRO__components.de.md create mode 100644 docs/content/asset_modelling/components/_index.de.md create mode 100644 docs/content/asset_modelling/components/services.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__assets.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__calendar.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__engagements.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__findings.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__organizations.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__tests.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__assets.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__calendar.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__engagements.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__findings.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__organizations.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__tests.de.md create mode 100644 docs/content/asset_modelling/engagements_tests/_index.de.md create mode 100644 docs/content/asset_modelling/locations/PRO__locations_overview.de.md create mode 100644 docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.de.md create mode 100644 docs/content/asset_modelling/locations/PRO__source_code_locations.de.md create mode 100644 docs/content/asset_modelling/locations/PRO__working_with_sboms.de.md create mode 100644 docs/content/asset_modelling/locations/PRO__working_with_urls.de.md create mode 100644 docs/content/asset_modelling/locations/_index.de.md create mode 100644 docs/content/asset_modelling/tags/OS__tagging_objects.de.md create mode 100644 docs/content/asset_modelling/tags/PRO__tagging_objects copy.de.md create mode 100644 docs/content/asset_modelling/tags/_index.de.md create mode 100644 docs/content/automation/api/_index.de.md create mode 100644 docs/content/automation/api/api-v2-docs.de.md create mode 100644 docs/content/automation/api/languages.de.md create mode 100644 docs/content/automation/api/notification_webhooks.de.md create mode 100644 docs/content/automation/api/rate_limiting.de.md create mode 100644 docs/content/automation/rules_engine/_index.de.md create mode 100644 docs/content/automation/rules_engine/about.de.md create mode 100644 docs/content/automation/rules_engine/scheduling.de.md create mode 100644 docs/content/automation/rules_engine_2/_index.de.md create mode 100644 docs/content/automation/rules_engine_2/about.de.md create mode 100644 docs/content/automation/rules_engine_2/building_rules.de.md create mode 100644 docs/content/automation/rules_engine_2/configuration.de.md create mode 100644 docs/content/automation/rules_engine_2/converting_from_rules_engine.de.md create mode 100644 docs/content/automation/rules_engine_2/deliveries.de.md create mode 100644 docs/content/automation/rules_engine_2/node_reference.de.md create mode 100644 docs/content/automation/rules_engine_2/runs.de.md create mode 100644 docs/content/connectors/_index.de.md create mode 100644 docs/content/connectors/about.de.md create mode 100644 docs/content/connectors/downstream/PRO__jira_guide.de.md create mode 100644 docs/content/connectors/downstream/_index.de.md create mode 100644 docs/content/connectors/downstream/about.de.md create mode 100644 docs/content/connectors/downstream/downstream_toolreference.de.md create mode 100644 docs/content/connectors/downstream/troubleshooting_jira.de.md create mode 100644 docs/content/connectors/issue_tracking.de.md create mode 100644 docs/content/connectors/os_jira/_index.de.md create mode 100644 docs/content/connectors/os_jira/os__jira_guide.de.md create mode 100644 docs/content/connectors/upstream/_index.de.md create mode 100644 docs/content/connectors/upstream/about.de.md create mode 100644 docs/content/connectors/upstream/add_edit.de.md create mode 100644 docs/content/connectors/upstream/manage_operations.de.md create mode 100644 docs/content/connectors/upstream/manage_records.de.md create mode 100644 docs/content/connectors/upstream/toolreference.de.md create mode 100644 docs/content/federal_compliance/_index.de.md create mode 100644 docs/content/federal_compliance/cmmc_assessments.de.md create mode 100644 docs/content/federal_compliance/compliance_profile.de.md create mode 100644 docs/content/federal_compliance/conmon_snapshots.de.md create mode 100644 docs/content/federal_compliance/control_coverage.de.md create mode 100644 docs/content/federal_compliance/poam_ledger.de.md create mode 100644 docs/content/federal_compliance/remediation_slas.de.md create mode 100644 docs/content/get_started/_index.de.md create mode 100644 docs/content/get_started/about/OS__new_user_checklist.de.md create mode 100644 docs/content/get_started/about/PRO__new_user_checklist.de.md create mode 100644 docs/content/get_started/about/_index.de.md create mode 100644 docs/content/get_started/about/about_defectdojo.de.md create mode 100644 docs/content/get_started/about/defectdojo_versions.de.md create mode 100644 docs/content/get_started/about/demo.de.md create mode 100644 docs/content/get_started/about/faq.de.md create mode 100644 docs/content/get_started/about/ui_pro_vs_os.de.md create mode 100644 docs/content/get_started/common_use_cases/_index.de.md create mode 100644 docs/content/get_started/common_use_cases/common_use_cases.de.md create mode 100644 docs/content/get_started/contributing/_index.de.md create mode 100644 docs/content/get_started/contributing/branching-model.de.md create mode 100644 docs/content/get_started/contributing/documentation.de.md create mode 100644 docs/content/get_started/contributing/how-to-write-a-parser.de.md create mode 100644 docs/content/get_started/contributing/parser-documentation-template.de.md create mode 100644 docs/content/get_started/open_source/_index.de.md create mode 100644 docs/content/get_started/open_source/architecture.de.md create mode 100644 docs/content/get_started/open_source/configuration.de.md create mode 100644 docs/content/get_started/open_source/installation.de.md create mode 100644 docs/content/get_started/open_source/running-in-production.de.md create mode 100644 docs/content/get_started/pro/cloud/_index.de.md create mode 100644 docs/content/get_started/pro/cloud/additional-cloud-instance.de.md create mode 100644 docs/content/get_started/pro/cloud/cloud-architecture.de.md create mode 100644 docs/content/get_started/pro/cloud/connectivity-troubleshooting.de.md create mode 100644 docs/content/get_started/pro/cloud/egress-ip-addresses.de.md create mode 100644 docs/content/get_started/pro/cloud/using-cloud-manager.de.md create mode 100644 docs/content/get_started/pro/onprem/_index.de.md create mode 100644 docs/content/get_started/pro/onprem/adding_storage_for_uploads.de.md create mode 100644 docs/content/get_started/pro/onprem/air_gapped_install.de.md create mode 100644 docs/content/get_started/pro/onprem/backing_up.de.md create mode 100644 docs/content/get_started/pro/onprem/fips_mode.de.md create mode 100644 docs/content/get_started/pro/onprem/hardware_sizing.de.md create mode 100644 docs/content/get_started/pro/onprem/installation_options.de.md create mode 100644 docs/content/get_started/pro/onprem/installing_on_docker_compose.de.md create mode 100644 docs/content/get_started/pro/onprem/installing_on_kubernetes.de.md create mode 100644 docs/content/get_started/pro/onprem/migrating_from_open_source.de.md create mode 100644 docs/content/get_started/pro/onprem/openshift_deployment.de.md create mode 100644 docs/content/get_started/pro/onprem/upgrading.de.md create mode 100644 docs/content/get_started/pro/onprem/upgrading_on_kubernetes.de.md create mode 100644 docs/content/get_started/pro/onprem/upload_size_limits.de.md create mode 100644 docs/content/get_started/pro/pro_features.de.md create mode 100644 docs/content/help/contact_sales.de.md create mode 100644 docs/content/help/contact_support.de.md create mode 100644 docs/content/help/glossary.de.md create mode 100644 docs/content/import_data/_index.de.md create mode 100644 docs/content/import_data/import_intro/_index.de.md create mode 100644 docs/content/import_data/import_intro/comparison.de.md create mode 100644 docs/content/import_data/import_intro/reimport.de.md create mode 100644 docs/content/import_data/import_scan_files/OS__create_findings_manually.de.md create mode 100644 docs/content/import_data/import_scan_files/OS__import_scan_ui.de.md create mode 100644 docs/content/import_data/import_scan_files/PRO__create_findings_manually.de.md create mode 100644 docs/content/import_data/import_scan_files/PRO__import_scan_ui.de.md create mode 100644 docs/content/import_data/import_scan_files/_index.de.md create mode 100644 docs/content/import_data/import_scan_files/api_pipeline_modelling.de.md create mode 100644 docs/content/import_data/import_scan_files/endpoint_meta_importer.de.md create mode 100644 docs/content/import_data/pro/specialized_import/_index.de.md create mode 100644 docs/content/import_data/pro/specialized_import/external_tools.de.md create mode 100644 docs/content/import_data/pro/specialized_import/smart_upload.de.md create mode 100644 docs/content/import_data/pro/specialized_import/universal_parser.de.md create mode 100644 docs/content/issue_tracking/pro_integration/messaging_connectors.de.md create mode 100644 docs/content/metrics_reports/_index.de.md create mode 100644 docs/content/metrics_reports/ai/_index.de.md create mode 100644 docs/content/metrics_reports/ai/mcp_server_pro.de.md create mode 100644 docs/content/metrics_reports/dashboards/Introduction_dashboard.de.md create mode 100644 docs/content/metrics_reports/dashboards/PRO__custom_dashboards.de.md create mode 100644 docs/content/metrics_reports/dashboards/PRO__custom_dashboards_api.de.md create mode 100644 docs/content/metrics_reports/dashboards/PRO__custom_dashboards_llm.de.md create mode 100644 docs/content/metrics_reports/dashboards/PRO__my_work.de.md create mode 100644 docs/content/metrics_reports/dashboards/_index.de.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__executive_insights.de.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__overview.de.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__priority_insights.de.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__program_insights.de.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__remediation_insights.de.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__tool_insights.de.md create mode 100644 docs/content/metrics_reports/pro_metrics/_index.de.md create mode 100644 docs/content/metrics_reports/reports/OS__using_the_report_builder.de.md create mode 100644 docs/content/metrics_reports/reports/PRO__report_builder.de.md create mode 100644 docs/content/metrics_reports/reports/PRO__report_builder_api.de.md create mode 100644 docs/content/metrics_reports/reports/PRO__report_builder_llm.de.md create mode 100644 docs/content/metrics_reports/reports/_index.de.md create mode 100644 docs/content/navigation/PRO__filter_index.de.md create mode 100644 docs/content/navigation/PRO__global_search.de.md create mode 100644 docs/content/navigation/PRO__menu_badges.de.md create mode 100644 docs/content/navigation/PRO__settings_menu.de.md create mode 100644 docs/content/navigation/PRO__table_customization.de.md create mode 100644 docs/content/navigation/_index.de.md create mode 100644 docs/content/sensei/OS__sensei.de.md create mode 100644 docs/content/sensei/_index.de.md create mode 100644 docs/content/sensei/about_sensei.de.md create mode 100644 docs/content/sensei/fixing_findings.de.md create mode 100644 docs/content/sensei/sensei_reference.de.md create mode 100644 docs/content/sensei/setup_sensei.de.md create mode 100644 docs/content/sensei/threat_modeling.de.md create mode 100644 docs/content/triage_findings/finding_correlation/PRO__root_cause_correlation.de.md create mode 100644 docs/content/triage_findings/finding_correlation/_index.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/OS__deduplication_tuning.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/OS__similar_findings.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__global_component_deduplication.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__global_locations_deduplication.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__similar_findings.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO_enabling_product_deduplication.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/_index.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/about_deduplication.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/avoid_excess_duplicates.de.md create mode 100644 docs/content/triage_findings/finding_deduplication/false_positive_history.de.md create mode 100644 docs/content/triage_findings/finding_scoring/_index.de.md create mode 100644 docs/content/triage_findings/finding_scoring/cvss_support.de.md create mode 100644 docs/content/triage_findings/finding_scoring/epss_kev.de.md create mode 100644 docs/content/triage_findings/finding_scoring/reachability.de.md create mode 100644 docs/content/triage_findings/findings_workflows/OS__add_files.de.md create mode 100644 docs/content/triage_findings/findings_workflows/OS__risk_acceptance.de.md create mode 100644 docs/content/triage_findings/findings_workflows/PRO__add_files.de.md create mode 100644 docs/content/triage_findings/findings_workflows/PRO__bulk_edit_findings.de.md create mode 100644 docs/content/triage_findings/findings_workflows/PRO__peer_review.de.md create mode 100644 docs/content/triage_findings/findings_workflows/PRO__risk_acceptance.de.md create mode 100644 docs/content/triage_findings/findings_workflows/_index.de.md create mode 100644 docs/content/triage_findings/findings_workflows/create_findings_manually.de.md create mode 100644 docs/content/triage_findings/findings_workflows/editing_findings.de.md create mode 100644 docs/content/triage_findings/findings_workflows/exporting.de.md create mode 100644 docs/content/triage_findings/findings_workflows/finding_status_definitions.de.md create mode 100644 docs/content/triage_findings/findings_workflows/intro_to_findings.de.md create mode 100644 docs/i18n/de.toml create mode 100644 docs/i18n/en.toml 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..ee1eb631626 100644 --- a/docs/config/_default/languages.toml +++ b/docs/config/_default/languages.toml @@ -1,7 +1,22 @@ +# 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" diff --git a/docs/config/_default/menus/menus.de.toml b/docs/config/_default/menus/menus.de.toml new file mode 100644 index 00000000000..3e742727c38 --- /dev/null +++ b/docs/config/_default/menus/menus.de.toml @@ -0,0 +1,93 @@ +# 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. +[[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/hierarchy/pro__assets_organizations/" + weight = 13 + +[[main]] + name = "Metriken & Berichte" + url = "/de/metrics_reports/dashboards/introduction_dashboard/" + weight = 14 + +[[main]] + name = "Administration" + url = "/de/admin/admin_intro/intro/" + weight = 16 + +[[main]] + name = "Issue-Tracking" + url = "/de/issue_tracking/intro/intro/" + weight = 15 + +[[main]] + name = "Automatisierung" + url = "/de/automation/api/api-v2-docs/" + weight = 15 + +[[main]] + name = "Unterstützte Tools" + url = "/supported_tools/" + weight = 16 + +[[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..2037d0b78b6 --- /dev/null +++ b/docs/content/_index.de.md @@ -0,0 +1,6 @@ +--- +title: DefectDojo-Dokumentation +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..05e30e7269a --- /dev/null +++ b/docs/content/admin/admin_intro/_index.de.md @@ -0,0 +1,17 @@ +--- +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/intro.de.md b/docs/content/admin/admin_intro/intro.de.md new file mode 100644 index 00000000000..c9c0a20c153 --- /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. \ No newline at end of file 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/_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/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/_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/notifications/_index.de.md b/docs/content/admin/notifications/_index.de.md new file mode 100644 index 00000000000..8676311a83c --- /dev/null +++ b/docs/content/admin/notifications/_index.de.md @@ -0,0 +1,17 @@ +--- +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/about_notifications.de.md b/docs/content/admin/notifications/about_notifications.de.md new file mode 100644 index 00000000000..3f30163f928 --- /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: +- /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/configure_personal_notifs.de.md b/docs/content/admin/notifications/configure_personal_notifs.de.md new file mode 100644 index 00000000000..a86d6c0cae9 --- /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: +- /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). \ No newline at end of file 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..cb49042d37c --- /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: +- /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.** \ No newline at end of file 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..68c2a54cb37 --- /dev/null +++ b/docs/content/admin/notifications/email_slack_teams.de.md @@ -0,0 +1,143 @@ +--- +title: E-Mail-, Slack- oder Teams-Benachrichtigungen einrichten +description: Microsoft Teams für den Empfang von Benachrichtigungen einrichten +aliases: +- /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/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__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__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__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__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__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__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__ldap.de.md b/docs/content/admin/sso/PRO__ldap.de.md new file mode 100644 index 00000000000..098a79e0c5e --- /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: +- /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__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__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__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__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/_index.de.md b/docs/content/admin/sso/_index.de.md new file mode 100644 index 00000000000..5ff8b87b857 --- /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: +- /admin/user_management/configure_sso/ +- /admin/sso/os__saml/ +- /admin/sso/os__auth0/ +- /admin/sso/os__azure_ad/ +- /admin/sso/os__github_enterprise/ +- /admin/sso/os__gitlab/ +- /admin/sso/os__google/ +- /admin/sso/os__keycloak/ +- /admin/sso/os__oidc/ +- /admin/sso/os__okta/ +- /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/user_management/OS__audit_logging.de.md b/docs/content/admin/user_management/OS__audit_logging.de.md new file mode 100644 index 00000000000..e3ef238e09e --- /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: +- /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) \ No newline at end of file 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__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__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/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_logging.de.md b/docs/content/admin/user_management/PRO__audit_logging.de.md new file mode 100644 index 00000000000..00908e65cd3 --- /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/` \ No newline at end of file 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__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__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__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/_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/about_perms_and_roles.de.md b/docs/content/admin/user_management/about_perms_and_roles.de.md new file mode 100644 index 00000000000..6b0af8cba95 --- /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: +- /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/create_user_group.de.md b/docs/content/admin/user_management/create_user_group.de.md new file mode 100644 index 00000000000..b7111b911a2 --- /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: +- /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/pro_permissions_overhaul.de.md b/docs/content/admin/user_management/pro_permissions_overhaul.de.md new file mode 100644 index 00000000000..37a5a4cde95 --- /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: +- /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/set_user_permissions.de.md b/docs/content/admin/user_management/set_user_permissions.de.md new file mode 100644 index 00000000000..e173d14c127 --- /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: +- /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/user_permission_chart.de.md b/docs/content/admin/user_management/user_permission_chart.de.md new file mode 100644 index 00000000000..3d0c5833aee --- /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: +- /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/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..59947dc5b45 --- /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: +- /asset_modelling/os_hierarchy/product_health_grade/ +- /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_hierarchy.de.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.de.md new file mode 100644 index 00000000000..43c572039de --- /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: +- /en/working_with_findings/organizing_engagements_tests/product_hierarchy +- /asset_modelling/os_hierarchy/product_hierarchy/ +- /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__sla_configuration.de.md b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.de.md new file mode 100644 index 00000000000..69d9edb3161 --- /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: +- /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__source-code-repositories.de.md b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.de.md new file mode 100644 index 00000000000..4e651550518 --- /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: +- /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/_index.de.md b/docs/content/asset_modelling/OS_hierarchy/_index.de.md new file mode 100644 index 00000000000..7ccbd79b1d7 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/_index.de.md @@ -0,0 +1,12 @@ +--- +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/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_questionnaires/OS__questionnaires.de.md b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.de.md new file mode 100644 index 00000000000..856cee893e2 --- /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. \ No newline at end of file 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..3ce57ff3f01 --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/_index.de.md @@ -0,0 +1,10 @@ +--- +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/PRO_hierarchy/_index.de.md b/docs/content/asset_modelling/PRO_hierarchy/_index.de.md new file mode 100644 index 00000000000..280a6751f88 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/_index.de.md @@ -0,0 +1,12 @@ +--- +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/asset_hierarchy.de.md b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.de.md new file mode 100644 index 00000000000..ea1d7da7a8e --- /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: +- /en/working_with_findings/organizing_engagements_tests/pro_assets_organizations +- /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. \ No newline at end of file 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..f7aea30a576 --- /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: +- /en/working_with_findings/finding_priority +- /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/product_health_grade.de.md b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.de.md new file mode 100644 index 00000000000..0483969a3e0 --- /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: +- /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/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_surveys/PRO__surveys.de.md b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.de.md new file mode 100644 index 00000000000..0d1709822d1 --- /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. \ No newline at end of file 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..6c7a150c9d9 --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/_index.de.md @@ -0,0 +1,10 @@ +--- +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/_index.de.md b/docs/content/asset_modelling/_index.de.md new file mode 100644 index 00000000000..08c479a44ac --- /dev/null +++ b/docs/content/asset_modelling/_index.de.md @@ -0,0 +1,11 @@ +--- +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/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/_index.de.md b/docs/content/asset_modelling/components/_index.de.md new file mode 100644 index 00000000000..a48894a51b1 --- /dev/null +++ b/docs/content/asset_modelling/components/_index.de.md @@ -0,0 +1,11 @@ +--- +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/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/engagements_tests/OS__assets.de.md b/docs/content/asset_modelling/engagements_tests/OS__assets.de.md new file mode 100644 index 00000000000..e6f9389aa5c --- /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: +- /asset_modelling/engagements_tests/os__products/ +- /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__calendar.de.md b/docs/content/asset_modelling/engagements_tests/OS__calendar.de.md new file mode 100644 index 00000000000..550206e75af --- /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 \ No newline at end of file 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..a529e7552bf --- /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)**. \ No newline at end of file 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..25aef7ca941 --- /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. \ No newline at end of file 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..61cc05952c4 --- /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: +- /asset_modelling/engagements_tests/os_producttype/ +- /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__tests.de.md b/docs/content/asset_modelling/engagements_tests/OS__tests.de.md new file mode 100644 index 00000000000..847eaacb319 --- /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. \ No newline at end of file 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__calendar.de.md b/docs/content/asset_modelling/engagements_tests/PRO__calendar.de.md new file mode 100644 index 00000000000..5c8d11aa62f --- /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) \ No newline at end of file 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__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__organizations.de.md b/docs/content/asset_modelling/engagements_tests/PRO__organizations.de.md new file mode 100644 index 00000000000..d1c568e166a --- /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. \ No newline at end of file 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..6bd7834e39b --- /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. \ No newline at end of file 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..1ddd52a4b24 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/_index.de.md @@ -0,0 +1,9 @@ +--- +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/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__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__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__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_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/_index.de.md b/docs/content/asset_modelling/locations/_index.de.md new file mode 100644 index 00000000000..35e135e67dc --- /dev/null +++ b/docs/content/asset_modelling/locations/_index.de.md @@ -0,0 +1,13 @@ +--- +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/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/PRO__tagging_objects copy.de.md b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.de.md new file mode 100644 index 00000000000..fe60f400e92 --- /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: +- /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/_index.de.md b/docs/content/asset_modelling/tags/_index.de.md new file mode 100644 index 00000000000..88e1ca34c28 --- /dev/null +++ b/docs/content/asset_modelling/tags/_index.de.md @@ -0,0 +1,9 @@ +--- +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/automation/api/_index.de.md b/docs/content/automation/api/_index.de.md new file mode 100644 index 00000000000..36fe467ec66 --- /dev/null +++ b/docs/content/automation/api/_index.de.md @@ -0,0 +1,17 @@ +--- +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/api-v2-docs.de.md b/docs/content/automation/api/api-v2-docs.de.md new file mode 100644 index 00000000000..6e4bf2494f9 --- /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: +- /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/languages.de.md b/docs/content/automation/api/languages.de.md new file mode 100644 index 00000000000..1d7ab3117bc --- /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: +- /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/notification_webhooks.de.md b/docs/content/automation/api/notification_webhooks.de.md new file mode 100644 index 00000000000..e8455483c87 --- /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: +- /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/rate_limiting.de.md b/docs/content/automation/api/rate_limiting.de.md new file mode 100644 index 00000000000..95702b7a767 --- /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: +- /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/rules_engine/_index.de.md b/docs/content/automation/rules_engine/_index.de.md new file mode 100644 index 00000000000..1a69d19f4ba --- /dev/null +++ b/docs/content/automation/rules_engine/_index.de.md @@ -0,0 +1,18 @@ +--- +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..27547fa6bdc --- /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: +- /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. \ No newline at end of file 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_2/_index.de.md b/docs/content/automation/rules_engine_2/_index.de.md new file mode 100644 index 00000000000..139500d9fde --- /dev/null +++ b/docs/content/automation/rules_engine_2/_index.de.md @@ -0,0 +1,19 @@ +--- +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/about.de.md b/docs/content/automation/rules_engine_2/about.de.md new file mode 100644 index 00000000000..034cbfe6920 --- /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: +- /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/building_rules.de.md b/docs/content/automation/rules_engine_2/building_rules.de.md new file mode 100644 index 00000000000..cab97af493b --- /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: +- /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/configuration.de.md b/docs/content/automation/rules_engine_2/configuration.de.md new file mode 100644 index 00000000000..4a6823e81a5 --- /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: +- /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/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..693a42db608 --- /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: +- /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/deliveries.de.md b/docs/content/automation/rules_engine_2/deliveries.de.md new file mode 100644 index 00000000000..8628e6c6b27 --- /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: +- /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/node_reference.de.md b/docs/content/automation/rules_engine_2/node_reference.de.md new file mode 100644 index 00000000000..8355e09cc0d --- /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: +- /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/runs.de.md b/docs/content/automation/rules_engine_2/runs.de.md new file mode 100644 index 00000000000..a9af94a1289 --- /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: +- /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/connectors/_index.de.md b/docs/content/connectors/_index.de.md new file mode 100644 index 00000000000..6e29bdcb22d --- /dev/null +++ b/docs/content/connectors/_index.de.md @@ -0,0 +1,18 @@ +--- +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/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/downstream/PRO__jira_guide.de.md b/docs/content/connectors/downstream/PRO__jira_guide.de.md new file mode 100644 index 00000000000..81f7ef598da --- /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: +- /issue_tracking/jira/pro__jira_guide/ +- /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/_index.de.md b/docs/content/connectors/downstream/_index.de.md new file mode 100644 index 00000000000..41e63ad479c --- /dev/null +++ b/docs/content/connectors/downstream/_index.de.md @@ -0,0 +1,20 @@ +--- +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: +- /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..63fae7cc7b2 --- /dev/null +++ b/docs/content/connectors/downstream/about.de.md @@ -0,0 +1,137 @@ +--- +title: Downstream Connectors +weight: 1 +audience: pro +aliases: +- /en/share_your_findings/integrations +- /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 ` -