From 4ecd42cba45077e860f0e1b1e56f2dda5aed0f63 Mon Sep 17 00:00:00 2001 From: Greg Anderson Date: Sun, 16 Aug 2026 11:47:46 -0600 Subject: [PATCH 1/3] docs: add Brazilian Portuguese translations 246 pages of the core guide set, applied with the integrity gates (fences, headings, shortcodes and link targets verified against the English source) and wired into the language switcher. Co-Authored-By: Claude Opus 5 --- docs/config/_default/languages.toml | 7 + docs/config/_default/menus/menus.pt-br.toml | 125 + docs/content/_index.pt-br.md | 5 + .../content/admin/admin_intro/_index.pt-br.md | 16 + docs/content/admin/admin_intro/intro.pt-br.md | 16 + .../diagnostics/PRO__diagnostics.pt-br.md | 169 ++ .../content/admin/diagnostics/_index.pt-br.md | 24 + .../feature_flags/PRO__feature_flags.pt-br.md | 195 ++ .../admin/feature_flags/_index.pt-br.md | 25 + .../admin/notifications/_index.pt-br.md | 16 + .../about_notifications.pt-br.md | 103 + .../configure_personal_notifs.pt-br.md | 35 + .../configure_system_notifs.pt-br.md | 44 + .../notifications/email_slack_teams.pt-br.md | 142 ++ docs/content/admin/sso/PRO__auth0.pt-br.md | 34 + .../PRO__authorization_connectors.pt-br.md | 103 + docs/content/admin/sso/PRO__azure_ad.pt-br.md | 78 + .../admin/sso/PRO__github_enterprise.pt-br.md | 39 + docs/content/admin/sso/PRO__gitlab.pt-br.md | 34 + docs/content/admin/sso/PRO__google.pt-br.md | 47 + docs/content/admin/sso/PRO__keycloak.pt-br.md | 60 + docs/content/admin/sso/PRO__ldap.pt-br.md | 107 + docs/content/admin/sso/PRO__oidc.pt-br.md | 62 + docs/content/admin/sso/PRO__okta.pt-br.md | 46 + docs/content/admin/sso/PRO__saml.pt-br.md | 155 ++ docs/content/admin/sso/PRO__scim.pt-br.md | 148 ++ docs/content/admin/sso/_index.pt-br.md | 76 + .../OS__audit_logging.pt-br.md | 17 + .../OS__authorized_users.pt-br.md | 61 + .../OS__creating_new_users.pt-br.md | 43 + ...OS__sso_user_local_login_fallback.pt-br.md | 58 + .../PRO__audit_log_index.pt-br.md | 134 + .../PRO__audit_logging.pt-br.md | 110 + .../PRO__creating_new_users.pt-br.md | 42 + .../PRO__custom_rbac_roles.pt-br.md | 212 ++ .../admin/user_management/PRO__mfa.pt-br.md | 85 + .../PRO__resetting_user_credentials.pt-br.md | 34 + .../admin/user_management/_index.pt-br.md | 43 + .../about_perms_and_roles.pt-br.md | 119 + .../create_user_group.pt-br.md | 139 ++ .../pro_permissions_overhaul.pt-br.md | 54 + .../set_user_permissions.pt-br.md | 154 ++ .../user_permission_chart.pt-br.md | 99 + .../OS__asset_health_grade.pt-br.md | 39 + .../OS_hierarchy/OS__asset_hierarchy.pt-br.md | 216 ++ .../OS__sla_configuration.pt-br.md | 79 + .../OS__source-code-repositories.pt-br.md | 59 + .../OS_hierarchy/_index.pt-br.md | 11 + .../OS_hierarchy/benchmarks.pt-br.md | 39 + .../OS__questionnaires.pt-br.md | 274 ++ .../OS_questionnaires/_index.pt-br.md | 9 + .../PRO_hierarchy/_index.pt-br.md | 11 + .../PRO_hierarchy/asset_hierarchy.pt-br.md | 149 ++ .../PRO_hierarchy/priority_sla.pt-br.md | 236 ++ .../product_health_grade.pt-br.md | 32 + .../threat_intelligence.pt-br.md | 128 + .../PRO_surveys/PRO__surveys.pt-br.md | 147 ++ .../PRO_surveys/_index.pt-br.md | 9 + docs/content/asset_modelling/_index.pt-br.md | 10 + .../components/PRO__components.pt-br.md | 69 + .../components/_index.pt-br.md | 10 + .../components/services.pt-br.md | 39 + .../engagements_tests/OS__assets.pt-br.md | 181 ++ .../engagements_tests/OS__calendar.pt-br.md | 61 + .../OS__engagements.pt-br.md | 182 ++ .../engagements_tests/OS__findings.pt-br.md | 302 +++ .../OS__organizations.pt-br.md | 139 ++ .../engagements_tests/OS__tests.pt-br.md | 274 ++ .../engagements_tests/PRO__assets.pt-br.md | 186 ++ .../engagements_tests/PRO__calendar.pt-br.md | 62 + .../PRO__engagements.pt-br.md | 193 ++ .../engagements_tests/PRO__findings.pt-br.md | 275 ++ .../PRO__organizations.pt-br.md | 140 ++ .../engagements_tests/PRO__tests.pt-br.md | 285 +++ .../engagements_tests/_index.pt-br.md | 8 + .../PRO__locations_overview.pt-br.md | 80 + .../PRO__migrating_from_endpoints.pt-br.md | 70 + .../PRO__source_code_locations.pt-br.md | 46 + .../PRO__working_with_sboms.pt-br.md | 107 + .../locations/PRO__working_with_urls.pt-br.md | 88 + .../asset_modelling/locations/_index.pt-br.md | 12 + .../tags/OS__tagging_objects.pt-br.md | 149 ++ .../tags/PRO__tagging_objects copy.pt-br.md | 179 ++ .../asset_modelling/tags/_index.pt-br.md | 8 + docs/content/automation/api/_index.pt-br.md | 16 + .../automation/api/api-v2-docs.pt-br.md | 398 +++ .../content/automation/api/languages.pt-br.md | 39 + .../api/notification_webhooks.pt-br.md | 347 +++ .../automation/api/rate_limiting.pt-br.md | 45 + .../automation/rules_engine/_index.pt-br.md | 17 + .../automation/rules_engine/about.pt-br.md | 126 + .../rules_engine/scheduling.pt-br.md | 55 + .../automation/rules_engine_2/_index.pt-br.md | 18 + .../automation/rules_engine_2/about.pt-br.md | 118 + .../rules_engine_2/building_rules.pt-br.md | 197 ++ .../rules_engine_2/configuration.pt-br.md | 141 ++ .../converting_from_rules_engine.pt-br.md | 89 + .../rules_engine_2/deliveries.pt-br.md | 120 + .../rules_engine_2/node_reference.pt-br.md | 347 +++ .../automation/rules_engine_2/runs.pt-br.md | 133 + docs/content/connectors/_index.pt-br.md | 17 + docs/content/connectors/about.pt-br.md | 66 + .../downstream/PRO__jira_guide.pt-br.md | 786 ++++++ .../connectors/downstream/_index.pt-br.md | 19 + .../connectors/downstream/about.pt-br.md | 135 + .../downstream_toolreference.pt-br.md | 767 ++++++ .../downstream/troubleshooting_jira.pt-br.md | 216 ++ .../connectors/issue_tracking.pt-br.md | 30 + .../connectors/os_jira/_index.pt-br.md | 19 + .../os_jira/os__jira_guide.pt-br.md | 698 ++++++ .../connectors/upstream/_index.pt-br.md | 20 + .../connectors/upstream/about.pt-br.md | 168 ++ .../connectors/upstream/add_edit.pt-br.md | 40 + .../upstream/manage_operations.pt-br.md | 82 + .../upstream/manage_records.pt-br.md | 158 ++ .../upstream/toolreference.pt-br.md | 1500 +++++++++++ .../federal_compliance/_index.pt-br.md | 43 + .../cmmc_assessments.pt-br.md | 53 + .../compliance_profile.pt-br.md | 47 + .../conmon_snapshots.pt-br.md | 53 + .../control_coverage.pt-br.md | 50 + .../federal_compliance/poam_ledger.pt-br.md | 60 + .../remediation_slas.pt-br.md | 51 + docs/content/get_started/_index.pt-br.md | 15 + .../about/OS__new_user_checklist.pt-br.md | 28 + .../about/PRO__new_user_checklist.pt-br.md | 29 + .../content/get_started/about/_index.pt-br.md | 5 + .../about/about_defectdojo.pt-br.md | 130 + .../about/defectdojo_versions.pt-br.md | 30 + docs/content/get_started/about/demo.pt-br.md | 21 + docs/content/get_started/about/faq.pt-br.md | 135 + .../get_started/about/ui_pro_vs_os.pt-br.md | 62 + .../common_use_cases/_index.pt-br.md | 5 + .../common_use_cases.pt-br.md | 158 ++ .../get_started/contributing/_index.pt-br.md | 11 + .../contributing/branching-model.pt-br.md | 71 + .../contributing/documentation.pt-br.md | 59 + .../how-to-write-a-parser.pt-br.md | 389 +++ .../parser-documentation-template.pt-br.md | 48 + .../get_started/open_source/_index.pt-br.md | 6 + .../open_source/architecture.pt-br.md | 51 + .../open_source/configuration.pt-br.md | 44 + .../open_source/installation.pt-br.md | 55 + .../running-in-production.pt-br.md | 96 + .../get_started/pro/cloud/_index.pt-br.md | 7 + .../cloud/additional-cloud-instance.pt-br.md | 63 + .../pro/cloud/cloud-architecture.pt-br.md | 117 + .../connectivity-troubleshooting.pt-br.md | 57 + .../pro/cloud/egress-ip-addresses.pt-br.md | 98 + .../pro/cloud/using-cloud-manager.pt-br.md | 75 + .../get_started/pro/onprem/_index.pt-br.md | 6 + .../adding_storage_for_uploads.pt-br.md | 66 + .../pro/onprem/air_gapped_install.pt-br.md | 353 +++ .../pro/onprem/backing_up.pt-br.md | 83 + .../get_started/pro/onprem/fips_mode.pt-br.md | 577 +++++ .../pro/onprem/hardware_sizing.pt-br.md | 87 + .../pro/onprem/installation_options.pt-br.md | 40 + .../installing_on_docker_compose.pt-br.md | 254 ++ .../onprem/installing_on_kubernetes.pt-br.md | 2222 +++++++++++++++++ .../migrating_from_open_source.pt-br.md | 206 ++ .../pro/onprem/openshift_deployment.pt-br.md | 156 ++ .../get_started/pro/onprem/upgrading.pt-br.md | 32 + .../onprem/upgrading_on_kubernetes.pt-br.md | 418 ++++ .../pro/onprem/upload_size_limits.pt-br.md | 92 + .../get_started/pro/pro_features.pt-br.md | 132 + docs/content/help/contact_sales.pt-br.md | 69 + docs/content/help/contact_support.pt-br.md | 47 + docs/content/help/glossary.pt-br.md | 81 + docs/content/import_data/_index.pt-br.md | 16 + .../import_data/import_intro/_index.pt-br.md | 16 + .../import_intro/comparison.pt-br.md | 40 + .../import_intro/reimport.pt-br.md | 116 + .../OS__create_findings_manually.pt-br.md | 3 + .../OS__import_scan_ui.pt-br.md | 67 + .../PRO__create_findings_manually.pt-br.md | 3 + .../PRO__import_scan_ui.pt-br.md | 104 + .../import_scan_files/_index.pt-br.md | 16 + .../api_pipeline_modelling.pt-br.md | 53 + .../endpoint_meta_importer.pt-br.md | 39 + .../pro/specialized_import/_index.pt-br.md | 18 + .../external_tools.pt-br.md | 927 +++++++ .../specialized_import/smart_upload.pt-br.md | 59 + .../universal_parser.pt-br.md | 234 ++ .../messaging_connectors.pt-br.md | 227 ++ docs/content/metrics_reports/_index.pt-br.md | 19 + .../metrics_reports/ai/_index.pt-br.md | 17 + .../ai/mcp_server_pro.pt-br.md | 882 +++++++ .../Introduction_dashboard.pt-br.md | 59 + .../PRO__custom_dashboards.pt-br.md | 202 ++ .../PRO__custom_dashboards_api.pt-br.md | 489 ++++ .../PRO__custom_dashboards_llm.pt-br.md | 191 ++ .../dashboards/PRO__my_work.pt-br.md | 37 + .../dashboards/_index.pt-br.md | 43 + .../PRO__executive_insights.pt-br.md | 18 + .../pro_metrics/PRO__overview.pt-br.md | 56 + .../PRO__priority_insights.pt-br.md | 19 + .../PRO__program_insights.pt-br.md | 12 + .../PRO__remediation_insights.pt-br.md | 16 + .../pro_metrics/PRO__tool_insights.pt-br.md | 14 + .../pro_metrics/_index.pt-br.md | 17 + .../OS__using_the_report_builder.pt-br.md | 163 ++ .../reports/PRO__report_builder.pt-br.md | 218 ++ .../reports/PRO__report_builder_api.pt-br.md | 573 +++++ .../reports/PRO__report_builder_llm.pt-br.md | 400 +++ .../metrics_reports/reports/_index.pt-br.md | 44 + .../navigation/PRO__filter_index.pt-br.md | 122 + .../navigation/PRO__global_search.pt-br.md | 74 + .../navigation/PRO__menu_badges.pt-br.md | 56 + .../navigation/PRO__settings_menu.pt-br.md | 81 + .../PRO__table_customization.pt-br.md | 46 + docs/content/navigation/_index.pt-br.md | 17 + docs/content/sensei/OS__sensei.pt-br.md | 28 + docs/content/sensei/_index.pt-br.md | 19 + docs/content/sensei/about_sensei.pt-br.md | 62 + docs/content/sensei/fixing_findings.pt-br.md | 72 + docs/content/sensei/sensei_reference.pt-br.md | 104 + docs/content/sensei/setup_sensei.pt-br.md | 267 ++ docs/content/sensei/threat_modeling.pt-br.md | 114 + .../PRO__root_cause_correlation.pt-br.md | 289 +++ .../finding_correlation/_index.pt-br.md | 8 + .../OS__deduplication_tuning.pt-br.md | 165 ++ .../OS__similar_findings.pt-br.md | 76 + .../PRO__deduplication_tuning.pt-br.md | 172 ++ ...O__global_component_deduplication.pt-br.md | 90 + ...O__global_locations_deduplication.pt-br.md | 120 + .../PRO__location_drift_matching.pt-br.md | 136 + .../PRO__similar_findings.pt-br.md | 56 + ...RO_enabling_product_deduplication.pt-br.md | 56 + .../finding_deduplication/_index.pt-br.md | 8 + .../about_deduplication.pt-br.md | 176 ++ .../avoid_excess_duplicates.pt-br.md | 118 + .../false_positive_history.pt-br.md | 76 + .../finding_scoring/_index.pt-br.md | 8 + .../finding_scoring/cvss_support.pt-br.md | 52 + .../finding_scoring/epss_kev.pt-br.md | 151 ++ .../finding_scoring/reachability.pt-br.md | 130 + .../findings_workflows/OS__add_files.pt-br.md | 79 + .../OS__risk_acceptance.pt-br.md | 140 ++ .../PRO__add_files.pt-br.md | 52 + .../PRO__bulk_edit_findings.pt-br.md | 73 + .../PRO__peer_review.pt-br.md | 73 + .../PRO__risk_acceptance.pt-br.md | 186 ++ .../findings_workflows/_index.pt-br.md | 8 + .../create_findings_manually.pt-br.md | 17 + .../editing_findings.pt-br.md | 100 + .../findings_workflows/exporting.pt-br.md | 18 + .../finding_status_definitions.pt-br.md | 140 ++ .../intro_to_findings.pt-br.md | 142 ++ docs/i18n/pt-br.toml | 246 ++ 249 files changed, 31628 insertions(+) create mode 100644 docs/config/_default/menus/menus.pt-br.toml create mode 100644 docs/content/_index.pt-br.md create mode 100644 docs/content/admin/admin_intro/_index.pt-br.md create mode 100644 docs/content/admin/admin_intro/intro.pt-br.md create mode 100644 docs/content/admin/diagnostics/PRO__diagnostics.pt-br.md create mode 100644 docs/content/admin/diagnostics/_index.pt-br.md create mode 100644 docs/content/admin/feature_flags/PRO__feature_flags.pt-br.md create mode 100644 docs/content/admin/feature_flags/_index.pt-br.md create mode 100644 docs/content/admin/notifications/_index.pt-br.md create mode 100644 docs/content/admin/notifications/about_notifications.pt-br.md create mode 100644 docs/content/admin/notifications/configure_personal_notifs.pt-br.md create mode 100644 docs/content/admin/notifications/configure_system_notifs.pt-br.md create mode 100644 docs/content/admin/notifications/email_slack_teams.pt-br.md create mode 100644 docs/content/admin/sso/PRO__auth0.pt-br.md create mode 100644 docs/content/admin/sso/PRO__authorization_connectors.pt-br.md create mode 100644 docs/content/admin/sso/PRO__azure_ad.pt-br.md create mode 100644 docs/content/admin/sso/PRO__github_enterprise.pt-br.md create mode 100644 docs/content/admin/sso/PRO__gitlab.pt-br.md create mode 100644 docs/content/admin/sso/PRO__google.pt-br.md create mode 100644 docs/content/admin/sso/PRO__keycloak.pt-br.md create mode 100644 docs/content/admin/sso/PRO__ldap.pt-br.md create mode 100644 docs/content/admin/sso/PRO__oidc.pt-br.md create mode 100644 docs/content/admin/sso/PRO__okta.pt-br.md create mode 100644 docs/content/admin/sso/PRO__saml.pt-br.md create mode 100644 docs/content/admin/sso/PRO__scim.pt-br.md create mode 100644 docs/content/admin/sso/_index.pt-br.md create mode 100644 docs/content/admin/user_management/OS__audit_logging.pt-br.md create mode 100644 docs/content/admin/user_management/OS__authorized_users.pt-br.md create mode 100644 docs/content/admin/user_management/OS__creating_new_users.pt-br.md create mode 100644 docs/content/admin/user_management/OS__sso_user_local_login_fallback.pt-br.md create mode 100644 docs/content/admin/user_management/PRO__audit_log_index.pt-br.md create mode 100644 docs/content/admin/user_management/PRO__audit_logging.pt-br.md create mode 100644 docs/content/admin/user_management/PRO__creating_new_users.pt-br.md create mode 100644 docs/content/admin/user_management/PRO__custom_rbac_roles.pt-br.md create mode 100644 docs/content/admin/user_management/PRO__mfa.pt-br.md create mode 100644 docs/content/admin/user_management/PRO__resetting_user_credentials.pt-br.md create mode 100644 docs/content/admin/user_management/_index.pt-br.md create mode 100644 docs/content/admin/user_management/about_perms_and_roles.pt-br.md create mode 100644 docs/content/admin/user_management/create_user_group.pt-br.md create mode 100644 docs/content/admin/user_management/pro_permissions_overhaul.pt-br.md create mode 100644 docs/content/admin/user_management/set_user_permissions.pt-br.md create mode 100644 docs/content/admin/user_management/user_permission_chart.pt-br.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.pt-br.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.pt-br.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.pt-br.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.pt-br.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/_index.pt-br.md create mode 100644 docs/content/asset_modelling/OS_hierarchy/benchmarks.pt-br.md create mode 100644 docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.pt-br.md create mode 100644 docs/content/asset_modelling/OS_questionnaires/_index.pt-br.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/_index.pt-br.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.pt-br.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/priority_sla.pt-br.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/product_health_grade.pt-br.md create mode 100644 docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.pt-br.md create mode 100644 docs/content/asset_modelling/PRO_surveys/PRO__surveys.pt-br.md create mode 100644 docs/content/asset_modelling/PRO_surveys/_index.pt-br.md create mode 100644 docs/content/asset_modelling/_index.pt-br.md create mode 100644 docs/content/asset_modelling/components/PRO__components.pt-br.md create mode 100644 docs/content/asset_modelling/components/_index.pt-br.md create mode 100644 docs/content/asset_modelling/components/services.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__assets.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__calendar.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__engagements.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__findings.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__organizations.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/OS__tests.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__assets.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__calendar.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__engagements.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__findings.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__organizations.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/PRO__tests.pt-br.md create mode 100644 docs/content/asset_modelling/engagements_tests/_index.pt-br.md create mode 100644 docs/content/asset_modelling/locations/PRO__locations_overview.pt-br.md create mode 100644 docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.pt-br.md create mode 100644 docs/content/asset_modelling/locations/PRO__source_code_locations.pt-br.md create mode 100644 docs/content/asset_modelling/locations/PRO__working_with_sboms.pt-br.md create mode 100644 docs/content/asset_modelling/locations/PRO__working_with_urls.pt-br.md create mode 100644 docs/content/asset_modelling/locations/_index.pt-br.md create mode 100644 docs/content/asset_modelling/tags/OS__tagging_objects.pt-br.md create mode 100644 docs/content/asset_modelling/tags/PRO__tagging_objects copy.pt-br.md create mode 100644 docs/content/asset_modelling/tags/_index.pt-br.md create mode 100644 docs/content/automation/api/_index.pt-br.md create mode 100644 docs/content/automation/api/api-v2-docs.pt-br.md create mode 100644 docs/content/automation/api/languages.pt-br.md create mode 100644 docs/content/automation/api/notification_webhooks.pt-br.md create mode 100644 docs/content/automation/api/rate_limiting.pt-br.md create mode 100644 docs/content/automation/rules_engine/_index.pt-br.md create mode 100644 docs/content/automation/rules_engine/about.pt-br.md create mode 100644 docs/content/automation/rules_engine/scheduling.pt-br.md create mode 100644 docs/content/automation/rules_engine_2/_index.pt-br.md create mode 100644 docs/content/automation/rules_engine_2/about.pt-br.md create mode 100644 docs/content/automation/rules_engine_2/building_rules.pt-br.md create mode 100644 docs/content/automation/rules_engine_2/configuration.pt-br.md create mode 100644 docs/content/automation/rules_engine_2/converting_from_rules_engine.pt-br.md create mode 100644 docs/content/automation/rules_engine_2/deliveries.pt-br.md create mode 100644 docs/content/automation/rules_engine_2/node_reference.pt-br.md create mode 100644 docs/content/automation/rules_engine_2/runs.pt-br.md create mode 100644 docs/content/connectors/_index.pt-br.md create mode 100644 docs/content/connectors/about.pt-br.md create mode 100644 docs/content/connectors/downstream/PRO__jira_guide.pt-br.md create mode 100644 docs/content/connectors/downstream/_index.pt-br.md create mode 100644 docs/content/connectors/downstream/about.pt-br.md create mode 100644 docs/content/connectors/downstream/downstream_toolreference.pt-br.md create mode 100644 docs/content/connectors/downstream/troubleshooting_jira.pt-br.md create mode 100644 docs/content/connectors/issue_tracking.pt-br.md create mode 100644 docs/content/connectors/os_jira/_index.pt-br.md create mode 100644 docs/content/connectors/os_jira/os__jira_guide.pt-br.md create mode 100644 docs/content/connectors/upstream/_index.pt-br.md create mode 100644 docs/content/connectors/upstream/about.pt-br.md create mode 100644 docs/content/connectors/upstream/add_edit.pt-br.md create mode 100644 docs/content/connectors/upstream/manage_operations.pt-br.md create mode 100644 docs/content/connectors/upstream/manage_records.pt-br.md create mode 100644 docs/content/connectors/upstream/toolreference.pt-br.md create mode 100644 docs/content/federal_compliance/_index.pt-br.md create mode 100644 docs/content/federal_compliance/cmmc_assessments.pt-br.md create mode 100644 docs/content/federal_compliance/compliance_profile.pt-br.md create mode 100644 docs/content/federal_compliance/conmon_snapshots.pt-br.md create mode 100644 docs/content/federal_compliance/control_coverage.pt-br.md create mode 100644 docs/content/federal_compliance/poam_ledger.pt-br.md create mode 100644 docs/content/federal_compliance/remediation_slas.pt-br.md create mode 100644 docs/content/get_started/_index.pt-br.md create mode 100644 docs/content/get_started/about/OS__new_user_checklist.pt-br.md create mode 100644 docs/content/get_started/about/PRO__new_user_checklist.pt-br.md create mode 100644 docs/content/get_started/about/_index.pt-br.md create mode 100644 docs/content/get_started/about/about_defectdojo.pt-br.md create mode 100644 docs/content/get_started/about/defectdojo_versions.pt-br.md create mode 100644 docs/content/get_started/about/demo.pt-br.md create mode 100644 docs/content/get_started/about/faq.pt-br.md create mode 100644 docs/content/get_started/about/ui_pro_vs_os.pt-br.md create mode 100644 docs/content/get_started/common_use_cases/_index.pt-br.md create mode 100644 docs/content/get_started/common_use_cases/common_use_cases.pt-br.md create mode 100644 docs/content/get_started/contributing/_index.pt-br.md create mode 100644 docs/content/get_started/contributing/branching-model.pt-br.md create mode 100644 docs/content/get_started/contributing/documentation.pt-br.md create mode 100644 docs/content/get_started/contributing/how-to-write-a-parser.pt-br.md create mode 100644 docs/content/get_started/contributing/parser-documentation-template.pt-br.md create mode 100644 docs/content/get_started/open_source/_index.pt-br.md create mode 100644 docs/content/get_started/open_source/architecture.pt-br.md create mode 100644 docs/content/get_started/open_source/configuration.pt-br.md create mode 100644 docs/content/get_started/open_source/installation.pt-br.md create mode 100644 docs/content/get_started/open_source/running-in-production.pt-br.md create mode 100644 docs/content/get_started/pro/cloud/_index.pt-br.md create mode 100644 docs/content/get_started/pro/cloud/additional-cloud-instance.pt-br.md create mode 100644 docs/content/get_started/pro/cloud/cloud-architecture.pt-br.md create mode 100644 docs/content/get_started/pro/cloud/connectivity-troubleshooting.pt-br.md create mode 100644 docs/content/get_started/pro/cloud/egress-ip-addresses.pt-br.md create mode 100644 docs/content/get_started/pro/cloud/using-cloud-manager.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/_index.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/adding_storage_for_uploads.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/air_gapped_install.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/backing_up.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/fips_mode.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/hardware_sizing.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/installation_options.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/installing_on_docker_compose.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/installing_on_kubernetes.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/migrating_from_open_source.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/openshift_deployment.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/upgrading.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/upgrading_on_kubernetes.pt-br.md create mode 100644 docs/content/get_started/pro/onprem/upload_size_limits.pt-br.md create mode 100644 docs/content/get_started/pro/pro_features.pt-br.md create mode 100644 docs/content/help/contact_sales.pt-br.md create mode 100644 docs/content/help/contact_support.pt-br.md create mode 100644 docs/content/help/glossary.pt-br.md create mode 100644 docs/content/import_data/_index.pt-br.md create mode 100644 docs/content/import_data/import_intro/_index.pt-br.md create mode 100644 docs/content/import_data/import_intro/comparison.pt-br.md create mode 100644 docs/content/import_data/import_intro/reimport.pt-br.md create mode 100644 docs/content/import_data/import_scan_files/OS__create_findings_manually.pt-br.md create mode 100644 docs/content/import_data/import_scan_files/OS__import_scan_ui.pt-br.md create mode 100644 docs/content/import_data/import_scan_files/PRO__create_findings_manually.pt-br.md create mode 100644 docs/content/import_data/import_scan_files/PRO__import_scan_ui.pt-br.md create mode 100644 docs/content/import_data/import_scan_files/_index.pt-br.md create mode 100644 docs/content/import_data/import_scan_files/api_pipeline_modelling.pt-br.md create mode 100644 docs/content/import_data/import_scan_files/endpoint_meta_importer.pt-br.md create mode 100644 docs/content/import_data/pro/specialized_import/_index.pt-br.md create mode 100644 docs/content/import_data/pro/specialized_import/external_tools.pt-br.md create mode 100644 docs/content/import_data/pro/specialized_import/smart_upload.pt-br.md create mode 100644 docs/content/import_data/pro/specialized_import/universal_parser.pt-br.md create mode 100644 docs/content/issue_tracking/pro_integration/messaging_connectors.pt-br.md create mode 100644 docs/content/metrics_reports/_index.pt-br.md create mode 100644 docs/content/metrics_reports/ai/_index.pt-br.md create mode 100644 docs/content/metrics_reports/ai/mcp_server_pro.pt-br.md create mode 100644 docs/content/metrics_reports/dashboards/Introduction_dashboard.pt-br.md create mode 100644 docs/content/metrics_reports/dashboards/PRO__custom_dashboards.pt-br.md create mode 100644 docs/content/metrics_reports/dashboards/PRO__custom_dashboards_api.pt-br.md create mode 100644 docs/content/metrics_reports/dashboards/PRO__custom_dashboards_llm.pt-br.md create mode 100644 docs/content/metrics_reports/dashboards/PRO__my_work.pt-br.md create mode 100644 docs/content/metrics_reports/dashboards/_index.pt-br.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__executive_insights.pt-br.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__overview.pt-br.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__priority_insights.pt-br.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__program_insights.pt-br.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__remediation_insights.pt-br.md create mode 100644 docs/content/metrics_reports/pro_metrics/PRO__tool_insights.pt-br.md create mode 100644 docs/content/metrics_reports/pro_metrics/_index.pt-br.md create mode 100644 docs/content/metrics_reports/reports/OS__using_the_report_builder.pt-br.md create mode 100644 docs/content/metrics_reports/reports/PRO__report_builder.pt-br.md create mode 100644 docs/content/metrics_reports/reports/PRO__report_builder_api.pt-br.md create mode 100644 docs/content/metrics_reports/reports/PRO__report_builder_llm.pt-br.md create mode 100644 docs/content/metrics_reports/reports/_index.pt-br.md create mode 100644 docs/content/navigation/PRO__filter_index.pt-br.md create mode 100644 docs/content/navigation/PRO__global_search.pt-br.md create mode 100644 docs/content/navigation/PRO__menu_badges.pt-br.md create mode 100644 docs/content/navigation/PRO__settings_menu.pt-br.md create mode 100644 docs/content/navigation/PRO__table_customization.pt-br.md create mode 100644 docs/content/navigation/_index.pt-br.md create mode 100644 docs/content/sensei/OS__sensei.pt-br.md create mode 100644 docs/content/sensei/_index.pt-br.md create mode 100644 docs/content/sensei/about_sensei.pt-br.md create mode 100644 docs/content/sensei/fixing_findings.pt-br.md create mode 100644 docs/content/sensei/sensei_reference.pt-br.md create mode 100644 docs/content/sensei/setup_sensei.pt-br.md create mode 100644 docs/content/sensei/threat_modeling.pt-br.md create mode 100644 docs/content/triage_findings/finding_correlation/PRO__root_cause_correlation.pt-br.md create mode 100644 docs/content/triage_findings/finding_correlation/_index.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/OS__deduplication_tuning.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/OS__similar_findings.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__deduplication_tuning.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__global_component_deduplication.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__global_locations_deduplication.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__location_drift_matching.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO__similar_findings.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/PRO_enabling_product_deduplication.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/_index.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/about_deduplication.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/avoid_excess_duplicates.pt-br.md create mode 100644 docs/content/triage_findings/finding_deduplication/false_positive_history.pt-br.md create mode 100644 docs/content/triage_findings/finding_scoring/_index.pt-br.md create mode 100644 docs/content/triage_findings/finding_scoring/cvss_support.pt-br.md create mode 100644 docs/content/triage_findings/finding_scoring/epss_kev.pt-br.md create mode 100644 docs/content/triage_findings/finding_scoring/reachability.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/OS__add_files.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/OS__risk_acceptance.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/PRO__add_files.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/PRO__bulk_edit_findings.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/PRO__peer_review.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/PRO__risk_acceptance.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/_index.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/create_findings_manually.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/editing_findings.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/exporting.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/finding_status_definitions.pt-br.md create mode 100644 docs/content/triage_findings/findings_workflows/intro_to_findings.pt-br.md create mode 100644 docs/i18n/pt-br.toml diff --git a/docs/config/_default/languages.toml b/docs/config/_default/languages.toml index 30e7deb539..ebcea1e494 100644 --- a/docs/config/_default/languages.toml +++ b/docs/config/_default/languages.toml @@ -41,3 +41,10 @@ [ja.params] languageISO = "JA" languageTag = "ja" + +[pt-br] + languageName = "Português (Brasil)" + weight = 60 + [pt-br.params] + languageISO = "PT" + languageTag = "pt-br" diff --git a/docs/config/_default/menus/menus.pt-br.toml b/docs/config/_default/menus/menus.pt-br.toml new file mode 100644 index 0000000000..5b74c33a38 --- /dev/null +++ b/docs/config/_default/menus/menus.pt-br.toml @@ -0,0 +1,125 @@ +# Generated from menus.en.toml by regen_menus.py - do not hand-edit. +# Labels are translated; a URL is language-prefixed when that page exists +# in this language and left as the English URL when it does not, so no nav +# entry 404s. Hugo does not merge menus across languages, so this file must +# carry every entry menus.en.toml has. + +[[main]] + name = "Primeiros passos" + url = "/pt-br/get_started/about/about_defectdojo" + weight = 10 + +[[main]] + name = "Importar dados" + url = "/pt-br/import_data/import_intro/comparison/" + weight = 12 + +[[main]] + name = "Triagem de achados" + url = "/pt-br/triage_findings/findings_workflows/intro_to_findings/" + weight = 12 + +[[main]] + name = "Modele seus ativos" + url = "/pt-br/asset_modelling/engagements_tests/os__assets/" + weight = 13 + +[[main]] + name = "Conectores" + url = "/pt-br/connectors/about/" + weight = 13 + +[[main]] + name = "Métricas e relatórios" + url = "/pt-br/metrics_reports/dashboards/introduction_dashboard/" + weight = 14 + +[[main]] + name = "Sensei" + url = "/pt-br/sensei/os__sensei/" + weight = 14 + +[[main]] + name = "Administração" + url = "/pt-br/admin/admin_intro/intro/" + weight = 16 + +[[main]] + name = "Automação" + url = "/pt-br/automation/api/api-v2-docs/" + weight = 15 + +[[main]] + name = "Ferramentas compatíveis" + url = "/supported_tools/" + weight = 16 + +[[sidebar_sensei]] + name = "Sensei" + pageRef = "/sensei/OS__sensei" + weight = 0 + +[[sidebar_sensei]] + name = "Sobre o Sensei" + pageRef = "/sensei/about_sensei" + weight = 1 + +[[sidebar_sensei]] + name = "Configurar o Sensei" + pageRef = "/sensei/setup_sensei" + weight = 2 + +[[sidebar_sensei]] + name = "Corrigindo achados com o Sensei" + pageRef = "/sensei/fixing_findings" + weight = 3 + +[[sidebar_sensei]] + name = "Referência do Sensei" + pageRef = "/sensei/sensei_reference" + weight = 4 + +[[social]] + name = "YouTube" + pre = '' + url = "https://www.youtube.com/@defectdojo" + weight = 9 + +[[social]] + name = "X" + pre = '' + url = "https://x.com/defectdojo" + weight = 10 + +[[social]] + name = 'Linkedin' + pre = '' + url = "https://www.linkedin.com/company/defectdojo/" + weight = 10 + +[[social]] + name = "GitHub" + pre = '' + url = "https://github.com/DefectDojo/django-DefectDojo" + post = "v0.1.0" + weight = 30 + +[[footer]] + name = "DefectDojo.com" + url = "https://defectdojo.com" + weight = 10 + +[[footer]] + name = "GitHub" + url = "https://github.com/DefectDojo/django-DefectDojo" + weight = 20 + +[[footer]] + name = "Community" + url = "https://defectdojo.com/open-source" + weight = 30 + +[[footer]] + name = "Support" + url = "mailto:support@defectdojo.com" + weight = 40 diff --git a/docs/content/_index.pt-br.md b/docs/content/_index.pt-br.md new file mode 100644 index 0000000000..f794dedc41 --- /dev/null +++ b/docs/content/_index.pt-br.md @@ -0,0 +1,5 @@ +--- +title: Documentação do DefectDojo +date: 2021-02-02 20:46:29+01:00 +draft: false +--- diff --git a/docs/content/admin/admin_intro/_index.pt-br.md b/docs/content/admin/admin_intro/_index.pt-br.md new file mode 100644 index 0000000000..39f86549de --- /dev/null +++ b/docs/content/admin/admin_intro/_index.pt-br.md @@ -0,0 +1,16 @@ +--- +title: Introdução +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.pt-br.md b/docs/content/admin/admin_intro/intro.pt-br.md new file mode 100644 index 0000000000..213ded39d2 --- /dev/null +++ b/docs/content/admin/admin_intro/intro.pt-br.md @@ -0,0 +1,16 @@ +--- +title: Controles de Administração do DefectDojo +description: Controles administrativos para configurar, proteger e manter sua instância + do DefectDojo. +weight: 0 +--- + +As ações administrativas do DefectDojo fornecem os controles necessários para configurar e manter a +plataforma em toda a sua organização. Essas ações são projetadas para administradores responsáveis pelo +gerenciamento de usuários, pela configuração do sistema e por garantir que o DefectDojo opere de forma segura +e confiável em escala. + +As ações administrativas permitem gerenciar aspectos essenciais do DefectDojo, incluindo métodos de +autenticação, acesso de usuários, configurações globais e integrações. Desde a configuração inicial até a +manutenção contínua, esses controles definem como o DefectDojo se comporta e como os usuários interagem com +ele. diff --git a/docs/content/admin/diagnostics/PRO__diagnostics.pt-br.md b/docs/content/admin/diagnostics/PRO__diagnostics.pt-br.md new file mode 100644 index 0000000000..bcb041b811 --- /dev/null +++ b/docs/content/admin/diagnostics/PRO__diagnostics.pt-br.md @@ -0,0 +1,169 @@ +--- +title: Diagnósticos +description: 'Leia o registro entre subsistemas das tentativas de integração: o que + é registrado, como filtrá-lo, como as credenciais são mantidas fora dele e quem + pode ver o detalhe técnico' +weight: 1 +audience: pro +--- + +Diagnósticos é um único registro de todas as tentativas que o DefectDojo faz para se comunicar com algo fora dele — e das tentativas que outros sistemas fazem para se comunicar com ele. Quando um ticket nunca aparece, um scan nunca é importado, ou um usuário não consegue fazer login, esta é a página que mostra o que aconteceu, quando, com qual configuração, e quem disparou a tentativa. + +Diagnósticos é um recurso do **DefectDojo Pro**. Encontre-o em **Connect > Diagnostics**. + +![The Diagnostics ledger, Errors view](images/diagnostics_errors.png) + +## O que é registrado + +Uma linha é gravada por tentativa, vinda de todo subsistema que se comunica para fora do DefectDojo: + +| Fonte | O que gera linhas | +| --- | --- | +| **Connector** | Execuções de descoberta e sincronização dos conectores upstream | +| **Downstream integrator** | Envios (pushes) para Jira, GitHub, GitLab, ServiceNow e os demais conectores downstream | +| **Jira** | A integração legada do Jira: envios, comentários e pré-visualizações | +| **SSO (OIDC/OAuth2)** | Tentativas de login por meio de um provedor OAuth | +| **SAML** | Asserções SAML, incluindo falhas de assinatura e de atributos | +| **LDAP** | Binds e consultas (lookups) LDAP | +| **Import / Reimport** | Envios de scans, seja pela interface, pela API ou por agendamento | +| **Rules engine** | Avaliações de regras e as ações que elas tentam executar | +| **Scheduling** | Execuções agendadas, incluindo as que nunca chegaram a iniciar | +| **Sensei** | Varreduras de repositórios e execuções de correção | +| **Notification** | Envio de notificações de saída | +| **System** | Atividade em nível de instância que não pertence a nenhum produto | + +As linhas são gravadas *ao lado* do subsistema, nunca em seu lugar. Cada adaptador está vinculado ao registro de origem e é deliberadamente à prova de falhas: se a gravação de uma linha de diagnóstico gerar um erro, esse erro é engolido e a operação original continua normalmente. Por isso, o Diagnósticos nunca pode ser a causa de uma falha em um envio, importação ou login. + +Como as linhas são indexadas pelo registro que as originou, salvar novamente um registro de origem atualiza a linha de diagnóstico existente em vez de criar uma duplicata. Uma tentativa é uma linha durante toda a sua existência, desde `Queued`, passando por `Running`, até o resultado final. + +### Campos de uma linha + +| Campo | Significado | +| --- | --- | +| **Quando** | Quando a linha foi registrada; **Iniciado**, **Concluído** e **Duração** descrevem a própria tentativa | +| **Fonte** | O subsistema, conforme a tabela acima | +| **Provedor** | A ferramenta ou provedor específico dentro dessa fonte (`jira`, `github`, `okta`, o nome de um scanner) | +| **Operação** | O que foi tentado (`push`, `sync`, `login`, `reimport`, `rule_run`) | +| **Status** | `Queued`, `Running`, `Success`, `Failed`, `Timed out`, `Skipped` ou `Dry run` | +| **Severidade** | `Info`, `Warning`, `Error` ou `Critical` | +| **Resumo** | Um resultado em uma linha, seguro de ler rapidamente | +| **Gatilho** | O que disparou a tentativa: `UI`, `API`, `Scheduled`, `Webhook`, `Automatic`, `Command line` ou `System` | +| **Acionado por** | O usuário responsável, ou `System` para trabalho não supervisionado | +| **Ativo** | O produto ao qual a tentativa pertence; vazio significa nível de instância | +| **Objeto relacionado** | O achado, engajamento ou outro registro sobre o qual a tentativa tratava | +| **Configuração** | Qual configuração foi usada, por seu rótulo | +| **Referência externa** | O identificador retornado pelo outro sistema, como a chave de um issue criado | +| **ID de correlação** | Relaciona as linhas de uma mesma operação lógica | +| **Detalhe relatado** e **Contexto** | O detalhe técnico completo (restrito, veja [Quem vê o quê](#who-sees-what)) | + +## As quatro visualizações + +As abas acima da tabela são pontos de partida salvos, não filtros que você precisa reconstruir toda vez: + +* **Errors** — falhas e timeouts. A primeira que você deve abrir. +* **Successes** — prova de que uma integração que funciona está de fato funcionando, útil quando alguém relata que "nada está sincronizando". +* **Never completed** — tentativas ainda em `Queued` ou `Running` muito depois do momento em que deveriam ter terminado. São os casos silenciosos: nada falhou, então nada foi relatado, mas também nada chegou. +* **All events** — tudo, sem filtro. + +![All events, showing every source](images/diagnostics_all_events.png) + +A visualização ativa faz parte da URL da página, então uma visualização pode ser compartilhada por link e sobrevive a uma atualização da página. + +## Restringindo a lista + +* **Intervalo de tempo** — 24 horas, 7 dias, 30 dias ou 90 dias, pelos botões no cabeçalho. +* **Contagens por fonte** — as contagens coloridas abaixo dos cartões de resumo também funcionam como filtros rápidos. Clique em uma para mostrar apenas aquela fonte; clique novamente (ou em **Clear source filter**) para voltar. No máximo uma fica ativa por vez. +* **Filtros e ordenação por coluna** — cada coluna permite filtrar e ordenar, incluindo Severidade e Fonte. A Severidade ordena por gravidade (`Critical` → `Info`) em vez de ordem alfabética, e a Fonte ordena pelo rótulo exibido, não pelo valor armazenado internamente. +* **Keyword Search** — pesquisa em todos os campos de texto ao mesmo tempo. +* **Preferências de colunas** — o seletor de colunas e os layouts salvos funcionam da mesma forma que em qualquer outra lista do Pro. + +![A source count used as a quick filter](images/diagnostics_chip_filter.png) + +Clique na lupa no início de uma linha para abrir a tentativa completa: + +![A single event, including the redaction notice](images/diagnostics_detail.png) + +## As credenciais são removidas antes da linha ser gravada + +Erros de integração citam a requisição que falhou, e essas citações carregam segredos: um cabeçalho `Authorization`, um token em uma query string, uma senha dentro de uma URL de conexão. O Diagnósticos remove esses valores **na entrada**, de modo que o valor original nunca chega ao banco de dados e nenhuma mudança de ideia posterior pode expô-lo. + +Duas coisas são higienizadas: + +* **Valores sob chaves com formato de credencial** — qualquer coisa cuja chave pareça um segredo (`password`, `token`, `secret`, `api_key`, `authorization`, `private_key` e similares, em qualquer capitalização ou com traços ou espaços). Um pequeno conjunto de chaves é isento, porque só a *presença* delas importa, nunca o conteúdo. +* **Valores que parecem credenciais onde quer que apareçam** — cabeçalhos de autorização bearer e basic, JWTs, credenciais embutidas em URLs (`https://user:pass@host`), prefixos de token reconhecíveis de fornecedores e blocos PEM. + +Cada um é substituído por `[redacted]`. A mensagem ao redor é mantida, para que o erro continue legível: + +```text +401 Unauthorized: Authorization: [redacted] +upload rejected: https://svc:[redacted]@sftp.example/out/… +``` + +Valores longos são truncados, e contextos profundamente aninhados são achatados, para que um payload enorme não sobrecarregue a tabela. + +Quando algo é removido de uma linha, a própria linha indica isso, em vez de deixar você se perguntando se o campo estava vazio ou foi esvaziado. + +> **A redação é, por design, uma tentativa de melhor esforço.** O higienizador reconhece *formatos* de credenciais. Um segredo que se pareça com texto comum, sob uma chave que não pareça sensível, ainda pode ser registrado. Trate o Diagnósticos como um log operacional, não como um lugar onde a ausência de segredos é garantida — e mantenha o detalhe técnico restrito a quem realmente precisa dele. + +## Quem vê o quê + +O Diagnósticos é dividido por nível de acesso, porque o resumo de uma falha é útil para o dono de um produto, mas a requisição bruta por trás dela não é. + +| | Superuser | Everyone else | +| --- | --- | --- | +| Linhas dos produtos aos quais têm autorização | Sim | Sim | +| Linhas em nível de instância (sem produto) | Sim | Não | +| Resumo, fonte, status, severidade, tempos, configuração | Sim | Sim | +| **Detalhe relatado**, **Contexto**, **IP remoto** | Sim | Ocultado, e identificado como ocultado | + +Um usuário que não é superusuário vê que um detalhe existe e está sendo ocultado, em vez de um campo vazio que pareça um dado ausente. As linhas em nível de instância — SSO, SAML, LDAP e outras atividades que não pertencem a nenhum produto — são exclusivas para superusuários, já que não há associação a nenhum produto que pudesse conceder acesso a elas. + +## Por quanto tempo os registros são mantidos + +Uma tarefa agendada faz a limpeza do registro para que ele não cresça sem limite: + +| Severidade | Mantido por | +| --- | --- | +| `Info` | 30 dias | +| `Warning`, `Error`, `Critical` | 180 dias | + +Ambas as janelas são configuráveis com as configurações `DIAGNOSTIC_EVENT_INFO_RETENTION_DAYS` e `DIAGNOSTIC_EVENT_RETENTION_DAYS`. A exclusão é feita em lotes, para que uma purga grande não mantenha uma transação longa aberta. + +## API + +O registro é somente leitura pela API, em `/api/v2/diagnostic_events/`: + +| Endpoint | Retorna | +| --- | --- | +| `GET /api/v2/diagnostic_events/` | A lista, com os filtros abaixo | +| `GET /api/v2/diagnostic_events/{id}/` | Um evento | +| `GET /api/v2/diagnostic_events/summary/` | As contagens por trás dos cartões do cabeçalho, incluindo os totais por fonte | +| `GET /api/v2/diagnostic_events/choices/` | Os valores válidos para `source`, `status`, `severity` e `trigger` | + +Parâmetros úteis: + +| Parâmetro | Efeito | +| --- | --- | +| `source`, `status`, `severity`, `trigger` | Aceitam vários valores separados por vírgula de uma vez | +| `failures_only=true` | Falhas e timeouts | +| `unresolved_only=true` | Tentativas ainda em fila ou em execução | +| `product_name` | Filtra pelo nome do produto | +| `object_model` | Filtra pelo tipo de registro sobre o qual a tentativa tratava | +| `o=` | Ordenação, com o prefixo `-` para inverter (`o=-created_at`) | + +As mesmas regras de acesso se aplicam: um usuário que não é superusuário recebe linhas restritas aos seus produtos, com os campos restritos ocultados. + +## Descobrindo o que deu errado + +* **Um ticket nunca apareceu.** Filtre a Fonte pelo integrador (ou Jira) e leia o Status. `Failed` fornece o motivo no Resumo; `Queued` muito tempo depois do fato indica que o job nunca chegou a rodar, o que é um problema de worker ou de agendamento, e não de credencial. +* **Um usuário não consegue fazer login.** Filtre a Fonte por SSO, SAML ou LDAP, e leia a falha da tentativa dele — uma assinatura de asserção inválida, um bind rejeitado, um atributo incompatível. Essas linhas são em nível de instância, portanto exclusivas para superusuários. +* **Um scan não apareceu.** Filtre a Fonte por Import / Reimport. Observe o Gatilho para distinguir um envio agendado e não supervisionado de um envio manual de alguém, e o Acionado por para saber a quem perguntar. +* **Algo está tentando novamente sem parar.** Ordene por ID de correlação, ou filtre por um valor específico, para ver juntas todas as tentativas da mesma operação lógica. +* **"Nada está funcionando."** Abra primeiro o Successes para a mesma janela de tempo. Uma lista saudável ali transforma uma indisponibilidade vaga em algo específico. + +## Relacionados + +* [Feature Flags](/admin/feature_flags/pro__feature_flags/) — ativando e desativando recursos opcionais do Pro +* [Connectors](/connectors/upstream/about/) — trazendo achados para dentro +* [Pro Integrations](/connectors/downstream/about/) — enviando achados para fora +* [Single Sign-On](/admin/sso/) — os provedores de identidade cujas tentativas de login aparecem aqui diff --git a/docs/content/admin/diagnostics/_index.pt-br.md b/docs/content/admin/diagnostics/_index.pt-br.md new file mode 100644 index 0000000000..f74526f812 --- /dev/null +++ b/docs/content/admin/diagnostics/_index.pt-br.md @@ -0,0 +1,24 @@ +--- +title: Diagnósticos +description: Um único lugar para ver por que uma tentativa de integração falhou, em + todos os subsistemas que se comunicam com algo fora do DefectDojo +summary: '' +date: 2026-07-30 00:00:00+00:00 +lastmod: 2026-07-30 00:00:00+00:00 +draft: false +weight: 6 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +pro-feature: true +--- + +Quando algo não chega — um ticket que nunca foi criado, um scan que nunca foi importado, um usuário que não consegue fazer login — a evidência costumava estar em qualquer subsistema que por acaso fosse dono da tentativa. O Diagnósticos registra cada uma dessas tentativas em um único registro central, de modo que a pergunta "por que isso não aconteceu?" vira uma única página em vez de oito. + +Diagnósticos é um recurso do **DefectDojo Pro**. + +* [Diagnósticos](./pro__diagnostics/) — o que é registrado, como ler e filtrar o registro, como as credenciais são mantidas fora dele, quem pode ver o detalhe técnico e por quanto tempo os registros são mantidos. diff --git a/docs/content/admin/feature_flags/PRO__feature_flags.pt-br.md b/docs/content/admin/feature_flags/PRO__feature_flags.pt-br.md new file mode 100644 index 0000000000..478725bb77 --- /dev/null +++ b/docs/content/admin/feature_flags/PRO__feature_flags.pt-br.md @@ -0,0 +1,195 @@ +--- +title: Feature Flags +description: Ative e desative recursos opcionais do DefectDojo Pro pela interface + do DefectDojo +weight: 1 +audience: pro +--- + +Os Feature Flags permitem ativar e desativar recursos opcionais do DefectDojo Pro na sua própria +instância — recursos que antes só podiam ser habilitados entrando em contato com o Suporte da DefectDojo agora +podem ser autoatendidos pela interface. + +A página Feature Flags é visível apenas para **superusuários**. Outros usuários, incluindo Global Owners, não +a veem. + +## Abrindo a página Feature Flags + +Acesse **Settings > Feature Flags** na barra lateral esquerda. + +A página lista todos os recursos opcionais com: + +* **Name** — o recurso, com uma tag **BETA** quando ainda está em beta +* **Description** — o que o recurso faz +* **Documentation link** — onde existe documentação para aquele recurso +* **Toggle** — se o recurso está ativado no momento + +Use a caixa de pesquisa para filtrar a lista pelo nome ou pela descrição do recurso. + +### Recursos que não aparecem na lista + +A página lista os recursos que você pode optar por adotar. Dois tipos de recurso estão ausentes dela. + +**Sempre ativos.** Quando um recurso atinge disponibilidade geral, ele fica ativo em todas as instâncias e +deixa de ser listado, pois não há mais decisão a tomar: + +* **Downstream Connectors** — consulte [Downstream Connectors](/connectors/downstream/about/) +* **Universal Parser** — consulte [Universal Parser](/import_data/pro/specialized_import/universal_parser/) +* **Asset Hierarchy** — consulte [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/) +* **Appearance** e **Feature Flags** — as duas páginas de Settings com o mesmo nome + +Nada muda na sua instância se você já tinha um desses recursos ativado. Se você tinha algum desativado, ele +agora está ativo: esses recursos fazem parte do DefectDojo Pro em vez de serem opcionais. Entre em contato +com o [Suporte da DefectDojo](mailto:support@defectdojo.com) se isso for um problema para a sua instância. + +**Habilitados pela DefectDojo mediante solicitação.** Alguns recursos dependem de infraestrutura provisionada +por instância, portanto são ativados pela DefectDojo em vez de por esta página: + +* **Scheduling Service** — consulte [Scheduling Rules](/automation/rules_engine/scheduling/) + +Entre em contato com o [Suporte da DefectDojo](mailto:support@defectdojo.com) para ativar um desses recursos. +Se já estiver ativo na sua instância, ele permanece ativo. + +## Ativando ou desativando um recurso + +1. Encontre o recurso na lista. +2. Clique no toggle dele. +3. A alteração entra em vigor imediatamente. Outros usuários recebem a alteração no próximo carregamento da + página. + +Alguns recursos exibem uma caixa de diálogo de confirmação antes que a alteração seja aplicada. Isso acontece +ao ativar um recurso que traz um aviso (por exemplo, um que exige reinicialização ou pode afetar dados +existentes), ou um que não pode ser desativado novamente. + +Desativar um recurso normalmente é apenas o inverso de ativá-lo. As exceções são indicadas em +[Quando um toggle está bloqueado](#when-a-toggle-is-locked). + +### Organization / Asset Relabeling + +**Organization / Asset Relabeling** renomeia "Product Type" para "Organization" e "Product" para "Asset". Ele +vem ativado por padrão e é alternado nesta página como qualquer outro recurso, mas vale a pena saber quais +partes do DefectDojo ele governa: + +* A **Pro UI** segue este toggle. Os novos rótulos aparecem no próximo carregamento da página. +* As páginas da **Classic UI**, suas URLs e os relatórios gerados obtêm sua nomenclatura da configuração de + deployment `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL` (também ativada por padrão), que é lida quando o + DefectDojo é iniciado. Este toggle não as altera, e reiniciar também não faz com que ele as altere. + +O toggle armazenado foi inicializado a partir dessa configuração de deployment, portanto os dois permanecem +alinhados até que você altere um deles. Se você desativar o relabeling aqui e também usar a Classic UI, +defina `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL=False` no seu deployment e reinicie para que as duas +superfícies fiquem alinhadas. No [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), entre em contato com o +[Suporte da DefectDojo](mailto:support@defectdojo.com) para que a configuração de deployment seja alterada. + +Por esse motivo, o recurso traz uma tag **Restart Recommended** na página Feature Flags: a nomenclatura usada +fora da Pro UI é fixada quando o processo é iniciado. De qualquer forma, o relabeling é apenas cosmético. Os +modelos de banco de dados, nomes de campos e endpoints da API permanecem inalterados, portanto a automação +existente continua funcionando. Consulte [Asset Hierarchy](/asset_modelling/pro_hierarchy/asset_hierarchy/). + +## Quando um toggle está bloqueado + +Um recurso que você não pode alterar é exibido com um selo de bloqueio explicando o motivo: + +| Badge | O que significa | O que fazer | +| --- | --- | --- | +| **Managed by DefectDojo** | A DefectDojo definiu este recurso de forma centralizada para a sua instância. Sua configuração não pode substituí-lo. | Entre em contato com o [Suporte da DefectDojo](mailto:support@defectdojo.com) se precisar alterá-lo. | +| **Unavailable on This Deployment** | O recurso não é oferecido no seu tipo de instalação. Veja [Disponibilidade de recursos](#feature-availability) abaixo. | Nada a fazer. O recurso não se aplica à sua instância. | +| **Cannot Be Disabled** | O recurso já está ativo e é de mão única. Não há mecanismo para revertê-lo. | Nada a fazer. Isso é esperado. | +| **Managed by deployment** | O recurso é controlado pela sua configuração de deployment, e não por esta página. | Veja [DefectDojo Pro (On-Premise)](#defectdojo-pro-on-premise) abaixo. | + +## DefectDojo Pro (Cloud) + +No [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), **Settings > Feature Flags** é o único lugar que você +precisa. Ative um recurso e ele já estará em produção. + +Duas coisas são tratadas pela DefectDojo, e não por você: + +* **Managed by DefectDojo** — o recurso é fixado de forma centralizada. Entre em contato com o + [Suporte da DefectDojo](mailto:support@defectdojo.com) para alterá-lo. +* **Managed by deployment** — o recurso faz parte de como sua instância é provisionada. Entre em contato com + o Suporte também para esses casos, já que as instâncias Cloud não expõem a configuração de deployment aos + clientes. + +As instâncias Cloud também têm acesso a recursos que não são oferecidos on-premise. Veja +[Disponibilidade de recursos](#feature-availability). + +## DefectDojo Pro (On-Premise) + +No [DefectDojo Pro (On-Premise)](/get_started/pro/onprem/), a maioria dos recursos funciona exatamente como +no Cloud: abra **Settings > Feature Flags** e ative-os ou desative-os. + +Um pequeno número de recursos, em vez disso, é lido a partir da sua configuração de deployment. Eles alteram +a forma como a aplicação é iniciada, portanto não podem ser alternados em tempo de execução. Esses recursos +aparecem na página como somente leitura, rotulados como **Managed by deployment**, e indicam a variável de +ambiente que os controla, por exemplo `DD_V3_FEATURE_LOCATIONS` para +[Locations](/asset_modelling/locations/pro__locations_overview/). + +Como esses recursos exigem uma reinicialização, e alguns deles não podem ser revertidos depois de ativados, +consulte a documentação específica do recurso antes de alterá-lo. Vários são melhor ativados com a ajuda do +[Suporte da DefectDojo](mailto:support@defectdojo.com). + +Para alterar um desses recursos: + +1. Defina a variável de ambiente no seu deployment do DefectDojo. A página indica qual variável definir. +2. Reinicie o DefectDojo para que o novo valor seja lido na inicialização. +3. Recarregue a página Feature Flags para confirmar o novo estado. + +Como esses valores são lidos na inicialização, não é possível alterá-los pela interface, e alterná-los no +seu ambiente sem uma reinicialização não tem efeito. + +Recursos oferecidos apenas no Cloud aparecem como **Unavailable on This Deployment** em uma instância +on-premise. Isso é esperado e não é um problema de licenciamento. + +## Disponibilidade de recursos + +A maioria dos recursos está disponível nos dois tipos de instalação. As exceções são: + +| Feature | Availability | How it is controlled | +| --- | --- | --- | +| Request a New Connector | Somente [DefectDojo Pro (Cloud)](/get_started/pro/cloud/) | Página Feature Flags. Exibido como **Unavailable on This Deployment** on-premise. | +| Locations | Ambos | Página Feature Flags. Observe que Locations não pode ser desativado novamente depois de ativado. Veja [Locations Overview](/asset_modelling/locations/pro__locations_overview/). | +| Organization / Asset Relabeling | Ambos | Página Feature Flags para a Pro UI; a Classic UI, suas URLs e os relatórios gerados seguem a configuração de deployment `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`. Veja [acima](#organization--asset-relabeling). | + +Todos os demais recursos opcionais são alternados diretamente na página Feature Flags, tanto em instâncias +Cloud quanto On-Premise. + +## Lendo feature flags fora da interface + +Não é necessário abrir a página Feature Flags para saber quais recursos estão ativados — o estado das flags +também pode ser lido de forma programática, o que é útil quando uma automação precisa verificar se um +recurso está disponível antes de depender dele. + +``` +GET /api/v2/defectdojo_information/feature_flags/ +``` + +Isso retorna um array JSON com um objeto por feature flag. Além de `key`, `title` e `description` da flag, +cada objeto informa os valores que a automação geralmente precisa: `effective` (se o recurso está de fato +ativo nesta instância), `default`, `application_value` (a configuração própria da instância, ou `null` se +não definida), `editable`, e `locked_reason` quando uma flag não pode ser alterada. Flags removidas do +produto são omitidas. + +Qualquer usuário **autenticado** pode lê-lo — não é necessária função de superusuário. Para o schema exato +de resposta na sua versão, consulte a documentação interativa da API da sua instância em +`/api/v2/oa3/swagger-ui/`, gerada a partir do build em execução. Veja também a +[documentação da API v2](/automation/api/api-v2-docs/). + +A mesma listagem somente leitura também é publicada na superfície `/api/mcp/` da instância, em +`/api/mcp/defectdojo_information/feature_flags/`. + +Este endpoint é **somente leitura**. Ativar ou desativar um recurso ainda é feito na página Feature Flags +ou — para os recursos configurados por deployment mencionados acima — nas configurações do seu deployment. + +## Perguntas frequentes + +**Um recurso que eu quero não está na lista.** +A lista mostra apenas recursos opcionais. Recursos que estão sempre ativos não aparecem. Se você esperava +encontrar um recurso que está faltando, confirme se a sua licença o inclui e, em seguida, entre em contato +com o [Suporte da DefectDojo](mailto:support@defectdojo.com). + +**Ativei um recurso, mas não o vejo.** +Recarregue a página — entradas de menu e rotas são avaliadas quando a página carrega, portanto um recurso +recém-ativado aparece no próximo carregamento, e não instantaneamente na visualização atual. + +**Uma atualização vai alterar minhas configurações?** +Não. A atualização preserva os recursos que você ativou e os que você desativou. diff --git a/docs/content/admin/feature_flags/_index.pt-br.md b/docs/content/admin/feature_flags/_index.pt-br.md new file mode 100644 index 0000000000..781395089d --- /dev/null +++ b/docs/content/admin/feature_flags/_index.pt-br.md @@ -0,0 +1,25 @@ +--- +title: Feature Flags +description: Ative e desative recursos opcionais do DefectDojo Pro para a sua instância +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 +--- + +Muitos recursos do DefectDojo Pro são lançados atrás de uma feature flag, para que você possa +adotá-los quando estiver pronto, em vez de na versão em que são introduzidos. + +Feature Flags é um recurso do DefectDojo Pro. O DefectDojo open-source não possui uma superfície de feature +flags. + +* [Feature Flags](./pro__feature_flags/) — veja todos os recursos opcionais, ative e desative recursos, e + entenda por que um recurso pode estar indisponível na sua instância. diff --git a/docs/content/admin/notifications/_index.pt-br.md b/docs/content/admin/notifications/_index.pt-br.md new file mode 100644 index 0000000000..cd00d1971c --- /dev/null +++ b/docs/content/admin/notifications/_index.pt-br.md @@ -0,0 +1,16 @@ +--- +title: Notificações +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.pt-br.md b/docs/content/admin/notifications/about_notifications.pt-br.md new file mode 100644 index 0000000000..93dfeb54a0 --- /dev/null +++ b/docs/content/admin/notifications/about_notifications.pt-br.md @@ -0,0 +1,103 @@ +--- +title: Sobre Notificações e 🔔 Alertas +description: Saiba mais sobre notificações e alertas no aplicativo +aliases: +- /pt-br/en/customize_dojo/notifications/about_notifications +--- + +DefectDojo mantém você atualizado de diversas formas. Notificações podem ser enviadas para Engajamentos futuros, [Menções a usuários](/triage_findings/findings_workflows/intro_to_findings/#notes-and-mentions), expiração de SLA e outros eventos no sistema. + +Este artigo apresenta uma visão geral das notificações, tanto no nível de Sistema quanto no nível Pessoal. + +## Tipos de Notificação + +O DefectDojo trata as notificações de duas formas diferentes:: + +* **Notificações do Sistema** são enviadas a todos os usuários. +* **As Notificações Pessoais são definidas por usuários individuais e são recebidas além de quaisquer Notificações do Sistema.** + +Em ambos os casos, as regras de [Controle de Acesso Baseado em Função](../../user_management/about_perms_and_roles/) se aplicam, portanto os usuários não receberão notificações de atividade de Produtos ou Tipos de Produto (ou seus objetos relacionados) aos quais não têm acesso. + +## Métodos de Entrega de Notificação + +Existem quatro métodos de entrega para as notificações do DefectDojo: + +* O DefectDojo pode compartilhar **🔔 Alertas,** armazenados como uma lista na interface do DefectDojo +* O DefectDojo pode enviar notificações para um endereço de **E-mail** +* O DefectDojo pode enviar notificações para o **Slack,** em um canal compartilhado ou individual +* O DefectDojo também pode enviar notificações para o **Microsoft Teams** em um canal compartilhado + +As notificações podem ser enviadas para vários destinos simultaneamente. + +Para receber notificações do Slack e do Teams, é necessário ter uma integração funcionando. Para mais informações sobre como configurar essa integração, consulte nosso [Guia](../email_slack_teams). + +## Alertas no Aplicativo + +O sistema de Alertas do DefectDojo mantém você atualizado sobre toda a atividade de Produto ou do sistema. + +### A Lista de Alertas + +A Lista de Alertas fica sempre visível no canto superior direito do DefectDojo e contém uma lista compacta de notificações. Clicar em cada Alerta o levará diretamente à página relevante no DefectDojo. + +Você pode abrir sua Lista de Alertas clicando no **ícone 🔔▼** no canto superior direito: + +![image](images/About_In-App_Alerts.png) + +Para ver todas as suas notificações, com detalhes adicionais, você pode clicar no botão **See All Alerts \>**, que abrirá a **Alerts Page**. + +Você também pode **Clear All Alerts \>** a partir da Lista de Alertas. + +### A Página de Alertas + +A Página de Alertas armazena todos os seus Alertas no DefectDojo com detalhes adicionais. Nesta página, você pode ler as descrições de cada Alerta no DefectDojo e removê-los da fila de Alertas quando não precisar mais deles. + +![image](images/About_In-App_Alerts_2.png) + +Para remover um ou mais Alertas da Página de Alertas, marque a caixa vazia ao lado dele e clique no botão **Remove selected** no canto inferior direito da Página. + +### Observações Sobre Alertas + +* Ler um Alerta, ou abrir a Página de Alertas, não removerá nenhum Alerta da contagem ao lado do ícone de sino. Isso permite que você acesse facilmente alertas anteriores para usá-los como lembretes ou como um registro de atividade pessoal. +* Usar a função **Clear All Alerts \>** no Menu de Alertas também limpará completamente a **Alerts Page**, portanto use esse recurso com cuidado. +* Remover um Alerta afeta apenas a sua própria Lista de Alertas \- isso não afetará os Alertas de nenhum outro usuário. +* Remover um Alerta não remove nenhum histórico de importação ou registro de atividade do DefectDojo. + +## Restringindo Notificações de Solicitação de Revisão (Pro) + +Se uma revisão for solicitada a todos os revisores elegíveis, todos os elegíveis para esse ativo são notificados. Isso representa muito e-mail para um revisor que cuida apenas de parte do seu ambiente. + +Na interface do DefectDojo Pro, você pode restringir suas próprias notificações de solicitação de revisão. Na sua página de configurações de notificação, em **Review Requests**: + +* **Review Request Scope** — *All* (o padrão) notifica você sobre tudo o que você pode visualizar. *Selected* restringe você aos ativos e tipos de ativo que você escolher. +* **Review Request Assets** / **Review Request Asset Types** — a parte do ambiente sobre a qual você quer ser avisado. Uma solicitação corresponde se estiver em um dos seus ativos selecionados *ou* em um dos seus tipos de ativo selecionados. + +Duas coisas devem ficar claras: + +* Escolher *Selected* e não selecionar nada significa **nenhum**, não todos. +* Restringir suprime a notificação, **não a solicitação**. Você continua sendo um revisor solicitado, e a solicitação ainda aparece na sua fila [My Work](/metrics_reports/dashboards/pro__my_work/), em **Awaiting My Review** — você simplesmente não é avisado por mensagem. Isso é proposital: a fila é o registro duradouro, as notificações são apenas o lembrete. + +Essa restrição também tem precedência sobre a substituição em nível de sistema descrita abaixo, portanto um revisor que se excluiu do escopo não é notificado mesmo quando `review_requested` está configurado para prevalecer sobre as preferências pessoais. + +A restrição também pode ser definida pela API, no endpoint de notificações, o que é a forma mais prática se você estiver configurando muitos revisores de uma vez. + +## Notificações de Atribuição de Trabalho (Pro) + +Quando Achados são atribuídos a você, a notificação **Work Assigned** informa quantos foram atribuídos e traz um link para sua fila My Work. + +Ela é agregada por pessoa, e não por Achado: atribuir cem Achados envia uma única mensagem, não cem. Assim como nas solicitações de revisão, a atribuição fica visível na sua fila independentemente de a notificação chegar até você. + +## Considerações sobre Código Aberto + +### Substituições específicas + +As configurações de notificação do sistema (scope: system) descrevem o envio de notificações a superadmins. As configurações de notificação do usuário (scope: personal) descrevem o envio de notificações ao usuário específico. + +No entanto, há um caso de uso específico em que o usuário decide desativar as notificações (para reduzir o ruído), mas a configuração do sistema é usada para substituir esse comportamento. Por padrão, essas substituições se aplicam apenas a `user_mentioned` e `review_requested`. + +O escopo dessa configuração é personalizável (veja a variável de ambiente `DD_NOTIFICATIONS_SYSTEM_LEVEL_TRUMP`). + +Para mais informações sobre esse comportamento, consulte o [pull request relacionado #9699](https://github.com/DefectDojo/django-DefectDojo/pull/9699/) + +### Webhooks (experimental) + +O DefectDojo também suporta webhooks que seguem os mesmos eventos que as demais notificações (você pode ser notificado nas mesmas situações). Detalhes sobre a configuração são descritos na [página relacionada](/automation/api/notification_webhooks/). diff --git a/docs/content/admin/notifications/configure_personal_notifs.pt-br.md b/docs/content/admin/notifications/configure_personal_notifs.pt-br.md new file mode 100644 index 0000000000..d70b7a06aa --- /dev/null +++ b/docs/content/admin/notifications/configure_personal_notifs.pt-br.md @@ -0,0 +1,35 @@ +--- +title: Definir Notificações Pessoais +description: Configure notificações para uma conta pessoal +aliases: +- /pt-br/en/customize_dojo/notifications/configure_personal_notifs +--- + +## Configurar Notificações Pessoais + +As Notificações Pessoais são enviadas além das Notificações do Sistema e se aplicam a qualquer Produto, Tipo de Produto ou outro tipo de dado ao qual você tenha acesso. As preferências de Notificação Pessoal se aplicam apenas a um único usuário e só podem ser definidas na conta que está configurando-as. + +![image](images/Configure_System_&_Personal_Notifications.png) + +As notificações do sistema são definidas por um Superuser do DefectDojo e não podem ser desativadas por um usuário individual. + +1. Comece pela página de Notificações (⚙️**Configuração \> Notifications** na barra lateral). +2. No menu suspenso **Escopo**, você pode selecionar qual conjunto de notificações deseja editar. +3. Selecione Notificações Pessoais. +4. Marque o método de notificação que deseja usar para cada tipo de notificação. Você pode selecionar mais de um. + +As Notificações Pessoais não podem ser enviadas pelo Microsoft Teams, já que o Teams só permite publicar notificações Globais em um único canal. + +### Receber Notificações Pessoais para um Produto específico + +Além das notificações pessoais padrão, os Usuários do DefectDojo também podem receber notificações sobre atividades em um Produto específico. Isso é útil quando há determinados Produtos que um usuário precisa monitorar mais de perto. + +![image](images/Configure_System_&_Personal_Notifications_3.png) + +Essa configuração pode ser alterada na seção **Notifications** da página do **Produto**: por exemplo, `your-instance.defectdojo.com/product/{id}`. + +A partir daí, você pode definir se deseja receber notificações de **🔔 Alert**, **Mail** ou **Slack** para ações realizadas nesse Produto específico. Essas notificações se aplicam além de quaisquer notificações do sistema que você já esteja recebendo. + +O Microsoft Teams não pode enviar notificações pessoais de nenhum tipo, portanto as notificações do Teams não podem ser escolhidas nesse menu. + +As notificações pessoais por e-mail sempre serão enviadas ao e-mail associado ao seu login do DefectDojo. Para configurar uma conta pessoal do Slack e receber notificações, consulte nosso [Guia](../email_slack_teams/#send-personal-notifications-to-slack). diff --git a/docs/content/admin/notifications/configure_system_notifs.pt-br.md b/docs/content/admin/notifications/configure_system_notifs.pt-br.md new file mode 100644 index 0000000000..811b611317 --- /dev/null +++ b/docs/content/admin/notifications/configure_system_notifs.pt-br.md @@ -0,0 +1,44 @@ +--- +title: Definir Notificações do Sistema +description: Como configurar notificações Pessoais e do Sistema +aliases: +- /pt-br/en/customize_dojo/notifications/configure_system_notifs +--- + +O DefectDojo possui dois tipos diferentes de notificação: **Pessoal** (enviada a uma única conta) e **do Sistema** (enviada a todos os usuários). + +Tanto as Notificações Pessoais de uma conta quanto as Notificações do Sistema globais podem ser configuradas na mesma página: **⚙️Configuração \> Notifications** na barra lateral. + +![image](images/Configure_System_&_Personal_Notifications.png) + +## Configurar notificações do Sistema (Interface Clássica) + +**Você precisará de acesso de Superuser para alterar as notificações do Sistema.** + +1. Comece pela página de Notificações (⚙️ **Configuração \> Notifications** na barra lateral). +2. No menu suspenso Escopo, você pode selecionar qual conjunto de notificações deseja editar. +3. Selecione Notificações do Sistema. +4. Marque o método de entrega de notificação que deseja usar para cada tipo de notificação. Você pode selecionar mais de um. + +![image](images/Configure_System_&_Personal_Notifications_2.png) + +Para definir os destinos das notificações de e-mail do sistema (Email, Slack ou MS Teams), consulte nosso [Guia](../email_slack_teams). + +## Notificações de Modelo + +Os Superusers também têm acesso a um formulário de "Modelo". O Formulário de Modelo permite definir as Notificações Pessoais padrão que ficam ativadas para qualquer novo usuário. + +## Para Onde as Notificações do Sistema São Enviadas + +As notificações do sistema serão enviadas para: +- o único endereço de e-mail especificado em System Settings (se ativado) +- quaisquer usuários do DefectDojo com contas e permissões de RBAC apropriadas +- a conta do Slack ou Teams em nível de Sistema. + +Assim como qualquer notificação no DefectDojo, as Notificações do Sistema só serão enviadas a usuários que tenham acesso aos dados relevantes. Portanto, mesmo que as Notificações de Produto sejam configuradas em nível de Sistema, os usuários só receberão notificações dos Produtos aos quais têm acesso para visualizar. + +Essa restrição não se aplica a Notificações do Sistema enviadas para um canal específico de E-mail ou Slack. + +Consulte nosso guia sobre [Controle de Acesso Baseado em Função](../../user_management/about_perms_and_roles/) para mais informações sobre RBAC e a definição de permissões. + +No entanto, as contas conectadas de E-mail, Slack e Teams do Sistema não podem aplicar RBAC, pois não estão associadas a um usuário específico do DefectDojo. **Todas as notificações selecionadas em nível de sistema serão enviadas para esses destinos, portanto você deve garantir que esses canais só possam ser acessados por pessoas específicas da sua organização.** diff --git a/docs/content/admin/notifications/email_slack_teams.pt-br.md b/docs/content/admin/notifications/email_slack_teams.pt-br.md new file mode 100644 index 0000000000..1c91ce836c --- /dev/null +++ b/docs/content/admin/notifications/email_slack_teams.pt-br.md @@ -0,0 +1,142 @@ +--- +title: Configurar notificações por e-mail, Slack ou Teams +description: Configure o Microsoft Teams para receber notificações +aliases: +- /pt-br/en/customize_dojo/notifications/email_slack_teams +--- + +**Você precisará de acesso de Superusuário para usar a página de Configurações do Sistema, que é necessária para concluir este processo.** + +As notificações podem ser enviadas para o Slack ou o Teams quando determinados eventos são disparados no DefectDojo. + +## Configuração das notificações do Slack + +O DefectDojo pode publicar notificações no Slack de duas formas diferentes: + +* Notificações de todo o sistema, que serão enviadas para um único canal do Slack +* Notificações pessoais, que serão enviadas apenas para usuários específicos. + +Veja um exemplo de uma notificação do Slack enviada pelo DefectDojo: +​ +![image](images/Configure_a_Slack_Integration.png) + +O DefectDojo não possui um aplicativo dedicado do Slack, mas é possível criar um facilmente para o seu workspace seguindo este guia. Um aplicativo do Slack é necessário para que tanto as notificações de sistema quanto as pessoais sejam enviadas corretamente. + +### Criar um aplicativo do Slack + +Para configurar uma conexão do Slack com o DefectDojo, você precisará criar um aplicativo Slack personalizado. + +1. Comece esse processo pela página de Apps do Slack: . +2. Clique em "**Create New App**". +3. Selecione "**From App Manifest**". +4. Selecione seu workspace do Slack no menu. +5. Insira seu App Manifest - você pode copiar e colar este arquivo JSON, que inclui todas as configurações de permissão necessárias para que a integração com o Slack funcione. +​ +``` +{ + "_metadata": { + "major_version": 1, + "minor_version": 1 + }, + "display_information": { + "name": "DefectDojo", + "description": "Notifications from DefectDojo. See https://docs.defectdojo.com/en/notifications/configure-a-slack-integration/ for configuration steps.", + "background_color": "#0000AA" + }, + "features": { + "bot_user": { + "display_name": "DefectDojo Notifications" + } + }, + "oauth_config": { + "scopes": { + "bot": [ + "chat:write", + "chat:write.customize", + "chat:write.public", + "incoming-webhook", + "users:read", + "users:read.email" + ] + }, + "redirect_urls": [ + "https://slack.com/oauth/v2/authorize" + ] + } + } +``` + +Revise o resumo do aplicativo (App Summary) e clique em Create App quando terminar. Conclua a instalação clicando no botão **Install To Workplace**. + +### Configurar sua integração do Slack no DefectDojo + +Agora você precisará configurar a integração do Slack no DefectDojo para concluir a integração. + +**Você precisará de acesso de Superusuário para acessar a página de Configurações do Sistema do DefectDojo.** + +1. Navegue até a página App Information do seu aplicativo Slack, em . Este será o aplicativo criado na primeira seção - **Criar um aplicativo do Slack**. +​ +2. Localize seu OAuth Access Token. Ele pode ser encontrado na barra lateral do Slack - **Features / OAuth & Permissions**. Copie o **Bot User OAuth Token. +​** + +![image](images/Configure_a_Slack_Integration_2.png) + +3. Abra o DefectDojo em uma nova aba e navegue até **Configuration > System Settings** na barra lateral. (Na interface Pro, este formulário está localizado em **Enterprise Settings > System Settings**.) +4. Marque a caixa **Enable Slack notifications**. +5. Cole o **Bot User OAuth Token** obtido no Passo 1 no campo **Slack token**. +6. O campo **Slack Channel** deve corresponder ao canal do seu workspace onde você deseja que as notificações sejam publicadas por um bot do DefectDojo. +7. Se quiser alterar o nome do bot do DefectDojo, você pode inserir um nome personalizado aqui. Caso contrário, será usado **DefectDojo Notifications**, conforme definido no App Manifest do Slack. + +Ao concluir esse processo, o DefectDojo poderá enviar notificações de todo o sistema para esse canal. Selecione as notificações que deseja enviar na [página de Notificações do Sistema](). + +![image](images/Configure_a_Slack_Integration_3.png) + +#### Observações sobre notificações de todo o sistema no Slack: + +O Slack não pode aplicar regras de RBAC ao canal do Slack que você está criando, portanto as notificações serão compartilhadas para todo o sistema DefectDojo. Não há como filtrar as notificações de todo o sistema no Slack por Tipo de Produto, Produto ou Engajamento. + +Se você deseja aplicar filtragem baseada em RBAC às suas mensagens do Slack, habilitar notificações pessoais do Slack é uma opção melhor. + +### Enviar notificações pessoais para o Slack + +Se sua equipe tiver uma integração do Slack habilitada (pelo processo acima), usuários individuais também podem configurar notificações para serem enviadas diretamente ao seu canal pessoal do Slackbot. + +1. Comece navegando até sua página de Perfil pessoal no DefectDojo. Encontre-a clicando no ícone 👤 no canto superior direito. Selecione seu nome de usuário do DefectDojo na lista. (👤 **paul** em nosso exemplo) +​ +![image](images/Configure_a_Slack_Integration_4.png) + +2. Defina seu **Slack Email Address** no menu. Esse campo está aninhado em **Additional Contact Information** no DefectDojo. + +Agora você pode [definir notificações específicas](../about_notifications/) para serem enviadas ao seu canal pessoal do Slackbot. Outros usuários do seu canal do Slack não receberão essas mensagens. + +## Configuração das notificações do Microsoft Teams + +O Microsoft Teams pode receber notificações em um canal específico. Para isso, você precisará **configurar um webhook de entrada** no canal onde deseja receber as mensagens. + +Observe que os antigos [webhooks do Office Connector](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook?tabs=newteams%2Cdotnet) serão descontinuados pela Microsoft; use um novo webhook baseado em Power Automate Workflow, conforme documentado abaixo. + +1. Conclua o processo descrito na **[documentação do Microsoft Teams](https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498)** para criar um novo Incoming Webhook. Mantenha seu link exclusivo logic.azure.com à mão, pois você vai precisar dele nas próximas etapas. Você pode criar o webhook para um canal ou para um chat específico. +​ +![image](images/Configure_a_Microsoft_Teams_Integration.png) +2. No DefectDojo, navegue até **Configuration > System Settings** na barra lateral. (Na interface Pro, este formulário está localizado em **Enterprise Settings > System Settings**.) +3. Marque a caixa **Enable Microsoft Teams notifications**. Isso abrirá uma seção oculta do formulário, chamada "**Msteams url**". +​ +![image](images/Configure_a_Microsoft_Teams_Integration_2.png) +4. Cole a URL logic.azure.com (criada no Passo 1) na caixa **Msteams url**. Seu aplicativo do Teams passará a escutar as notificações recebidas do DefectDojo e a publicá-las no canal selecionado. + +### Observações sobre a integração com o Teams + +* O Slack não pode aplicar regras de RBAC ao canal do Teams que você está criando, portanto as notificações serão compartilhadas para todo o sistema DefectDojo. Não há como filtrar as notificações de todo o sistema no Teams por Tipo de Produto, Produto ou Engajamento. +* O DefectDojo não pode enviar notificações pessoais a usuários no Microsoft Teams. + +## Configuração das notificações por e-mail de todo o sistema + +As notificações do DefectDojo também podem ser enviadas para um endereço de e-mail específico. + +1. Na página de Configurações do Sistema (**Configuration > System Settings** na interface Clássica, ou **Enterprise Settings > System Settings** na interface Pro), navegue até Enable Mail (email) Notifications. + +2. Marque a caixa **Enable mail notifications** e, em seguida, insira o endereço de e-mail para o qual deseja que essas notificações sejam enviadas (mail notifications to). + +![image](images/notifs_email.png) + +Observe que o DefectDojo não pode aplicar filtragem de RBAC a esses e-mails - eles serão enviados para toda a atividade no DefectDojo. Se preferir enviar um conjunto mais personalizado de notificações por e-mail, é melhor configurar [Notificações Pessoais](../configure_personal_notifs) com um usuário ou conta de serviço vinculada ao endereço apropriado. diff --git a/docs/content/admin/sso/PRO__auth0.pt-br.md b/docs/content/admin/sso/PRO__auth0.pt-br.md new file mode 100644 index 0000000000..59123fcd3d --- /dev/null +++ b/docs/content/admin/sso/PRO__auth0.pt-br.md @@ -0,0 +1,34 @@ +--- +title: Auth0 +description: Configure o SSO do Auth0 no DefectDojo Pro +weight: 3 +audience: pro +--- + +O DefectDojo Pro oferece suporte a login via Auth0. O DefectDojo open-source não inclui SSO — consulte +[Usuários Autorizados](/admin/user_management/os__authorized_users/) para controle de acesso no open-source. + +## Pré-requisitos + +Conclua as etapas a seguir no seu painel do Auth0 antes de configurar o DefectDojo: + +1. Crie uma nova aplicação: **Applications > Create Application > Single Page Web Application**. + +2. Configure a aplicação: + - **Name:** `DefectDojo` + - **Allowed Callback URLs:** `https://your-instance.cloud.defectdojo.com/complete/auth0/` + +3. Anote os seguintes valores — você vai precisar deles no DefectDojo: + - **Domain** + - **Client ID** + - **Client Secret** + +## Configuração + +No DefectDojo, acesse **Enterprise Settings > OAuth Settings**, selecione **Auth0** e preencha o formulário: + +- **Auth0 OAuth Key** — insira seu **Client ID** +- **Auth0 OAuth Secret** — insira seu **Client Secret** +- **Auth0 Domain** — insira seu **Domain** + +Marque **Enable Auth0 OAuth** para adicionar um botão **Login With Auth0** à página de login do DefectDojo. diff --git a/docs/content/admin/sso/PRO__authorization_connectors.pt-br.md b/docs/content/admin/sso/PRO__authorization_connectors.pt-br.md new file mode 100644 index 0000000000..998fad2367 --- /dev/null +++ b/docs/content/admin/sso/PRO__authorization_connectors.pt-br.md @@ -0,0 +1,103 @@ +--- +title: Authorization Connectors +description: 'Veja todos os provedores de identidade em uma única página: quais estão + configurados, quais estão ativados e qual protocolo cada um utiliza' +weight: 1 +audience: pro +--- + +Authorization Connectors é uma única página que lista todos os provedores de identidade compatíveis com +o DefectDojo Pro, o estado em que cada um se encontra e qual protocolo utiliza. Antes de essa página existir, +cada provedor tinha seu próprio formulário de configurações, e não havia como responder "o que está +configurado nesta instância?" sem abrir todos eles. + +Authorization Connectors é um recurso do **DefectDojo Pro**. Encontre-o em **Connect > Authorization**. +Somente um **Superuser** pode visualizar ou alterar a configuração dos provedores de identidade. + +![Authorization Connectors](images/authorization_connectors.png) + +## Como a página está organizada + +Os provedores são divididos em duas seções, e cada seção é listada em ordem alfabética com uma contagem ao +lado do título: + +* **Configured Providers** — provedores que já foram configurados nesta instância, estejam ativados ou não + no momento. +* **Available Providers** — provedores que são compatíveis, mas ainda não foram configurados. + +A divisão é feita propositalmente por *configurado*, e não por *ativado*. Um provedor que foi configurado e +depois desativado permanece em Configured Providers, porque é ali que a pessoa que o configurou vai +procurá-lo. O estado dele fica indicado no card. + +Cada card mostra: + +| | | +| --- | --- | +| **Logo and name** | O provedor, nomeado sem o seu protocolo | +| **Protocol tag** | `SAML 2.0`, `OAuth 2.0`, `OpenID Connect`, ou `LDAP` | +| **Status tag** | `Enabled`, `Disabled`, ou `Not configured` | +| **`BETA` tag** | Presente em provedores que ainda estão em beta | +| **Action** | **Manage Configuration** para um provedor configurado, **Configure** para um disponível | + +Ambas as seções têm uma caixa de pesquisa que corresponde ao nome do provedor e ao protocolo, então +pesquisar `oauth` restringe a página aos provedores OAuth. + +![Available providers](images/authorization_available.png) + +## Uma configuração por provedor + +As configurações de provedor de identidade são um único conjunto de valores por provedor por instância — +uma aplicação Okta, um provedor de identidade SAML, um diretório LDAP. Os cards deixam isso claro, e não +existe a opção "adicionar outro": para alterar como um provedor está configurado, você edita a configuração +que já existe. + +É isso que diferencia o Authorization Connectors das [galerias de conectores](/connectors/upstream/about/), +onde uma ferramenta pode ter várias configurações lado a lado. + +## Os três estados, e o que significam + +| Status | Significado | O que fazer em seguida | +| --- | --- | --- | +| **Enabled** | Configurado e aceitando logins | Nada a fazer | +| **Disabled** | Configurado, mas desativado — seu botão não aparecerá na página de login | Reative-o a partir da sua configuração quando quiser tê-lo de volta | +| **Not configured** | Compatível, mas nada foi preenchido ainda | **Configure** para configurá-lo | + +Selecionar um provedor abre diretamente o formulário de configurações daquele provedor. Não há um seletor +intermediário de provedores. + +## Provedores compatíveis + +| Provider | Protocol | Setup guide | +| --- | --- | --- | +| Auth0 | OAuth 2.0 | [Auth0](/admin/sso/pro__auth0/) | +| GitHub Enterprise | OAuth 2.0 | [GitHub Enterprise](/admin/sso/pro__github_enterprise/) | +| GitLab | OAuth 2.0 | [GitLab](/admin/sso/pro__gitlab/) | +| Google | OAuth 2.0 | [Google](/admin/sso/pro__google/) | +| Keycloak | OAuth 2.0 | [KeyCloak](/admin/sso/pro__keycloak/) | +| LDAP | LDAP | [LDAP](/admin/sso/pro__ldap/) | +| Microsoft Entra ID | OAuth 2.0 | [Azure Active Directory](/admin/sso/pro__azure_ad/) | +| Okta | OAuth 2.0 | [Okta](/admin/sso/pro__okta/) | +| OpenID Connect | OpenID Connect | [OIDC](/admin/sso/pro__oidc/) | +| SAML | SAML 2.0 | [SAML](/admin/sso/pro__saml/) | + +A página informa qual é o *estado* da configuração de um provedor. Ela nunca retorna os segredos da +configuração — client secrets, bind passwords e certificados não fazem parte dos dados por trás desta +página, e não podem ser lidos a partir dela. + +## Quando um provedor não consegue se conectar + +Authorization Connectors informa o que está configurado; ele não mostra tentativas de login que falharam. +Essas são registradas em [Diagnostics](/admin/diagnostics/pro__diagnostics/), onde SSO, SAML e LDAP relatam +cada um suas próprias tentativas com o motivo da rejeição — uma assinatura de assertion inválida, um bind +rejeitado, um atributo incompatível. Essas linhas são de nível de instância e, portanto, exclusivas para +superusuários. + +Mantenha pelo menos uma conta de superusuário com nome de usuário e senha como alternativa, e lembre-se de +que `/login?force_login_form` retorna o formulário de login padrão caso um provedor de identidade pare de +funcionar. Veja [Single Sign-On](/admin/sso/) para ambos. + +## Conteúdo relacionado + +* [Single Sign-On](/admin/sso/) — os guias de configuração por provedor e as configurações de login +* [Diagnostics](/admin/diagnostics/pro__diagnostics/) — por que uma tentativa de login falhou +* [Connectors](/connectors/upstream/about/) — a galeria upstream na qual esta página é baseada diff --git a/docs/content/admin/sso/PRO__azure_ad.pt-br.md b/docs/content/admin/sso/PRO__azure_ad.pt-br.md new file mode 100644 index 0000000000..b6cd7fb39b --- /dev/null +++ b/docs/content/admin/sso/PRO__azure_ad.pt-br.md @@ -0,0 +1,78 @@ +--- +title: Azure Active Directory +description: Configure o SSO do Azure AD e o mapeamento de grupos no DefectDojo Pro +weight: 5 +audience: pro +--- + +O DefectDojo Pro oferece suporte a login via Azure Active Directory (Azure AD), incluindo sincronização +automática de User Group. O DefectDojo open-source não inclui SSO — consulte +[Usuários Autorizados](/admin/user_management/os__authorized_users/) para controle de acesso no open-source. + +## Pré-requisitos + +Conclua as etapas a seguir no portal do Azure antes de configurar o DefectDojo: + +1. [Registre uma nova aplicação](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) + no Azure Active Directory. + +2. Anote os seguintes valores da aplicação registrada: + - **Application (client) ID** + - **Directory (tenant) ID** + - Em **Certificates & Secrets**, crie um novo **Client Secret** e anote o valor + - **Application ID URI** + +3. Em **Authentication > Redirect URIs**, adicione uma URI do tipo **Web**: + `https://your-instance.cloud.defectdojo.com/complete/azuread-tenant-oauth2/` + +## Configuração + +No DefectDojo, acesse **Enterprise Settings > OAuth Settings**, selecione **Azure AD** e preencha o +formulário: + +- **Azure AD OAuth Key** — insira seu **Application (client) ID** +- **Azure AD OAuth Secret** — insira seu **Client Secret** +- **Azure AD Resource** — o padrão é `https://graph.microsoft.com/`. Esta é a URI que o DefectDojo usa para + ler informações adicionais (como nomes de grupos) da + [Microsoft Graph Web API](https://docs.azure.cn/en-us/entra/identity-platform/security-best-practices-for-app-registration#application-id-uri). + Altere isso apenas se os nomes dos seus grupos estiverem armazenados em outro recurso de API. +- **Azure AD Tenant ID** — insira seu **Directory (tenant) ID** +- **Azure AD Groups Filter** — opcionalmente, insira uma expressão regular para restringir quais User + Groups são importados (veja [Group Mapping](#group-mapping) abaixo) + +Marque **Enable Azure AD OAuth** e envie o formulário. Um botão **Login With Azure AD** aparecerá na página +de login. + +## Group Mapping + +O group mapping permite que o DefectDojo importe a associação a +[User Group](../../user_management/create_user_group/) do Azure AD. Os User Groups no DefectDojo controlam +o acesso a produtos e tipos de produto por meio do [RBAC](../../user_management/set_user_permissions/). + +Marque **Enable Azure AD OAuth Grouping** para ativar este recurso. No login, o DefectDojo vai corresponder +os grupos do Azure AD do usuário aos grupos já existentes no DefectDojo. Quaisquer grupos não encontrados no +DefectDojo serão criados automaticamente. + +Para importar apenas um subconjunto de grupos, insira uma expressão regular no campo **Azure AD Groups +Filter**. Por exemplo: +- `^team-.*` — corresponde a qualquer grupo que comece com `team-` +- `teamA|teamB|groupC` — corresponde a grupos específicos nomeados + +### Configurando o Azure AD para enviar grupos + +O token do Azure AD deve ser configurado para incluir IDs de grupo. Sem isso, nenhuma informação de grupo +estará presente no token. + +Para configurar isso: +1. Adicione um [Group Claim](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) + na configuração do token do Azure AD. Se não tiver certeza de qual tipo de grupo selecionar, escolha + **All Groups**. +2. **Não** habilite **Emit groups as role claims**. +3. Atualize as permissões de API da aplicação para incluir `GroupMember.Read.All` ou `Group.Read.All`. + `GroupMember.Read.All` é recomendado, pois concede menos permissões. + +### Group Cleaning + +Se **Enable Azure AD OAuth Group Cleaning** estiver ativado, os grupos do DefectDojo criados pela +sincronização com o Azure AD serão removidos automaticamente quando não tiverem mais membros. Quando um +usuário é removido de um grupo no Azure AD, ele também é removido do grupo correspondente no DefectDojo. diff --git a/docs/content/admin/sso/PRO__github_enterprise.pt-br.md b/docs/content/admin/sso/PRO__github_enterprise.pt-br.md new file mode 100644 index 0000000000..f563d2e41e --- /dev/null +++ b/docs/content/admin/sso/PRO__github_enterprise.pt-br.md @@ -0,0 +1,39 @@ +--- +title: GitHub Enterprise +description: Configure o SSO do GitHub Enterprise no DefectDojo Pro +weight: 7 +audience: pro +--- + +O DefectDojo Pro oferece suporte a login via GitHub Enterprise. O DefectDojo open-source não inclui +SSO — consulte [Usuários Autorizados](/admin/user_management/os__authorized_users/) para controle de acesso +no open-source. + +## Pré-requisitos + +Conclua as etapas a seguir no GitHub Enterprise antes de configurar o DefectDojo: + +1. [Crie um novo OAuth App](https://docs.github.com/en/enterprise-server/developers/apps/building-oauth-apps/creating-an-oauth-app) + no seu GitHub Enterprise Server. + +2. Escolha um nome para a aplicação, por exemplo `DefectDojo`. + +3. Defina a **Redirect URI**: + `https://your-instance.cloud.defectdojo.com/complete/github-enterprise/` + +4. Anote o **Client ID** e o **Client Secret** da aplicação. + +## Configuração + +No DefectDojo, acesse **Enterprise Settings > OAuth Settings**, selecione **GitHub Enterprise** e preencha o +formulário: + +- **GitHub Enterprise OAuth Key** — insira seu **Client ID** +- **GitHub Enterprise OAuth Secret** — insira seu **Client Secret** +- **GitHub Enterprise URL** — insira a URL do GitHub da sua organização, por exemplo + `https://github.yourcompany.com/` +- **GitHub Enterprise API URL** — insira a URL da API do GitHub da sua organização, por exemplo + `https://github.yourcompany.com/api/v3/` + +Marque **Enable GitHub Enterprise OAuth** e envie o formulário. Um botão **Login With GitHub** aparecerá na +página de login. diff --git a/docs/content/admin/sso/PRO__gitlab.pt-br.md b/docs/content/admin/sso/PRO__gitlab.pt-br.md new file mode 100644 index 0000000000..b19f9f7277 --- /dev/null +++ b/docs/content/admin/sso/PRO__gitlab.pt-br.md @@ -0,0 +1,34 @@ +--- +title: GitLab +description: Configure o SSO do GitLab no DefectDojo Pro +weight: 9 +audience: pro +--- + +O DefectDojo Pro oferece suporte a login via GitLab. O DefectDojo open-source não inclui SSO — consulte +[Usuários Autorizados](/admin/user_management/os__authorized_users/) para controle de acesso no open-source. + +## Pré-requisitos + +Conclua as etapas a seguir no GitLab antes de configurar o DefectDojo: + +1. Acesse a página Applications do seu perfil do GitLab: + - GitLab.com: `https://gitlab.com/profile/applications` + - Self-hosted: `https://your-gitlab-host/profile/applications` + +2. Crie uma nova aplicação: + - **Name:** `DefectDojo` + - **Redirect URI:** `https://your-dojo-instance.cloud.defectdojo.com/complete/gitlab/` + +3. Anote o **Application ID** e o **Secret** da aplicação. + +## Configuração + +No DefectDojo, acesse **Enterprise Settings > OAuth Settings**, selecione **GitLab** e preencha o formulário: + +- **GitLab OAuth Key** — insira seu **Application ID** +- **GitLab OAuth Secret** — insira seu **Secret** +- **GitLab API URL** — insira a URL base da sua instância do GitLab, por exemplo `https://gitlab.com` + +Marque **Enable GitLab OAuth** e envie o formulário. Um botão **Login With GitLab** aparecerá na página de +login. diff --git a/docs/content/admin/sso/PRO__google.pt-br.md b/docs/content/admin/sso/PRO__google.pt-br.md new file mode 100644 index 0000000000..f06179a060 --- /dev/null +++ b/docs/content/admin/sso/PRO__google.pt-br.md @@ -0,0 +1,47 @@ +--- +title: Google Auth +description: Configure o OAuth do Google no DefectDojo Pro +weight: 11 +audience: pro +--- + +O DefectDojo Pro oferece suporte a login via contas do Google. Novos usuários são criados +automaticamente no primeiro login, caso ainda não existam. Usuários já existentes no DefectDojo são +correspondidos a contas do Google pelo nome de usuário (a parte antes do `@` no e-mail do Google). O +DefectDojo open-source não inclui SSO — consulte +[Usuários Autorizados](/admin/user_management/os__authorized_users/) para controle de acesso no open-source. + +## Pré-requisitos + +Conclua as etapas a seguir no Google Cloud Console antes de configurar o DefectDojo: + +1. Faça login no [Google Developers Console](https://console.developers.google.com). + +2. Acesse **Credentials > Create Credentials > OAuth Client ID**. + + ![image](images/google_1.png) + +3. Selecione **Web Application** e dê a ela um nome descritivo (por exemplo, `DefectDojo`). + +4. Em **Authorized Redirect URIs**, adicione: + `https://your-instance.cloud.defectdojo.com/complete/google-oauth2/` + +5. Anote o **Client ID** e a **Client Secret Key**. + +## Configuração + +No DefectDojo, acesse **Enterprise Settings > OAuth Settings**, selecione **Google** e preencha o +formulário: + +- **Google OAuth Key** — insira seu **Client ID** +- **Google OAuth Secret** — insira sua **Client Secret Key** +- **Whitelisted Domains** — insira o domínio da sua organização (por exemplo, `yourcompany.com`) para + permitir que qualquer usuário com esse domínio faça login +- **Whitelisted E-mail Addresses** — alternativamente, insira endereços de e-mail específicos para permitir + (por exemplo, `user1@yourcompany.com, user2@yourcompany.com`) + +É necessário definir pelo menos um domínio ou endereço de e-mail na lista de permissões, caso contrário +nenhum usuário conseguirá fazer login via Google. + +Marque **Enable Google OAuth** e envie o formulário. Um botão **Login With Google** aparecerá na página de +login. diff --git a/docs/content/admin/sso/PRO__keycloak.pt-br.md b/docs/content/admin/sso/PRO__keycloak.pt-br.md new file mode 100644 index 0000000000..0f3d2ee140 --- /dev/null +++ b/docs/content/admin/sso/PRO__keycloak.pt-br.md @@ -0,0 +1,60 @@ +--- +title: KeyCloak +description: Configure o SSO do KeyCloak no DefectDojo Pro +weight: 13 +audience: pro +--- + +O DefectDojo Pro oferece suporte a login via KeyCloak. O DefectDojo open-source não inclui SSO — +consulte [Usuários Autorizados](/admin/user_management/os__authorized_users/) para controle de acesso no +open-source. + +Este guia pressupõe que você já tenha um Realm do KeyCloak configurado. Caso contrário, consulte a +[documentação do KeyCloak](https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/realms/create.html). + +## Pré-requisitos + +Conclua as etapas a seguir no seu realm do KeyCloak antes de configurar o DefectDojo: + +1. Adicione um novo client com o tipo `openid-connect`. Anote o client ID. + +2. Nas configurações do client: + - Defina **Access Type** como `confidential` + - Em **Valid Redirect URIs**, adicione a URL do seu DefectDojo, por exemplo + `https://yourorganization.cloud.defectdojo.com` ou `https://your-dojo-host/*` + - Em **Web Origins**, adicione a mesma URL (ou `+`) + - Em **Fine Grained OpenID Connect Configuration**: + - Defina **User Info Signed Response Algorithm** como `RS256` + - Defina **Request Object Signature Algorithm** como `RS256` + - Salve as configurações. + +3. Em **Scope**, defina **Full Scope Allowed** como `off`. + +4. Em **Mappers**, adicione um mapper personalizado: + - **Name:** `aud` + - **Mapper Type:** `audience` + - **Included Audience:** selecione o seu client ID + - **Add ID to Token:** `off` + - **Add Access to Token:** `on` + +5. Em **Credentials**, copie o **Secret**. + +6. Em **Realm Settings > Keys**, copie a **Public Key** (chave de assinatura). + +7. Em **Realm Settings > General > Endpoints**, abra a configuração de endpoint do OpenID e copie as URLs + de endpoint **Authorization** e **Token**. + +## Configuração + +No DefectDojo, acesse **Enterprise Settings > OAuth Settings**, selecione **KeyCloak** e preencha o +formulário: + +- **KeyCloak OAuth Key** — insira o nome do seu client (da etapa 1) +- **KeyCloak OAuth Secret** — insira o secret de credenciais do seu client (da etapa 5) +- **KeyCloak Public Key** — insira a Public Key das configurações do seu realm (da etapa 6) +- **KeyCloak Resource** — insira a URL do Authorization Endpoint (da etapa 7) +- **KeyCloak Group Limiter** — insira a URL do Token Endpoint (da etapa 7) +- **KeyCloak OAuth Login Button Text** — escolha o texto do botão de login do DefectDojo + +Marque **Enable KeyCloak OAuth** e envie o formulário. Um botão de login aparecerá na página de login com o +texto que você configurou. diff --git a/docs/content/admin/sso/PRO__ldap.pt-br.md b/docs/content/admin/sso/PRO__ldap.pt-br.md new file mode 100644 index 0000000000..4f1f232bbc --- /dev/null +++ b/docs/content/admin/sso/PRO__ldap.pt-br.md @@ -0,0 +1,107 @@ +--- +title: Autenticação LDAP +description: Configure a autenticação LDAP no DefectDojo Pro +weight: 20 +audience: pro +aliases: +- /pt-br/en/open_source/ldap-authentication +--- + +O DefectDojo Pro oferece suporte a autenticação LDAP diretamente pela interface **Enterprise +Settings** — não são necessárias imagens Docker personalizadas nem arquivos de configuração. + +Diferentemente dos outros provedores nesta página, o LDAP não é um fluxo baseado em redirecionamento. Os +usuários fazem login com o formulário padrão de nome de usuário e senha do DefectDojo, e suas credenciais +são verificadas no seu diretório. Não há um botão de login extra. + +## Configuração + +Abra **Enterprise Settings > LDAP Settings**. + +![image](images/sso_ldap_settings.png) + +1. **Server URI** — o diretório ao qual se conectar, por exemplo `ldaps://ldap.example.com:636`. + Prefira `ldaps://`. Se for necessário usar `ldap://` simples, habilite **Use StartTLS** abaixo para que + a conexão seja atualizada antes do envio das credenciais. +2. **Bind DN** — o distinguished name da conta de serviço usada para pesquisar usuários. + Deixe em branco para um bind anônimo. +3. **Bind Password** — a senha dessa conta de serviço. O valor armazenado nunca é + retornado ao navegador; deixe o campo em branco para manter a senha que você já salvou. +4. **User Search Base** — o DN sob o qual pesquisar as entradas de usuário, por exemplo + `ou=people,dc=example,dc=com`. +5. **User Search Filter** — o filtro usado para localizar o usuário. Ele **deve** conter o + placeholder literal `%(user)s`, que é substituído pelo nome de usuário enviado. Valores + comuns são `(uid=%(user)s)` para OpenLDAP e `(sAMAccountName=%(user)s)` para Active + Directory. +6. **User Attribute Mapping** — veja abaixo. +7. Marque **Enable LDAP** para ativá-lo. + +Use **Validate Config** para verificar as configurações sem salvá-las. Ele reporta a integridade das +configurações, se o servidor está acessível, se o bind é bem-sucedido, se as bases de pesquisa são +resolvidas, e se o mapeamento de atributos parece utilizável. + +## User Attribute Mapping + +Cada linha mapeia um **LDAP Attribute** para o **DefectDojo Field** que ele deve preencher. Use +**Add Attribute Mapping** para adicionar linhas e o ícone de lixeira para remover uma. + +![image](images/sso_ldap_attribute_mapping.png) + +- **LDAP Attribute** é texto livre e deve corresponder ao atributo que o seu diretório realmente + retorna — por exemplo `uid`, `givenName`, `sn`, `mail` no OpenLDAP, ou `sAMAccountName`, + `givenName`, `sn`, `mail` no Active Directory. +- **DefectDojo Field** é escolhido a partir de uma lista: **Username**, **First Name**, **Last Name** e + **Email**. +- Mapear um atributo para **Email** é fortemente recomendado: o DefectDojo usa o endereço de e-mail para + notificações. +- O mesmo atributo pode alimentar mais de um campo. Cada campo do DefectDojo pode ser mapeado a partir de + apenas um atributo. +- Sem nenhum mapeamento, as contas são criadas sem nome ou endereço de e-mail. + +**Always Update User** controla quando o mapeamento é aplicado. Quando habilitado (o padrão), os atributos +mapeados são atualizados a partir do diretório a cada login, de modo que uma alteração de nome ou e-mail no +LDAP chega ao DefectDojo. Quando desabilitado, eles só são aplicados quando a conta é criada pela primeira +vez. + +## Group Mapping + +O DefectDojo pode espelhar os grupos LDAP de um usuário em grupos do DefectDojo no login. Marque +**Enable Group Mapping** para revelar as configurações. + +![image](images/sso_ldap_group_mapping.png) + +- **Group Search Base** — o DN sob o qual pesquisar as entradas de grupo, por exemplo + `ou=groups,dc=example,dc=com`. Obrigatório quando o group mapping está habilitado. +- **Group Type** — como o seu diretório modela a associação. Escolha **groupOfNames** para OpenLDAP e + Active Directory, **groupOfUniqueNames**, ou **posixGroup**. +- **Group Limiter Regex Expression** — apenas os grupos cujo nome corresponde a esta expressão são + espelhados. Use `.*` para permitir todos, ou um prefixo como `^dd-` para espelhar apenas os grupos que + você pretende que o DefectDojo gerencie. + +Os grupos são criados no primeiro uso, caso ainda não existam. Um grupo recém-criado não tem permissões até +que um Superuser as configure — veja [User Groups](../../user_management/create_user_group/). + +## Opções adicionais + +* **Use StartTLS** — atualiza uma conexão `ldap://` simples para TLS antes do bind. Não é necessário quando + a URI já é `ldaps://`. +* **Always Update User** — atualiza os atributos mapeados a partir do diretório a cada login. + +## Solução de problemas + +Execute **Validate Config** primeiro — geralmente ele indica o problema diretamente. Além disso: + +**Todo login falha, mas o diretório está acessível.** Verifique se o **User Search Filter** contém +`%(user)s` e se o atributo nele corresponde ao que os usuários realmente digitam. Um filtro +`(uid=%(user)s)` nunca vai corresponder se os seus usuários fizerem login com um `sAMAccountName` do Active +Directory. + +**Os logins são bem-sucedidos, mas as contas não têm nome ou e-mail.** O **User Attribute Mapping** está +vazio, ou os nomes de atributo LDAP à esquerda não correspondem ao que o seu diretório retorna. + +**Um nome mudou no LDAP, mas não no DefectDojo.** **Always Update User** está desabilitado, portanto o +mapeamento só foi aplicado quando a conta foi criada. + +**As tentativas de login travam ou ficam lentas.** As conexões e pesquisas são limitadas por um timeout, de +modo que um diretório inacessível falha em vez de bloquear indefinidamente. Verifique **Server +Reachability** em **Validate Config** e confirme se a porta está aberta a partir do host do DefectDojo. diff --git a/docs/content/admin/sso/PRO__oidc.pt-br.md b/docs/content/admin/sso/PRO__oidc.pt-br.md new file mode 100644 index 0000000000..4dad98c8bd --- /dev/null +++ b/docs/content/admin/sso/PRO__oidc.pt-br.md @@ -0,0 +1,62 @@ +--- +title: OIDC +description: Configure o SSO OpenID Connect (OIDC) no DefectDojo Pro +weight: 17 +audience: pro +--- + +O DefectDojo Pro oferece suporte a login por meio de um provedor genérico OpenID Connect (OIDC). O DefectDojo open-source não inclui SSO — consulte [Usuários Autorizados](/admin/user_management/os__authorized_users/) para o controle de acesso no open-source. + +## Configuração + +No DefectDojo, acesse **Enterprise Settings > OIDC Settings**. + +![image](images/oidc_pro.png) + +Preencha o formulário: + +1. **Endpoint** — a URL base do seu provedor OIDC. Não inclua `/.well-known/openid-configuration`. +2. **Client ID** — o ID de cliente do seu OIDC. +3. **Client Secret** — o segredo de cliente do seu OIDC. +4. Opcionalmente, configure **Claim Mapping** e **Group Mapping** — veja abaixo. +5. Marque **Enable OIDC**. + +Envie o formulário. Um botão **Log In With OIDC** aparecerá na página de login do DefectDojo. + +Use **Validate Config** a qualquer momento para verificar as configurações sem salvá-las. Isso busca o documento de descoberta, verifica as chaves de assinatura e o emissor, exibe o URI de redirecionamento exato a ser registrado no seu provedor e faz a validação cruzada dos seus mapeamentos de claims e grupos com as claims anunciadas pelo provedor. + +## Mapeamento de Claims + +Cada linha mapeia uma **OIDC Claim** para o **DefectDojo Field** que ela deve preencher. Use **Add Claim Mapping** para adicionar linhas e o ícone de lixeira para remover uma. + +![image](images/sso_oidc_claim_mapping.png) + +Um campo sem linha correspondente mantém sua claim padrão, então esta seção só é necessária quando seu provedor nomeia as coisas de forma diferente. As claims padrão são: + +| DefectDojo Field | Claim padrão | +| --- | --- | +| Username | `preferred_username` | +| Email | `email` | +| First Name | `given_name` | +| Last Name | `family_name` | + +Observações: + +- Uma instância não configurada é aberta com essas quatro linhas já preenchidas, para que você possa ver o que o OIDC está fazendo antes de alterar qualquer coisa. +- A mesma claim pode alimentar mais de um campo. Cada campo do DefectDojo só pode ser mapeado a partir de uma única claim. +- As claims são lidas tanto do ID token quanto da resposta userinfo, então uma claim que seu provedor libera em apenas um dos dois ainda funciona. +- Se uma claim mapeada estiver ausente ou vazia para um determinado usuário, esse campo mantém seu valor padrão em vez de ficar em branco. + +## Mapeamento de Grupos + +O DefectDojo pode espelhar os grupos que seu provedor reporta nos grupos do DefectDojo a cada login. Marque **Enable Group Mapping** para exibir as configurações. + +![image](images/sso_oidc_group_mapping.png) + +- **Group Claim Name** — a claim que contém os grupos do usuário. **A maioria dos provedores não emite uma por padrão** e precisa que um mapper seja configurado explicitamente; no Keycloak, por exemplo, adicione um mapper *Group Membership* ao cliente. Observe que um mapper *User Realm Role* envia **roles** de realm, não grupos. +- **Group Limiter Regex Expression** — apenas os grupos que correspondem a esta expressão são espelhados. Use `.*` para permitir todos. +- **Remove Stale Group Memberships** — quando habilitado, as associações em grupos provisionados pelo OIDC que o provedor não reporta mais são removidas no próximo login. Apenas os grupos criados pelo OIDC são afetados; grupos que você atribuiu manualmente e grupos provisionados por outro provedor, como o SAML, nunca são alterados. + +Os grupos são criados no primeiro uso e nomeados exatamente como o provedor os reporta. Se o seu provedor enviar caminhos completos de grupo (o mapper *Group Membership* do Keycloak faz isso quando **Full group path** está habilitado), o grupo do DefectDojo será nomeado `/Group A` em vez de `Group A`. Desative essa opção se quiser que os nomes correspondam aos grupos vindos de outro provedor; caso contrário, você acabará com dois grupos do DefectDojo para o mesmo grupo lógico. + +Se o mapeamento de grupos parecer não fazer nada, execute **Validate Config**: ele informa se a claim que você indicou é uma das que o provedor anuncia. diff --git a/docs/content/admin/sso/PRO__okta.pt-br.md b/docs/content/admin/sso/PRO__okta.pt-br.md new file mode 100644 index 0000000000..e60c61664f --- /dev/null +++ b/docs/content/admin/sso/PRO__okta.pt-br.md @@ -0,0 +1,46 @@ +--- +title: Okta +description: Configure o SSO do Okta no DefectDojo Pro +weight: 15 +audience: pro +--- + +O DefectDojo Pro oferece suporte a login via Okta. O DefectDojo open-source não inclui SSO — consulte [Usuários Autorizados](/admin/user_management/os__authorized_users/) para o controle de acesso no open-source. + +## Pré-requisitos + +Conclua as etapas a seguir no Okta antes de configurar o DefectDojo: + +1. Faça login ou crie uma conta em [Okta](https://www.okta.com/developer/signup/). + +2. Acesse **Applications** e clique em **Add Application**. + + ![image](images/okta_1.png) + +3. Selecione **Web Applications**. + + ![image](images/okta_2.png) + +4. Em **Login Redirect URLs**, adicione a URL de callback do seu DefectDojo. Marque também a caixa **Implicit**. + + ![image](images/okta_3.png) + +5. Clique em **Done**. + +6. No **Dashboard**, anote a **Org-URL**. + + ![image](images/okta_4.png) + +7. Abra o aplicativo recém-criado e anote o **Client ID** e o **Client Secret**. + + ![image](images/okta_5.png) + +## Configuração + +No DefectDojo, acesse **Enterprise Settings > OAuth Settings**, selecione **Okta** e preencha o formulário: + +- **Okta OAuth Key** — insira seu **Client ID** +- **Okta OAuth Secret** — insira seu **Client Secret** +- **Okta Tenant ID** — insira sua Org-URL no formato `https://your-org-url/oauth2` + +Marque **Enable Okta OAuth** e envie o formulário. Um botão **Login With Okta** aparecerá na página de login. diff --git a/docs/content/admin/sso/PRO__saml.pt-br.md b/docs/content/admin/sso/PRO__saml.pt-br.md new file mode 100644 index 0000000000..fcf5133f8f --- /dev/null +++ b/docs/content/admin/sso/PRO__saml.pt-br.md @@ -0,0 +1,155 @@ +--- +title: Configuração de SAML +description: Configure o SAML no DefectDojo Pro +weight: 1 +audience: pro +--- + +O DefectDojo Pro oferece suporte à autenticação SAML por meio da interface **Enterprise Settings**. O DefectDojo open-source não inclui SSO — consulte [Usuários Autorizados](/admin/user_management/os__authorized_users/) para o controle de acesso no open-source. + +## URL do ACS (Assertion Consumer Service) + +Seu Identity Provider precisa saber para onde enviar (POST) a resposta SAML depois que um usuário se autentica. A URL do ACS do DefectDojo é: + +``` +https://.cloud.defectdojo.com/saml2/acs/ +``` + +Algumas coisas a saber sobre esse endpoint: + +- **O endpoint aceita apenas requisições `POST`.** Abrir a URL do ACS diretamente em um navegador emite um GET e retornará um **HTTP 405 Method Not Allowed**. Esse é o comportamento esperado — não significa que o SAML esteja quebrado ou mal configurado. O endpoint foi projetado para ser invocado pelo seu IdP como parte do fluxo de redirecionamento SAML, não por um navegador acessando a URL diretamente. +- **A URL do ACS está disponível na sua instância do DefectDojo Cloud o tempo todo** — você não precisa habilitar o SAML no DefectDojo antes de apontar seu IdP para ela. Você pode configurar o lado do IdP e o lado do DefectDojo em qualquer ordem. + +## Configuração inicial + +1. Acesse **Enterprise Settings > SAML Settings**. + + ![image](images/sso_betaui_1.png) + +2. Defina um **Entity ID** — um rótulo ou URL que seu SAML Identity Provider usa para identificar o DefectDojo. Este campo é obrigatório. + +3. Opcionalmente, defina o **Login Button Text** — o texto exibido no botão em que os usuários clicam para iniciar o login SAML. + +4. Opcionalmente, defina uma **Logout URL** para redirecionar os usuários depois que eles saírem do DefectDojo. + +5. Escolha um **Name ID Format**: + - **Persistent** — os usuários são identificados de forma consistente pelo SAML entre sessões. + - **Transient** — os usuários recebem um ID SAML diferente a cada login. + - **Entity** — todos os usuários compartilham um único NameID SAML. + - **Encrypted** — o NameID de cada usuário é criptografado. + +6. **Required Attributes** — especifique os atributos que o DefectDojo exige na resposta SAML. + +7. **Attribute Mapping** — mapeie os atributos enviados pelo seu IdP para os campos de usuário do DefectDojo que eles devem preencher. Cada linha associa um **SAML Attribute** a um **DefectDojo Field**; use **Add Attribute Mapping** para adicionar linhas e o ícone de lixeira para remover uma. + + ![image](images/sso_saml_attribute_mapping.png) + + - **SAML Attribute** é um campo de texto livre e deve corresponder exatamente ao nome do atributo que seu IdP realmente emite. Alguns IdPs (por exemplo, Entra ID / Azure AD) enviam URIs de claim totalmente qualificados, como `http://schemas.microsoft.com/identity/claims/emailaddress`, em vez de nomes amigáveis. Se você não tiver certeza do que seu IdP envia, habilite **Enable SAML Debugging** (veja [Solução de problemas](#troubleshooting)) e inspecione a assertion nos logs. + - **DefectDojo Field** é escolhido a partir de uma lista: **Username**, **First Name**, **Last Name** e **Email**. + - No mínimo, mapeie o atributo que corresponde a **Username**. O DefectDojo procura usuários pelo nome de usuário ao associar logins SAML a contas existentes. + - É altamente recomendável mapear um atributo para **Email**: o DefectDojo usa o endereço de e-mail para notificações e para associar um login recebido a uma conta existente pelo e-mail. + - O mesmo atributo pode alimentar mais de um campo — por exemplo, uma claim de e-mail usada tanto para **Email** quanto para **Username**. O inverso não é permitido: cada campo do DefectDojo só pode ser mapeado a partir de um único atributo. + - Uma linha com apenas metade preenchida é rejeitada ao salvar, e a célula problemática é destacada. Linhas que você adiciona mas nunca preenche são descartadas em vez de tratadas como erros. + +8. **Remote SAML Metadata** — a URL onde os metadados do seu SAML Identity Provider estão hospedados. + +9. Marque **Enable SAML** na parte inferior do formulário para ativar o login SAML. Um botão **Login With SAML** aparecerá na página de login do DefectDojo. + + ![image](images/sso_saml_login.png). + +## Opções adicionais + +* **Create Unknown User** — cria automaticamente um novo usuário do DefectDojo caso ele não seja encontrado na resposta SAML. +* **Allow Unknown Attributes** — permite o login de usuários que possuem atributos não listados no Attribute Mapping. +* **Sign Assertions/Responses** — exige que todas as respostas SAML recebidas sejam assinadas. +* **Sign Logout Requests** — assina todas as requisições de logout enviadas pelo DefectDojo. +* **Force Authentication** — exige que os usuários se autentiquem no Identity Provider a cada login, independentemente de sessões existentes. +* **Enable SAML Debugging** — registra a saída detalhada do SAML para solução de problemas. Veja [Solução de problemas → Saída do SAML Debugging](#saml-debugging-output) para saber onde essa saída aparece. + +## Mapeamento de Grupos SAML + +O DefectDojo pode usar a assertion SAML para atribuir usuários automaticamente a [Grupos de Usuários](../../user_management/create_user_group/). Os grupos no DefectDojo atribuem permissões a todos os seus membros, então o Group Mapping permite gerenciar permissões em massa. Essa é a única forma de definir permissões via SAML. + +**O mapeamento de grupos é opcional.** Embora os campos **Group Name Attribute** e **Group Limiter Regex Expression** apareçam com um asterisco de campo obrigatório (`*`) na interface, o formulário SAML será enviado sem eles, e o login SAML funcionará sem o mapeamento de grupos. Não é necessário pré-criar grupos ou roles no seu IdP (por exemplo, application roles do Azure AD) antes de habilitar o SAML — você só precisa configurar esses campos quando realmente quiser que o DefectDojo leia a associação a grupos a partir da assertion. Se você não configurar o mapeamento de grupos, os usuários de SSO recém-criados não terão permissões por padrão; veja [Acesso padrão para usuários provisionados por SSO](#default-access-for-sso-provisioned-users) abaixo. + +O campo **Group Name Attribute** especifica qual atributo na assertion SAML contém as associações de grupo do usuário. Quando um usuário faz login, o DefectDojo lê esse atributo e atribui o usuário a quaisquer grupos correspondentes. Para limitar quais grupos da assertion são considerados, use o campo **Group Limiter Regex Expression** — uma expressão regular aplicada aos nomes de grupo da assertion, usada para filtrar em quais o DefectDojo deve atuar. + +O valor deve corresponder exatamente ao nome do atributo que seu Identity Provider emite na assertion, incluindo qualquer prefixo de namespace. Um nome curto e amigável como `groups` só funcionará se o seu IdP estiver configurado para emitir esse nome de atributo literal — muitos IdPs usam, em vez disso, um URI de claim totalmente qualificado. + +### Group Name Attribute por Identity Provider + +| Identity Provider | Nome de atributo padrão a ser usado | +|---|---| +| **Entra ID / Azure AD** | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | +| **Okta** | `groups` (o nome de atributo configurado no Group Attribute Statement do aplicativo SAML) | +| **Keycloak** | `groups` (ou o que você definir como "SAML Attribute Name" no mapper Group List) | +| **PingFederate / generic** | O valor que você configurou no lado do IdP — verifique a assertion do seu IdP antes de presumir `groups` | + +Se o mapeamento de grupos parecer não fazer nada — os usuários fazem login com sucesso, mas nenhum grupo é criado ou atribuído — veja [Solução de problemas → O mapeamento de grupos SAML não faz nada](#saml-group-mapping-does-nothing--users-log-in-but-no-groups-are-assigned) abaixo. + +Se não existir um grupo com o nome correspondente, o DefectDojo criará um automaticamente e atribuirá a seus membros a role **Reader**. Observe que essa role Reader rege o acesso do membro *ao próprio grupo* — ela não concede nenhum acesso aos Produtos, Tipos de Produto ou outros ativos organizacionais subjacentes. Essas permissões são configuradas separadamente, e um grupo recém-criado automaticamente ainda não tem nenhuma delas até que um Superuser atribua ao grupo uma role nos Produtos ou Tipos de Produto relevantes. + +Para ativar o mapeamento de grupos, marque a caixa de seleção **Enable Group Mapping** na parte inferior do formulário. + +## Acesso padrão para usuários provisionados por SSO + +Quando um novo usuário é criado via SAML (ou qualquer provedor social-auth) e não é adicionado a nenhum grupo via SAML Group Mapping, ele chegará a uma instância do DefectDojo **sem permissões**. Ao fazer login, ele verá zero Tipos de Produto, zero Produtos e zero Engajamentos — o painel aparecerá vazio. + +Para dar a todo novo usuário de SSO provisionado uma base razoável, configure um **Default group** + **Default group role** na página System Settings: + +1. Acesse **⚙️ Configuration → System Settings** (somente Superuser). +2. Defina **Default group** como o [Grupo de Usuários](../../user_management/create_user_group/) que os usuários recém-criados devem integrar. +3. Defina **Default group role** como a role que eles devem ter nesse grupo (por exemplo, **Reader**). +4. Opcionalmente, defina **Default group email pattern** com uma regex (por exemplo, `.*@yourcompany\\.com$`) para que o grupo padrão seja aplicado somente a usuários cujo e-mail corresponda. +5. Salve. + +Tanto **Default group** quanto **Default group role** precisam estar definidos — se algum deles estiver vazio, o grupo padrão não é aplicado. + +Essa configuração se aplica a **todo usuário recém-criado**, incluindo usuários criados via SAML, OAuth e outros provedores social-auth, porque ela é executada no sinal de criação de usuário do Django, em vez de dentro de um backend de autenticação específico. + +> **Usuários existentes não são afetados.** O grupo padrão só é aplicado quando um usuário é criado pela primeira vez. Os usuários existentes do DefectDojo manterão suas associações de grupo atuais mesmo que você altere essa configuração posteriormente. + +## Diferenças entre Cloud e On-Premise + +O DefectDojo Cloud não tem o mesmo nível de personalização de SAML que o DefectDojo On-Prem. As únicas variáveis que podem ser definidas são pela interface. Aqui estão algumas das principais diferenças: + +| Capacidade | Cloud | On-Premise | +|---|---|---| +| **Correspondência de nome de usuário** | Somente NameID | Somente NameID (a variável de ambiente `SAML_USE_NAME_ID_AS_USERNAME` se aplica somente ao Open Source, não ao Pro) | +| **Criptografia de assertion SAML** | Atualmente não suportado | Atualmente não suportado | +| **Logs de login SAML** | Não disponível na interface. Entre em contato com o Suporte para solicitar os logs. | Disponível via logs do container da aplicação (`docker logs dojo`) | +| **Método de configuração** | Somente pela interface Enterprise Settings | Interface Enterprise Settings, Django Admin ou Django Shell | +| **Variáveis de ambiente** | Não podem ser definidas diretamente pelos clientes. Entre em contato com o Suporte para alterações. | Podem ser definidas via `dojo-compose-cli environment add` | + +Se você precisar corresponder usuários por um atributo diferente de NameID (como `uid` ou `email`), configure seu Identity Provider para enviar o valor desejado como o NameID, em vez de ajustar as configurações do DefectDojo. + +## Solução de problemas + +### Saída do SAML Debugging + +Quando **Enable SAML Debugging** (em [Opções adicionais](#additional-options)) está marcado, o DefectDojo grava a saída detalhada do processamento SAML — incluindo os atributos brutos recebidos do IdP — nos logs da aplicação no nível `DEBUG`, sob o logger `saml2`. + +| Onde você está executando | Onde ler a saída de debug | +|---|---| +| **DefectDojo Cloud** | O log de debug do SAML não é exposto na interface. Entre em contato com o Suporte do DefectDojo para solicitar os logs de uma janela de tempo específica. | +| **On-Premise (container único)** | `docker logs dojo` (ou sua agregação de logs Helm/K8s) | +| **On-Premise (Helm/K8s)** | `kubectl logs deployment/defectdojo-django -c uwsgi` (ou o agregador de logs do seu cluster) | + +Desative essa opção depois de concluir a solução de problemas — os logs de debug do SAML são verbosos e podem conter valores de atributos sensíveis do seu IdP. + +### Os usuários recebem um erro "User not found" ou "Permission denied" depois de um login bem-sucedido no IdP + +Se a assertion SAML for processada com sucesso (sem erros de XML ou de assinatura), mas o DefectDojo recusar o login, a causa mais comum é uma **incompatibilidade de nome de usuário** entre o IdP e o DefectDojo. + +O DefectDojo procura o usuário **pelo nome de usuário** ao associar um login SAML a uma conta existente. Se o valor que seu IdP envia como o atributo `username` não corresponder ao nome de usuário de um usuário existente do DefectDojo, a busca falha — mesmo que o restante da assertion seja válido. + +Duas soluções possíveis, escolha a que melhor se encaixa no seu ambiente: + +- **Remova `username` do Attribute Mapping** e deixe o DefectDojo usar o `NameID` do SAML como nome de usuário. Isso é apropriado se os nomes de usuário do DefectDojo já corresponderem ao formato de NameID emitido pelo seu IdP. +- **Alinhe os nomes de usuário.** Certifique-se de que os nomes de usuário no DefectDojo sejam exatamente o que seu IdP envia na claim `username`. Para a maioria das organizações, a convenção mais simples é fazer os nomes de usuário do DefectDojo serem iguais ao endereço de e-mail do usuário, e configurar o IdP para enviar o e-mail como a claim `username`. + +Se você não tiver certeza do que o IdP está realmente enviando, habilite **Enable SAML Debugging** (acima) e inspecione os atributos processados nos logs. + +### O mapeamento de grupos SAML não faz nada — os usuários fazem login, mas nenhum grupo é atribuído + +A causa mais comum é uma incompatibilidade entre o campo **Group Name Attribute** e o nome do atributo que seu IdP está realmente enviando. Veja a tabela [Group Name Attribute por Identity Provider](#group-name-attribute-by-identity-provider) acima, e habilite **Enable SAML Debugging** para ver os atributos brutos retornados pelo IdP. diff --git a/docs/content/admin/sso/PRO__scim.pt-br.md b/docs/content/admin/sso/PRO__scim.pt-br.md new file mode 100644 index 0000000000..d76309eb0b --- /dev/null +++ b/docs/content/admin/sso/PRO__scim.pt-br.md @@ -0,0 +1,148 @@ +--- +title: Provisionamento SCIM +description: Provisione e desprovisione usuários do DefectDojo Pro a partir do seu + identity provider +weight: 19 +audience: pro +--- + +O DefectDojo Pro oferece suporte ao SCIM 2.0, que permite que seu identity provider crie, atualize e desative usuários do DefectDojo diretamente. Sem ele, o DefectDojo só toma conhecimento de um usuário quando esse usuário faz login, então remover alguém do seu identity provider impede logins futuros, mas deixa a conta do DefectDojo ativa. + +O SCIM é independente do single sign-on e o complementa. O SSO decide quem pode fazer login; o SCIM mantém a própria lista de contas sincronizada com o seu diretório. A maioria dos clientes configura os dois: SAML ou OIDC para autenticação, SCIM para provisionamento. + +A configuração do SCIM só pode ser feita por um **Superuser**. + +## O que o SCIM faz no DefectDojo + +Ao conectar um identity provider via SCIM, ele pode: + +* criar usuários do DefectDojo quando alguém é atribuído ao aplicativo +* atualizar nomes e endereços de e-mail quando eles mudam no diretório +* desativar usuários quando eles são desatribuídos ou saem da organização +* criar grupos e adicionar e remover seus membros + +Desativar um usuário via SCIM faz duas coisas ao mesmo tempo. A conta é marcada como inativa, para que o usuário não possa mais fazer login, e os tokens de API do DefectDojo desse usuário são excluídos. O offboarding, portanto, fecha as duas portas em uma única etapa, que é o principal motivo para usar o SCIM em vez de depender apenas do seu identity provider. + +O registro do usuário em si é mantido. Achados, notas e o histórico fazem referência às pessoas que os criaram, então o DefectDojo desativa a conta em vez de excluí-la. Se a mesma pessoa retornar, reativá-la pelo seu identity provider restaura o acesso sem afetar esse histórico. + +## Configuração + +1. Acesse **Connect > Authorization** e selecione **SCIM Provisioning**. O SCIM aparece listado junto com seus provedores de login porque se conecta ao mesmo identity provider, e é marcado como **Provisioning** para diferenciá-lo dos provedores que colocam um botão na página de login. + +2. Marque **Enable SCIM Provisioning** e envie. Enquanto isso estiver desativado, os endpoints do SCIM se comportam como se não existissem, de modo que um teste de conexão do seu identity provider reporta o endereço como não encontrado. + +3. Copie a **Tenant URL** exibida na página. Ela se parece com isto: + + ``` + https://.cloud.defectdojo.com/scim/v2 + ``` + +4. No painel **SCIM Tokens**, dê ao token um nome que indique onde ele será usado, por exemplo "Okta production", e depois selecione **Generate Token**. + +5. Copie o token da caixa de diálogo e cole-o no seu identity provider. O DefectDojo armazena apenas um hash do token, então ele não pode ser exibido novamente. Se você o perder, gere outro e revogue o antigo. + +Você pode manter mais de um token ativo ao mesmo tempo. Para fazer o rodízio, gere um novo token, atualize seu identity provider e depois revogue o antigo. Não há nenhuma janela em que o provisionamento pare de funcionar. + +O painel de tokens registra quando cada token foi usado pela última vez, o que é uma forma rápida de confirmar que seu identity provider está realmente alcançando o DefectDojo. + +## Okta + +1. No Okta Admin Console, acesse **Applications > Browse App Catalog** e adicione **SCIM 2.0 Test App (Header Auth)**. Se você já tiver um aplicativo SAML para o DefectDojo, pode habilitar o provisionamento nesse aplicativo em vez disso. + +2. Abra a aba **Provisioning** e selecione **Configure API Integration**. + +3. Defina **SCIM 2.0 Base Url** com a Tenant URL que você copiou acima. + +4. Defina **API Token** como `Bearer `, incluindo a palavra `Bearer` e um único espaço. Esse tipo de aplicativo envia o valor literalmente como o cabeçalho Authorization. + +5. Selecione **Test API Credentials** e depois salve. + +6. Em **Provisioning > To App**, habilite **Create Users**, **Update User Attributes** e **Deactivate Users**. + +7. Atribua pessoas ou grupos ao aplicativo. O Okta primeiro procura cada pessoa no DefectDojo pelo nome de usuário e só cria uma conta quando não encontra nenhuma, então qualquer pessoa que já tenha uma conta do DefectDojo é vinculada em vez de duplicada. + +Para enviar grupos também, abra a aba **Push Groups** e adicione os grupos que você quer que o DefectDojo espelhe. Veja [Grupos](#groups) abaixo para saber o que o DefectDojo faz com eles. + +## Microsoft Entra ID + +1. No Entra admin center, acesse **Enterprise applications > New application > Create your own application** e escolha a opção non-gallery. Se você já tiver um aplicativo para o DefectDojo, use-o. + +2. Abra **Provisioning** e defina **Provisioning Mode** como **Automatic**. + +3. Defina **Tenant URL** com a Tenant URL que você copiou acima. + +4. Defina **Secret Token** com o seu token SCIM. O Entra o envia como um bearer token, então não adicione a palavra `Bearer` aqui. + +5. Selecione **Test Connection** e depois salve. + +6. Atribua usuários e grupos em **Users and groups** e inicie o provisionamento. + +O Entra provisiona em um ciclo de aproximadamente 40 minutos. Enquanto você estiver configurando, **Provision on demand** aplica um único usuário ou grupo imediatamente, o que torna muito mais rápido confirmar que a configuração funciona. + +## O que o DefectDojo armazena + +O DefectDojo mapeia um pequeno conjunto de atributos SCIM e ignora o restante. + +| Atributo SCIM | Campo do DefectDojo | +|---|---| +| `userName` | Username | +| `name.givenName` | First name | +| `name.familyName` | Last name | +| `emails` | Email address | +| `active` | Se a conta está habilitada | +| `externalId` | Mantido para que seu identity provider possa corresponder o registro posteriormente | + +Atributos que o DefectDojo não modela, incluindo números de telefone, cargos e a extensão enterprise do SCIM, são aceitos e ignorados em vez de rejeitados. Mapear atributos extras no seu identity provider é inofensivo. + +Dois atributos merecem atenção especial: + +**Username.** O DefectDojo permite letras, dígitos e os caracteres `@ . + - _` em um nome de usuário. Se o seu identity provider enviar um nome de usuário contendo qualquer outra coisa, o DefectDojo rejeita esse usuário com um erro indicando o problema, em vez de silenciosamente armazenar um nome de usuário diferente. Armazenar um nome de usuário alterado impediria que seu provedor conseguisse localizar a conta posteriormente. + +**Email address.** O SCIM não exige um, e o DefectDojo criará o usuário sem ele. Tenha em mente que as notificações do DefectDojo, incluindo relatórios agendados e alertas, não têm para onde ir para um usuário sem endereço de e-mail. Mapeie o atributo `emails`, a menos que você tenha um motivo para não fazê-lo. + +O SCIM nunca define senhas e nunca concede status de superuser ou staff. Se o seu identity provider estiver configurado para enviar senhas, o DefectDojo as ignora. Usuários provisionados dessa forma fazem login pelo SSO. + +## Grupos + +O SCIM gerencia apenas os grupos que ele criou. Grupos criados por você na interface do DefectDojo, ou que chegaram por meio do mapeamento de grupos do SAML ou do Azure AD, são invisíveis para o SCIM e não podem ser renomeados, esvaziados ou excluídos pelo seu identity provider. + +Isso importa porque o push de grupo é, por natureza, uma substituição completa. Se um identity provider pudesse adotar um grupo existente, sua próxima sincronização substituiria a associação cuidadosamente escolhida desse grupo pelo que quer que o diretório contenha. Por isso, enviar um grupo cujo nome já está em uso falha com uma mensagem explicando o conflito. Para transferir um grupo existente para o seu identity provider, renomeie um dos dois, ou exclua o grupo do DefectDojo e deixe o provedor recriá-lo. + +Dentro de um grupo gerenciado pelo SCIM, a associação pertence ao seu identity provider e as roles pertencem ao DefectDojo: + +* Um membro recém-adicionado recebe a role **Reader**. +* Se você promover alguém a uma role superior no DefectDojo, sincronizações posteriores não alteram essa role. +* Qualquer pessoa adicionada manualmente a um grupo gerenciado pelo SCIM é removida na próxima sincronização, porque o identity provider é a fonte da verdade sobre quem pertence ao grupo. + +Excluir um grupo via SCIM remove o grupo e suas associações. Isso nunca exclui as pessoas que faziam parte dele. + +## Protegendo o acesso de administrador + +Por padrão, o SCIM não desativa uma conta de superuser. A falha comum em qualquer configuração de provisionamento é um identity provider com escopo mais amplo do que o pretendido, e os superusers são a forma de você voltar a acessar o DefectDojo quando algo dá errado. + +Se você quiser que seu identity provider também gerencie superusers, habilite **Allow SCIM to deactivate superusers** na página de configurações do SCIM. Mesmo assim, o DefectDojo se recusa a desativar o último superuser ativo restante, de modo que o provisionamento não pode deixar a instância sem um administrador. + +## Limitações + +* Um identity provider por instância do DefectDojo. +* A filtragem é suportada em `userName`, `displayName`, `externalId` e `id`, usando uma única comparação de igualdade. Isso cobre o que o Okta e o Entra enviam ao corresponder registros. Filtros mais complexos são rejeitados com um erro informando isso. +* Operações em massa, ordenação e o endpoint `/Me` não estão implementados. +* As associações a grupos são gerenciadas por meio do endpoint Groups. Enviar a associação a grupo em um registro de usuário não tem efeito, o que corresponde ao comportamento dos dois provedores. + +## Solução de problemas + +**O teste de conexão reporta "not found".** O SCIM está desativado, ou a instância não tem licença para ele. Verifique se **Enable SCIM Provisioning** está ativado e se a sua assinatura inclui SSO. Todo o endereço do SCIM se comporta como se não existisse até que ambas as condições sejam verdadeiras. + +**O teste de conexão reporta uma falha de autenticação.** O token está errado ou foi revogado. Gere um novo e atualize seu identity provider. No Okta, verifique se o valor começa com `Bearer ` e um espaço; no Entra, verifique se não começa. + +**Um usuário falha ao ser provisionado com um erro sobre o nome de usuário.** O nome de usuário contém caracteres que o DefectDojo não permite. Altere o atributo que seu identity provider mapeia para `userName`, geralmente para o endereço de e-mail do usuário ou o user principal name. + +**Um grupo falha ao ser enviado, informando que já existe um grupo com esse nome.** Um grupo do DefectDojo com esse nome foi criado em outro lugar. Veja [Grupos](#groups) acima. + +**Um membro de grupo falha ao ser provisionado.** A pessoa ainda não foi provisionada no DefectDojo. Atribua-a ao aplicativo, e a associação terá sucesso no próximo ciclo. + +**Comece pelo Diagnostics.** As requisições SCIM recusadas são registradas em **Connect > Diagnostics**, com o endpoint, o status e a mensagem que o DefectDojo enviou de volta. Isso geralmente é mais rápido do que ler o log do seu identity provider, e é o único lugar que mostra os dois lados da troca. O provisionamento bem-sucedido não é registrado ali; as alterações em usuários e grupos aparecem no histórico de auditoria. + +**Tudo reporta sucesso, mas nada aparece no DefectDojo.** Verifique se a Tenant URL termina em `/scim/v2` sem barra final, e se o seu identity provider está realmente alcançando sua instância. A coluna **Last Used** no painel SCIM Tokens mostra se alguma requisição chegou. + +**Usuários do DefectDojo Pro:** se a sua instância restringe o acesso por endereço IP, adicione os endereços do seu identity provider à allowlist do firewall antes de configurar o SCIM. Veja [Firewall Rules](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings). diff --git a/docs/content/admin/sso/_index.pt-br.md b/docs/content/admin/sso/_index.pt-br.md new file mode 100644 index 0000000000..db2b0dbd02 --- /dev/null +++ b/docs/content/admin/sso/_index.pt-br.md @@ -0,0 +1,76 @@ +--- +title: Single Sign-On +description: O DefectDojo Pro oferece suporte a SAML e a uma variedade de provedores + OAuth para 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: +- /pt-br/admin/user_management/configure_sso/ +- /pt-br/admin/sso/os__saml/ +- /pt-br/admin/sso/os__auth0/ +- /pt-br/admin/sso/os__azure_ad/ +- /pt-br/admin/sso/os__github_enterprise/ +- /pt-br/admin/sso/os__gitlab/ +- /pt-br/admin/sso/os__google/ +- /pt-br/admin/sso/os__keycloak/ +- /pt-br/admin/sso/os__oidc/ +- /pt-br/admin/sso/os__okta/ +- /pt-br/admin/sso/os__remote_user/ +--- + +Single Sign-On é um recurso do **DefectDojo Pro**. A partir do DefectDojo 3.0, a superfície de SSO — SAML, OIDC e os provedores OAuth integrados — está disponível somente no DefectDojo Pro. O DefectDojo open-source usa login local por nome de usuário/senha e o fluxo de redefinição de senha. + +Se você estiver usando o DefectDojo open-source e quiser SSO, será necessário migrar para o [DefectDojo Pro](https://defectdojo.com); a migração está descrita nas [notas de atualização do 3.0](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only). As contas de usuário e associações de grupo existentes são preservadas na atualização. Para controle de acesso no DefectDojo open-source, veja a página [Usuários Autorizados](/admin/user_management/os__authorized_users/). + +## Vendo o que está configurado + +**[Authorization Connectors](/admin/sso/pro__authorization_connectors/)** lista todos os provedores suportados em uma única página — quais estão configurados, quais estão habilitados e qual protocolo cada um utiliza — e leva você diretamente ao formulário de configurações de qualquer um deles. Comece por ali se quiser saber o estado desta instância, em vez de configurar um provedor específico. + +## Provedores de SSO suportados (DefectDojo Pro) + +O DefectDojo Pro oferece suporte a SAML e aos seguintes provedores OAuth. Cada guia percorre a configuração no lado do provedor e a configuração correspondente na interface **Enterprise Settings** do Pro. + +* **[Auth0](/admin/sso/pro__auth0/)** +* **[Azure Active Directory](/admin/sso/pro__azure_ad/)** +* **[GitHub Enterprise](/admin/sso/pro__github_enterprise/)** +* **[GitLab](/admin/sso/pro__gitlab/)** +* **[Google](/admin/sso/pro__google/)** +* **[KeyCloak](/admin/sso/pro__keycloak/)** +* **[Okta](/admin/sso/pro__okta/)** +* **[OIDC (OpenID Connect)](/admin/sso/pro__oidc/)** +* **[SAML](/admin/sso/pro__saml/)** +* **[LDAP](/admin/sso/pro__ldap/)** + +## Provisionando usuários a partir do seu diretório (DefectDojo Pro) + +Os provedores acima decidem quem pode fazer login. **[SCIM Provisioning](/admin/sso/pro__scim/)** mantém a própria lista de contas sincronizada com o seu diretório, de modo que os usuários sejam criados quando entram, atualizados quando seus dados mudam e desativados (junto com seus tokens de API) quando saem. + +A configuração de SSO no DefectDojo Pro só pode ser feita por um **Superuser**. + +**Usuários do DefectDojo Pro:** adicione os endereços IP dos seus serviços SAML ou SSO à whitelist do Firewall antes de configurar o SSO. Veja [Firewall Rules](/get_started/pro/cloud/using-cloud-manager/#changing-your-firewall-settings) para mais informações. + +## Desabilitando o login por Nome de usuário / Senha + +Depois que o SSO estiver configurado no DefectDojo Pro, você pode querer desabilitar o formulário tradicional de login por nome de usuário/senha. Desmarque **Allow Login via Username and Password** em **Enterprise Settings > Login Settings**. + +![image](images/pro_login_settings.png) + +### Fallback de login + +Se a sua integração de SSO parar de funcionar, você sempre pode voltar ao formulário de login padrão adicionando o seguinte à URL do seu DefectDojo: + +`/login?force_login_form` + +Recomendamos manter pelo menos uma conta de administrador com nome de usuário e senha configurados como fallback. diff --git a/docs/content/admin/user_management/OS__audit_logging.pt-br.md b/docs/content/admin/user_management/OS__audit_logging.pt-br.md new file mode 100644 index 0000000000..5b4c37e46f --- /dev/null +++ b/docs/content/admin/user_management/OS__audit_logging.pt-br.md @@ -0,0 +1,17 @@ +--- +title: Logs de Auditoria +description: Acesse os logs de auditoria dos objetos do DefectDojo +weight: 1 +audience: opensource +aliases: +- /pt-br/en/customize_dojo/user_management/audit_logging +--- + +Os logs de auditoria do DefectDojo podem ser acessados de algumas formas diferentes. + +## Logs individuais de objeto +* Cada objeto do DefectDojo tem um Histórico do Objeto associado, que pode ser acessado pela interface. Esses históricos são registrados para Ativos, Engajamentos, Testes, Achados e Endpoints, além das Aceitações de risco. + +Na interface Clássica (Open Source), os Logs de Objeto ficam no menu ☰ hambúrguer na visualização de um objeto. + +![image](images/auditlogs_ss6.png) diff --git a/docs/content/admin/user_management/OS__authorized_users.pt-br.md b/docs/content/admin/user_management/OS__authorized_users.pt-br.md new file mode 100644 index 0000000000..cbb7d77795 --- /dev/null +++ b/docs/content/admin/user_management/OS__authorized_users.pt-br.md @@ -0,0 +1,61 @@ +--- +title: Permissões do Open Source +description: Como o acesso a Produtos e Tipos de Produto é concedido no DefectDojo + open source +weight: 1 +audience: opensource +--- + +O DefectDojo open source controla o acesso a Produtos e Tipos de Produto com o modelo de **Usuários Autorizados**. Cada Produto e Tipo de Produto tem um painel de Usuários Autorizados listando as pessoas que podem ver aquele registro e os dados aninhados sob ele. + +Se você está usando o DefectDojo Pro, este artigo não se aplica à sua instalação — o Pro usa um sistema baseado em papéis mais completo, abordado em [Permissões no DefectDojo](../about_perms_and_roles/). + +## Como o acesso é concedido + +Existem duas listas, e um usuário só precisa aparecer em uma delas para obter acesso: + +- **A lista de Usuários Autorizados de um Produto** concede acesso a esse Produto específico, além de tudo o que está aninhado sob ele (seus Engajamentos, Testes, Achados e Endpoints). +- **A lista de Usuários Autorizados de um Tipo de Produto** concede acesso ao próprio Tipo de Produto **e se propaga para todos os Produtos sob ele**. Um usuário autorizado em um Tipo de Produto não precisa também ser adicionado a cada Produto filho — ele já está coberto. + +Não existem papéis, grupos ou papéis globais. Um usuário está na lista (ou é superusuário/membro da equipe — veja abaixo), ou não consegue ver o Produto. + +## Superusuários e membros da equipe ignoram as listas + +Usuários marcados como **superusuário** ou **membro da equipe (staff)** no DefectDojo podem ver e atuar em todos os Produtos e Tipos de Produto, independentemente das listas de Usuários Autorizados. As listas existem para conceder acesso a usuários que não são da equipe; elas não restringem membros da equipe ou superusuários. + +A primeira conta criada em uma instalação nova do DefectDojo é automaticamente um superusuário. + +## Quem pode editar as listas + +Somente usuários **superusuário** ou **membro da equipe** veem os controles para adicionar ou remover pessoas de um painel de Usuários Autorizados. Todos os demais que têm acesso a um Produto ou Tipo de Produto veem o painel como uma lista somente leitura — útil para descobrir quem mais está na equipe, mas não para alterar a associação. + +## Onde o painel fica + +O painel de Usuários Autorizados aparece em duas páginas na interface clássica: + +- A **página de detalhes do Produto** tem um painel de Usuários Autorizados para aquele Produto. Ela oferece duas ações para usuários da equipe: + - **Adicionar um usuário à lista de Usuários Autorizados do Produto** + - **Remover um usuário da lista de Usuários Autorizados do Produto** +- A **página de detalhes do Tipo de Produto** tem um painel de Usuários Autorizados para aquele Tipo de Produto, com as duas ações correspondentes: + - **Adicionar um usuário à lista de Usuários Autorizados do Tipo de Produto** + - **Remover um usuário da lista de Usuários Autorizados do Tipo de Produto** + +Quando você remove um usuário da lista de um Tipo de Produto, a propagação também é removida — ele perde o acesso a todos os Produtos filhos, a menos que ainda esteja na lista de um Produto específico, ou seja membro da equipe/superusuário. + +## Escolhendo entre acesso por Produto ou por Tipo de Produto + +Algumas regras práticas: + +- Se uma pessoa deve ver todos os Produtos de uma categoria (por exemplo, todos os Produtos de uma determinada equipe), coloque-a na lista do **Tipo de Produto** e deixe a propagação cuidar do resto. +- Se uma pessoa deve ver apenas um Produto específico, coloque-a na lista daquele **Produto**. +- Se você perceber que está adicionando a mesma pessoa a vários Produtos individuais dentro de um mesmo Tipo de Produto, isso é um sinal de que deveria adicioná-la ao Tipo de Produto em vez disso. + +## Vindo de uma versão anterior do DefectDojo + +O DefectDojo open source voltou ao modelo de Usuários Autorizados na versão 3.0. Se você está atualizando a partir de uma versão que tinha o sistema de Membros / Grupos / Papéis Globais, seu acesso existente é migrado automaticamente para Usuários Autorizados pela própria atualização — não é necessário nenhum mapeamento manual. + +A atualização vem com um comando de gerenciamento somente leitura, `preview_legacy_authorization_migration`, que resume o que uma atualização mudaria em uma cópia do seu banco de dados. O fluxo de trabalho recomendado é instalar a versão 3.0 em um ambiente de staging com um snapshot da produção, executar o comando, revisar o resumo e só então atualizar a produção. + +Se você está indo na direção contrária — do open source para o DefectDojo Pro — o Pro vem com um comando `reconcile_authorized_users_to_rbac` que traz o acesso de Usuários Autorizados para o RBAC do Pro. Ele suporta `--dry-run` e é idempotente. + +Para mais detalhes sobre os dois caminhos, veja as [notas de atualização da versão 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.pt-br.md b/docs/content/admin/user_management/OS__creating_new_users.pt-br.md new file mode 100644 index 0000000000..8606e2791c --- /dev/null +++ b/docs/content/admin/user_management/OS__creating_new_users.pt-br.md @@ -0,0 +1,43 @@ +--- +title: Criando um novo usuário +description: Como integrar um novo usuário à sua instância do DefectDojo +audience: opensource +weight: 1 +--- + +Esta página descreve o fluxo de integração recomendado para adicionar novos usuários a uma instância do DefectDojo. Usuários do DefectDojo podem ser usados tanto como contas padrão, operadas por humanos, quanto como contas de serviço. + +O administrador que cria a conta é responsável por entregar as credenciais iniciais (usuário e senha) ao novo usuário. + +## Fluxo de trabalho recomendado + +1. **Crie a conta de usuário** no DefectDojo (somente Superusuário): + * Navegue até **👤 Users → Users** para abrir a tabela All Users. + * Clique no ícone 🛠️ (chave inglesa e chave de fenda cruzadas). + * Digite o nome e o endereço de e-mail do novo usuário. + * Defina uma senha temporária. + * Envie o formulário. + +2. **Atribua as permissões** conforme apropriado — associação a Produto/Tipo de Produto, Permissões de Configuração, Papel Global ou status de Superusuário. Veja [Definir as permissões de um usuário](../set_user_permissions/) para mais detalhes. Um novo usuário sem nenhuma atribuição não conseguirá ver nenhum Produto ou Achado. + +3. **Envie as credenciais ao novo usuário por um canal separado** (por e-mail, pela ferramenta de chat da sua equipe, ou da forma como você costuma compartilhar segredos). Inclua: + * A URL da instância do DefectDojo. + * O nome de usuário (normalmente o e-mail dele). + * A senha temporária que você acabou de definir. + * Uma observação de que ele deve trocar a senha e ativar o MFA (se a sua instância usar MFA) no primeiro login. + +4. **O novo usuário faz login e troca a credencial.** Ele pode: + * Fazer login com a senha temporária e depois trocá-la pelo menu de perfil, ou + * Usar o link **Esqueci minha senha** na página de login para definir uma senha diretamente, sem usar a temporária. A senha temporária ainda é necessária para que o registro inicial da conta exista, mas o usuário não precisa memorizá-la se usar o fluxo de redefinição de senha. + +5. **O novo usuário configura o MFA** pelo menu de perfil. Recomendamos fortemente exigir MFA para todos os usuários em instâncias que não estejam atrás de um SSO. + +## Usuários de SSO + +Se a sua instância estiver configurada com [SSO](../configure_sso/), o fluxo é diferente — os usuários normalmente são criados no primeiro login a partir do Provedor de Identidade, e você só precisa conceder a eles associação a grupos ou papéis depois. + +Se você migrou para o DefectDojo open source (onde o SSO é exclusivo do Pro) e os usuários de SSO existentes não conseguem mais fazer login, veja [Reativando o login para usuários de SSO](../os__sso_user_local_login_fallback/). + +## Recuperando-se de um token de MFA perdido + +Se um usuário perder o acesso ao dispositivo de MFA, veja a [seção de recuperação de MFA](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes) do guia de solução de problemas de conectividade. Atualmente não há como remover o MFA de uma conta sem um código de MFA — a solução alternativa é criar uma nova conta para o usuário e conceder novamente as mesmas permissões. diff --git a/docs/content/admin/user_management/OS__sso_user_local_login_fallback.pt-br.md b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.pt-br.md new file mode 100644 index 0000000000..3f11af5715 --- /dev/null +++ b/docs/content/admin/user_management/OS__sso_user_local_login_fallback.pt-br.md @@ -0,0 +1,58 @@ +--- +title: Reativando o login para usuários de SSO (Open Source) +description: Defina uma senha local para usuários provisionados via SSO após migrar + para o Open Source, onde o SSO é um recurso exclusivo do Pro +audience: opensource +weight: 2 +--- + +## Quando isso se aplica + +O SSO (SAML, OIDC, OAuth) é um recurso do [DefectDojo Pro](https://defectdojo.com). Se você atualizar para o DefectDojo open source 3.x (ou de alguma outra forma deixar de usar o Pro), as opções de login via SSO são removidas, e os usuários que foram provisionados por SSO não conseguem mais fazer login. As contas deles nunca receberam uma senha local, e a interface e a API não permitem definir uma para eles: o DefectDojo os detecta como contas de SSO e bloqueia a alteração. + +Você **não** precisa excluir e recriar esses usuários (o que faria você perder o histórico, as permissões e a propriedade dos objetos deles). Em vez disso, defina uma senha local para cada conta no backend e force uma redefinição de senha no próximo login. + +Veja a [seção de SSO](/admin/sso/) e as [notas de atualização da versão 3.0](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only) para entender o contexto de o SSO ser exclusivo do Pro. + +## Por que isso acontece + +O DefectDojo open source autentica apenas contra o banco de dados local de usuários do Django. Ele decide se uma conta é uma "usuária de SSO" unicamente pelo fato de a conta ter ou não uma senha utilizável. As contas provisionadas via SSO foram criadas com uma senha *inutilizável*, então: + +* o login local falha (não há senha para verificar), e +* o controle **Forçar redefinição de senha** na interface e na API fica bloqueado, com uma mensagem informando que o usuário está autorizado via SSO. + +Definir uma senha real resolve as duas condições de uma vez: a conta passa a conseguir fazer login localmente, e a flag de redefinição forçada passa a poder ser definida. + +## A solução alternativa + +Execute estes passos a partir do shell do Django dentro do container `uwsgi`: + +```bash +docker compose exec -it uwsgi ./manage.py shell +``` + +### Exemplo para um único usuário + +```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() +``` + +## O que o usuário faz em seguida + +Entregue a senha temporária a cada usuário por um canal separado (e-mail, o chat da sua equipe, ou da forma como você costuma compartilhar segredos). No próximo login, o DefectDojo os redireciona para a página **Alterar senha** e não permite que eles vão a nenhum outro lugar até definirem sua própria senha. A flag de redefinição forçada é limpa automaticamente assim que isso acontece. + +Se a sua instância tiver o fluxo "Esqueci minha senha" habilitado (`DD_FORGOT_PASSWORD`, ativado por padrão) e o e-mail configurado, os usuários podem, em vez disso, usar o link **Esqueci minha senha** na página de login depois que a conta tiver uma senha utilizável, e definir uma senha sem precisar da temporária. + +## Observações + +* **Kubernetes:** execute o shell no pod do Django, por exemplo `kubectl exec -it deploy/defectdojo-django -c uwsgi -- ./manage.py shell` (ajuste os nomes do deployment e do container para a sua versão). +* Escolha uma senha temporária forte. Com `force_password_reset = True` o usuário não pode mantê-la, então ela só precisa sobreviver a um login. +* Mantenha pelo menos uma conta de administrador local funcionando para que você nunca fique bloqueado. diff --git a/docs/content/admin/user_management/PRO__audit_log_index.pt-br.md b/docs/content/admin/user_management/PRO__audit_log_index.pt-br.md new file mode 100644 index 0000000000..48c167fefb --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_log_index.pt-br.md @@ -0,0 +1,134 @@ +--- +title: Log de Auditoria +description: Toda ação de criação, atualização e exclusão que o DefectDojo registra + no seu log de auditoria, além do que é capturado e como configurar a retenção. +draft: false +weight: 4 +--- + +O DefectDojo registra uma trilha de auditoria das alterações em seus dados. Todo objeto rastreado +registra automaticamente eventos de **criação**, **atualização** e **exclusão**, e as tabelas de relacionamento +(muitos-para-muitos) registram eventos de **adição** e **remoção**. + +## Como funciona + +O rastreamento de auditoria é conduzido por triggers de banco de dados registrados por modelo. Para cada +objeto rastreado, três tipos de evento podem ser disparados: + +| Tipo de evento | Quando é disparado | Ação | +| ------------- | ----------------------------------------------------------------------------- | ---------- | +| `InsertEvent` | Um novo registro é criado | **Criação** | +| `UpdateEvent` | Um registro é alterado — apenas quando o valor de um campo realmente muda | **Atualização** | +| `DeleteEvent` | Um registro é excluído | **Exclusão** | + +As tabelas de relacionamento muitos-para-muitos (tags, revisores, faixas de IP do firewall) rastreiam +apenas **adição** (`InsertEvent`) e **remoção** (`DeleteEvent`) — não existe +"atualização" para uma linha de relacionamento. + +### O que é capturado em cada evento + +- **Quem** — o usuário que executou a ação, obtido do contexto da requisição. +- **Quando** — um timestamp. +- **IP de origem** — o endereço remoto, respeitando as cadeias de proxy `X-Forwarded-For`. +- **Snapshot antes/depois** — os valores completos dos campos do registro. +- **Contexto / rótulo** — agrupa eventos originados da mesma requisição. O rótulo + `initial_backfill` marca registros históricos importados quando o rastreamento foi + ativado pela primeira vez. + +Eventos produzidos por jobs em segundo plano são reconectados ao contexto da +requisição de origem, de modo que uma ação concluída de forma assíncrona ainda é +atribuída ao usuário que a disparou. + +## Core (Open Source) — ações rastreadas + +| Objeto | Criação | Atualização | Exclusão | Notas | +| ------------------------------ | :----: | :----: | :----: | ---------------------------------------------- | +| Usuário | ✅ | ✅ | ✅ | `password` excluído dos snapshots | +| Tipo de Produto | ✅ | ✅ | ✅ | | +| Produto | ✅ | ✅ | ✅ | | +| Engajamento | ✅ | ✅ | ✅ | | +| Teste | ✅ | ✅ | ✅ | | +| Achado | ✅ | ✅ | ✅ | | +| Grupo de Achados | ✅ | ✅ | ✅ | | +| Modelo de Achado | ✅ | ✅ | ✅ | | +| Aceitação de risco | ✅ | ✅ | ✅ | | +| Endpoint | ✅ | ✅ | ✅ | | +| Localização | ✅ | ✅ | ✅ | | +| URL | ✅ | ✅ | ✅ | | +| Webhook de Notificação | ✅ | ✅ | ✅ | `header_name` / `header_value` excluídos (segredos) | + +### Core — eventos de relacionamento (adição / remoção) + +| Relacionamento | Adição | Remoção | +| ---------------------------------- | :-: | :----: | +| Achado → Revisores | ✅ | ✅ | +| Achado → Tags | ✅ | ✅ | +| Achado → Tags Herdadas | ✅ | ✅ | +| Produto → Tags | ✅ | ✅ | +| Engajamento → Tags | ✅ | ✅ | +| Engajamento → Tags Herdadas | ✅ | ✅ | +| Teste → Tags | ✅ | ✅ | +| Teste → Tags Herdadas | ✅ | ✅ | +| Endpoint → Tags | ✅ | ✅ | +| Endpoint → Tags Herdadas | ✅ | ✅ | +| Modelo de Achado → Tags | ✅ | ✅ | +| App Analysis (Tecnologia) → Tags | ✅ | ✅ | +| Objects/Product → Tags | ✅ | ✅ | + +## Pro — ações rastreadas + +| Objeto | Criação | Atualização | Exclusão | Notas | +| --------------------------------- | :----: | :----: | :----: | ------------------------------ | +| Achado Aprimorado | ✅ | ✅ | ✅ | Complemento Pro do Achado | +| Regra | ✅ | ✅ | ✅ | Mecanismo de regras | +| Ação de Regra | ✅ | ✅ | ✅ | | +| Condição de Ação de Regra | ✅ | ✅ | ✅ | | +| Entrada de Filtro de Regra | ✅ | ✅ | ✅ | | +| Operação do Mecanismo de Regras | ✅ | ✅ | ✅ | | +| Mensagem de Operação do Mecanismo de Regras | ✅ | ✅ | ✅ | | +| Tarefa Agendada | ✅ | ✅ | ✅ | | +| Execução de Tarefa Agendada | ✅ | ✅ | ✅ | | +| Política de Mitigação | ✅ | ✅ | ✅ | | +| Configuração Ajustável | ✅ | ✅ | ✅ | Alterações de configuração do sistema | +| Estado do Feature Flag | ✅ | ✅ | ✅ | Ativação/desativação de flags + fixações do sistema | +| Definição do Feature Flag | ✅ | ✅ | ✅ | Metadados / sincronização de registro | +| Firewall de Nuvem | ✅ | ✅ | ✅ | Campo `locked` excluído | +| Máscara de IP do Firewall | ✅ | ✅ | ✅ | | + +### Pro — RBAC / permissões + +| Objeto | Criação | Atualização | Exclusão | +| ----------------------------- | :----: | :----: | :----: | +| Grupo | ✅ | ✅ | ✅ | +| Papel | ✅ | ✅ | ✅ | +| Associação a Grupo | ✅ | ✅ | ✅ | +| Papel Global | ✅ | ✅ | ✅ | +| Atribuição de Grupo a Produto | ✅ | ✅ | ✅ | +| Atribuição de Grupo a Tipo de Produto | ✅ | ✅ | ✅ | +| Membro do Produto | ✅ | ✅ | ✅ | +| Membro do Tipo de Produto | ✅ | ✅ | ✅ | + +### Pro — eventos de relacionamento (adição / remoção) + +| Relacionamento | Adição | Remoção | +| --------------------------- | :-: | :----: | +| Firewall de Nuvem → Faixas de IP | ✅ | ✅ | + +## Configuração e retenção (Controles On-Premise) + +| Configuração | Variável de ambiente | Padrão | Efeito | +| -------------------- | ------------------------------------- | ------------------ | ------------------------------------------------------------------ | +| Ativar log de auditoria | `DD_ENABLE_AUDITLOG` | `True` | Quando definido como `False`, todos os triggers de histórico são desativados e nenhum evento é registrado | +| Período de retenção | `DD_AUDITLOG_FLUSH_RETENTION_PERIOD` | `-1` (nunca limpa) | Meses de histórico a manter; eventos mais antigos são excluídos em lotes pelo job de limpeza | +| Tamanho do lote de limpeza | `DD_AUDITLOG_FLUSH_BATCH_SIZE` | `1000` | Linhas excluídas por lote durante a limpeza | +| Máximo de lotes de limpeza | `DD_AUDITLOG_FLUSH_MAX_BATCHES` | `100` | Limite do número de lotes por execução de limpeza | + +## Observações e limitações + +- **Segredos nunca são capturados.** As senhas de usuário e os valores de cabeçalho dos webhooks de notificação + são explicitamente excluídos dos snapshots de eventos. +- **As atualizações só são registradas quando há uma mudança real.** Um salvamento que não altera nenhum + valor de campo não gera um evento de atualização; campos gerenciados automaticamente, como + `last_updated` isoladamente, não disparam um evento. +- **Eventos de autenticação não são capturados aqui.** Apenas + mudanças de dados. As atividades de login, logout e tentativas de login malsucedidas são tratadas separadamente e não fazem parte deste log de auditoria. diff --git a/docs/content/admin/user_management/PRO__audit_logging.pt-br.md b/docs/content/admin/user_management/PRO__audit_logging.pt-br.md new file mode 100644 index 0000000000..389db05726 --- /dev/null +++ b/docs/content/admin/user_management/PRO__audit_logging.pt-br.md @@ -0,0 +1,110 @@ +--- +title: Logs de Auditoria +description: Acesse os logs de auditoria de objetos do DefectDojo +weight: 1 +audience: pro +--- + +**Logs de Auditoria** fornecem um registro cronológico das ações realizadas no DefectDojo. Eles garantem responsabilização e conformidade ao registrar qual usuário realizou qual ação e quando. + +Os logs de auditoria são valiosos para: +- **Investigações de segurança**: Determinar quem realizou ações sensíveis. +- **Conformidade**: Demonstrar um histórico auditável para padrões como SOC 2, ISO 27001, ou requisitos internos de governança. +- **Solução de problemas**: Identificar quando uma configuração ou objeto foi alterado. +- **Responsabilização**: Rastrear a atividade administrativa e de usuários em toda a plataforma. + +Em resumo, os Logs de Auditoria fornecem um registro centralizado de eventos importantes que ajuda os administradores a entender o histórico de atividades de sua instância além do histórico de qualquer objeto individual. + +### Acessando os Logs de Auditoria + +Os Logs de Auditoria são acessíveis pela barra lateral, dentro do submenu Configurations. + +![image](images/auditlogs_ss2.png) + +### Permissões + +O acesso aos Logs de Auditoria é determinado pela função global de um Usuário. + +As funções globais de API Importer, Reader e Writer não permitem acesso aos Logs de Auditoria, enquanto as funções Maintainer e Owner permitem. Superusuários também têm acesso aos Logs de Auditoria independentemente de sua função global. + +Mais informações sobre permissões e funções globais podem ser encontradas [aqui](/admin/user_management/pro_permissions_overhaul/). + +## Conteúdo dos Logs de Auditoria + +Os Logs de Auditoria rastreiam uma variedade de ações, incluindo, mas não se limitando a: +- Interações com objetos (por exemplo, criar, atualizar ou excluir objetos). +- Atualizações na prioridade e no risk score de um Achado. +- Criação e edição de perfis de Usuário. +- Atualizações de percentil EPSS. + +A lista completa de alterações e ações capturadas nos Logs de Auditoria pode ser encontrada [aqui](../pro__audit_log_index/). + +## Tabela de Logs de Auditoria + +Os Logs de Auditoria incluem várias colunas com diferentes dados para melhorar a rastreabilidade, incluindo: +- **Timestamp**: O momento em que a alteração ocorreu. +- **User**: O usuário que realizou a ação. +- **Action**: Qual ação foi realizada (por exemplo, criar, atualizar, excluir). +- **Model**: Qual aspecto foi modificado (por exemplo, Asset, User, Finding, Location, Firewall, URL, etc.). +- **Object ID**: O ID exclusivo do DefectDojo para o objeto que foi modificado. +- **Object Name**: O nome do objeto afetado. +- **Changes**: Campos específicos modificados pela ação, incluindo seus valores anteriores e atualizados. +- **Data**: Um snapshot exato do registro no momento em que a ação foi realizada, incluindo todos os campos, não apenas os que foram alterados. +- **Context**: Detalhes sobre como a alteração aconteceu, quem a fez, de onde no aplicativo ela veio, e um rótulo indicando qual job realizou a alteração (se foi um job automatizado). +- **URL**: A URL usada para executar a operação em questão. Esses caminhos podem se referir à Vue UI do DefectDojo, ou à API REST. O campo URL não será preenchido para processos de back-end. +- **IP Address**: O endereço de rede do dispositivo que fez a alteração. Isso não será preenchido para processos de back-end. + +### Linha do Tempo dos Logs de Auditoria + +Por padrão, os Logs de Auditoria exibem entradas dos últimos 31 dias. Entradas mais antigas permanecem disponíveis e podem ser visualizadas ajustando o filtro Timestamp. + +![image](images/auditlogs_ss3.gif) + +### Filtrando os Logs de Auditoria + +A tabela de Logs de Auditoria inclui filtros para ajudar a restringir os resultados exibidos. Por exemplo, se você quisesse ver apenas ações referentes a Assets, poderia filtrar por Assets dentro da tabela. + +![image](images/auditlogs_ss1.png) + +As colunas dentro dos Logs de Auditoria também podem ser organizadas em ordem alfabética, crescente/decrescente, ou cronológica, dependendo do conteúdo da coluna em questão. As colunas também podem ser arrastadas para a esquerda ou para a direita, conforme o arranjo preferido. + +![image](images/auditlogs_ss4.gif) + +## Histórico do Objeto + +O **Histórico do Objeto** fornece um registro cronológico das alterações feitas em um objeto individual do DefectDojo (por exemplo, Organization, Asset, Engagement, Test, Findings, Endpoints e Risk Acceptances). Cada entrada inclui detalhes como o timestamp, o usuário, a ação realizada e as alterações associadas. + +Diferente dos Logs de Auditoria, que registram eventos em toda a instância, o Histórico do Objeto diz respeito estritamente à atividade de um único objeto, facilitando o entendimento do histórico de um objeto sem precisar filtrar eventos de sistema não relacionados. + +O Histórico do Objeto é útil para: +- Revisar a progressão de um objeto ao longo do tempo. +- Determinar quando uma alteração foi feita. +- Identificar qual usuário fez uma modificação. +- Solucionar alterações inesperadas. + +### Acessando o Histórico do Objeto + +O Histórico do Objeto pode ser acessado pelo menu de engrenagem no canto superior direito da visualização de qualquer objeto. Somente Usuários com acesso ao objeto em questão podem visualizar o Histórico do Objeto correspondente. + +### Logs de Auditoria e Histórico do Objeto + +Embora a função dos Logs de Auditoria e do Histórico do Objeto se sobreponha, eles operam em escopos diferentes. O Histórico do Objeto foca nas alterações feitas em objetos individuais, enquanto os Logs de Auditoria fornecem um registro de eventos significativos em toda a sua instância do DefectDojo, oferecendo uma visão mais ampla, de "visão de pássaro", da atividade. + +## Endpoints + +### Endpoint de Histórico do Objeto (Somente Pro) + +Usuários do DefectDojo Pro têm acesso a um caminho de API `/history` para esses objetos, a fim de visualizar dados semelhantes. Por exemplo: `/api/v2/findings/{id}/history/`. + +### Endpoint de Log de Auditoria (Somente Pro) + +Usuários do DefectDojo Pro também têm acesso a um endpoint dedicado `/audit_log` para toda a sua instância. Este log só pode ser acessado por usuários ou tokens de API com permissões de superusuário. + +Esta API retorna 31 dias de logs de auditoria. + +* Enviar parâmetros padrão ou vazios retornará os últimos 31 dias de logs de auditoria. + +* O parâmetro `window_month` recebe um mês e ano no formato MM-YYYY e fornece os logs de auditoria daquele mês. +* Você pode definir o parâmetro `window_start` para limitar esses logs a uma janela mais curta, em vez de retornar o mês inteiro. + +Para mais informações, consulte a documentação da API, localizada em sua instância: `your-instance.cloud.defectdojo.com/api/v2/oa3/swagger-ui/` diff --git a/docs/content/admin/user_management/PRO__creating_new_users.pt-br.md b/docs/content/admin/user_management/PRO__creating_new_users.pt-br.md new file mode 100644 index 0000000000..604dd87b01 --- /dev/null +++ b/docs/content/admin/user_management/PRO__creating_new_users.pt-br.md @@ -0,0 +1,42 @@ +--- +title: Criando um novo usuário +description: Como integrar um novo usuário à sua instância do DefectDojo +audience: pro +weight: 1 +--- + +Esta página descreve o fluxo de integração recomendado para adicionar novos usuários a uma instância do DefectDojo. Usuários do DefectDojo podem ser usados tanto como contas padrão, operadas por humanos, quanto como contas de serviço. + +O administrador que cria a conta é responsável por entregar as credenciais iniciais (nome de usuário e senha) ao novo usuário. + +## Fluxo recomendado + +1. **Crie a conta de usuário** no DefectDojo (somente Superusuário): + * Navegue até **👤 Users → ➕ New User**. + * Insira o nome e o endereço de e-mail do novo usuário. + * Defina uma senha temporária. + * Envie o formulário. + +2. **Atribua as permissões** conforme apropriado — associação a Produto/Tipo de Produto, Permissões de Configuração, Função Global, ou status de Superusuário. Consulte [Definir as permissões de um Usuário](../set_user_permissions/) para mais detalhes. Um novo usuário sem nenhuma atribuição não conseguirá ver nenhum Produto ou Achado. + +3. **Envie as credenciais ao novo usuário por um canal separado** (por e-mail, pela ferramenta de chat da sua equipe, ou da forma como você normalmente compartilha segredos). Inclua: + * A URL da instância do DefectDojo. + * O nome de usuário (geralmente o endereço de e-mail). + * A senha temporária que você acabou de definir. + * Uma observação de que o usuário deve trocar a senha e ativar o MFA (se sua instância usar MFA) no primeiro login. + +4. **O novo usuário faz login e rotaciona a credencial.** Ele pode: + * Fazer login com a senha temporária e depois alterá-la pelo menu de perfil, ou + * Usar o link **I forgot my password** na página de login para definir uma senha diretamente, sem usar a temporária. A senha temporária ainda é necessária para que o registro inicial da conta exista, mas o usuário não precisa memorizá-la se usar o fluxo de redefinição de senha. + +5. **O novo usuário configura o MFA** pelo menu de perfil. Recomendamos fortemente exigir MFA para todos os usuários em instâncias que não estejam atrás de SSO. + +## Usuários SSO + +Se sua instância estiver configurada com [SSO](../configure_sso/), o fluxo é diferente — os usuários normalmente são criados no primeiro login a partir do Provedor de Identidade, e você só precisa conceder a eles associação a grupos ou funções posteriormente. + +## Recuperando-se da perda de um token MFA + +Se um usuário perder o acesso ao seu dispositivo MFA, ele pode fazer login com um dos códigos de recuperação emitidos no momento do cadastro. Se esses também tiverem sido perdidos, um administrador com acesso ao servidor pode limpar o MFA da conta com `python manage.py remove_mfa --username `, após o que o usuário faz login com sua senha e se cadastra novamente — suas permissões e seu histórico são preservados, portanto não é necessário criar uma conta substituta. + +Consulte [Autenticação Multifator](../pro__mfa/#recovering-a-user-who-has-lost-their-mfa-device) para conhecer todas as opções de recuperação, e observe que o acesso ao **Cloud Manager** em si é uma questão separada — consulte o [guia de solução de problemas de conectividade](/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.pt-br.md b/docs/content/admin/user_management/PRO__custom_rbac_roles.pt-br.md new file mode 100644 index 0000000000..ffd1c333fd --- /dev/null +++ b/docs/content/admin/user_management/PRO__custom_rbac_roles.pt-br.md @@ -0,0 +1,212 @@ +--- +title: Funções RBAC Personalizadas +description: Crie suas próprias funções escolhendo permissões individuais, usando + as cinco funções integradas como pontos de partida clonáveis +weight: 5 +audience: pro +--- + +> **Recurso do DefectDojo Pro.** O sistema de RBAC Members / Groups / Global Roles descrito nesta página faz parte do DefectDojo Pro. O DefectDojo de código aberto usa o modelo [Authorized Users](../os__authorized_users/). Consulte essa página para o controle de acesso no código aberto, e as [notas de atualização da 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) caso você esteja migrando entre edições. + +O DefectDojo Pro vem com cinco funções: **Reader**, **Writer**, **Maintainer**, **Owner** e **API Importer**. Se nenhuma delas for adequada, agora você pode criar sua própria função escolhendo exatamente quais permissões ela concede. + +Uma função personalizada funciona em qualquer lugar onde uma função integrada funciona: como Função Global, como a função de um Grupo, como a função padrão do grupo, e como função de membro em uma Organização ou Asset individual. + +As cinco funções integradas se tornam **predefinições bloqueadas e clonáveis**. Suas permissões não mudam (consulte os [gráficos de permissões de ação](../user_permission_chart/) para saber o que cada uma concede), elas não podem ser editadas nem excluídas, e cloná-las é a forma recomendada de começar uma nova função. + +## Antes de começar + +O gerenciamento de funções personalizadas vem desativado por padrão. Um **superusuário** o ativa em **Settings > Feature Flags**, habilitando **Custom Roles**. Consulte [Feature Flags](/admin/feature_flags/pro__feature_flags/) para saber como essa página funciona. + +Enquanto o recurso estiver desativado, a página Roles ainda pode ser lida: você pode visualizar as funções integradas e suas permissões, mas não pode criar, editar, clonar ou excluir nada. + +Gerenciar funções exige status de **superusuário** ou a Função Global integrada **Owner**. Isso é intencional e não pode ser delegado a uma função personalizada: consulte [O que uma Função Global personalizada desbloqueia](#what-a-custom-global-role-unlocks). + +## Abrindo a página Roles + +Vá até **👤 Users > Roles** na barra lateral esquerda. O item do menu fica visível para superusuários e para quem possui a Função Global integrada Owner. + +![The Roles page listing built-in and custom roles](images/pro_roles_list.png) + +A tabela lista todas as funções da sua instância: + +| Coluna | O que mostra | +| --- | --- | +| **ID** | O id numérico da função. Útil ao filtrar a tabela de Users ou ao chamar a API. | +| **Name** | O nome da função. | +| **Description** | Sua própria anotação sobre a finalidade da função. Opcional, e vazia a menos que alguém a preencha. As funções integradas vêm sem uma. | +| **Permissions** | Uma contagem de permissões concedidas. Clique para abrir uma visualização somente leitura da grade completa. | +| **Users** | Quantos usuários possuem essa função como sua Função Global. Clique para vê-los na tabela de Users. | +| **Type** | **Built-in** para as cinco predefinições, **Custom** para funções criadas por você. | + +Todas as colunas podem ser ordenadas e filtradas, e a busca por palavra-chave corresponde ao nome e à descrição. + +## Criando uma função + +### Clonar uma função integrada (recomendado) + +Clonar parte de um conjunto de permissões já validado, em vez de uma grade vazia, o que torna muito mais difícil esquecer acidentalmente uma permissão de que a função precisa. + +1. Encontre a função mais próxima do que você deseja. +2. Abra seu menu **⋮** e escolha **Clone Role**. +3. Uma cópia é criada imediatamente, chamada ` (copy)`, com as mesmas permissões e descrição da função de origem. +4. Abra o menu **⋮** da cópia, escolha **Edit Role**, depois renomeie-a e ajuste suas permissões. + +Funções integradas podem ser clonadas mesmo não podendo ser editadas. O clone registra de qual função ele se originou. + +### Começar do zero + +1. Clique em **New Role**. +2. Dê a ela um **Name** (obrigatório) e, opcionalmente, uma **Description**. +3. Escolha suas permissões na grade abaixo (veja a próxima seção). +4. Clique em **Save Role**. + +Os nomes das funções devem ser únicos, e a verificação ignora maiúsculas/minúsculas: se `Triage Lead` já existir, `triage lead` será rejeitado. + +## Escolhendo permissões + +![The permission grid in the role form](images/pro_role_permission_grid.png) + +As permissões são agrupadas em três tabelas mais uma lista de verificação. + +**Object Permissions** se aplicam às Organizations e Assets aos quais a função é atribuída, e a tudo o que está aninhado sob eles. + +| Linha | 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** significa criar um novo Asset dentro de uma Organization à qual a função está atribuída. +2. A visualização (View) de Notes e Benchmarks é herdada: uma função que pode ver o Engagement, Test, Finding ou Asset pai pode ver suas Notes e Benchmarks. Essas células mostram um ícone **?** em vez de uma caixa de seleção. + +**Group & Member Permissions** controlam quem pode gerenciar a associação. As colunas aqui são View, Manage, Add, Add Owner, Edit e Delete. + +| Linha | Ações disponíveis | +| --- | --- | +| Organization Group, Asset Group | View, Add, Add Owner, Edit, Delete | +| Organization Member, Asset Member, Group Member | Manage, Add Owner, Delete | + +**Global Feature Permissions** controlam recursos do Pro em toda a instância, e não Organizations ou Assets individuais, portanto **só têm efeito quando a função é mantida como uma Função Global**. Concedê-las em uma função usada apenas como associação de Asset não tem efeito. + +| Linha | Ações disponíveis | +| --- | --- | +| 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** é uma lista de verificação de capacidades que não se encaixam no formato View/Add/Edit/Delete: + +* **Configure Asset Notifications**: escolher quais notificações um único Asset envia, e para onde. +* **Import Scan Result**: importar e reimportar resultados de scan, criando e atualizando achados. +* **Share Dashboard Layout**: publicar um layout de painel para outros usuários. Somente Função Global. +* **Share Table Preference**: publicar uma visualização de tabela salva (colunas, filtros, ordem de classificação). Somente Função Global. +* **View Note History**: ver quem alterou uma nota e quando. + +### Como ler a grade + +![The read-only view of a role's permissions](images/pro_role_permissions_modal.png) + +| O que você vê | O que significa | +| --- | --- | +| An empty checkbox | A permissão existe e não está concedida. Clique para concedê-la. | +| A checked checkbox | Concedida. | +| A shaded, empty cell | A permissão não existe para aquela linha e ação. Não é selecionável. | +| A **?** icon | A visualização (View) é herdada de um objeto pai, portanto não há nada para conceder aqui. | +| A green ✔ (read-only view) | Concedida. | +| A red ✘ (read-only view) | Não concedida. | + +Em cada linha, a permissão mais à esquerda (**View**, ou **Manage** nas linhas de membro) controla o restante da linha. Você precisa concedê-la antes que as outras células daquela linha fiquem disponíveis, porque uma função não pode, de forma significativa, editar ou excluir o que não pode ver. Desmarcar essa permissão limpa o restante da linha junto com ela. + +## Editando, clonando e excluindo + +O menu **⋮** de cada linha oferece **Edit Role**, **Clone Role**, **Delete Role** e **Role History**. + +Funções integradas só oferecem **Clone Role**. Elas não podem ser editadas nem excluídas, por ninguém, incluindo superusuários. Isso mantém uma base conhecida estável e torna as atualizações previsíveis. + +Excluir uma função que ainda está atribuída a alguém falhará. Reatribua ou remova essas atribuições primeiro, depois exclua a função. As atribuições que contam para esse fim são associações de Organization e Asset (tanto de usuário quanto de grupo), Funções Globais, associações de Grupo, e a função de grupo padrão em System Settings. + +A API pode fazer essa reatribuição para você em uma única chamada. Consulte [Gerenciando funções pela API](#managing-roles-through-the-api). + +## Atribuindo uma função personalizada + +Funções personalizadas aparecem em todos os menus suspensos de função, junto com as integradas: + +| Onde | Como | +| --- | --- | +| **Global Role em um usuário** | O campo **Global Role** no formulário do usuário. Somente superusuários. Consulte [Definir as permissões de um Usuário](../set_user_permissions/). | +| **Global Role em um grupo** | O campo **Global Role** no formulário do grupo. Consulte [Compartilhar permissões: Grupos de Usuários](../create_user_group/). | +| **Associação de Organization ou Asset** | A caixa de diálogo Permissions na Organization ou Asset, tanto para usuários quanto para grupos. Consulte [Definir permissões no Pro](../pro_permissions_overhaul/). | +| **Função de grupo padrão** | **Default group role** em System Settings, aplicada a usuários recém-criados. Consulte [Gerenciar permissões padrão](../about_perms_and_roles/#manage-default-permissions). | +| **Função dentro de um grupo** | O menu suspenso de função na lista de membros de um grupo. Esse menu suspenso só oferece funções que concedem ao menos uma permissão de Group, portanto uma função sem permissões de Group não aparecerá ali. | + +Duas restrições valem a pena conhecer: + +* **O nível Owner é reservado.** Uma função personalizada nunca pode ser uma função de nível owner. Somente a Owner integrada é, portanto só ela carrega o poder implícito de gerenciar outros Owners. +* **Conceder a função Owner a outra pessoa ainda exige a permissão Add Owner correspondente**, seja em uma Organization, um Asset ou um Grupo. + +## O que uma Função Global personalizada desbloqueia + +Partes da interface são controladas por uma Função Global mínima, em vez de por uma permissão individual. Para que funções personalizadas funcionem com esses controles, o DefectDojo classifica uma Função Global personalizada em relação aos níveis integrados: uma função personalizada alcança o nível mais alto cujas permissões ela cobre **completamente**. + +* Uma função personalizada que cobre tudo o que Maintainer concede é tratada como Maintainer para esses controles. +* Cubra tudo o que Writer concede, e ela é tratada como Writer. O mesmo vale para Reader. +* Não cubra nenhum deles completamente, e ela não alcança nenhum nível. Suas permissões individuais continuam funcionando exatamente como concedidas; apenas os controles de interface baseados em nível permanecem fechados. +* **Owner nunca pode ser alcançado dessa forma.** O gerenciamento de funções, e tudo o mais controlado pela Função Global Owner, permanece restrito a superusuários e à Owner integrada. + +A cobertura precisa ser completa, o que às vezes surpreende as pessoas. Uma função clonada de Maintainer alcança o nível Maintainer. Reconstrua as permissões de Maintainer manualmente, esqueça uma, e a função cai para o nível Writer. Se uma Função Global personalizada estiver sem uma parte da interface que você esperava, compare-a com o nível integrado nos [gráficos de permissões de ação](../user_permission_chart/). + +## Histórico de funções + +Funções personalizadas mantêm uma trilha de auditoria. Abra **Role History** no menu **⋮** de uma função para ver quais permissões foram concedidas ou revogadas, por quem, e quando, junto com alterações em quem possui a função. + +Duas coisas que esse histórico não mostra: alterações no próprio nome e descrição de uma função, e as permissões das funções integradas (essas são pré-carregadas, nunca editadas, e portanto nunca geram histórico). + +O histórico de funções é uma leitura, portanto está disponível independentemente de o recurso Custom Roles estar ativado. + +## Gerenciando funções pela API + +As funções estão disponíveis em `/api/v2/roles/`. As leituras são abertas a qualquer usuário autenticado, pois os clientes precisam da lista de funções para preencher menus suspensos. As gravações exigem status de superusuário ou a Função Global Owner integrada, além do feature flag Custom Roles. + +| Operação | Requisição | +| --- | --- | +| Listar funções | `GET /api/v2/roles/` | +| Obter uma função | `GET /api/v2/roles/{id}/` | +| Listar todas as permissões concedíveis | `GET /api/v2/roles/permissions_catalog/` | +| Criar uma função | `POST /api/v2/roles/` com `name`, `description` opcional, e uma lista de `permissions` | +| Substituir as permissões de uma função | `PATCH /api/v2/roles/{id}/` com uma lista de `permissions` | +| Clonar uma função | `POST /api/v2/roles/{id}/clone/` com `name` e `description` opcionais | +| Excluir uma função | `DELETE /api/v2/roles/{id}/` | +| Excluir uma função e mover suas atribuições | `DELETE /api/v2/roles/{id}/?reassign_to={other_role_id}` | +| Ler o histórico de uma função | `GET /api/v2/roles/{id}/history/` | + +Observações: + +* `permissions` **substitui** a lista de permissões concedidas da função, em vez de adicionar a ela. Envie o conjunto completo que você quer que a função tenha ao final. +* `?reassign_to=` move todas as atribuições da função excluída para a função que você indicar, em uma única transação. Essa é a única forma de reatribuir em massa: a interface não oferece isso. +* Tentar editar ou excluir uma função integrada retorna `403`. Editar um valor de permissão desconhecido, reutilizar um nome de função existente, ou excluir uma função em uso sem `reassign_to` retorna `400` com uma explicação. +* `is_owner` não pode ser definido pela API. Enviá-lo é aceito e ignorado. + +## Coisas a saber + +* **Múltiplas funções no mesmo objeto concedem a união de suas permissões.** Se um usuário possui uma função diretamente em um Asset e herda outra por meio de um grupo, ele obtém tudo o que qualquer uma das funções conceder. As funções só adicionam permissões, nunca as removem. +* **Alterações de permissão são aplicadas no próximo carregamento de página**, não instantaneamente na visualização atual. Jobs em segundo plano podem levar até 30 segundos, e dados de permissão em cache até 5 minutos, para refletir uma edição. +* **Os menus suspensos de função listam até 250 funções.** Além disso, algumas funções não aparecerão nos menus suspensos, embora continuem funcionando. +* **Maintainer e Owner podem adicionar Organizations, mas a grade não mostra isso.** Para essas duas funções, essa concessão é armazenada como uma concessão de escopo global, e a grade só lê concessões de escopo de objeto, portanto a célula **Organization > Add** delas aparece como não concedida. Clonar qualquer uma das duas preserva a concessão. +* **A terminologia segue sua instância.** Esta documentação usa Organization e Asset, os rótulos padrão. Se sua instância desativou a renomeação de Organization / Asset, as mesmas linhas mostram Product Type e Product em vez disso. +* **A página Roles é somente leitura para todos os demais.** Um usuário que acessar `/settings/roles` diretamente pode ver as funções e suas permissões, mas não pode alterar nada. Os dados de permissão não são sensíveis, e o servidor aplica o limite real em cada gravação. diff --git a/docs/content/admin/user_management/PRO__mfa.pt-br.md b/docs/content/admin/user_management/PRO__mfa.pt-br.md new file mode 100644 index 0000000000..cffbe3a8f0 --- /dev/null +++ b/docs/content/admin/user_management/PRO__mfa.pt-br.md @@ -0,0 +1,85 @@ +--- +title: Autenticação Multifator (MFA) +description: Configure o MFA em sua própria conta, exija-o em toda a sua instância + e recupere um usuário que perdeu o dispositivo +audience: pro +weight: 3 +--- + +A autenticação multifator adiciona uma segunda etapa ao login: depois da sua senha, o DefectDojo solicita um código de seis dígitos de um aplicativo autenticador. Recomendamos fortemente exigi-la para todos os usuários em instâncias que não estejam atrás de SSO. + +O MFA do DefectDojo Pro usa um **aplicativo autenticador TOTP** — Google Authenticator, 1Password, Authy, ou qualquer outro aplicativo que leia um QR code padrão. Não há opção de e-mail ou SMS. + +## Configurando o MFA na sua conta + +1. Vá até **Connect \> Authorization \> MFA Settings**. +2. Em **Personal Multi-Factor Authentication Settings**, clique em **Set Up MFA**. +3. Leia o QR code com seu aplicativo autenticador. Se você não conseguir ler o código, a tela de configuração também mostra a chave em formato de texto, que você pode digitar manualmente no seu aplicativo. +4. Digite o código de seis dígitos exibido pelo seu aplicativo, e clique em **Verify & enable**. +5. O DefectDojo mostra seus **códigos de recuperação**. Salve-os em um local seguro antes de continuar — veja abaixo. Clique em **Copy codes**, guarde-os, depois clique em **I've saved them. Continue**. + +O MFA fica ativo a partir desse momento. Na próxima vez que você fizer login, o DefectDojo pedirá um código depois da sua senha. + +### Códigos de recuperação + +Você recebe **dez códigos de recuperação de uso único** ao ativar o MFA. Cada um pode ser usado uma vez, no lugar de um código do seu aplicativo autenticador, e é consumido ao ser usado. + +Eles são exibidos **uma única vez**, na tela final de configuração. Depois disso, a página MFA Settings mostra apenas quantos códigos ainda restam, não os códigos em si. + +Se você perder seus códigos de recuperação — ou quiser um novo conjunto depois de usar vários — clique em **Regenerate Recovery Codes** na página MFA Settings. Isso **substitui todos os seus códigos existentes**: qualquer código salvo anteriormente para de funcionar imediatamente, então salve o novo conjunto assim que possível. + +Os códigos de recuperação são o que permite que você volte a acessar a conta quando perde o celular, então guarde-os em um local separado do dispositivo que executa seu aplicativo autenticador. + +### Desativando o MFA + +**Disable MFA** na página MFA Settings o desativa para sua própria conta. Você só precisa estar logado — não é solicitado nenhum código para confirmar. + +Se o seu administrador tiver tornado o MFA obrigatório, você será solicitado a configurá-lo novamente no próximo login. + +## Fazendo login com MFA + +Depois de digitar seu nome de usuário e senha, o DefectDojo solicita seu código de seis dígitos. Se você não tiver seu aplicativo autenticador, digite um dos seus **códigos de recuperação** no mesmo campo — esse código é então consumido. + +## Exigindo MFA para todos + +Superusuários podem tornar o MFA obrigatório em toda a instância: + +1. Vá até **Connect \> Authorization \> MFA Settings**. +2. No card **MFA Settings** — visível apenas para Superusuários — marque **Require Multi-Factor Authentication Globally**. +3. Envie o formulário. + +Isso vem **desativado por padrão**. + +Uma vez ativado, qualquer usuário que ainda não tenha se cadastrado é enviado para a tela de configuração de MFA no próximo login, e **não pode pular essa etapa**. O usuário conclui o cadastro, salva seus códigos de recuperação, e chega ao destino original. + +### Usuários SSO + +O MFA é aplicado pelo DefectDojo, e não delegado ao seu provedor de identidade. Com o MFA global exigido, os usuários que fazem login via SSO também são enviados para configurar o MFA depois que o provedor os retorna ao DefectDojo, e são solicitados a fornecer um código nos logins seguintes. + +Não há uma configuração para isentar usuários de SSO. Se o seu provedor de identidade já aplica seu próprio MFA, decida deliberadamente se você quer os dois — ativar o MFA global significa duas solicitações para usuários de SSO. + +## Recuperando um usuário que perdeu o dispositivo de MFA + +Siga estas etapas em ordem: + +1. **Use um código de recuperação.** Se o usuário ainda tiver seus códigos de recuperação, ele digita um deles em vez de um código do aplicativo no login, e depois configura o MFA novamente do zero. +2. **Se ele ainda estiver logado em algum lugar,** pode ir até **MFA Settings** e clicar em **Disable MFA** sem precisar de um código, depois se cadastrar novamente. +3. **Peça a um administrador para limpar o MFA dele.** Com acesso ao servidor, um administrador pode remover o MFA de uma conta: + + ``` + python manage.py remove_mfa --username + ``` + + O comando também aceita `--user-id` ou `--email` em vez de `--username` (exatamente um é obrigatório; `--email` não diferencia maiúsculas de minúsculas). Ele pede confirmação antes de fazer a alteração. O usuário pode então fazer login apenas com a senha e se cadastrar novamente. + + Este é um comando de shell, portanto requer acesso ao container ou host do DefectDojo. Não há um botão equivalente na interface, nem um endpoint na API. No **DefectDojo Cloud**, entre em contato com o [Suporte do DefectDojo](mailto:support@defectdojo.com) para que ele seja executado. + +Criar uma conta substituta **não** é necessário — limpar o MFA preserva as permissões, o histórico e as atribuições existentes do usuário. + +## MFA e a API + +Quando um usuário tem o MFA ativado, as requisições para `/api/v2/api-token-auth/` — o endpoint que troca um nome de usuário e senha por um token de API — também devem incluir um código de MFA, em um campo `mfa_code` junto com as credenciais. Tanto um código TOTP atual quanto um código de recuperação não utilizado são aceitos; usar um código de recuperação aqui o **consome**. + +Um código ausente ou incorreto retorna o mesmo erro genérico *"Unable to log in with provided credentials"* de uma senha incorreta, então, se as requisições de token começarem a falhar depois que um usuário ativar o MFA, esse é o primeiro ponto a verificar. + +**Os tokens de API existentes continuam funcionando.** Ativar ou desativar o MFA não revoga nem rotaciona tokens já emitidos — a verificação de MFA se aplica no momento em que um token é emitido, não em cada requisição feita com ele. Uma automação de longa duração que já possui um token não é afetada quando um usuário se cadastra no MFA. diff --git a/docs/content/admin/user_management/PRO__resetting_user_credentials.pt-br.md b/docs/content/admin/user_management/PRO__resetting_user_credentials.pt-br.md new file mode 100644 index 0000000000..2338e90f32 --- /dev/null +++ b/docs/content/admin/user_management/PRO__resetting_user_credentials.pt-br.md @@ -0,0 +1,34 @@ +--- +title: Redefinindo credenciais de usuários em massa +description: Rotacione tokens de API e force a redefinição de senha para vários usuários + de uma vez a partir da lista de Usuários +audience: pro +weight: 2 +--- + +A lista de **Usuários** do DefectDojo Pro permite rotacionar tokens de API e forçar a redefinição de senha para vários usuários de uma vez — útil para higiene periódica de credenciais ou para responder a uma suspeita de exposição de credenciais. + +Essas ações em massa estão disponíveis apenas para **Superusuários** e usuários com o papel **Global Owner**. Se você não tiver uma dessas permissões, as caixas de seleção e os botões de ação em massa não aparecem. + +## Selecionando usuários + +Na lista de **Usuários**, use as caixas de seleção para selecionar um ou mais usuários. Uma barra de ações em massa aparece com os botões de redefinição. Cada ação pede confirmação em uma caixa de diálogo antes de ser executada. + +A ação se aplica aos usuários que você marcou explicitamente. Você **não pode incluir sua própria conta** em uma redefinição em massa: se sua conta estiver entre as linhas selecionadas, os botões de ação em massa ficam desabilitados e um aviso é exibido. + +## Reset API Tokens + +**Reset API Tokens** rotaciona o token de API de cada usuário selecionado: o DefectDojo exclui o token existente do usuário e emite um novo. **O token atual do usuário para de funcionar imediatamente**, portanto qualquer script ou integração que use o token antigo precisa ser atualizado com o novo. + +* Os novos valores de token **não** são exibidos para você como administrador. Cada usuário afetado recebe uma notificação de **"API Token Reset"** informando que deve obter o novo token na interface (entregue de acordo com as configurações de notificação desse usuário). + +## Force Password Reset + +**Force Password Reset** define o sinalizador *force-password-reset-on-next-login* em cada usuário selecionado. Na próxima vez que esse usuário fizer uma requisição, o DefectDojo o redireciona para a página **Change Password** e não permite que ele continue até definir uma nova senha. O sinalizador é removido automaticamente assim que isso acontece. + +Tenha em mente o que essa ação **não** faz: + +* Ela **não** define nem randomiza uma senha temporária, e **não** retorna nenhuma credencial para você. +* Ela **não** envia um e-mail ou notificação aos usuários afetados. Como não há aviso automático, informe os usuários afetados por outro canal de que serão solicitados a alterar a senha no próximo login. + +> **Usuários SSO:** Diferente do formulário de edição de usuário único (que desabilita o sinalizador de redefinição forçada para contas autorizadas via SSO), a ação em massa aplica o sinalizador a **todos** os usuários selecionados, independentemente de como eles se autenticam. Como os usuários SSO fazem login através do seu Provedor de Identidade em vez de uma senha do DefectDojo, forçar uma redefinição de senha para eles geralmente não faz sentido — evite incluir usuários somente-SSO na seleção. diff --git a/docs/content/admin/user_management/_index.pt-br.md b/docs/content/admin/user_management/_index.pt-br.md new file mode 100644 index 0000000000..e32064ceaf --- /dev/null +++ b/docs/content/admin/user_management/_index.pt-br.md @@ -0,0 +1,43 @@ +--- +title: Gerenciamento de Usuários +description: Gerencie usuários, controle de acesso e autenticação no DefectDojo +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 5 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +--- + +A superfície de gerenciamento de usuários do DefectDojo é diferente em cada edição. Escolha a seção que corresponde à sua instalação. + +## DefectDojo Open-Source + +O DefectDojo open-source usa o modelo de **Usuários Autorizados**: um usuário recebe acesso a um Produto ou a um Tipo de Produto ao ser adicionado à lista de Usuários Autorizados desse registro. Superusuários e a equipe (staff) podem ver tudo. + +* [Usuários Autorizados](./os__authorized_users/) — como conceder acesso a Produtos e Tipos de Produto + +A autenticação no DefectDojo open-source é feita por usuário/senha local, além do fluxo de redefinição de senha. + +## DefectDojo Pro + +O DefectDojo Pro usa um sistema baseado em papéis (roles) com Membros, Grupos e Papéis Globais. Os usuários também podem receber acesso via SSO através de SAML ou de um dos provedores OAuth suportados. + +* [Permissões no DefectDojo](./about_perms_and_roles/) — visão geral de Papéis, Associações, Papéis Globais e Permissões de Configuração +* [Definir as Permissões de um Usuário](./set_user_permissions/) — atribuindo Papéis, Papéis Globais e Permissões de Configuração +* [Compartilhar permissões: Grupos de Usuários](./create_user_group/) — atribuindo permissões a vários usuários de uma vez +* [Definir Permissões no Pro](./pro_permissions_overhaul/) — interface específica do Pro para gerenciar Membros e Permissões +* [Redefinindo credenciais de usuários em massa](./pro__resetting_user_credentials/) — rotacione tokens de API e force a redefinição de senha para vários usuários de uma vez +* [Tabelas de permissões por ação](./user_permission_chart/) — referência completa de cada permissão para cada Papel integrado +* [Papéis RBAC Personalizados](./pro__custom_rbac_roles/) — crie seus próprios papéis escolhendo permissões individuais +* [Single Sign-On](/admin/sso/) — configuração de SAML e OAuth para o Pro + +## Migrando entre edições + +Se você está migrando dos Usuários Autorizados do open-source para o RBAC do Pro, ou atualizando de uma versão open-source anterior à 3.0 que usava RBAC para o modelo atual de Usuários Autorizados, consulte as [notas de atualização da 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization). O acesso existente é preservado automaticamente. diff --git a/docs/content/admin/user_management/about_perms_and_roles.pt-br.md b/docs/content/admin/user_management/about_perms_and_roles.pt-br.md new file mode 100644 index 0000000000..e10f0cfa7d --- /dev/null +++ b/docs/content/admin/user_management/about_perms_and_roles.pt-br.md @@ -0,0 +1,119 @@ +--- +title: Permissões no DefectDojo +description: Resumo detalhado de todas as opções de permissão do DefectDojo Pro +weight: 2 +audience: pro +aliases: +- /pt-br/en/customize_dojo/user_management/about_perms_and_roles +--- + +> **Recurso do DefectDojo Pro.** O sistema de RBAC de Membros / Grupos / Papéis Globais descrito nesta página faz parte do DefectDojo Pro. O DefectDojo open-source usa o modelo de [Usuários Autorizados](../os__authorized_users/) — consulte essa página para o controle de acesso do open-source, e as [notas de atualização da 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) se você estiver migrando entre edições. + +Se você tem uma equipe de usuários trabalhando no DefectDojo, é importante configurar adequadamente o Controle de Acesso Baseado em Papéis (RBAC) para que os usuários só possam acessar dados específicos. Dados de segurança são altamente sensíveis, e as opções de controle de acesso do DefectDojo permitem que você seja específico sobre o acesso de cada membro da equipe às informações. + +Este artigo é uma visão geral de como as permissões funcionam no DefectDojo. Se você preferir ver um detalhamento de **cada ação** que pode ser controlada pelas Permissões, consulte nosso artigo **[Tabela de Permissões](../user_permission_chart/)**. + +## Tipos de Permissões + +O DefectDojo gerencia quatro tipos diferentes de permissões: + +* Os usuários podem ser designados como **Membros** de **Produtos ou Tipos de Produto**. Uma Associação a Produto vem com um **Papel** que permite aos seus usuários visualizar e interagir com Tipos de Dados (Tipos de Produto, Produtos, Engajamentos, Testes e Achados) no DefectDojo. Os usuários podem ter múltiplas associações a Produtos ou Tipos de Produto, com diferentes níveis de acesso. +​ +* Os usuários também podem ter **Permissões de Configuração** atribuídas, que permitem acessar páginas de configuração no DefectDojo. As Permissões de Configuração não estão relacionadas a Produtos ou Tipos de Produto, e não estão associadas a Papéis. +​ +* Os usuários podem receber **Papéis Globais**, que dão a eles um nível padronizado de acesso a todos os Produtos e Tipos de Produto. +​ +* Os usuários podem ser configurados como **Superusuários**: papéis de nível administrativo que dão a eles controle e acesso a todos os dados e configurações do DefectDojo. + +Cada um desses tipos de Permissão também pode ser atribuído a um **Grupo** de **Usuários**. Se você tiver um grande número de usuários no DefectDojo, como uma equipe de testes dedicada a um Produto específico, os Grupos permitem configurar e manter as permissões rapidamente. + +## Associação a Produto/Tipo de Produto e Papéis + +Quando os usuários são designados como membros de um Produto ou Tipo de Produto, eles também recebem um papel que controla como interagem com os dados de Achados associados. + +### Resumo dos Papéis + +O DefectDojo Pro vem com cinco **papéis integrados**: Reader, Writer, Maintainer, Owner e API Importer. Qualquer um deles pode ser atribuído globalmente ou dentro de um Produto / Tipo de Produto. + +Os papéis integrados são predefinições fixas. Eles não podem ser editados ou excluídos, e suas permissões são as mesmas em todas as instâncias do DefectDojo Pro. Se nenhum deles se encaixar na forma como sua equipe trabalha, você pode criar um papel que se encaixe, escolhendo permissões individuais ou clonando um papel integrado e ajustando-o. Veja [Papéis RBAC Personalizados](../pro__custom_rbac_roles/). + +"Dados subjacentes" refere-se a todos os Produtos, Engajamentos, Testes, Achados ou Endpoints aninhados sob um Produto, ou Tipo de Produto. + +* **Usuários Reader** podem visualizar os dados subjacentes de qualquer Produto ou Tipo de Produto ao qual estejam atribuídos, e adicionar comentários. Eles não podem editar, adicionar ou modificar de outra forma nenhum dado subjacente, mas podem exportar Relatórios e adicionar Notas aos dados. +​ +* **Usuários Writer** têm todas as habilidades de Reader, além da capacidade de Adicionar ou Editar Engajamentos, Testes e Achados. Eles não podem adicionar novos Produtos, e não podem Excluir nenhum dado subjacente. +​ +* **Usuários Maintainer** têm todas as habilidades de Writer, além da capacidade de editar Produtos ou Tipos de Produto. Eles podem adicionar novos Membros com Papéis ao Produto ou Tipo de Produto, e também podem Excluir Engajamentos, Testes e Achados. +​ +* **Usuários Owner** têm o maior nível de controle sobre um Produto ou Tipo de Produto. Eles podem designar outros Owners, e também podem Excluir os Produtos ou Tipos de Produto aos quais estão atribuídos. +​ +* **Usuários API Importer** têm habilidades limitadas. Este Papel permite acesso limitado à API sem expor a maioria dos endpoints da API, sendo útil para automação ou para usuários que devem ser 'externos' ao DefectDojo. Eles podem visualizar dados subjacentes, Adicionar / Editar Engajamentos, e Importar Dados de Varredura. + +Para informações detalhadas sobre os Papéis integrados, consulte nossa **[Tabela de Permissões por Papel](../user_permission_chart/)**. Para a lista completa de permissões que um papel pode receber, e como criar o seu próprio, veja **[Papéis RBAC Personalizados](../pro__custom_rbac_roles/)**. + +### Papéis Globais + +Usuários com **Papéis Globais** podem visualizar e interagir com qualquer Tipo de Dados (Tipos de Produto, Produtos, Engajamentos, Testes e Achados) no DefectDojo, dependendo do Papel atribuído a eles. + +### Associações de Grupo + +Grupos de Usuários podem ser adicionados como Membros de um Produto ou Tipo de Produto. Os usuários que fazem parte do Grupo herdarão acesso a todos os Produtos ou Tipos de Produto associados, e herdarão o Papel atribuído ao Grupo. + +#### Usuários com múltiplos papéis + +* Se um Usuário é designado como membro de um Produto, ele não recebe automaticamente as permissões associadas do Tipo de Produto. + +* Se um Usuário acabar com mais de um papel no mesmo Produto ou Tipo de Produto (por exemplo, um atribuído diretamente e outro herdado de um Grupo), ele recebe as permissões **combinadas** de todos os papéis que possui ali. + +* O Papel de Produto de um Usuário sempre substitui seu Papel de Tipo de Produto 'padrão'. +​ +* O Papel de Produto / Tipo de Produto de um Usuário sempre substitui seu Papel Global dentro do Produto ou Tipo de Produto subjacente. Por exemplo, se um Usuário tem um Papel de Tipo de Produto de Reader, mas também está atribuído como Owner em um Produto aninhado sob esse Tipo de Produto, ele terá permissões adicionais de Owner somente para esse Produto. +​ +* Os Papéis não podem retirar permissões, eles só podem adicionar novas. Por exemplo, se um Usuário tem um Papel de Tipo de Produto ou Papel Global de Owner, atribuir a ele um papel de Reader em um Produto específico não removerá suas permissões de Owner nesse Produto. +​ +* O status de Superusuário sempre substitui quaisquer Papéis atribuídos. + +## Superusuários + +Os Superusuários (Admins) não têm limitações no sistema. Eles podem alterar todas as configurações, gerenciar usuários e têm acesso de leitura/gravação a todos os dados. Eles também podem alterar as regras de acesso para todos os usuários do DefectDojo. Os Superusuários também recebem notificações de todos os problemas e alertas do sistema. + +Por padrão, a primeira conta criada em uma nova instância do DefectDojo terá permissões de Superusuário. Esse usuário poderá editar as permissões de todos os usuários do DefectDojo criados posteriormente. Somente um Superusuário existente pode adicionar outro superusuário, ou adicionar um Papel Global a um usuário. + + +## Permissões de Configuração + +As Permissões de Configuração, embora semelhantes, não estão relacionadas a Produtos ou Papéis. Elas devem ser atribuídas separadamente dos Papéis. **Usuários comuns não têm nenhuma Permissão de Configuração por padrão, e a atribuição dessas permissões de configuração deve ser feita com cuidado.** + +Os usuários podem ter Permissões de Configuração atribuídas de diferentes formas: + +1. Os usuários podem receber Permissões de Configuração diretamente. Permissões específicas podem ser configuradas diretamente na página de um Usuário. + +2. Grupos de Usuários podem receber Permissões de Configuração. Assim como com os Papéis, Permissões de Configuração específicas podem ser adicionadas aos Grupos, o que dará a todos os membros do Grupo essas permissões. + +Os Superusuários têm todas as Permissões de Configuração, portanto não têm uma seção de Permissões de Configuração em sua página de Usuário. + +### Permissões de Configuração de Grupo + +Se os usuários fazem parte de um Grupo, eles também têm Permissões de Configuração de Grupo, que controlam seu nível de acesso à configuração de um Grupo. As Permissões de Grupo não correspondem à associação do Grupo a Produtos ou Tipos de Produto. + +Se os usuários criarem um novo Grupo, receberão o papel de Owner do novo Grupo por padrão. + +Para mais informações sobre Permissões de Configuração, consulte nossa **[Tabela de Permissões de Configuração](../user_permission_chart/#configuration-permission-chart)**. + +## Gerenciar permissões padrão + +Quando um usuário totalmente novo é criado no DefectDojo — seja manualmente, via SAML / SSO, ou via qualquer provedor de social-auth — ele **não tem nenhuma permissão por padrão**. Ele verá zero Tipos de Produto, zero Produtos e zero Engajamentos no primeiro login. Ele não pode visualizar ou interagir com nenhum dado até que um Superusuário conceda acesso (diretamente, via um Papel Global, via uma associação a Produto / Tipo de Produto, ou adicionando-o a um Grupo). + +Se você quiser que todo usuário recém-provisionado receba automaticamente um nível básico de acesso — por exemplo, "todo novo usuário SSO deve ser Reader em um determinado grupo" — você pode configurar um **Grupo padrão** na página de Configurações do Sistema. + +1. Abra **⚙️ Configuration → System Settings** (somente Superusuário). +2. Defina **Default group** como o [Grupo de Usuários](../create_user_group/) ao qual os usuários recém-criados devem ser adicionados. +3. Defina **Default group role** como o papel que eles devem ter nesse grupo (por exemplo, **Reader**). +4. Opcionalmente, defina **Default group email pattern** como uma expressão regular (por exemplo, `.*@yourcompany\.com$`) para que o grupo padrão seja aplicado apenas a usuários cujo e-mail corresponda. +5. Salve. + +Tanto **Default group** quanto **Default group role** devem ser definidos — se algum estiver vazio, o grupo padrão não é aplicado. + +Essa configuração se aplica a todos os fluxos de criação de usuário: criação manual, SAML, OAuth e outros provedores de social-auth. Ela não é aplicada retroativamente — os usuários existentes manterão suas associações de grupo atuais mesmo que você altere essa configuração posteriormente. + +Para orientações específicas sobre SSO, consulte [Configuração SAML](/admin/sso/pro__saml/#default-access-for-sso-provisioned-users) ou a seção do seu provedor em [Configuração de SSO](../configure_sso/). diff --git a/docs/content/admin/user_management/create_user_group.pt-br.md b/docs/content/admin/user_management/create_user_group.pt-br.md new file mode 100644 index 0000000000..f5f5366929 --- /dev/null +++ b/docs/content/admin/user_management/create_user_group.pt-br.md @@ -0,0 +1,139 @@ +--- +title: 'Compartilhar permissões: Grupos de Usuários' +description: Compartilhe e mantenha permissões para vários usuários no DefectDojo + Pro +weight: 3 +audience: pro +aliases: +- /pt-br/en/customize_dojo/user_management/create_user_group +--- + +> **Recurso do DefectDojo Pro.** Os Grupos de Usuários e o sistema de RBAC subjacente são parte do DefectDojo Pro. O DefectDojo open-source usa o modelo de [Usuários Autorizados](../os__authorized_users/) — consulte essa página para o controle de acesso do open-source, e as [notas de atualização da 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) se você estiver migrando entre edições. + +Se você tem um número significativo de usuários no DefectDojo, pode ser interessante criar um ou mais **Grupos**, para definir as mesmas regras de Controle de Acesso Baseado em Papéis (RBAC) para vários usuários simultaneamente. Somente Superusuários podem criar Grupos de Usuários. + +Os Grupos podem funcionar de várias formas: + +* Definir um, ou vários Papéis diferentes em nível de Produto ou Tipo de Produto para todos os Membros do Grupo, permitindo controle específico sobre quais Produtos ou Tipos de Produto podem ser acessados e editados pelo Grupo. +* Definir um Papel Global para todos os Membros do Grupo, dando a eles visibilidade e acesso a todos os Produtos ou Tipos de Produto. +* Definir Permissões de Configuração para um Grupo, permitindo que alterem funcionalidades específicas do DefectDojo. + +Para mais informações sobre Papéis, consulte nosso artigo **Introdução aos Papéis**. + +## A página Todos os Grupos + +Na barra lateral, navegue até 👤**Usuários \> Grupos** para ver uma lista de todos os grupos de usuários ativos e inativos. + +![image](images/Create_a_User_Group_for_shared_permissions.png) +A partir daqui, você pode criar, excluir ou visualizar suas páginas de Grupo individuais. + +Para usuários do DefectDojo Pro, a página Todos os Grupos da interface Pro tem algumas opções adicionais. +* Você pode filtrar essa tabela por Nome do Grupo, Descrição, Endereço de E-mail, Papel Global, além do número total de Usuários, Tipos de Produto e Produtos associados ao Grupo. +* Você também pode ajustar as Permissões de um Grupo ou outras configurações clicando no botão "⋮" ao lado do Grupo que deseja editar. + +![image](images/all_groups_pro.png) + +## Visualizando um Grupo + +Visualizar um grupo exibe todas as informações do Grupo, como ID, nome, descrição, papel global etc. Os Membros do Grupo, Tipos de Produto e Produtos associados ao grupo também são exibidos. Além disso, as permissões de configuração vinculadas a um Grupo podem ser atualizadas diretamente na página "View Group". + +Para usuários do DefectDojo Pro, a Visualização de Grupo da interface Pro permite atribuir ajustes de Permissão de Configuração de uma forma um pouco diferente. + +![image](images/group_view_pro_ui.png) + +* Todas as permissões de configuração são exibidas em um menu suspenso agrupado em subcategorias. Se a seleção de permissões de configuração for diferente do valor atual, um botão "Update Configuration Permissions" é exibido. + +![image](images/groups_pro_configuration_permissions.png) + +* Depois que algumas permissões adicionais forem selecionadas, o usuário será solicitado a confirmar que deseja atualizar as permissões do grupo selecionado antes que a atualização seja feita. + +## Criar / Editar um Grupo de Usuários + +1. Navegue até a página 👤**Usuários \> Grupos** na barra lateral. Você verá uma lista de todos os Grupos de Usuários existentes, incluindo Nome, Descrição, Número de Usuários, Papel Global (se aplicável) e E-mail. +​ +![image](images/Create_a_User_Group_for_shared_permissions_2.png) + +2. Clique no **botão 🛠️** ao lado do título Todos os Grupos, e selecione **\+ Novo Grupo.** +​ +![image](images/Create_a_User_Group_for_shared_permissions_3.png) + + +3. Isso o levará a uma página onde você pode criar um novo Grupo. Defina o Nome deste Grupo, e adicione uma Descrição, se desejar. + +Você também pode selecionar um Papel Global que deseja aplicar a este Grupo, se desejar. Adicionar um Papel Global ao Grupo dará a todos os Membros do Grupo acesso a todos os dados do DefectDojo, junto com um nível limitado de acesso de edição, dependendo do Papel Global escolhido. Consulte nosso artigo **Introdução aos Papéis** para mais informações. + +A conta que cria um Grupo inicialmente terá o Papel de Owner do Grupo por padrão. + +### Definir um endereço de e-mail para receber relatórios + +O Resumo Semanal (Weekly Digest) é um relatório sobre todos os Produtos / Tipos de Produto atribuídos ao Grupo. Para que um Resumo Semanal seja enviado, insira o endereço de e-mail de destino que deseja usar no formulário Criar / Editar Grupo. Os membros do Grupo continuarão recebendo notificações normalmente. + +### Visualizando uma página de Grupo + +Depois de criar um Grupo, você pode acessá-lo selecionando-o no menu listado em **Usuários \> Grupos.** + +A página do Grupo pode ser personalizada com uma **Descrição**.Ela apresenta uma lista de todos os **Membros do Grupo,** bem como os **Produtos, Tipos de Produto**, atribuídos, e o **Papel** associado a cada um deles**.** + +Você também pode ver as **Permissões de Configuração** do Grupo listadas aqui. + +## Gerenciar os Usuários de um Grupo + +A Associação ao Grupo é gerenciada a partir da página individual do Grupo, que você pode selecionar na lista da página **Usuários \> Grupos**. Clique no Nome do Grupo destacado para acessar a página do Grupo que deseja editar. + +Para visualizar ou editar a Associação de um Grupo, um Usuário deve ter as permissões de Configuração apropriadas habilitadas, além de ser Membro do Grupo (ou ter status de Superusuário). + +### **Adicionar um Usuário a um Grupo** + +Os Grupos de Usuários podem ter quantos Usuários você desejar. Todos os Usuários em um Grupo receberão o Papel associado em cada Produto ou Tipo de Produto listado, mas os Usuários também podem ter Papéis Individuais que substituem o papel do Grupo. + +1. Na página do Grupo, selecione **\+ Add Users** no botão **☰** na borda do título **Members**. +​ +![image](images/Create_a_User_Group_for_shared_permissions_4.png) + +2. Isso o levará à tela **Add Some Group Members**. Abra o menu suspenso de Usuários e marque cada usuário que deseja adicionar ao Grupo. +​ +![image](images/Create_a_User_Group_for_shared_permissions_5.png) + +3. Selecione o Papel de Grupo que deseja atribuir a esses Usuários. Isso determina a capacidade deles de configurar o Grupo. + +Observe que adicionar um membro a um Grupo não dará a ele, por padrão, acesso à sua própria página de Grupo. Essa é uma Permissão de Configuração separada que deve ser habilitada primeiro. + +### **Editar ou Excluir um Membro de um Grupo de Usuários** + +1. Na página do Grupo, selecione o ⋮ ao lado do Nome do Usuário que deseja Editar ou Excluir do Grupo. + +**📝 Edit** o levará à tela de Edição de Membro, onde você pode alterar o Papel desse usuário (de Reader, Maintainer ou Owner para outra opção). + +**🗑️ Delete** remove completamente a Associação de um Usuário. Isso não removerá nenhuma contribuição ou alteração que o Usuário tenha feito no Produto ou Tipo de Produto. + +![image](images/Create_a_User_Group_for_shared_permissions_6.png) + +## Gerenciar as Permissões de um Grupo + +As Permissões de Grupo são gerenciadas a partir da página individual do Grupo, que você pode selecionar na lista da página **Usuários \> Grupos**. Clique no Nome do Grupo destacado para acessar a página do Grupo que deseja editar. + +Observe que somente Superusuários podem editar as permissões de um Grupo (Produto / Tipo de Produto, ou Configuração). +​ +### **Adicionar Papéis de Produto ou Papéis de Tipo de Produto para um Grupo** + +Você pode registrar quantos Papéis de Produto ou Papéis de Tipo de Produto desejar em cada Grupo. + +1. Na página do Grupo, selecione **\+ Add Product Types**, ou \+ **Add Product** no título correspondente (Grupos de Tipo de Produto ou Grupos de Produto). +​ +![image](images/Create_a_User_Group_for_shared_permissions_7.png) + +2. Isso o levará a uma página **Register New Products / Product Types**, onde você pode selecionar um Produto ou Tipo de Produto para adicionar no menu suspenso. + +![image](images/Create_a_User_Group_for_shared_permissions_8.png) + +3. Selecione o Papel que deseja que todos os membros do Grupo tenham em relação a esse Produto ou Tipo de Produto específico. + +Os Grupos não podem ser atribuídos a Produtos ou Tipos de Produto sem um Papel. Se você não tiver certeza de qual Papel deseja que um Grupo tenha, Reader é uma boa opção 'padrão'. Isso manterá o estado do seu Produto seguro até que você tome sua decisão final sobre o Papel do Grupo. + +### **Atribuir Permissões de Configuração a um Grupo** + +Se você quiser que os Membros do seu Grupo acessem funções de Configuração e controlem certos aspectos do DefectDojo, você pode atribuir essas responsabilidades a partir da página do Grupo. + +Atribua os papéis de Visualizar, Adicionar, Editar ou Excluir no menu no canto inferior direito. Marcar uma Permissão de Configuração dará imediatamente ao Grupo acesso a essa função específica. + +![image](images/Create_a_User_Group_for_shared_permissions_9.png) diff --git a/docs/content/admin/user_management/pro_permissions_overhaul.pt-br.md b/docs/content/admin/user_management/pro_permissions_overhaul.pt-br.md new file mode 100644 index 0000000000..164a805604 --- /dev/null +++ b/docs/content/admin/user_management/pro_permissions_overhaul.pt-br.md @@ -0,0 +1,54 @@ +--- +title: Definir Permissões no Pro +description: Reformulação, recurso do Pro +weight: 3 +audience: pro +aliases: +- /pt-br/en/customize_dojo/user_management/pro_permissions_overhaul +--- + +## Introdução aos Tipos de Permissão + +Usuários individuais têm quatro tipos diferentes de permissão que podem ser atribuídos a eles: + +* Os usuários podem ser designados como **Membros de Produtos ou Tipos de Produto**. Isso permite que eles visualizem e interajam com Tipos de Dados (Tipos de Produto, Produtos, Engajamentos, Testes e Achados) no DefectDojo, dependendo do papel atribuído a eles no Produto específico. Os usuários podem ter múltiplas associações a Produtos ou Tipos de Produto, com diferentes níveis de acesso. +​ +* Os usuários também podem ter **Permissões de Configuração** atribuídas, que permitem acessar páginas de configuração no DefectDojo. As Permissões de Configuração não estão relacionadas a Produtos ou Tipos de Produto. +​ +* Os usuários podem receber **Papéis Globais**, que dão a eles um nível padronizado de acesso a todos os Produtos e Tipos de Produto. +​ +* Os usuários podem ser configurados como **Superusuários**: papéis de nível administrativo que dão a eles controle e acesso a todos os dados e configurações do DefectDojo. + +Você também pode criar Grupos se quiser atribuir Associação a Produto, Permissões de Configuração ou Papéis Globais a um grupo de usuários ao mesmo tempo. Se você tiver um grande número de usuários no DefectDojo, como uma equipe de testes dedicada a um Produto específico, os Grupos podem ser um recurso mais útil. + +## Superusuários e Papéis Globais + +Parte da sua configuração de Controle de Acesso Baseado em Papéis (RBAC) pode exigir a criação de Superusuários adicionais, ou de usuários com Papéis Globais. + +* Os Superusuários (Admins) não têm limitações no sistema. Eles podem alterar todas as configurações, gerenciar usuários e têm acesso de leitura/gravação a todos os dados. Eles também podem alterar as regras de acesso para todos os usuários do DefectDojo. Os Superusuários também recebem notificações de todos os problemas e alertas do sistema. +* Usuários com Papéis Globais podem visualizar e interagir com qualquer Tipo de Dados (Tipos de Produto, Produtos, Engajamentos, Testes e Achados) no DefectDojo, dependendo do Papel atribuído a eles. Para mais informações sobre cada Papel e os privilégios associados, consulte nosso artigo Introdução aos Papéis. +* Os usuários também podem ter Permissões de Configuração específicas atribuídas, permitindo que acessem determinadas páginas de configuração do DefectDojo. Por padrão, os usuários não têm nenhuma Permissão de Configuração. + +Por padrão, a primeira conta criada em uma nova instância do DefectDojo terá permissões de Superusuário. Esse usuário poderá editar as permissões de todos os usuários do DefectDojo criados posteriormente. Somente um Superusuário existente pode adicionar outro superusuário, ou adicionar um Papel Global a um usuário. + +As permissões no DefectDojo Pro foram simplificadas, para facilitar a atribuição de acesso a objetos. Esse recurso pode ser acessado através da [interface Pro](/get_started/about/ui_pro_vs_os/). + +### Abrindo a janela de Permissões + +![image](images/pro_permissions.png) + +Ao visualizar um Tipo de Produto ou Produto, você pode abrir a janela de Permissões para definir permissões rapidamente. Esse menu pode ser encontrado em uma Tabela clicando nos pontos horizontais **"⋮"**. Se estiver em uma página individual de **Produto** ou **Tipo de Produto**, esse menu pode ser encontrado sob a engrenagem azul '⚙️'. + +## Definindo Permissões através da janela de permissões + +![image](images/pro_permissions_2.png) + +1. Na parte superior dessa janela, você pode optar por gerenciar permissões para um usuário individual ou para um [grupo de usuários](../create_user_group). +2. Aqui, você pode selecionar um usuário ou grupo para adicionar ao Produto, e selecionar o [Papel](../about_perms_and_roles) que deseja que esse usuário tenha. +3. Na tabela inferior, você pode ver uma lista de todos os usuários ou grupos que têm acesso a esse objeto. Você também pode atribuir rapidamente um novo papel a um desses usuários ou grupos a partir do menu suspenso. + +## Definindo Permissões de Configuração através da visualização do Usuário + +As permissões de configuração de um usuário agora podem ser definidas de uma forma mais amigável. Na Visualização de Usuários, todas as permissões de configuração são exibidas em um menu suspenso, agrupadas por tipo de permissão. Se a seleção de permissões de configuração for diferente do valor atual, um botão "Update Configuration Permissions" é exibido. Ao clicar nele, o usuário será solicitado a confirmar que deseja atualizar as permissões do grupo selecionado antes que a atualização seja feita. + +![image](images/pro_user_view.png) diff --git a/docs/content/admin/user_management/set_user_permissions.pt-br.md b/docs/content/admin/user_management/set_user_permissions.pt-br.md new file mode 100644 index 0000000000..b0b935600f --- /dev/null +++ b/docs/content/admin/user_management/set_user_permissions.pt-br.md @@ -0,0 +1,154 @@ +--- +title: Definir as permissões de um Usuário +description: Como conceder Funções e Permissões a um usuário, além do status de superuser +weight: 2 +audience: pro +aliases: +- /pt-br/en/customize_dojo/user_management/set_user_permissions +--- + +> **Recurso do DefectDojo Pro.** O sistema de RBAC de Membros / Grupos / Funções Globais descrito nesta página faz parte do DefectDojo Pro. O DefectDojo de código aberto usa o modelo [Usuários Autorizados](../os__authorized_users/) — consulte essa página para o controle de acesso no código aberto, e as [notas de atualização da versão 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) caso você esteja migrando entre edições. + +## Introdução aos Tipos de Permissão + +Usuários individuais podem receber quatro tipos diferentes de permissão: + +* Os usuários podem ser atribuídos como **Membros de Produtos ou Tipos de Produto**. Isso permite que eles visualizem e interajam com Tipos de Dados (Tipos de Produto, Produtos, Engajamentos, Testes e Achados) no DefectDojo, de acordo com o papel atribuído a eles no Produto específico. Os usuários podem ter várias associações de Produto ou Tipo de Produto, com diferentes níveis de acesso. +​ +* Os usuários também podem ter **Permissões de Configuração** atribuídas, que permitem acessar páginas de configuração no DefectDojo. As Permissões de Configuração não estão relacionadas a Produtos ou Tipos de Produto. +​ +* Os usuários podem receber **Funções Globais**, que concedem um nível padronizado de acesso a todos os Produtos e Tipos de Produto. +​ +* Os usuários podem ser configurados como **Superusers**: papéis em nível de administrador que concedem controle e acesso a todos os dados e configurações do DefectDojo. + +Você também pode criar Grupos caso deseje atribuir Associação de Produto, Permissões de Configuração ou Funções Globais a um grupo de usuários ao mesmo tempo. Se você tiver um grande número de usuários no DefectDojo, como uma equipe de testes dedicada a um Produto específico, os Grupos podem ser um recurso mais útil. + +## Superusers \& Funções Globais + +Parte da configuração do seu Controle de Acesso Baseado em Função (RBAC) pode exigir que você crie Superusers adicionais, ou usuários com Funções Globais. + +* Os Superusers (Admins) não têm limitações no sistema. Eles podem alterar todas as configurações, gerenciar usuários e têm acesso de leitura/gravação a todos os dados. Também podem alterar as regras de acesso de todos os usuários no DefectDojo. Os Superusers também recebem notificações de todos os problemas e alertas do sistema. +* Os usuários com Funções Globais podem visualizar e interagir com qualquer Tipo de Dado (Tipos de Produto, Produtos, Engajamentos, Testes e Achados) no DefectDojo, de acordo com a Função atribuída a eles. Para mais informações sobre cada Função e os privilégios associados, consulte nosso artigo Introdução às Funções. +* Os usuários também podem ter Permissões de Configuração específicas atribuídas, permitindo o acesso a determinadas páginas de configuração do DefectDojo. Por padrão, os usuários não têm nenhuma Permissão de Configuração. + +Por padrão, a primeira conta criada em uma nova instância do DefectDojo terá permissões de Superuser. Esse usuário poderá editar as permissões de todos os usuários do DefectDojo criados posteriormente. Somente um Superuser existente pode adicionar outro superuser, ou atribuir uma Função Global a um usuário. + +### Adicionar status de Superuser ou Função Global a um usuário existente + +1. Navegue até a página 👤 Usuários \> Usuários na barra lateral. Você verá uma lista de todas as contas registradas no DefectDojo, junto com o status Ativo de cada conta, as Funções Globais e outros dados relevantes do Usuário. +​ +![image](images/Set_a_User's_Permissions.png) +​ +2. Clique no nome da conta à qual deseja conceder privilégios de Superuser. Isso o levará à Página do Usuário. +​ +3. Na seção Informações Padrão da Página do Usuário, abra o menu ☰ e selecione Editar. +​ +![image](images/Set_a_User's_Permissions_2.png) + +4. Na página Editar Usuário: +​ +Para o Status de Superuser, marque a caixa ☑️ Status de Superuser, localizada nas Informações Padrão do usuário. +​ +Para atribuir uma Função Global, selecione uma no menu suspenso Função Global, na parte inferior da página. +​ +![image](images/Set_a_User's_Permissions_3.png) +​ +5. Clique em Enviar para aceitar essas alterações. + +## Associação de Produto \& Tipo de Produto + +Por padrão, qualquer nova conta criada no DefectDojo não terá permissão para visualizar nenhum dado em nível de Produto. Será necessário atribuir a ela associação a cada Produto que deve visualizar e com o qual deve interagir. + +* A associação de Produto \& Tipo de Produto só pode ser configurada por **Superusers, Maintainers ou Owners**. +* **Maintainers \& Owners** só podem configurar associação em Produtos / Tipos de Produto aos quais já estão atribuídos. +* **Global Maintainers \& Owners** podem configurar associação em qualquer Produto ou Tipo de Produto, assim como os **Superusers**. + +Os usuários podem ter dois tipos de associação simultaneamente no nível de **Produto**: + +* A Função conferida pela sua associação subjacente de Tipo de Produto, se aplicável +* Sua Função específica de Produto, se existir. + +Se um usuário já foi adicionado como membro de Tipo de Produto e não precisa de um nível adicional de permissões em um Produto específico, não há necessidade de adicioná-lo como Membro do Produto. + +### Adicionando um novo Membro + +1. Navegue até o Produto ou Tipo de Produto ao qual deseja atribuir um usuário. Você pode selecionar o Produto na lista em **Produtos \> Todos os Produtos**. + +![image](images/Set_a_User's_Permissions_4.png) + +2. Localize o cabeçalho **Membros**, clique no menu **☰** e selecione **\+ Adicionar Usuários**. +3. Isso o levará a uma página onde você pode **Registrar novos Membros**. Selecione um Usuário no menu suspenso Usuários. +4. Selecione a Função que deseja que esse Usuário tenha nesse Produto ou Tipo de Produto: **API Importer, Reader, Writer, Maintainer** ou **Owner.** +​ +![image](images/Set_a_User's_Permissions_5.png) + +Os usuários não podem ser atribuídos como Membros de um Produto ou Tipo de Produto sem também ter uma Função. Se você não tiver certeza de qual Função deseja atribuir a um novo usuário, **Reader** é uma boa opção "padrão". Isso manterá o estado do seu Produto seguro até que você tome sua decisão final sobre a Função dele. + +### Editar ou Excluir um Membro + +Os Membros podem ter sua Função alterada dentro de um Produto ou Tipo de Produto. + +Na página do **Produto** ou **Tipo de Produto**, navegue até o cabeçalho **Membros** e clique no botão **⋮** ao lado do Usuário que deseja Editar ou Excluir. + +![image](images/Set_a_User's_Permissions_6.png) + +📝 **Editar** o levará à tela **Editar Membro**, onde você pode alterar a **Função** desse usuário (de **API Importer, Reader, Writer, Maintainer** ou **Owner** para uma opção diferente). + +🗑️ **Excluir** remove completamente a Associação de um Usuário. Isso não removerá quaisquer contribuições ou alterações que o Usuário tenha feito no Produto ou Tipo de Produto. + +* Se você não conseguir Editar ou Excluir a Associação de um usuário (o **⋮** não está visível), é porque essa Associação foi conferida em nível de **Tipo de Produto**. +* Um usuário pode ter dois níveis de associação dentro de um Produto \- um atribuído no nível de **Tipo de Produto** e outro no nível de **Produto**. + +#### Adicionar uma Função de Produto adicional a um usuário com uma Função de Tipo de Produto relacionada + +Se um Usuário tiver uma Função em nível de Tipo de Produto, ele também receberá Associação com essa Função em todos os Produtos subjacentes dentro da categoria. No entanto, se você quiser que esse Usuário tenha uma Função especial em um Produto específico dentro desse Tipo de Produto, você pode atribuir a ele uma Função adicional em nível de Produto. + +1. Na página do Produto, navegue até o cabeçalho **Membros**, clique no menu **☰** e selecione **\+ Adicionar Usuários** (como se estivesse adicionando um novo Usuário ao Produto). +2. Selecione o nome do Usuário no menu suspenso e selecione a Função de Produto que deseja atribuir a esse Usuário. + +Uma Função de Produto substitui a Função padrão de Tipo de Produto ou a Função Global de um usuário. Por exemplo, se um Usuário tiver uma Função de Tipo de Produto **Reader**, mas também estiver atribuído como **Owner** em um Produto vinculado a esse Tipo de Produto, ele terá permissões adicionais de **Owner** somente para esse Produto. + +No entanto, isso não funciona ao contrário. Se um Usuário tiver uma Função de Tipo de Produto ou Função Global **Owner**, atribuir a ele uma função **Reader** em um Produto específico não removerá suas permissões de **Owner**. **As Funções não podem remover permissões concedidas a um Usuário por outras Funções, elas só podem adicionar permissões extras.** + +## Permissões de Configuração + +Muitas caixas de diálogo de configuração e endpoints de API podem ser habilitados para usuários ou grupos de usuários, independentemente do status de superuser deles. Essas Permissões de Configuração permitem que usuários comuns acessem e contribuam para partes do DefectDojo fora de sua atribuição padrão de Produto ou Função de Produto. + +As Permissões de Configuração não estão relacionadas a um Produto ou Tipo de Produto específico \- os usuários podem ter Permissões de Configuração atribuídas sem a necessidade de outros status ou de Associação a Produto / Tipo de Produto. +​ +### Lista de Permissões de Configuração + +* **Gerenciador de Credenciais:** Acesso à página ⚙️Configuração \> Gerenciador de Credenciais +* **Ambientes de Desenvolvimento:** Gerenciar a lista Engajamentos \> Ambientes +* **Modelos de Achado:** Acesso à página Achados \> Modelos de Achado +* **Grupos**: Acessar a página 👤Usuários \> Grupos +* **Instâncias do Jira:** Acessar a página ⚙️Configuração \> JIRA +* **Tipos de Idioma**: Acessar o endpoint de API [Tipos de Idioma](/automation/api/languages/) +* **Banner de Login**: Editar a página ⚙️Configuração \> Banner de Login +* **Anúncios**: Acessar ⚙️Configuração \> Anúncios +* **Tipos de Nota:** Acesso à página ⚙️Configuração \> Tipos de Nota +* **Tipos de Produto:** n/a +* **Questionários**: Acesso à página Questionários \> Todos os Questionários +* **Perguntas**: Acesso à página Questionários \> Perguntas +* **Regulamentações**: Acesso à página ⚙️Configuração \> Regulamentações +* **Configuração de SLA:** Acesso à página ⚙️Configuração \> Configuração de SLA +* **Tipos de Teste:** Adicionar ou editar um Tipo de Teste (em Engajamentos \> Tipos de Teste) +* **Configuração de Ferramenta:** Acesso à página **⚙️Configuração \> Tipos de Ferramenta** +* **Tipos de Ferramenta:** Acesso à página ⚙️Configuração \> Tipos de Ferramenta +* **Usuários:** Acesso à página 👤Usuários \> Usuários + +### Adicionar Permissões de Configuração a um Usuário + +**Somente Superusers podem adicionar Permissões de Configuração a um Usuário**. + +1. Navegue até a página 👤 Usuários \> Usuários na barra lateral. Você verá uma lista de todas as contas registradas no DefectDojo, junto com o status Ativo de cada conta, as Funções Globais e outros dados relevantes do Usuário. +​ +![image](images/Set_a_User's_Permissions_7.png) + +2. Clique no nome da conta que deseja editar. +​ +3. Navegue até a Lista de Permissões de Configuração. Ela está localizada no lado direito da Página do Usuário. +​ +4. Selecione as Permissões de Configuração de Usuário que deseja adicionar. +​ +Para uma descrição detalhada das Permissões de Configuração de Usuário, consulte nosso [Quadro de Permissões](../user_permission_chart/). diff --git a/docs/content/admin/user_management/user_permission_chart.pt-br.md b/docs/content/admin/user_management/user_permission_chart.pt-br.md new file mode 100644 index 0000000000..0ca95d5952 --- /dev/null +++ b/docs/content/admin/user_management/user_permission_chart.pt-br.md @@ -0,0 +1,99 @@ +--- +title: Quadros de permissões de ações +description: Todas as permissões de usuário do DefectDojo Pro em detalhes +weight: 4 +audience: pro +aliases: +- /pt-br/en/customize_dojo/user_management/user_permission_chart +--- + +> **Recurso do DefectDojo Pro.** O sistema de RBAC de Membros / Grupos / Funções Globais descrito nesta página faz parte do DefectDojo Pro. O DefectDojo de código aberto usa o modelo [Usuários Autorizados](../os__authorized_users/) — consulte essa página para o controle de acesso no código aberto, e as [notas de atualização da versão 3.0](/releases/os_upgrading/3.0/#authorized-users-panel-replaces-membersgroups-under-legacy-authorization) caso você esteja migrando entre edições. + +## Quadro de Permissões por Função + +Este quadro tem como objetivo listar todas as permissões relacionadas a um Produto ou Tipo de Produto, bem como quais permissões estão disponíveis para cada função. + +As cinco funções abaixo são as **funções integradas** do DefectDojo Pro. Elas são predefinições bloqueadas: suas permissões são as mesmas em todas as instâncias e não podem ser alteradas. Se você criou suas próprias funções, este quadro descreve as funções integradas a partir das quais elas foram clonadas, e não as funções personalizadas em si. Para o catálogo completo de permissões que podem ser atribuídas a uma função, consulte [Funções RBAC Personalizadas](../pro__custom_rbac_roles/#choosing-permissions). + +| **Seção** | **Permissão** | Reader | Writer | Maintainer | Owner | API Importer | +| --- | --- | --- | --- | --- | --- | --- | +| **Acesso a Produto / Tipo de Produto** | Visualizar o Produto ou Tipo de Produto atribuído ¹ | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Visualizar Produtos, Engajamentos, Testes, Achados e Endpoints aninhados | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Adicionar novos Produtos (dentro do Tipo de Produto atribuído) ² | | | ☑️ | ☑️ | | +| | Excluir Produtos ou Tipos de Produto atribuídos | | | | ☑️ | | +| **Associação a Produto / Tipo de Produto** | Adicionar Usuários como Membros (exceto a Função Owner) | | | ☑️ | ☑️ | | +| | Editar Funções de membros (exceto a Função Owner) | | | ☑️ | ☑️ | | +| | Editar Funções de membros (incluindo a Função Owner) | | | | ☑️ | | +| | Remover a si mesmo da associação a Produto / Tipo de Produto | ☑️ | ☑️ | ☑️ | ☑️ | | +| | Atribuir a Função Owner a outro Usuário | | | | ☑️ | | +| | Editar uma Associação a Produto/Tipo de Produto vinculada a um Grupo³ | | | | ☑️ | | +| | Excluir uma Associação a Produto/Tipo de Produto vinculada a um Grupo³ | | | | | | +| **Engajamentos** (Dentro de um Produto) | Adicionar, Editar Engajamentos | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Visualizar Aceitações de risco ⁴ | | ☑️ | ☑️ | ☑️ | | +| | Adicionar, Editar Aceitações de risco | | ☑️ | ☑️ | ☑️ | | +| | Excluir Engajamentos | | | ☑️ | ☑️ | | +| **Testes** (Dentro de um Produto) | Adicionar Testes | | ☑️ | ☑️ | ☑️ | | +| | Editar Testes | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Excluir Testes | | | ☑️ | ☑️ | | +| **Achados** (Dentro de um Produto) | Adicionar Achados | | ☑️ | ☑️ | ☑️ | | +| | Editar Achados | | ☑️ | ☑️ | ☑️ | | +| | Importar, Reimportar Resultados de Scan | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Excluir Achados | | | ☑️ | ☑️ | | +| | Adicionar, Editar, Excluir Grupos de Achados | | ☑️ | ☑️ | ☑️ | | +| **Outros Dados** (Dentro de um Produto) | Adicionar, Editar Endpoints | | ☑️ | ☑️ | ☑️ | | +| | Excluir Endpoints | | | ☑️ | ☑️ | | +| | Editar Benchmarks | | ☑️ | ☑️ | ☑️ | | +| | Excluir Benchmarks | | | ☑️ | ☑️ | | +| | Visualizar Histórico de Notas | ☑️ | ☑️ | ☑️ | ☑️ | | +| | Adicionar, Editar, Excluir Notas próprias | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ | +| | Editar Notas de terceiros | | ☑️ | ☑️ | ☑️ | ☑️ | +| | Excluir Notas de terceiros | | | ☑️ | ☑️ | | + +1. Um usuário que recebe permissões apenas em nível de Produto não pode visualizar o Tipo de Produto no qual esse Produto está contido. +2. Quando um novo Produto é adicionado sob um Tipo de Produto, todos os Usuários em nível de Tipo de Produto serão adicionados como Membros do novo Produto com sua Função em nível de Tipo de Produto. +3. O usuário que deseja fazer alterações em um Grupo também precisa ter a **Permissão de Configuração** **Editar Grupo**, e uma **Função de Configuração de Grupo** de **Maintainer ou Owner** no Grupo que deseja editar. +4. A visibilidade de Aceitação de risco é controlada por uma permissão mínima distinta da visibilidade de Achados — um Reader no Produto pode visualizar os Achados subjacentes, mas **não pode** visualizar as Aceitações de risco às quais esses Achados pertencem. Para detalhes sobre permissões de Aceitação de risco, comportamento da data de expiração e fluxos de reinstauração, consulte [Aceitações de risco (Pro)](/triage_findings/findings_workflows/pro__risk_acceptance/#risk-acceptance-permissions-and-visibility). + +## Quadro de Permissões de Configuração + +Cada Permissão de Configuração se refere a uma função específica do software e tem um conjunto associado de ações que um usuário pode realizar relacionadas a essa função. + +A maioria das Permissões de Configuração dá aos usuários acesso a determinadas páginas na interface. + +| **Configuration Permission** | **View ☑️** | **Add ☑️** | **Edit ☑️** | **Delete ☑️** | +| --- | --- | --- | --- | --- | +| Gerenciador de Credenciais | Acessar a página **⚙️Configuração \> Gerenciador de Credenciais** | Adicionar novas entradas no Gerenciador de Credenciais | Editar entradas do Gerenciador de Credenciais | Excluir entradas do Gerenciador de Credenciais | +| Ambientes de Desenvolvimento | n/a | Adicionar novos Ambientes de Desenvolvimento à lista 🗓️**Engajamentos \> Ambientes** | Editar Ambientes de Desenvolvimento na lista 🗓️**Engajamentos \> Ambientes** | Excluir Ambientes de Desenvolvimento da lista **🗓️Engajamentos \> Ambientes** | +| Modelos de Achado¹ | Acessar a página **Achados \> Modelos de Achado** | Adicionar um Modelo de Achado | Editar um Modelo de Achado | Excluir um Modelo de Achado | +| Grupos | Acessar a página **👤Usuários \> Grupos** | Adicionar um novo Grupo de Usuários | Somente Superuser | Somente Superuser | +| Instâncias do Jira | Acessar a página **⚙️Configuração \> JIRA page** | Adicionar uma nova Configuração do JIRA | Editar uma Configuração do JIRA existente | Excluir uma Configuração do JIRA | +| Tipos de Idioma | | | | | +| Banner de Login | n/a | n/a | Editar o banner de login, localizado em **⚙️Configuração \> Banner de Login** | n/a | +| Anúncios | n/a | n/a | Configurar Anúncios, localizados em **⚙️Configuração \> Anúncios** | n/a | +| Tipos de Nota | Acesso à página ⚙️Configuração \> Tipos de Nota | Adicionar um Tipo de Nota | Editar um Tipo de Nota | Excluir um Tipo de Nota | +| Mecanismos de Priorização | Acessar a página de configuração do Mecanismo de Priorização | Adicionar um novo Mecanismo de Priorização | Editar um Mecanismo de Priorização existente | Excluir um Mecanismo de Priorização | +| Tipos de Produto | n/a | Adicionar um novo Tipo de Produto (em Produtos \> Tipo de Produto) | n/a | n/a | +| Questionários | Acessar a página **Questionários \> Todos os Questionários** | Adicionar um novo Questionário | Editar um Questionário existente | Excluir um Questionário | +| Perguntas | Acessar a página **Questionários \> Perguntas** | Adicionar uma nova Pergunta | Editar uma Pergunta existente | n/a | +| Regulamentações | n/a | Adicionar uma Regulamentação à página **⚙️Configuração \> Regulamentações** | Editar uma Regulamentação existente | Excluir uma Regulamentação | +| Agendamento do Serviço de Agendamento | Acessar a página **Agendamento** | Somente Superuser | Editar um Agendamento existente (alterar gatilho, ativar/desativar) | Excluir um Agendamento | +| Configuração de SLA | Acessar a página **⚙️Configuração \> Configuração de SLA** | Adicionar uma nova Configuração de SLA | Editar uma Configuração de SLA existente | Excluir uma Configuração de SLA | +| Tipos de Teste | n/a | Adicionar um novo Tipo de Teste (em **Engajamentos \> Tipos de Teste**) | Editar um Tipo de Teste existente | n/a | +| Configuração de Ferramenta | Acessar a página **⚙️Configuração \> Configuração de Ferramenta** | Adicionar uma nova Configuração de Ferramenta | Editar uma Configuração de Ferramenta existente | Excluir uma Configuração de Ferramenta | +| Tipos de Ferramenta | Acessar a página **⚙️Configuração \> Tipos de Ferramenta** | Adicionar um novo Tipo de Ferramenta | Editar um Tipo de Ferramenta existente | Excluir um Tipo de Ferramenta | +| Usuários | Acessar a página **👤Usuários \> Usuários** | Adicionar um novo Usuário ao DefectDojo | Editar um Usuário existente | Excluir um Usuário | + +1. O acesso à página de Modelos de Achado também requer a Função Global **Writer, Maintainer** ou **Owner** para esse usuário. + +## Permissões de Configuração de Grupo + +| Configuration Permission | **Reader** | **Maintainer** | **Owner** | +| --- | --- | --- | --- | +| Visualizar Grupo | ☑️ | ☑️ | ☑️ | +| Remover a si mesmo do Grupo | ☑️ | ☑️ | ☑️ | +| Editar a função de um Membro em um Grupo | | ☑️ | ☑️ | +| Editar ou Excluir uma Associação a Produto ou Tipo de Produto de um Grupo¹ | | ☑️ | ☑️ | +| Alterar a função de um Membro do Grupo para Owner | | | ☑️ | +| Excluir Grupo | | | ☑️ | + +1. Isso também exige que o Usuário tenha pelo menos a Função Maintainer no Produto ou Tipo de Produto que deseja editar. diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.pt-br.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.pt-br.md new file mode 100644 index 0000000000..23cda91338 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_health_grade.pt-br.md @@ -0,0 +1,39 @@ +--- +title: Nota de Integridade do Ativo +description: Como o DefectDojo calcula a Nota de Integridade do Ativo +weight: 7 +audience: opensource +aliases: +- /pt-br/asset_modelling/os_hierarchy/product_health_grade/ +- /pt-br/en/asset_modelling/os_hierarchy/product_health_grade/ +--- + +O DefectDojo pode calcular uma nota para seus Ativos com base na quantidade de Achados contidos neles. As notas são classificadas de A a F. + +Observe que apenas Achados Ativos e Verificados contribuem para a Nota do Ativo - achados não verificados não terão impacto. + +*A nota de integridade de cada Ativo (A a F) aparece ao lado do seu nome na Lista de Ativos.* + +![Notas de Integridade do Ativo exibidas ao lado de cada Ativo na Lista de Ativos](images/asset-health-grade.png) + +## Cálculo da Nota do Ativo + +Toda Nota de Ativo começa em 100 (sem Achados). + +O cálculo da nota começa observando o maior nível de **Severidade** de um Achado no Ativo, reduzindo a Integridade do Ativo a um nível base. + +| **Maior Nível de Severidade de um Achado** | **Nota Máxima** | +| --- | --- | +| **Crítica** | **40** | +| **Alto** | **60** | +| **Médio** | **80** | +| **Baixo** | **95** | + +Pontos adicionais são então deduzidos da Nota para cada Achado adicional: + +| **Nível de Severidade de um Achado adicional** | **Redução na Nota** | +| --- | --- | +| **Crítica** | **5** | +| **Alto** | **3** | +| **Médio** | **2** | +| **Baixo** | **1** | diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.pt-br.md b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.pt-br.md new file mode 100644 index 0000000000..c8f6fa3057 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__asset_hierarchy.pt-br.md @@ -0,0 +1,216 @@ +--- +title: 'Hierarquia de Ativos: Visão Geral' +description: Entenda Organizações, Ativos, Engajamentos, Testes e Achados +weight: 1 +audience: opensource +aliases: +- /pt-br/en/working_with_findings/organizing_engagements_tests/product_hierarchy +- /pt-br/asset_modelling/os_hierarchy/product_hierarchy/ +- /pt-br/en/asset_modelling/os_hierarchy/product_hierarchy/ +--- + +O DefectDojo usa cinco classes principais de dados para organizar seu trabalho: **Organizações, Ativos**, **Engajamentos**, **Testes**, e **Achados**. + +O DefectDojo foi criado para se adaptar à sua equipe, em vez de exigir que sua equipe se adapte à ferramenta. Você poderá projetar um ambiente de trabalho robusto e adaptável assim que entender como essas classes de dados podem ser usadas para organizar seu trabalho. + +### Diagrama de Hierarquia de Ativos +![image](images/Asset_Hierarchy_Full.png) + + +## **Organizações** + +A primeira categoria de dados que você precisará configurar no DefectDojo é uma Organização. As Organizações têm como objetivo categorizar Ativos de uma maneira específica. Isso pode ser: + +* por domínio de negócio +* por equipe de desenvolvimento +* por equipe de segurança + +![image](images/Asset_Hierarchy_Overview.png) +*Os Ativos são agrupados e aninhados sob sua Organização.* + +Organizações podem ter regras de Controle de Acesso Baseado em Função aplicadas, que limitam a capacidade dos membros da equipe de visualizar e interagir com seus dados (incluindo quaisquer Ativos subjacentes com dados de Engajamento, Teste e Achado). Para mais informações sobre funções de usuário, consulte nosso artigo **Introdução às Funções**. + +#### O que uma Organização pode representar? + +* Se um determinado projeto de software tiver várias implantações ou versões distintas, pode valer a pena criar uma única Organização que cubra o escopo de todo o projeto, com cada versão existindo como Ativos individuais. +​ +* Você também pode considerar o uso de Organizações para representar estágios do seu processo de desenvolvimento de software: uma Organização para 'Em Desenvolvimento', uma Organização para 'Em Produção', etc. +​ +* No final das contas, a decisão de como organizar seus Ativos, e o que você deseja que suas Organizações representem, é sua. Sua hierarquia do DefectDojo pode precisar mudar para atender às necessidades da sua equipe de segurança. + +## **Ativos** + +Um **Ativo** no DefectDojo tem como objetivo representar qualquer projeto, programa ou aplicação que você esteja testando no momento. O Ativo hospeda todo o trabalho de segurança e o histórico de testes relacionados ao objetivo subjacente. + +![image](images/Asset_Hierarchy_Overview_2.png) + +* um **Nome** único +* uma **Descrição** +* uma **Organização** +* uma **Configuração de SLA** atribuída + +Os Ativos podem ter um escopo tão amplo ou específico quanto você desejar. Por padrão, os Ativos são objetos completamente separados na hierarquia, mas podem ser agrupados por **Organização**. + +Os Ativos são 'isolados' e não interagem com outros Ativos. Os Recursos Inteligentes do DefectDojo, como a **Deduplicação**, se aplicam apenas no contexto de um único Ativo. + +Assim como as **Organizações**, os **Ativos** podem ter regras de Controle de Acesso Baseado em Função aplicadas, que limitam a capacidade dos membros da equipe de visualizar e interagir com eles (bem como com quaisquer dados subjacentes de Engajamento, Teste e Achado). Para mais informações sobre funções de usuário, consulte nosso artigo **Introdução às Funções**. + +#### O que um Ativo pode representar? + +O conceito de 'Ativo' do DefectDojo não corresponde necessariamente 1:1 ao que sua organização chamaria de 'Produto'. O desenvolvimento de software é complexo, e as necessidades de segurança podem variar muito mesmo dentro do escopo de um único software. + +Os cenários a seguir são bons motivos para considerar a criação de um Ativo separado no DefectDojo: + +* "**ExampleAsset**" tem uma versão para Windows, uma versão para Mac e uma versão para Cloud +* "**ExampleAsset 1.0**" usa componentes de software completamente diferentes de "**ExampleAsset 2.0**", e ambas as versões são ativamente suportadas pela sua empresa. +* A equipe designada para trabalhar em "**ExampleAsset version A**" é diferente da equipe de Ativo designada para trabalhar em "**ExampleAsset version B**", e por isso precisa ter permissões de segurança diferentes atribuídas. + +Essas variações dentro de um único Ativo também podem ser tratadas no nível do Engajamento. Observe que os Engajamentos não têm controle de acesso da mesma forma que os Ativos e as Organizações. + +## **Engajamentos** + +Depois que um Ativo é configurado, você pode começar a criar e agendar Engajamentos. Os Engajamentos têm como objetivo representar momentos no tempo em que os testes estão ocorrendo, e contêm um ou mais **Testes**. + +Os Engajamentos sempre têm: + +* um **Nome** único +* **Datas de início e término** previstas +* **Status** (Not Started, In Progress, Cancelled, Completed...) +* um **Testing Lead** atribuído +* um **Ativo** associado + +Existem dois tipos de Engajamento: **Interactive** e **CI/CD**. + +* Um **Interactive Engagement** é normalmente executado por um engenheiro. Os Interactive Engagements se concentram em testar a aplicação enquanto ela está em execução, usando um teste automatizado, um testador humano ou qualquer atividade que "interaja" com a funcionalidade da aplicação. Veja [a definição de IAST da OWASP](https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing#:~:text=Interactive%20Application%20Security%20Testing,interacting%E2%80%9D%20with%20the%20application%20functionality.). +* Um **CI/CD Engagement** é destinado à integração automatizada com um pipeline de CI/CD. Os CI/CD Engagements têm como objetivo importar dados como uma ação automatizada, disparada por uma etapa do processo de release. + +Os Engajamentos podem ser acompanhados usando a visualização de **Calendar** do DefectDojo. + +#### O que um Engajamento pode representar? + +Os Engajamentos têm como objetivo representar grupos de esforços de teste relacionados. A forma como você deseja agrupar seus esforços de teste depende da sua abordagem. + +Se você tem um esforço de teste planejado e agendado, um Engajamento oferece um local para armazenar todos os resultados relacionados. Aqui está um exemplo desse tipo de Engajamento: + +#### **Engajamento:** ExampleSoftware 1.5.2 - Esforço de Teste Interativo + +*Neste exemplo, uma equipe de segurança executa múltiplos testes no mesmo dia como parte de um release de software.* + +* **Teste:** Resultados do Nessus Scan (12 de março) +* **Teste:** Resultados do NPM Scan Audit (12 de março) +* **Teste:** Resultados do Snyk Scan (12 de março) +​ +Você também pode organizar resultados de Teste de CI/CD dentro de um Engajamento. Esse tipo de Engajamento é 'Open-Ended' (sem prazo definido), o que significa que eles não têm uma data e, em vez disso, adicionam dados adicionais toda vez que as ações de CI/CD associadas são executadas. + +#### Engajamento: ExampleSoftware CI/CD Testing + +*Neste exemplo, vários scans de CI/CD são importados automaticamente como Testes toda vez que um novo release de software é criado.* + +* Teste: Resultados do Scan 1.5.2 (12 de março) +* Teste: Resultados do Scan 1.5.1 (3 de março) +* Teste: Resultados do Scan 1.5.0 (14 de fevereiro) + +Os Engajamentos podem ser organizados da forma que funcionar melhor para sua equipe. Todos os Engajamentos aninhados sob um Ativo podem ser visualizados pela equipe designada para trabalhar nesse Ativo. + +## **Testes** + +Os Testes são um agrupamento de atividades realizadas por engenheiros na tentativa de descobrir falhas em um Ativo. + +Os Testes sempre têm: + +* um **Título de Teste** único +* um **Tipo de Teste** específico (API Test, Nessus Scan etc.) +* um **Ambiente** de teste associado +* um **Engajamento** associado + +Os Testes podem ser criados de diferentes maneiras. Eles podem ser criados automaticamente quando os dados de um scan são importados diretamente em um Engajamento, resultando em um novo Teste contendo os dados do scan. Os Testes também podem ser criados antecipadamente, para planejar futuros engajamentos, ou para achados de segurança inseridos manualmente que exijam acompanhamento e remediação. + +### **Tipos de Teste** + +O DefectDojo oferece suporte a duas categorias de Tipos de Teste: + +1. **Tipos de Teste baseados em parser**: Correspondem a scanners de segurança específicos que produzem saída em formatos como XML, JSON ou CSV. Ao importar resultados de scan, o DefectDojo usa parsers especializados para converter a saída do scanner em Achados. + +2. **Tipos de Teste sem parser**: São usados para Achados criados manualmente, não importados de arquivos de scan. Esses Tipos de Teste usam o método [Generic Findings Import](/supported_tools/parsers/generic_findings_import/) para renderizar Achados e metadados. + +Os seguintes Tipos de Teste aparecem no menu suspenso "Scan Type" ao criar um novo teste. + * API Test + * Static Check + * Pen Test + * Web Application Test + * Security Research + * Threat Modeling + * Manual Code Review + +Os Tipos de Teste sem parser devem ser usados quando você precisa criar manualmente achados que exigem remediação, mas que não se originam da saída de um scanner automatizado. + +#### **Tipos de Teste baseados em parser** + +Os tipos de teste baseados em parser podem ser categorizados pela forma como o nome do tipo de teste é determinado: + +- **Nomes de Tipo de Teste fixos**: O nome do tipo de teste é predefinido e conhecido antes da importação (por exemplo, "ZAP Scan", "Nessus Scan"). + +- **Nomes de Tipo de Teste definidos pelo relatório**: O nome do tipo de teste é extraído do conteúdo do relatório de scan no momento da importação. + +Exemplos incluem: + - **Generic Findings Import**: Cria tipos de teste com base no campo `type` em relatórios JSON + - **SARIF**: Cria tipos de teste com base nos nomes das ferramentas no relatório SARIF (por exemplo, "Dockle Scan (SARIF)") + - **OpenReports**: Cria tipos de teste separados para cada origem encontrada no relatório + +**Regras de Nomenclatura de Tipo de Teste Definido pelo Relatório:** +- Se o campo `type` do relatório for igual ao tipo de scan → usa o tipo de scan diretamente (por exemplo, "Generic Findings Import") +- Se o campo `type` do relatório for diferente → cria o formato "{type} Scan ({scan_type})" (por exemplo, "Tool1 Scan (Generic Findings Import)") +- Se o campo `type` do relatório já terminar com o sufixo " ({scan_type})" → ele é usado literalmente, de modo que o sufixo nunca é duplicado (por exemplo, "Tool1 (Generic Findings Import)" permanece "Tool1 (Generic Findings Import)") +- Se nenhum campo `type` for fornecido → usa o tipo de scan diretamente + +**Considerações Importantes:** +- Tipos de teste definidos pelo relatório são criados automaticamente quando um novo tipo é detectado durante a importação ou reimportação. +- Para reimportações, o nome do tipo de teste deve corresponder exatamente - divergências gerarão um erro de validação +- As configurações de Deduplicação (`HASHCODE_FIELDS_PER_SCANNER`) usam os nomes dos tipos de teste como chaves, portanto, os nomes definidos pelo relatório devem ser configurados adequadamente caso você deseje um comportamento de deduplicação personalizado + +#### **Como os Testes interagem entre si?** + +Os Testes pegam seus dados de teste e os agrupam em Achados. Geralmente, as equipes de segurança executam o mesmo esforço de teste repetidamente, e os Testes no DefectDojo permitem lidar com esse processo de forma elegante. + +**Testes previamente importados podem ser reimportados** - Se você estiver executando o mesmo tipo de teste dentro do mesmo contexto de Engajamento, você pode Reimportar os resultados do teste após cada scan concluído. DefectDojo comparará os dados Reimportados com o resultado existente, e não criará novos Achados se houver duplicatas nos dados do scan. + +**Testes podem ser importados separadamente** - Se você executar o mesmo teste em um Ativo dentro de Engajamentos separados, DefectDojo ainda comparará os dados com Testes anteriores para encontrar Achados duplicados. Isso permite acompanhar Achados previamente mitigados ou com risco aceito. + +Se um Teste for adicionado diretamente a um Ativo sem um Engajamento, um Engajamento genérico será criado automaticamente para contê-lo. Isso permite importações de dados ad-hoc. + +**Exemplos de Testes:** + +* Burp Scan de 29 de out. de 2015 a 29 de out. de 2015 +* Nessus Scan de 31 de out. de 2015 a 31 de out. de 2015 +* API Test de 15 de out. de 2015 a 20 de out. de 2015 + +## **Achados** + +Depois que os dados forem enviados para um Teste, os resultados desses dados serão listados no Teste como **Achados** individuais para revisão. + +Um achado representa uma falha específica descoberta durante o teste. + +Os Achados sempre têm: + +* um **Nome de Achado** único +* a **Data** em que foram descobertos +* múltiplos **Status** associados, como Ativo, Verificado ou Falso positivo +* um **Teste** associado +* um nível de **Severidade**: Crítica, Alto, Médio, Baixo e Informativa (Info). + +Os Achados podem ser adicionados por meio de uma importação de dados, mas também podem ser adicionados manualmente a um Teste. + +**Exemplos de Achados:** + +* OpenSSL 'ChangeCipherSpec' MiTM Potential Vulnerability +* Web Application Potentially Vulnerable to Clickjacking +* Web Browser XSS Protection Not Enabled + +## **Endpoints** + +Os dados de scan geralmente contêm referências aos hosts ou endpoints afetados por um determinado Achado. DefectDojo agrega automaticamente os Achados por endpoint, para que você possa usar a visualização de Endpoint para ver todos os Achados que afetam um determinado Endpoint ou Hostname. + +Exemplos: +- 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.pt-br.md b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.pt-br.md new file mode 100644 index 0000000000..fac0acb3c3 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__sla_configuration.pt-br.md @@ -0,0 +1,79 @@ +--- +title: Configuração de SLA +description: Configure Acordos de Nível de Serviço para diferentes Produtos +weight: 2 +audience: opensource +aliases: +- /pt-br/en/working_with_findings/sla_configuration +--- + +Cada Produto no DefectDojo pode ter sua própria configuração de Acordo de Nível de Serviço (SLA), que representa os dias que sua organização tem para remediar ou, de outra forma, gerenciar um Achado. + +O SLA pode ser definido com base na **[Severidade do Achado](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** ou no **[Risco do Achado](/asset_modelling/pro_hierarchy/priority_sla/)** (no DefectDojo Pro). + +![image](images/sla_multiple.png) + +Os SLAs aplicam uma contagem regressiva de dias a um Achado com base no dia em que o Achado foi criado no DefectDojo. Se um Achado não for Fechado dentro da contagem regressiva, ele será rotulado como em violação do SLA. + +## Trabalhando com SLAs + +Você pode usar os SLAs como uma forma de representar as políticas de remediação da sua organização. Você também pode usá-los como uma forma de priorizar os Achados mais críticos e ativos há mais tempo na sua instância do DefectDojo. + +* Você pode ordenar ou filtrar tabelas de Achados por dias de SLA. +* As violações de SLA podem ser configuradas para disparar [Notificações](/admin/notifications/about_notifications/) para usuários do DefectDojo atribuídos ao Produto relacionado. +* No **DefectDojo Pro**, o desempenho do SLA também é acompanhado nos Painéis de Métricas de [Executive Insights and Remediation](/metrics_reports/pro_metrics/pro__overview/). +* A conformidade com o SLA também pode ser exibida em um [painel](/metrics_reports/dashboards/custom-dashboards/) personalizado no **DefectDojo Pro** — por exemplo, com um SLA Burndown ou um widget de Contagem filtrado. + +### O status Mitigated Within SLA + +Se um Achado for Mitigado com sucesso até o prazo do SLA, ele registrará uma marca de verificação verde ✅ na coluna Mitigated Within SLA. + +![image](images/sla_mitigated_within.png) + +Se um Achado foi Mitigado, mas não antes de o SLA ser violado, ele registrará um X vermelho ❌ na coluna Mitigated Within SLA. + +### Violação de SLAs + +Quando o SLA de um determinado Achado é violado (o Achado não é Fechado dentro do prazo do SLA) a marca de verificação verde ✅ muda para um X vermelho ❌. O SLA continuará sendo acompanhado com um número negativo, para representar há quantos dias o SLA foi violado. + +![image](images/sla_breached.png) + +## Gerenciando Configurações de SLA (Pro) + +No DefectDojo Pro, uma ou mais Configurações de SLA são gerenciadas na seção **Configuration > Service Level Agreements** da barra lateral. Você pode criar um **New Service Level Agreement** ou trabalhar com configurações de SLA existentes na página **All Service Level Agreements**. + +![image](images/pro_sla_risk.png) + +As Configurações de SLA só podem ser editadas por Superusuários ou por um usuário com a [Permissão de Configuração](/admin/user_management/user_permission_chart/#configuration-permission-chart) correspondente. + +### Configurando o SLA + +As configurações de SLA contêm os dias atribuídos a cada valor de **Severidade** ou **Risco** do DefectDojo. + +![image](images/pro_new_sla.png) + +Cada Acordo de Nível de Serviço pode ter um nome único, junto com uma descrição opcional. + +**Restart SLA on Finding Reactivation**: se habilitada, essa opção reiniciará o SLA quando um Achado for Reaberto. Caso contrário, o SLA será baseado em quando o Achado foi criado. + +Ao editar um SLA, você pode escolher se esse SLA usará **Severidade** ou **Risco** como referência para atribuir os Days To Remediate. Isso é feito selecionando a opção correspondente na seção **Service Level configuration Type** do formulário. + +A partir daqui, você pode definir o número de dias permitido para cada nível de **Severidade** ou **Risco**. Você também pode aplicar os SLAs seletivamente; desmarcando **Enforce ___ Finding Days**, você pode ignorar o cálculo do SLA para esses níveis de Severidade ou Risco. + +## Aplicar uma Configuração de SLA a um Produto (Pro) + +Produtos recém-criados no DefectDojo sempre aplicarão a **Default SLA Configuration**, que pode ser definida com valores diferentes, se desejado. + +Se você tiver configurações de SLA, pode escolher qual delas será aplicada ao seu Produto no formulário **Edit Product**. + +![image](images/pro_sla_product.png) + +### Recálculo de SLA + +Depois que um novo SLA for selecionado para um Produto, os SLAs de todos os Achados associados precisarão ser recalculados pelo DefectDojo. Enquanto esse processo estiver em execução, o SLA do Produto não pode ser alterado. + +## Observações sobre SLAs + +* Os SLAs podem, opcionalmente, ser reiniciados quando um Achado com [Risco aceito](/triage_findings/findings_workflows/os__risk_acceptance/) é reativado. Isso é definido ao criar a Aceitação de Risco, configurando o campo **Restart SLA Expired**. +* Reimportar um Achado não reinicia o SLA - os SLAs são sempre calculados a partir do momento em que um Achado foi detectado pela primeira vez, a menos que **Restart SLA on Finding Reactivation** esteja habilitado. +* A expiração da Aceitação de Risco ou a reativação de um Achado Fechado são as únicas formas de redefinir ou recalcular um SLA para um Achado depois de criado (sem alterar a configuração de SLA do Produto). diff --git a/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.pt-br.md b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.pt-br.md new file mode 100644 index 0000000000..8e24e61d80 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/OS__source-code-repositories.pt-br.md @@ -0,0 +1,59 @@ +--- +title: Vincular Achados ao código-fonte +description: Integração de repositórios para navegar até a localização dos achados + no código-fonte. +draft: false +weight: 5 +audience: opensource +aliases: +- /pt-br/en/working_with_findings/organizing_engagements_tests/source-code-repositories +--- + +Algumas ferramentas (particularmente ferramentas SAST) incluem o nome do arquivo associado e o número da linha nos dados de vulnerabilidade. Se o repositório do código-fonte for especificado no Engajamento, o DefectDojo apresentará o caminho do arquivo como um link, e o usuário poderá navegar diretamente até a localização da vulnerabilidade. + +## Definindo o repositório no Engajamento e no Teste + +### Engajamento + +Ao editar o Engajamento, os usuários podem definir a URL do repositório específico de Gerenciamento de Código-Fonte (SCM). **(Na UI do Pro, esse campo pode ser definido em Editar Engajamento > Campos Opcionais > Repositório)**. + +Para um Engajamento Interativo, é necessário informar uma URL que especifique a branch: +- para o GitHub - como https://github.com/DefectDojo/django-DefectDojo/tree/dev +![Editar Engajamento (GitHub)](images/source-code-repositories_1.png) +- para o GitLab - como https://gitlab.com/gitlab-org/gitlab/-/tree/master +![Editar Engajamento (Gitlab)](images/source-code-repositories-gitlab_1.png) +- para o BitBucket público - como (como uma URL de git clone) +![Editar Engajamento (Bitbucket público)](images/source-code-repositories-bitbucket_1.png) +- para o BitBucket standalone/on-premise https://bb.example.com/scm/some-project/some-repo.git ou https://bb.example.com/scm/some-user-name/some-repo.git para o repositório público do usuário (como uma URL de git clone) +![Editar Engajamento (Bitbucket standalone)](images/source-code-repositories-bitbucket-onpremise_1.png) + +Para Engajamentos de CI/CD, o hash do commit, a branch/tag e a linha de código podem variar, então você só precisa incluir a URL do repositório. +- para o GitHub - como `https://github.com/DefectDojo/django-DefectDojo` +- para o GitLab - como `https://gitlab.com/gitlab-org/gitlab` +- para o BitBucket público, Gitea e Codeberg - como `https://bitbucket.org/some-user/some-project.git` (como uma URL de git clone) +- para o BitBucket standalone/on-premise `https://bb.example.com/scm/some-project.git` ou `https://bb.example.com/scm/some-user-name/some-repo.git` para o repositório público do usuário (como uma URL de git clone) + +Em um Engajamento de CI/CD, você pode especificar um hash de commit ou uma branch/tag no formulário **Editar Engajamento**, que será anexado a todos os links renderizados pelo DefectDojo. Se esses valores não forem definidos, a URL do SCM precisará conter um link completo que inclua a branch de código. + +A URL de navegação do SCM é composta a partir da URL do Repo usando o Tipo de SCM. Um tipo de SCM específico pode ser definido no campo personalizado do Ativo "scm-type". Se nenhum "scm-type" for definido e a URL contiver "https://github.com", será assumido o tipo de SCM "github". + +Campos personalizados do Ativo: + +![Campos personalizados do Ativo](images/asset-custom-fields_1.png) + +Adição do tipo de SCM do Ativo: + +![Tipo de SCM do Ativo](images/asset-scm-type_1.png) + +Os possíveis tipos de SCM podem ser 'github', 'gitlab', 'bitbucket', 'bitbucket-standalone', 'gitea', 'codeberg' ou nenhum (para o padrão github). + + +## Links para o código-fonte nos Achados + +Ao visualizar um achado, a localização será apresentada como um link, caso o repositório do código-fonte tenha sido definido no Engajamento: + +![Link para a localização](images/source-code-repositories_2.png) + +Clicar nesse link abrirá uma nova aba no navegador, com o arquivo de origem da vulnerabilidade na linha correspondente: + +![Ver no repositório](images/source-code-repositories_3.png) diff --git a/docs/content/asset_modelling/OS_hierarchy/_index.pt-br.md b/docs/content/asset_modelling/OS_hierarchy/_index.pt-br.md new file mode 100644 index 0000000000..b5d6272632 --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/_index.pt-br.md @@ -0,0 +1,11 @@ +--- +title: Hierarquia de Ativos +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.pt-br.md b/docs/content/asset_modelling/OS_hierarchy/benchmarks.pt-br.md new file mode 100644 index 0000000000..a085e0c08e --- /dev/null +++ b/docs/content/asset_modelling/OS_hierarchy/benchmarks.pt-br.md @@ -0,0 +1,39 @@ +--- +title: Benchmarks do OWASP ASVS +description: Compare um Produto com o OWASP Application Security Verification Standard + por meio de Benchmarks +weight: 6 +audience: opensource +--- + +O DefectDojo oferece suporte à realização de benchmark de Produtos em relação ao [OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/), que fornece uma base para testar controles técnicos de segurança de aplicações web. + +Os Benchmarks permitem medir o quanto um Produto atende aos requisitos de segurança definidos pela sua organização, além de publicar uma pontuação na página do Produto para maior visibilidade. + +## Acessando Benchmarks + +Os Benchmarks estão disponíveis na página **Product**. Para abrir a visualização de Benchmarks, selecione o menu suspenso no canto superior direito da página do Produto e escolha **OWASP ASVS v.3.1** próximo à parte inferior do menu. + +## Níveis de Benchmark + +O OWASP ASVS define três níveis de cobertura de verificação: + +- **Nível 1** – Para todo software. Cobre os requisitos de segurança mais críticos com o menor custo de verificação. Este é o nível padrão no DefectDojo. +- **Nível 2** – Para aplicações que contêm dados sensíveis. Adequado para a maioria das aplicações. +- **Nível 3** – Para as aplicações mais críticas, como aquelas que realizam transações de alto valor ou armazenam dados sensíveis médicos, financeiros ou de segurança. + +Você pode alternar entre os níveis usando o menu suspenso no canto superior direito da visualização de Benchmarks. + +## Pontuação de Benchmark + +O lado esquerdo da visualização de Benchmarks exibe a pontuação atual do seu Produto no nível ASVS selecionado: + +- A **pontuação desejada** que sua organização definiu como meta +- A **porcentagem de benchmarks aprovados** em direção a essa pontuação +- O **número total de benchmarks habilitados** para o nível selecionado + +Habilitar a caixa de seleção **Publicar** exibirá a pontuação do ASVS diretamente na página do Produto. + +## Gerenciando Entradas de Benchmark + +Entradas individuais de benchmark podem ser marcadas como aprovadas ou reprovadas à medida que sua equipe avança pelos controles do ASVS. Entradas adicionais de benchmark, além do conjunto padrão do ASVS, podem ser adicionadas ou atualizadas por meio do **Django admin site**. diff --git a/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.pt-br.md b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.pt-br.md new file mode 100644 index 0000000000..ffc303eb2c --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/OS__questionnaires.pt-br.md @@ -0,0 +1,274 @@ +--- +title: Questionários +description: Entendendo os Questionários no DefectDojo OS +audience: opensource +weight: 2 +--- + +No DefectDojo, um Questionário é um conjunto reutilizável de perguntas que coleta informações de desenvolvedores, equipes e partes interessadas tanto internas quanto externas. Eles podem ser usados para reunir informações antes do início do trabalho, garantir o alinhamento entre indivíduos e equipes à medida que o trabalho avança, e permitir uma análise retrospectiva após a conclusão do trabalho. + +## Modelos de Questionário + +Um modelo de Questionário define a estrutura e o conteúdo do Questionário, incluindo seu nome, descrição e Perguntas associadas. Criar um modelo de Questionário não o torna automaticamente disponível para receber respostas. Para coletar respostas, um modelo de Questionário deve ser implantado como um **Questionário Geral** ou um **Questionário Vinculado**. + +### Questionários Gerais e Vinculados + +Os Questionários Gerais e Vinculados diferem de várias formas, incluindo como são distribuídos, quem pode responder e onde as respostas são armazenadas. + +| Questionários Gerais | Questionários Vinculados | +|---|---| +| Exigem publicação | Não exigem publicação | +| Exigem uma data de expiração | Permanecem ativos se o Engajamento ainda estiver ativo | +| Permitem respostas anônimas | Não permitem respostas anônimas | +| São compartilháveis interna e externamente | São compartilháveis apenas internamente | +| Não permitem alterar respostas | Permitem alterar respostas | +| Respostas só ficam visíveis após a expiração | Respostas ficam visíveis imediatamente | +| Respostas ficam visíveis em "Todos os Questionários" | Respostas ficam visíveis dentro do Engajamento | +| Podem ser convertidos em um Engajamento | Já está vinculado a um Engajamento | + +#### Ciclo de Vida da Implantação do Questionário + +Os modelos de Questionário seguem ciclos de vida diferentes, dependendo do tipo de implantação: + +**Questionários Gerais** +Modelo → Publicado → Aceita Respostas → Expira → Conversão Opcional em Engajamento + +**Questionários Vinculados** +Modelo → Vinculado ao Engajamento → Aceita Respostas → Permanece ativo enquanto o Engajamento estiver ativo + +#### Separação de Respostas + +Um único modelo de Questionário pode ser implantado várias vezes simultaneamente, tanto como Questionário Geral quanto Vinculado. Cada implantação cria seu próprio conjunto independente de respostas. + +Se o mesmo modelo de Questionário for implantado como um Questionário Geral e também vinculado a um Engajamento, as respostas enviadas por meio de cada implantação são armazenadas de forma independente e não são combinadas. Isso permite que o mesmo modelo de Questionário seja reutilizado em diferentes contextos, mantendo os conjuntos de respostas separados. + +## Acessando Questionários e Perguntas + +Questionários e Perguntas podem ser acessados na barra lateral clicando na opção **Questionários**. O submenu oferece acesso a **Todos os Questionários** e **Todas as Perguntas**. + +![imagem](images/q_ss1.png) + +Vale destacar que o acesso às visualizações Todos os Questionários e Todas as Perguntas é restrito a Usuários com status de Superusuário. Apenas Superusuários podem criar modelos de Questionário, criar Perguntas e implantar Questionários. Usuários sem status de Superusuário ainda podem responder aos Questionários Gerais compartilhados com eles, bem como responder aos Questionários Vinculados dos Engajamentos aos quais têm acesso, mas não podem criá-los nem gerenciá-los. + +### Questionários + +A visualização de Todos os Questionários inclui duas tabelas: +- **Questionários** + - Esta seção inclui todos os modelos de Questionário existentes. +- **Questionários Gerais** + - Esta seção inclui todos os Questionários Gerais que estão atualmente abertos para respostas. + +Ambas as seções podem ser filtradas por nome, descrição ou status de atividade. + +### Perguntas + +A visualização de Todas as Perguntas inclui uma tabela de Perguntas que podem atualmente ser adicionadas a um Questionário. Ela também pode ser filtrada pelo status opcional de cada Pergunta, pelo conteúdo ou pelo tipo de pergunta (por exemplo, pergunta de texto ou pergunta de múltipla escolha). + +## Gerenciando Modelos de Questionário + +### Criar Questionários + +Novos Questionários podem ser criados usando o botão Criar Questionário na visualização Todos os Questionários. + +![imagem](images/q_ss2.png) + +Depois de incluir um nome e uma descrição, o Questionário pode ser criado sem Perguntas (que podem ser adicionadas posteriormente) ou as Perguntas podem ser adicionadas imediatamente. + +#### Adicionar Perguntas Imediatamente a um Novo Questionário + +Se as Perguntas estiverem sendo adicionadas imediatamente, selecione todas as Perguntas aplicáveis no menu suspenso que aparece em seguida. Você também pode criar uma nova Pergunta para adicionar ao Questionário clicando no sinal + à direita do menu suspenso. + +![imagem](images/q_ss12.png) + +Depois que todas as Perguntas aplicáveis tiverem sido selecionadas, clique em **Atualizar Perguntas do Questionário** para adicionar todas as Perguntas selecionadas ao Questionário. + +#### Adicionar Perguntas a um Questionário Já Existente + +Para adicionar Perguntas a um Questionário já existente, clique no nome do Questionário na tabela de Questionários, clique em **Editar Perguntas**, selecione quaisquer novas Perguntas a adicionar ao Questionário no menu suspenso e, em seguida, clique em **Atualizar Perguntas do Questionário**. + +### Criar Perguntas + +Novas Perguntas podem ser criadas usando o botão **Criar Pergunta** na visualização Todas as Perguntas. + +![imagem](images/q_ss3.png) + +Além disso, as Perguntas também podem ser criadas no momento de decidir quais Perguntas adicionar a um Questionário, clicando no sinal + à direita do menu suspenso. + +#### Tipos de Pergunta + +Ao criar uma nova Pergunta, ela pode ser formatada como uma pergunta baseada em texto ou como uma pergunta de múltipla escolha, selecionando **Texto** ou **Múltipla Escolha** no menu suspenso. + +#### Permitindo Múltiplas Respostas e Respostas Opcionais + +O número máximo de respostas permitidas em uma pergunta de múltipla escolha é seis. Marcar a caixa de seleção **Múltipla Escolha** permite que várias respostas sejam selecionadas (disponível apenas para perguntas de múltipla escolha). As Perguntas também podem ser marcadas como **Opcional** ao clicar na caixa de seleção correspondente. + +Consulte a seção [Editando Perguntas](#editing-questions) para saber como adicionar respostas adicionais a uma pergunta de múltipla escolha. + +#### Ordem das Perguntas + +Determine a ordem de uma Pergunta atribuindo a ela um número de ordem. Por exemplo, se uma Pergunta tiver 1 no campo Ordem, essa Pergunta aparecerá acima de uma Pergunta com 2 no campo Ordem. + +![imagem](images/q_ss13.png) + +### Editando Perguntas + +Depois que uma Pergunta é criada, ela pode ser editada acessando o submenu Todas as Perguntas e clicando na Pergunta a ser alterada. As Perguntas não podem ser excluídas. + +É importante evitar editar Perguntas que fazem parte de Questionários ativos. Se qualquer parte de uma Pergunta for alterada (por exemplo, ordem, status opcional, correção de um erro de digitação, adição de uma resposta possível etc.) e essa Pergunta fizer parte de um Questionário ativo que já tenha recebido respostas, todas as respostas enviadas anteriormente serão invalidadas e será necessário reenviá-las. + +#### Editando Perguntas de Texto + +Após a criação, as únicas alterações que podem ser feitas em Perguntas baseadas em texto são a ordem, o status opcional e a formulação da pergunta. + +#### Editando Perguntas de Múltipla Escolha + +Embora o número padrão de respostas possíveis para uma pergunta de múltipla escolha seja seis, esse número pode ser aumentado depois que o Questionário for criado. Para isso, clique na Pergunta na visualização Todas as Perguntas, clique no sinal **+** à direita do menu suspenso Choices, adicione a nova resposta e clique em **Submit**. + +![imagem](images/q_ss16.png) + +![imagem](images/q_ss17.png) + +A opção recém-criada não será adicionada automaticamente ao Questionário. Para adicioná-la, clique no menu suspenso **Choices** e selecione a opção recém-adicionada. Uma marca de seleção aparecerá ao lado dela, indicando que ela agora está incluída como uma resposta possível no Questionário. + +![imagem](images/q_ss18.png) + +## Implantando Questionários + +Depois que um modelo de Questionário é criado com sucesso, ele pode ser implantado para aceitar respostas. O processo de implantação é ligeiramente diferente, dependendo do tipo de Questionário. + +### Implantação de Questionário Geral + +Para implantar um Questionário Geral: +1. Acesse a visualização Todos os Questionários. +2. Clique no **+** no lado direito da tabela de Questionários Gerais. +3. Selecione o Questionário a ser implantado. +4. Defina a data de expiração. +5. Clique em **Adicionar Questionário**. + +#### Compartilhando um Questionário Geral + +Depois de implantado, um Questionário Geral pode ser compartilhado clicando em **Compartilhar Questionário** na coluna Ações da tabela de Questionários Gerais. Isso gerará um link que você pode compartilhar com os destinatários pretendidos, além de permitir confirmar se o Questionário está formatado como esperado antes de fazer isso. + +![imagem](images/q_ss14.png) + +Observe o seguinte: +- Nenhuma resposta a um Questionário Geral ficará visível até que o Questionário tenha expirado. +- Não é possível alterar a data de expiração depois que o Questionário tiver sido publicado. +- O horário padrão de expiração de um Questionário é meia-noite (por exemplo, um Questionário com expiração em 31 de dezembro de 2026 só ficará visível até as 23:59:59 dessa data). +- Não é possível definir um horário de expiração personalizado. + +Consulte [Habilitando Respostas Anônimas](#enabling-anonymous-responses) abaixo para saber como permitir respostas de Usuários externos. + +### Implantação de Questionário Vinculado + +Para implantar um Questionário Vinculado: +1. Acesse o Engajamento que será vinculado ao Questionário. +2. Clique na seta para baixo na tabela **Additional Features**. +3. Clique no **+** no lado direito da subtabela de Questionários. +4. Selecione o Questionário a ser vinculado no menu suspenso. +5. Clique em **Adicionar Questionário** ou em **Adicionar Questionário e Responder**. + +O Questionário Vinculado agora estará ativo para qualquer Usuário com acesso ao Engajamento. + +#### Compartilhando um Questionário Vinculado + +Para compartilhar o Questionário Vinculado diretamente com Usuários internos do DefectDojo, clique no menu kebab ⋮ e selecione **Compartilhar Questionário** no menu suspenso. Um link aparecerá, que pode ser copiado e encaminhado ao destinatário pretendido. + +![imagem](images/q_ss10.png) + +Como mencionado, os Questionários Vinculados só podem ser compartilhados com Usuários do DefectDojo. + +## Respondendo Questionários + +O fluxo de resposta é ligeiramente diferente dependendo se o Questionário é Geral ou Vinculado. + +### Respondendo a um Questionário Geral + +Para responder a um Questionário Geral, os usuários que não são Superusuários precisam receber o link diretamente de um Superusuário, conforme descrito [aqui](#sharing-a-general-questionnaire). + +#### Habilitando Respostas Anônimas + +Por padrão, os Questionários Gerais só podem ser acessados por Usuários do DefectDojo. Para permitir que partes externas respondam aos Questionários do DefectDojo, certifique-se de que a opção **Allow Anonymous Survey Responses** esteja ativada nas Configurações do Sistema, encontradas na seção **Configurations** da barra lateral. + +![imagem](images/q_ss4.png) + +![imagem](images/q_ss5.png) + +As respostas externas aparecerão como anônimas porque não há nenhum ID de usuário do DefectDojo associado à resposta. + +Se o escopo de um Questionário incluir Usuários tanto internos quanto externos, crie um Questionário Geral e especifique o nome do Engajamento na descrição no momento da criação, o que permitirá filtrar os resultados. + +![imagem](images/q_ss8.png) + +![imagem](images/q_ss9.png) + +### Respondendo a Questionários Vinculados + +Para responder a um Questionário Vinculado: +1. Acesse a visualização do Engajamento. +2. Expanda a tabela Additional Features. +3. Expanda a subtabela de Questionários. +4. Clique no menu kebab ⋮ do Questionário Vinculado. +5. Clique em **Responder Questionário**. + +![imagem](images/q_ss15.png) + +Os Questionários Vinculados não permitem respostas externas/anônimas porque é necessário ter acesso ao DefectDojo para acessar o Engajamento. + +## Respostas + +Como mencionado, cada implantação de um modelo de Questionário cria seu próprio container de respostas. Vincular o mesmo modelo de Questionário a vários Engajamentos resulta em conjuntos de respostas separados, e publicar um Questionário Geral não afeta os conjuntos de respostas dos Questionários Vinculados. + +### Respostas de Questionário Geral + +Depois que a expiração de um Questionário Geral tiver passado: +- Não será mais possível enviar respostas adicionais. +- Todas as respostas anteriores serão salvas e ficarão visíveis. +- O Questionário será listado como um Questionário de Engajamento Respondido e Não Atribuído no painel do DefectDojo. + +Há três ações que podem ser realizadas quando a janela de respostas de um Questionário for encerrada: **Ver Respostas**, **Criar Engajamento** e **Atribuir Usuário**. + +#### Visualizando Respostas do Questionário + +Selecionar **Ver Respostas** exibirá todas as respostas do Questionário. + +#### Criando um Engajamento a partir de um Questionário + +Após a expiração, um Questionário Geral pode ser conectado a um Ativo por meio de um Engajamento, selecionando a ação **Criar Engajamento**. Selecione um Ativo na lista suspensa que aparece em seguida e clique em **Criar Engajamento**. Um novo Engajamento poderá então ser criado e receber detalhes específicos, semelhantes aos de outros Engajamentos no DefectDojo, como Descrição, Versão, Status, Tags etc. + +![imagem](images/q_ss6.png) + +![imagem](images/q_ss7.png) + +#### Atribuir Usuário + +A ação Atribuir Usuário solicitará que um Usuário seja selecionado no menu suspenso de Usuários disponíveis. Selecione um Usuário no menu suspenso e clique em **Atribuir Questionário**, o que tornará esse Usuário o proprietário do Questionário. + +### Respostas de Questionário Vinculado + +Os Questionários Vinculados permanecem disponíveis enquanto o Engajamento associado estiver ativo. Dessa forma, as respostas ficam visíveis a qualquer momento. + +O menu kebab ⋮ de um Questionário Vinculado inclui várias funções para gerenciar o Questionário e suas respostas: +- **Responder Questionário**: Esta opção aparece se um Usuário ainda não tiver respondido ao Questionário Vinculado. Depois de respondido, as opções Ver Respostas e Editar Respostas serão exibidas. +- **Ver respostas**: Permite que os Usuários vejam todas as respostas do Questionário até o momento. +- **Editar Respostas**: Permite que Usuários individuais editem suas Respostas anteriores. +- **Atribuir Usuário**: Atribui o questionário a um Usuário. +- **Vincular a um Engajamento Diferente**: Abre um menu suspenso com outros Engajamentos aos quais o Questionário pode ser atribuído. +- **Compartilhar Questionário**: Gera um link para compartilhar o Questionário com Usuários internos. +- **Excluir Questionário**: Desvincula o Questionário do Engajamento e exclui todas as respostas coletadas anteriormente. + +## Excluindo Questionários + +Excluir Questionários Gerais e Vinculados tem efeitos posteriores diferentes, dependendo do resultado pretendido com a exclusão. + +### Excluindo Questionários Gerais + +Excluir um Questionário Geral da tabela de Questionários Gerais na seção Todos os Questionários excluirá todas as respostas coletadas nessa implantação antes da exclusão. Quaisquer Questionários Vinculados que usem o mesmo modelo de Questionário não serão excluídos. + +### Excluindo Questionários Vinculados + +Excluir um Questionário Vinculado desvinculará o Questionário do Engajamento. Todas as respostas coletadas dentro do Engajamento antes da exclusão serão perdidas. Os Questionários Gerais implantados anteriormente usando o mesmo modelo de Questionário não serão afetados. + +### Excluindo Modelos de Questionário + +Para excluir completamente um modelo de Questionário, selecione-o na tabela de Questionários na visualização Todos os Questionários e clique em **Excluir Questionário**. Isso exclui permanentemente o modelo de Questionário e todas as respostas associadas de todas as implantações. Esta ação não pode ser desfeita. diff --git a/docs/content/asset_modelling/OS_questionnaires/_index.pt-br.md b/docs/content/asset_modelling/OS_questionnaires/_index.pt-br.md new file mode 100644 index 0000000000..fae824b25d --- /dev/null +++ b/docs/content/asset_modelling/OS_questionnaires/_index.pt-br.md @@ -0,0 +1,9 @@ +--- +title: Questionários +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.pt-br.md b/docs/content/asset_modelling/PRO_hierarchy/_index.pt-br.md new file mode 100644 index 0000000000..3a313ac7a9 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/_index.pt-br.md @@ -0,0 +1,11 @@ +--- +title: Hierarquia de Ativos +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.pt-br.md b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.pt-br.md new file mode 100644 index 0000000000..d632d85f2d --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/asset_hierarchy.pt-br.md @@ -0,0 +1,149 @@ +--- +title: Hierarquia de Ativos +description: DefectDojo Pro - Reformulação da Hierarquia de Produtos +audience: pro +weight: 1 +aliases: +- /pt-br/en/working_with_findings/organizing_engagements_tests/pro_assets_organizations +- /pt-br/asset_modelling/pro_hierarchy/assets_organizations +--- + +O DefectDojo Pro está estendendo as classes de objeto Produto/Tipo de Produto para oferecer maior flexibilidade ao modelo de dados. + +## Habilitando o recurso de Hierarquia + +As duas partes abaixo são separadas e controladas por meios diferentes. + +### Hierarquia de Ativos + +**Hierarquia de Ativos** habilita relações pai/filho entre Ativos. A hierarquia é visualizada e gerenciada a partir da aba **Produto** na navegação. + +A Hierarquia de Ativos está disponível de forma geral e ativa para toda instância, seja Cloud ou On-Premise. Não há nada a habilitar, e ela não está mais listada na página de Feature Flags. + +### Alterações de rótulo (opcional) + +**Alterações de rótulo** renomeia "Tipo de Produto" para "Organização" e "Produto" para "Ativo" em toda a UI. Esta é uma etapa separada da habilitação da hierarquia e pode ser feita ao mesmo tempo ou posteriormente. + +As alterações de rótulo estão ativas por padrão a partir da versão 3.0. Existem dois controles, cobrindo partes diferentes da aplicação: + +* **UI Pro** (a UI padrão): um superusuário alterna "Organization / Asset Relabeling" em **Settings > Feature Flags**, tanto em instâncias Cloud quanto On-Premise. Os novos rótulos aparecem no próximo carregamento de página. Veja [Feature Flags](/admin/feature_flags/pro__feature_flags/). +* **Páginas da UI Clássica e relatórios gerados**: seus rótulos e URLs vêm da configuração de implantação `DD_ENABLE_V3_ORGANIZATION_ASSET_RELABEL`, que é lida quando o DefectDojo é iniciado. No modelo on-premise, defina-a e reinicie o DefectDojo. No [DefectDojo Pro (Cloud)](/get_started/pro/cloud/), envie um e-mail para [support@defectdojo.com](mailto:support@defectdojo.com) com a URL da sua instância. + +Ambos vêm ativados por padrão, e o valor de Feature Flags foi originado a partir da configuração de implantação, portanto os dois concordam a menos que você altere um deles. Mantenha-os sincronizados se você também usar a UI Clássica, além da UI Pro. + +Observe que as alterações de rótulo são apenas cosméticas: os endpoints da API e os nomes de campo permanecem inalterados, portanto a automação existente continuará funcionando. + +## Alterações significativas + +* **Tipos de Produto** foram renomeados para "Organizações", e **Produtos** foram renomeados para "Ativos". A partir da versão 3.0, essa mudança de nome está ativa por padrão. Veja [Alterações de rótulo](#label-changes-optional) para os controles que a desativam. +* **Ativos** agora podem ter relações pai/filho entre si para subcategorizar ainda mais os componentes organizacionais. + +### Organizações + +Assim como os Tipos de Produto, as **Organizações** devem ser entendidas como uma categoria de nível superior. Você pode usá-las para separar as principais aplicações de software, departamentos ou funções de negócio da sua empresa. + +Por exemplo, você poderia criar uma Organização para diversos agrupamentos de repositórios: "Aplicação Principal", "Infraestrutura", "DevOps", "Analytics", "SDK" poderiam conter, cada uma, múltiplos repositórios de código. + +Tenha em mente que, para fins de relatório, é mais fácil combinar múltiplas Organizações em um único documento do que subdividir uma única Organização em documentos separados. Portanto, recomendamos configurar as Organizações no nível mais granular que fizer sentido para os relatórios da sua equipe. Por exemplo, não há necessidade de representar uma grande divisão de negócio como uma Organização se você pretende, principalmente, gerar relatórios sobre departamentos individuais dentro dessa divisão. + +### Ativos + +Os Ativos têm o objetivo de representar subdivisões das suas Organizações. No entanto, diferentemente dos Produtos, os Ativos podem ser aninhados e ter relações pai-filho entre si. + +## Exemplos de aninhamento de Ativos + +### Representação de branch no nível de Ativo + +Branches de desenvolvimento e de funcionalidades podem ser representados de várias formas; Engajamentos ou Testes separados são formas já existentes de representar a diferença entre seus branches de Produção, Dev e outras funcionalidades. + +Você também pode representar isso usando Ativos aninhados. Considere a seguinte árvore de Ativos: + +``` +Core Application [Organization] +└── webapp-frontend + ├── webapp-frontend/prod + └── webapp-frontend/dev + ├── webapp-frontend/dev/feature-a + └── webapp-frontend/dev/feature-b +``` + +Nesse ambiente, cada branch (`prod`, `dev`, `feature a`, `feature b`) poderia ter seus próprios Engajamentos e Testes, isolados dos demais Ativos, de modo que não deduplicam entre si. Essa configuração também pode facilitar a navegação, já que os nomes dos Ativos podem corresponder diretamente ao caminho no Git. + +### Mono-repo: componentes separados + +Se você usa um único repositório para todo o seu código, mas tem diferentes equipes contribuindo para diretórios dentro desse repositório, você pode configurar o aninhamento de Ativos para representar essa estrutura. + +``` +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 +``` + +Neste diagrama, cada elemento sob "Core Application" poderia ser registrado como um Ativo separado, com criticidade de negócio (veja: [Priority & Risk](/asset_modelling/pro_hierarchy/priority_sla/#prioritization-engines)), RBAC e Engajamentos e Testes correspondentes próprios. Você poderia continuar testando e armazenando resultados no Ativo pai (por exemplo, `webapp-backend`), mas também poderia executar testes isolados em um Ativo filho específico (por exemplo, `database`). + +### Testes de invasão: RBAC isolado + +Se você quiser armazenar resultados de testes de invasão dentro de um único ativo, mas não quiser que os testadores consigam visualizar os dados do ativo, você poderia criar ativos filhos para que cada grupo de teste envie seus resultados. + +``` +Core Application [Organization] +└── webapp-frontend [Parent Asset] + ├── Pen Test Group A + └── Pen Test Group B +``` + +Fundamentalmente, dar a um usuário acesso RBAC a um único Ativo Filho (por exemplo, `Pen Test Group A`) aqui não permite que ele visualize nenhum Achado de outros Ativos Filhos (por exemplo, `Pen Test Group B`), nem permite que ele visualize Achados no Ativo Pai (`webapp-frontend`). + +O Ativo Pai poderia conter Engajamentos representando resultados de CI/CD, Testes internos, dados históricos ou outros dados de Achados que você não deseja que terceiros consigam descobrir. Criar um Ativo Filho para resultados de testes específicos permite que sua equipe interna gere relatórios sobre esses resultados em combinação com o estado do Ativo pai. + +## Visualizando Ativos - Hierarquia + +Você pode visualizar a estrutura dos Ativos no DefectDojo e alterar as relações usando a opção Asset Hierarchy no menu. + +![image](images/asset_hierarchy.png) + +Abrir o Asset Hierarchy exibirá uma tabela com todos os seus Ativos, que pode ser filtrada. Selecionar um ou mais Ativos nessa tabela renderizará um diagrama de hierarquia. + +![image](images/asset_hierarchy_diagram.png) + +### Navegação no diagrama + +Os ícones no canto superior esquerdo do diagrama de hierarquia permitem que você aumente e diminua o zoom. Clicar e arrastar nesse diagrama permite rolar por ele. + +Cada Ativo é renderizado como um único nó nesse diagrama, que pode ser movido para fins de exibição. + +Os Ativos são conectados entre si por meio de caminhos rotulados, que representam o tipo de relação que cada um tem com o outro. Atualmente, `parent` é o único rótulo suportado. + +### Explorando nós de Ativo + +É possível interagir com cada nó de Ativo clicando nos botões azuis. Esses botões aparecem somente quando um nó de Ativo está selecionado (clicando no nó). + +![image](images/asset_hierarchy_node.png) + +* 👁️ (ícone de olho) leva você diretamente para a View de Ativo correspondente (anteriormente conhecida como View de Produto). +* ✏️ (ícone de lápis) abre um modal com o formulário Edit Asset (anteriormente conhecido como formulário Edit Product) +* ➕ (ícone de mais) permite adicionar um novo Ativo Filho a este Ativo. O Ativo não precisa estar visível no diagrama no momento, mas deve fazer parte da mesma Organização. +* ✥ (ícone de quatro setas) permite alterar o Ativo Pai do Ativo atualmente selecionado. +* 🗑️ (ícone de lixeira) permite remover a relação de Ativo pai de um Ativo. Este ícone só aparece se um Ativo já tiver um Pai. + +Se o seu diagrama exibir um Ativo com Ativos Pai não selecionados, você pode clicar no botão Load More para preencher o diagrama com o Ativo Pai (assim como os filhos desse Ativo Pai). + +![image](images/assets_loadmore.png) + +## Notas + +* Observe que os escopos de deduplicação não mudaram; os Ativos deduplicam Achados apenas dentro de si mesmos, e não consideram Achados em outros Ativos, independentemente das relações Pai/Filho. +* Os escopos de RBAC não mudaram nesse sistema; cada Ativo ainda é considerado um objeto individual para fins de atribuição de permissões. Nenhuma nova herança de RBAC foi criada. + * Conceder a um usuário acesso a uma Organização inteira ainda dará a esse usuário acesso a todos os Ativos contidos nessa Organização (assim como ocorre com os Tipos de Produto). + * Conceder a um usuário acesso a um único Ativo não dá a esse usuário acesso a nenhum Ativo Pai ou Filho relacionado, nem acesso à Organização. +* Não há limite para o número de relações Pai/Filho que podem ser criadas. Teoricamente, você poderia representar toda a estrutura de diretórios de um repositório usando Ativos separados, se quisesse. +* Relações cíclicas não são permitidas: Ativos Pai não podem ser Filhos de seus Ativos Filhos. diff --git a/docs/content/asset_modelling/PRO_hierarchy/priority_sla.pt-br.md b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.pt-br.md new file mode 100644 index 0000000000..ea5a9ca208 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/priority_sla.pt-br.md @@ -0,0 +1,236 @@ +--- +title: Atribuir Prioridade, Risco e SLAs +description: Como o DefectDojo classifica seus Achados +weight: 1 +audience: pro +aliases: +- /pt-br/en/working_with_findings/finding_priority +- /pt-br/en/working_with_findings/priority_adjustments +--- + +![image](images/pro_finding_priority.png) + +Um gerenciamento eficaz de vulnerabilidades baseado em risco requer uma abordagem que considere tanto o contexto de negócio quanto a explorabilidade técnica. Usando o recurso de Prioridade e Risco do DefectDojo Pro, os usuários podem organizar automaticamente os Achados em um contexto significativo, garantindo que as vulnerabilidades de alto impacto sejam tratadas primeiro. + +**Prioridade** é uma classificação numérica calculada, aplicada a todos os Achados da sua instância do DefectDojo. Ela permite entender rapidamente as vulnerabilidades em contexto, especialmente em organizações grandes que supervisionam as necessidades de segurança de muitos Achados e/ou Produtos. + +**Risco** é um sistema de classificação de 4 níveis que leva em conta a explorabilidade de um Achado em maior grau. Trata-se de uma versão menos granular e mais voltada ao 'nível executivo' da Prioridade. + +![image](images/pro_risk_example.png) + +Os valores de Prioridade e Risco podem ser usados com outros filtros para comparar Achados em qualquer contexto, como: + +* dentro de um único Produto, Engajamento ou Teste +* globalmente em todos os Produtos do DefectDojo +* entre alguns Produtos específicos + +Aplicar Prioridade e Risco aos Achados ajuda sua equipe a responder às vulnerabilidades mais relevantes da sua organização, além de fornecer uma estrutura que auxilia na conformidade com padrões regulatórios. + + +Saiba mais sobre Prioridade e Risco no Office Hours de maio de 2025 da DefectDojo, Inc.: + + + +## Como a Prioridade e o Risco são calculados +O intervalo de valores de Prioridade vai de 0 a 1150. Quanto maior o número, maior a urgência do Achado para triagem ou remediação. + +De forma semelhante à Severidade, o Risco é pontuado de Baixo -> Médio -> Requer Ação -> Urgente. **Risco** leva em conta os campos de Prioridade e, por isso, pode ser diferente da Severidade reportada por uma ferramenta. + +![image](images/priority-overview.png) + +## Campos de Prioridade: Nível de Produto + +Cada Produto no DefectDojo possui metadados que rastreiam a criticidade de negócio e os fatores de risco. Esses metadados são usados para ajudar a calcular a Prioridade e o Risco de quaisquer Achados associados. + +Todos esses campos de metadados podem ser definidos no formulário **Editar Produto** de um determinado Produto. + +![image](images/priority_edit_product.png) + +* **Criticidade** pode ser definida com qualquer um dos valores Nenhuma, Muito Baixa, Baixa, Média, Alta ou Muito Alta. Criticidade é um campo subjetivo, então, ao atribuí-lo, considere como o Produto se compara a outros Produtos da sua organização. +* **Registros de Usuários** é uma estimativa numérica de registros de usuários em um banco de dados (ou em um sistema que pode acessar esse banco de dados). +* **Receita** é uma estimativa numérica da receita anual do Produto. Para calcular a Prioridade, o DefectDojo calculará uma porcentagem comparando a receita deste Produto com a soma de todos os Produtos dentro do Tipo de Produto. + +Não é possível definir um tipo de moeda no DefectDojo, então certifique-se de que todas as suas estimativas de Receita tenham a mesma denominação monetária. ("50000" pode significar 50.000 dólares americanos ou ¥50.000 ienes japoneses - a denominação não importa, desde que todos os seus Produtos tenham a receita calculada na mesma moeda). +* **Público Externo** é um valor verdadeiro/falso - defina como Verdadeiro se este Produto puder ser acessado por um público externo. Por exemplo, clientes, usuários ou qualquer pessoa fora da sua organização. +* **Acessível pela Internet** é um valor verdadeiro/falso. Se este Produto puder se conectar à internet aberta, você deve definir esse valor como Verdadeiro. + +A Prioridade é um cálculo "relativo", destinado a comparar diferentes Produtos dentro da sua instância do DefectDojo. No fim das contas, cabe à sua organização decidir como esses filtros são definidos. Esses valores devem ser o mais precisos possível, mas o objetivo principal é destacar seus Produtos-chave para que você possa priorizar vulnerabilidades de acordo com as políticas da sua organização - portanto, esses campos não precisam necessariamente estar definidos com perfeição. + +## Campos de Prioridade: Nível de Achado + +Os Achados dentro de um Produto podem ter metadados adicionais que ajustam ainda mais o nível de Prioridade e Risco do Achado: + +* Se o Achado tem ou não uma **Pontuação EPSS** - isso é adicionado automaticamente aos Achados e mantido atualizado para usuários Pro. A **Pontuação EPSS** é o campo que contribui para a Pontuação de Prioridade — o **Percentil EPSS** é registrado no Achado apenas para referência, mas não alimenta diretamente o cálculo. +* Quantos Endpoints do Produto são afetados por este Achado +* Se um Achado está ou não Em Revisão +* Se o Achado está ou não na base KEV (Known Exploited Vulnerabilities), verificada pelo DefectDojo regularmente +* A Severidade reportada pela ferramenta para um Achado (Informativa, Baixo, Médio, Alto, Crítica) + +#### Pontuação EPSS vs. Percentil EPSS + +Dois Achados que parecem idênticos nos fatores visíveis (Severidade, Criticidade de Negócio, Acessível pela Internet, Exploit Disponível) ainda podem acabar com Pontuações de Prioridade diferentes se suas **Pontuações EPSS** forem diferentes. Isso é esperado: a Pontuação EPSS é uma entrada contextual do cálculo. + +O Percentil EPSS é exibido no Achado para contexto, mas não é utilizado no cálculo da Pontuação de Prioridade. Se você precisar comparar dois Achados para entender uma diferença na Pontuação de Prioridade, observe os valores da Pontuação EPSS, não os valores do Percentil. + +O peso exato que a Pontuação EPSS (e os outros fatores) tem no cálculo da Pontuação de Prioridade não é divulgado intencionalmente. Se você precisar influenciar o quanto a Pontuação EPSS afeta a pontuação no seu ambiente, ajuste o controle deslizante de **Explorabilidade** no seu [Mecanismo de Priorização](#prioritization-engines). + + +## Cálculo de Risco do Achado + +![image](images/risk_table.png) + +A coluna Risco em uma tabela de Achados é outra forma de priorizar rapidamente os Achados. O Risco é calculado usando o nível de Prioridade de um Achado, mas também leva em conta a explorabilidade do Achado em maior grau. Trata-se de uma versão menos granular e mais voltada ao 'nível executivo' da Prioridade. + +Os quatro níveis de Risco atribuíveis são: + +![image](images/pro_risk_levels.png) + +O EPSS / a explorabilidade de um Achado é muito mais enfatizado no cálculo de Risco. Como resultado, um Achado pode ter tanto uma prioridade alta quanto um valor de risco baixo. + +O cálculo de Risco em si atualmente não pode ser ajustado diretamente. No entanto, se a [Inteligência de Ameaças](/asset_modelling/pro_hierarchy/threat_intelligence/) estiver habilitada, o **Piso de Risco de Exploração Ativa** permite controlar o resultado para o caso mais importante: um Achado confirmado como explorado ativamente é elevado a, no mínimo, uma faixa de Risco que você escolher, em vez de permanecer em uma faixa baixa só porque sua severidade base é Baixa. Por padrão, vem definido como **Requer Ação**, e cada Mecanismo de Priorização pode elevá-lo, reduzi-lo ou desativá-lo. Consulte [o Piso de Risco de Exploração Ativa](/asset_modelling/pro_hierarchy/threat_intelligence/#the-actively-exploited-risk-floor). + +## Painel de Insights de Prioridade + +Os usuários podem ter uma visão de nível executivo da Prioridade e do Risco em seu ambiente usando o Painel de Insights de Prioridade (Metrics > Priority Insights na barra lateral) + +![image](images/priority_dashboard.png) + +Esse painel pode ser filtrado para incluir Produtos específicos ou intervalos de datas. Como os demais painéis do Pro, este painel pode ser exportado do DefectDojo como PDF para gerar um relatório rapidamente. + +## Definindo Prioridade e Risco para Conformidade Regulatória + +Esta é uma lista não exaustiva de padrões regulatórios que exigem especificamente métodos de priorização de vulnerabilidades: + +* A conformidade com a [SOX (Sarbanes-Oxley Act](https://www.sarbanes-oxley-act.com/)) exige priorização baseada em receita para sistemas que impactam dados financeiros. No DefectDojo, a receita de um sistema pode ser inserida no nível do Produto. +* A conformidade com [PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/) exige priorização baseada em classificações de risco e criticidade para ambientes de dados de titulares de cartão. A Criticidade de Negócio e o Público Externo podem ser definidos no nível do Produto, enquanto a sincronização de EPSS no nível de Achado do DefectDojo apoia a abordagem baseada em risco do PCI. +* A [NIST SP 800-40](https://csrc.nist.gov/pubs/sp/800/40/r4/final) é um guia de manutenção preventiva que exige especificamente a priorização de vulnerabilidades com base em impacto de negócio, criticidade do produto e fatores de acessibilidade pela internet. Todos esses fatores podem ser definidos no nível de Produto do DefectDojo. +* A conformidade com o Controle A.12.6.1 da [ISO 27001/27002](https://www.iso.org/standard/27001) exige a gestão de vulnerabilidades técnicas com Prioridade baseada em avaliação de risco. +* O [Artigo 32 do GDPR](https://gdpr-info.eu/art-32-gdpr/) exige medidas de segurança baseadas em risco - os registros de usuários e os sinalizadores de público externo no nível do Produto podem ajudar a priorizar sistemas da sua organização que processam dados pessoais. +* A conformidade com [FISMA/FedRAMP](https://help.fedramp.gov/hc/en-us) exige monitoramento contínuo e remediação de vulnerabilidades baseada em risco. + +Os cálculos de Prioridade e Risco do DefectDojo Pro podem ser ajustados, permitindo adaptar o DefectDojo Pro aos padrões internos da sua organização para Prioridade e Risco de Achados. + +## Mecanismos de Priorização + +Assim como as configurações de SLA, os Mecanismos de Priorização permitem definir as regras que determinam como a Prioridade e o Risco são calculados. + +![image](images/priority_default.png) + +O DefectDojo vem com um Mecanismo de Priorização integrado, aplicado a todos os Produtos. No entanto, você pode editar esse Mecanismo de Priorização para alterar o peso dos multiplicadores de **Achado** e **Produto**, o que ajustará como a Prioridade e o Risco dos Achados são atribuídos. + +### Multiplicadores de Achado + +Oito fatores contextuais impactam a pontuação de Prioridade de um Achado. Três deles são específicos do Achado, e os outros cinco são atribuídos com base no Produto ao qual o Achado pertence. + +Você pode ajustar seu Mecanismo de Priorização controlando como esses fatores são aplicados ao cálculo final. + +![image](images/priority_sliders.png) + +Selecione um fator clicando no botão; o controle deslizante permite controlar a porcentagem com que um determinado fator é aplicado. Conforme você ajusta o controle deslizante, verá os limiares de Risco mudarem como resultado. + +#### Multiplicadores no Nível do Achado + +* **Severidade** - o nível de Severidade de um Achado +* **Explorabilidade** - o KEV e/ou a pontuação EPSS de um Achado +* **Endpoints** - a quantidade de Endpoints associados a um Achado + +#### Multiplicadores no Nível do Produto + +* **Criticidade de Negócio** - a Criticidade de Negócio do Produto relacionado (Nenhuma, Muito Baixa, Baixa, Média, Alta ou Muito Alta) +* **Registros de Usuários** - a contagem de Registros de Usuários do Produto relacionado +* **Receita** - a receita do Produto relacionado, em relação à receita total do Tipo de Produto +* **Público Externo** - se o Produto relacionado tem ou não um público externo +* **Acessível pela Internet** - se o Produto relacionado é ou não acessível pela internet + +### Limiares de Risco + +Com base no ajuste do Mecanismo de Priorização, o DefectDojo recomendará automaticamente Limiares de Risco. No entanto, esses limiares também podem ser ajustados e definidos com os valores que você considerar apropriados. + +![image](images/risk_threshold.png) + +## Criando Novos Mecanismos de Priorização + +Você pode usar vários Mecanismos de Priorização, cada um podendo ser atribuído a Produtos diferentes. + +![image](images/priority_engine_new.png) + +Criar um novo Mecanismo de Priorização abrirá o formulário do Mecanismo de Priorização. Depois que esse formulário for enviado, um novo Mecanismo de Priorização será adicionado à tabela. + +## Atribuindo Mecanismos de Priorização a Produtos + +Cada Produto pode ter um Mecanismo de Priorização em uso, definido no formulário **Editar Produto** de um determinado Produto. + +![image](images/priority_chooseengine.png) + +Observe que, quando o Mecanismo de Priorização de um Produto é alterado, ou quando um Mecanismo de Priorização é atualizado, o Mecanismo de Priorização do Produto ou o próprio Mecanismo de Priorização ficará "Bloqueado" até que o cálculo de priorização seja concluído. + +Cada Produto no DefectDojo pode ter sua própria configuração de Acordo de Nível de Serviço (SLA), que representa os dias que sua organização tem para remediar ou, de alguma forma, gerenciar um Achado. + +O SLA pode ser definido com base na **[Severidade do Achado](/asset_modelling/os_hierarchy/product_hierarchy/#findings)** ou no **[Risco do Achado](/asset_modelling/pro_hierarchy/priority_sla/)** (no DefectDojo Pro). + +![image](images/sla_multiple.png) + +Os SLAs aplicam uma contagem regressiva de dias a um Achado com base no dia em que o Achado foi criado no DefectDojo. Se um Achado não for Fechado dentro da contagem regressiva, ele será rotulado como em violação de SLA. + +## Trabalhando com SLAs + +Você pode usar os SLAs como uma forma de representar as políticas de remediação da sua organização. Também pode usá-los para priorizar os Achados mais críticos e ativos há mais tempo na sua instância do DefectDojo. + +* Você pode ordenar ou filtrar tabelas de Achados por dias de SLA. +* As violações de SLA podem ser configuradas para disparar [Notificações](/admin/notifications/about_notifications/) para os usuários do DefectDojo atribuídos ao Produto relacionado. +* No **DefectDojo Pro**, o desempenho do SLA também é acompanhado nos Painéis de Métricas de [Insights Executivos e Remediação](/metrics_reports/pro_metrics/pro__overview/). +* A conformidade com o SLA também pode ser exibida em um [painel personalizado](/metrics_reports/dashboards/custom-dashboards/) no **DefectDojo Pro** - por exemplo, com um widget de SLA Burndown ou de Contagem filtrada. + +### Status Mitigado Dentro do SLA + +Se um Achado for Mitigado com sucesso até o prazo do SLA, o Achado registrará uma marca de verificação verde ✅ na coluna Mitigado Dentro do SLA. + +![image](images/sla_mitigated_within.png) + +Se um Achado foi Mitigado, mas não antes da violação do SLA, o Achado registrará um X vermelho ❌ na coluna Mitigado Dentro do SLA. + +### Violação de SLAs + +Quando o SLA de um determinado Achado é violado (o Achado não é Fechado dentro do prazo do SLA), a marca de verificação verde ✅ muda para um X vermelho ❌. O SLA continuará sendo acompanhado com um número negativo, representando por quantos dias o SLA foi violado. + +![image](images/sla_breached.png) + +## Gerenciando Configurações de SLA (Pro) + +No DefectDojo Pro, uma ou mais Configurações de SLA são gerenciadas na seção **Configuration > Service Level Agreements** da barra lateral. Você pode criar um **Novo Acordo de Nível de Serviço** ou trabalhar com configurações de SLA existentes na página **Todos os Acordos de Nível de Serviço**. + +![image](images/pro_sla_risk.png) + +As Configurações de SLA só podem ser editadas por Superusuários ou por um usuário com a [Permissão de Configuração](/admin/user_management/user_permission_chart/#configuration-permission-chart) correspondente. + +### Configurando o SLA + +As configurações de SLA contêm os dias atribuídos a cada valor de **Severidade** ou **Risco** do DefectDojo. + +![image](images/pro_new_sla.png) + +Cada Acordo de Nível de Serviço pode ter um nome exclusivo, além de uma descrição opcional. + +**Reiniciar SLA na Reativação do Achado**: se habilitada, essa opção reiniciará o SLA do zero quando um Achado for Reaberto. Caso contrário, o SLA será baseado na data em que o Achado foi criado. + +Ao editar um SLA, você pode escolher se esse SLA usará **Severidade** ou **Risco** como referência para atribuir os Dias para Remediação. Isso é feito selecionando a opção correspondente na seção **Tipo de Configuração de Nível de Serviço** do formulário. + +A partir daí, você pode definir o número de dias permitido para cada nível de **Severidade** ou **Risco**. Você também pode aplicar os SLAs seletivamente; desmarcando a opção **Enforce ___ Finding Days**, você pode ignorar o cálculo de SLA para esses níveis de Severidade ou Risco. + +## Aplicar uma Configuração de SLA a um Produto (Pro) + +Produtos recém-criados no DefectDojo sempre aplicarão a **Configuração de SLA Padrão**, que pode ser definida com valores diferentes, se desejado. + +Se você tiver configurações de SLA, poderá escolher qual delas será aplicada ao seu Produto no formulário **Editar Produto**. + +![image](images/pro_sla_product.png) + +### Recálculo de SLA + +Depois que um novo SLA for selecionado para um Produto, todos os SLAs dos Achados associados precisarão ser recalculados pelo DefectDojo. Enquanto esse processo estiver em execução, o SLA de um Produto não poderá ser alterado. + +## Notas sobre SLAs + +* Os SLAs podem, opcionalmente, ser reiniciados quando um Achado com [Risco aceito](/triage_findings/findings_workflows/pro__risk_acceptance/) é reativado. Isso é definido ao criar a Aceitação de risco, configurando o campo **Reiniciar SLA Expirado**. +* Reimportar um Achado não reinicia o SLA - os SLAs são sempre calculados a partir do momento em que um Achado foi detectado pela primeira vez, a menos que a opção **Reiniciar SLA na Reativação do Achado** esteja habilitada. +* A expiração da Aceitação de risco ou a reativação de um Achado Fechado são as únicas formas de redefinir ou recalcular um SLA de um Achado depois de criado (sem alterar a configuração de SLA do Produto). diff --git a/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.pt-br.md b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.pt-br.md new file mode 100644 index 0000000000..cb77936ed8 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/product_health_grade.pt-br.md @@ -0,0 +1,32 @@ +--- +title: Nota de Integridade do Produto +description: Como o DefectDojo calcula a Nota de Integridade do Produto +aliases: +- /pt-br/en/working_with_findings/organizing_engagements_tests/product_health_grade +--- + +O DefectDojo pode calcular uma nota para seus Produtos com base na quantidade de Achados neles contidos. As notas variam de A a F. + +Observe que apenas Achados Ativos e Verificados contribuem para a Nota do Produto - Achados não verificados não têm impacto. + +## Cálculo da Nota do Produto + +Toda Nota de Produto começa em 100 (sem Achados). + +O cálculo da nota começa observando o nível de **Severidade** mais alto de um Achado em um Produto, reduzindo a Integridade do Produto a um nível base. + +| **Nível de Severidade Mais Alto de um Achado** | **Nota Máxima** | +| --- | --- | +| **Crítica** | **40** | +| **Alto** | **60** | +| **Médio** | **80** | +| **Baixo** | **95** | + +Em seguida, mais pontos são deduzidos da Nota para cada Achado adicional: + +| **Nível de Severidade de um Achado adicional** | **Redução na Nota** | +| --- | --- | +| **Crítica** | **5** | +| **Alto** | **3** | +| **Médio** | **2** | +| **Baixo** | **1** | diff --git a/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.pt-br.md b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.pt-br.md new file mode 100644 index 0000000000..cda2902427 --- /dev/null +++ b/docs/content/asset_modelling/PRO_hierarchy/threat_intelligence.pt-br.md @@ -0,0 +1,128 @@ +--- +title: Inteligência de Ameaças +description: Evidências de exploração e ameaças como entrada de primeira classe para + Prioridade e Risco +weight: 2 +audience: pro +--- + +O DefectDojo Pro enriquece seus achados com **inteligência de ameaças dedicada** — disponibilidade de exploit, exploração conhecida e atividade de agentes de ameaça — e leva isso em conta na Prioridade e no Risco. Isso vai muito além do EPSS e do sinalizador KEV da CISA. + +## O que você obtém + +Todo achado com um CVE é comparado, todas as noites, com um feed de inteligência selecionado, construído a partir do CISA KEV, Metasploit, Exploit-DB, templates do Nuclei e rastreamento de provas de conceito públicas. Quando há evidência de exploração, o achado exibe um card de **Inteligência de Ameaças**: + +* um selo de **maturidade de exploração** — *Nenhum → PoC → Armado → Ativo em ambiente real* +* uma **pontuação de ameaça** (0–100) +* **chips de evidência que linkam para o comprovante** — a entrada no KEV (com sua data de listagem), + uso em ransomware, um módulo do Metasploit, uma entrada no Exploit-DB, um template do Nuclei e + repositórios públicos de prova de conceito +* uma linha em linguagem simples explicando **por que** a prioridade do achado aumentou + +Além do card, essa inteligência é uma camada funcional em todo o aplicativo: + +* uma **coluna Maturidade de Exploração** na lista de achados — ordenável e filtrável + (por exemplo, "somente Armado ou Ativo") +* um bloco **"Urgente e Ativamente Explorado"** no painel de Layout de Prioridade, contabilizando + achados ativos de risco Urgente com exploração em ambiente real — ao clicar, abre a + lista exata de achados filtrados +* um **evento de notificação** (`threat_intel_alert`) quando o CVE de um achado existente ganha nova + evidência de exploração, como entrar no CISA KEV ou ganhar um módulo do Metasploit. Apenas atualizações + para cima — evidências que silenciosamente perdem validade nunca geram notificação. + +## Como isso muda a pontuação + +O mecanismo de Prioridade já combinava severidade, contexto de negócio e uma "pontuação externa" +construída a partir de EPSS + KEV. A inteligência de ameaças generaliza essa pontuação externa: cada tipo +de evidência de exploração atua como um piso na escala do EPSS. + +| Evidência | Piso de Prioridade (equivalente a EPSS) | +|---|---| +| Exploração ativa + ransomware/agente nomeado | 45% | +| No CISA KEV **e** usado em ransomware | 30% | +| No KEV ou explorado em ambiente real | 20% | +| Exploit público armado (Metasploit / Exploit-DB) | 15% | +| Existe template de detecção do Nuclei | 12% | +| Apenas prova de conceito pública | 8% | +| Sem evidência de exploração | sem alteração | + +A pontuação externa do achado é o **maior** valor entre o derivado do EPSS e o piso de evidência mais alto +acima — portanto, a inteligência só *aumenta* uma pontuação, nunca a reduz, e um achado cujo EPSS já +exceda o piso não é afetado. O já conhecido **escalar de pontuação externa** por tipo de produto, nas +configurações do seu Mecanismo de Priorização, dimensiona essa contribuição exatamente como sempre +dimensionou o EPSS/KEV. + +### O piso de Risco de exploração ativa + +A tabela acima aumenta a **Prioridade**, mas proporcionalmente à severidade base de um achado. Isso tem +uma consequência que vale a pena declarar claramente: um achado de severidade Baixa com um CVE que está +sendo explorado em ambiente real recebe apenas um pequeno aumento absoluto, e ainda pode permanecer em +uma faixa de **Risco** baixa. A maioria das equipes considera isso errado — "ativamente explorado" nunca +deveria ser classificado como Baixo. + +Por isso, existe uma segunda regra, categórica. Quando a inteligência de ameaças reporta **exploração +ativa em ambiente real**, a Prioridade do achado é elevada a, no mínimo, o nível de uma faixa de Risco +configurada, independentemente do que o cálculo ponderado sozinho produziria. Por padrão, vem definido +como **Requer Ação**; cada tipo de produto pode elevá-lo para Urgente, reduzi-lo ou desativá-lo, nas +configurações do Mecanismo de Priorização, em *Piso de Risco de Exploração Ativa*. + +O piso só eleva — nunca move um achado para baixo, e um achado que já pontua mais alto por conta própria +permanece inalterado. Como isso se aplica à Prioridade, a faixa de Risco e a pontuação de Risco decorrem +automaticamente dela, de modo que toda lista, filtro, gráfico e cálculo de SLA enxergam o mesmo número +consistente. + +## Achados sem CVE + +A inteligência de ameaças é correlacionada por CVE. Muitos achados — a maioria dos resultados de SAST, +segredos, configurações incorretas, regras personalizadas — não têm CVE, e não existe inteligência de +ameaças por instância de vulnerabilidade para eles em lugar nenhum (isso vale para todos os fornecedores, +não só o DefectDojo). Esses achados: + +* mantêm sua Prioridade e Risco atuais **exatos** — o recurso nunca reduz uma pontuação +* ainda são priorizados por todas as outras entradas do mecanismo (severidade, criticidade de negócio, + exposição, e assim por diante) +* exibem "Nenhuma inteligência de ameaças disponível — este achado não tem CVE para correlacionar" no + card, diferente de um achado com CVE que simplesmente ainda não tem exploit conhecido + +Uma consequência honesta: em uma fila mista, à medida que achados com CVE ganham evidência de exploração, +os achados sem CVE caem em classificação *relativa*, mesmo que sua pontuação permaneça inalterada. + +## Confiança e estabilidade da pontuação + +* **Inteligência assinada.** Todo pacote noturno é assinado criptograficamente pelo DefectDojo; sua + instância recusa dados adulterados ou não assinados. Instâncias air-gapped importam o mesmo pacote + assinado com uma etapa de verificação offline. +* **Sem oscilação de pontuação.** As atualizações de evidência são aplicadas na mesma noite em que + surgem. Se uma fonte *perde* uma evidência, as pontuações permanecem estáveis por uma janela de + estabilidade (14 dias por padrão) — uma falha pontual no feed nunca desestabiliza sua fila, e + desescaladas genuínas se acomodam silenciosamente após a janela. +* **Suporte a air-gapped.** O pacote diário (incluindo dados de EPSS) pode ser transferido e importado + offline, para que instâncias isoladas recebam o mesmo enriquecimento. + +## Implantações self-hosted + +Instâncias do DefectDojo Cloud não precisam de nenhuma configuração. Instâncias self-hosted têm três +opções: + +* **Conectado (padrão).** A instância busca o pacote assinado todas as noites em `intel.defectdojo.com` + via HTTPS. Esse é um destino que nenhum outro recurso do DefectDojo utiliza, então geralmente precisa + ser liberado explicitamente: abra a porta 443 de saída para esse host e, no Kubernetes, adicione-o à + sua política de rede de egress. Observe que a busca é executada no **worker do Celery**, não no pod + web, então as configurações de proxy também precisam alcançar essa carga de trabalho. +* **Espelho interno.** Aponte `DD_THREAT_INTEL_BUNDLE_URL` (e as URLs correspondentes de digest e + assinatura) para um local dentro da sua rede que você mesmo sincroniza. A verificação de assinatura + continua se aplicando, então um espelho não pode alterar os dados. +* **Air-gapped.** Transfira o pacote e sua assinatura manualmente e importe-os com + `manage.py load_threat_intel_bundle --file `. A assinatura é verificada na importação. + +Se a instância não conseguir acessar o feed, o recurso falha de forma segura (fail closed): a execução é +registrada como falha, e suas pontuações e evidências existentes permanecem exatamente como estavam. Nada +se degrada, exceto a atualidade da inteligência. + +## Habilitando o recurso + +O recurso vem desativado por padrão. Os administradores podem habilitá-lo diretamente ou, primeiro, +executá-lo em **modo shadow** — que calcula as pontuações que seriam aplicadas sem alterar nada em +produção e produz um relatório de divergência mostrando exatamente quais achados mudariam — antes de +ativá-lo de fato. Entre em contato com o suporte ou consulte o runbook de operações para a implantação +recomendada em instâncias grandes. diff --git a/docs/content/asset_modelling/PRO_surveys/PRO__surveys.pt-br.md b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.pt-br.md new file mode 100644 index 0000000000..5b885ddcea --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/PRO__surveys.pt-br.md @@ -0,0 +1,147 @@ +--- +title: Pesquisas +description: Entendendo as Pesquisas no DefectDojo Pro +audience: pro +weight: 2 +--- + +No DefectDojo, um modelo de Pesquisa é um conjunto reutilizável de Perguntas que serve para coletar informações de desenvolvedores, equipes e partes interessadas internas e externas. Eles podem ser usados para reunir informações antes do início do trabalho, garantir alinhamento entre indivíduos e equipes à medida que o trabalho avança, e permitir uma análise retrospectiva após a conclusão do trabalho. + +No DefectDojo, um sistema de Pesquisas é composto por três componentes: +- **Modelos de Pesquisa**, que agrupam e ordenam as Perguntas. +- **Implantações de Pesquisa**, que são instâncias ativas que coletam respostas. +- **Respostas**, que são as respostas enviadas pelos Usuários. + +Criar um modelo de Pesquisa não o torna automaticamente disponível para respostas. Para coletar respostas, um modelo de Pesquisa precisa ser implantado. + +## Permissões + +A seção Surveys na barra lateral só é visível para Usuários com status de Superusuário, e somente Superusuários podem criar modelos de Pesquisa, criar Perguntas e implantar Pesquisas. + +Usuários sem status de Superusuário ainda podem responder a Pesquisas que sejam compartilhadas com eles, mas não podem criá-las ou gerenciá-las, nem às Perguntas associadas. + +## Acessando Pesquisas e Perguntas + +Usuários com status de Superusuário podem acessar Pesquisas e Perguntas na barra lateral clicando na opção **Surveys**. O submenu oferece acesso a **All Surveys** e **All Questions**, além da opção de criar novas Pesquisas e Perguntas. + +![image](images/pq_ss1.png) + +### Acessando Pesquisas + +A visualização All Surveys inclui uma tabela contendo todos os modelos de Pesquisa, incluindo seu ID, nome, descrição e status ativo. A tabela pode ser filtrada usando palavras-chave, e pode ser reorganizada clicando no cabeçalho de cada coluna. + +### Acessando Perguntas + +A visualização All Questions inclui uma tabela de Perguntas que podem ser adicionadas a uma Pesquisa. A tabela pode ser filtrada usando palavras-chave, e pode ser reorganizada clicando no cabeçalho de cada coluna. + +## Gerenciando Modelos de Pesquisa + +### Criar Modelos de Pesquisa + +Os modelos de Pesquisa podem ser criados clicando em **New Survey** na barra lateral, ou clicando no botão **New Survey** no topo da visualização All Surveys. + +![image](images/pq_ss2.png) + +O modelo de Pesquisa precisa receber um nome e uma descrição, e ter pelo menos uma Pergunta escolhida no menu suspenso antes de ser criado. + +#### Adicionar Perguntas a um Modelo de Pesquisa Já Existente + +Para adicionar Perguntas a um modelo de Pesquisa já existente, clique no ícone de kebab ⋮ à esquerda da Pesquisa desejada, clique em **Edit Survey**, selecione quaisquer novas Perguntas a serem adicionadas à Pesquisa no menu suspenso e, em seguida, clique em **Submit**. + +Como boa prática, recomenda-se fortemente evitar modificar ou adicionar Perguntas a um modelo de Pesquisa enquanto ele possui implantações ativas. Adicionar novas Perguntas não afetará as Respostas existentes, mas essas Respostas terão sido enviadas sem responder às Perguntas recém-adicionadas, o que pode resultar em dados incompletos. + +### Criar Perguntas + +Assim como os modelos de Pesquisa, as Perguntas podem ser criadas clicando em **New Question** na barra lateral, ou clicando no botão **New Question** no topo da visualização All Questions. + +#### Tipos de Pergunta + +Ao criar uma nova Pergunta, ela pode ser formatada como uma pergunta baseada em texto ou como uma pergunta de múltipla escolha, selecionando **Text Question** ou **Choice Question** no topo da visualização New Question. + +![image](images/pq_ss3.png) + +#### Ordem das Perguntas + +Determine a ordem de uma Pergunta atribuindo a ela um número de ordem. Por exemplo, se uma Pergunta tiver 1 no campo Order, essa Pergunta aparecerá acima de uma Pergunta com 2 no campo Order. + +#### Respostas Opcionais + +Tanto as perguntas baseadas em texto quanto as de múltipla escolha podem ser marcadas como **Optional** clicando na caixa de seleção correspondente. + +#### Permitindo Múltiplas Respostas + +Um número ilimitado de respostas possíveis pode ser adicionado a uma pergunta de múltipla escolha. Clicar na caixa de seleção **Allow Multiple Selections** permite que múltiplas respostas sejam selecionadas (disponível apenas para perguntas de múltipla escolha). + +### Editando Perguntas + +Para alterar uma Pergunta, navegue até a visualização All Questions, clique no ícone de kebab ⋮ à esquerda da Pergunta a ser alterada, clique em Edit Question, faça a alteração desejada e finalize a alteração clicando em Submit. As Perguntas não podem ser excluídas. + +![image](images/pq_ss4.png) + +É importante evitar editar Perguntas que fazem parte de Questionários ativos ou adicionar Perguntas a Questionários ativos. Fazer isso não afetará nenhuma resposta coletada anteriormente, mas pode resultar em dados incompletos ou não confiáveis. + +## Implantando Pesquisas + +Depois que um modelo de Pesquisa é criado com sucesso, implantar uma Pesquisa cria uma instância ativa que aceita respostas. + +Para implantar uma Pesquisa, navegue até a visualização All Surveys, clique no ícone de kebab ⋮ à esquerda da Pesquisa a ser implantada, clique em **Open Survey**, defina a data de expiração e clique em Submit. + +Se você quiser implantar a mesma Pesquisa novamente, siga o mesmo processo. Todas as implantações aparecerão na tabela Open Survey Instances na visualização da Pesquisa, e podem ser distinguidas por seu ID, horário de criação e data de expiração. + +![image](images/pq_ss10.png) + +Uma Pesquisa se encerrará na data escolhida, no mesmo horário em que foi implantada. Por exemplo, se você implantar uma Pesquisa às 8h00 do dia 1º de fevereiro de 2026 e agendar seu encerramento para 1º de março de 2026, a pesquisa se encerrará às 8h00 da manhã de 1º de março de 2026. + +Depois que uma Pesquisa é aberta, sua data e horário de expiração não podem ser alterados. Se um prazo diferente for necessário, uma nova implantação precisa ser criada. + +Depois que uma data de expiração passa, não será mais possível enviar respostas para aquela implantação da Pesquisa, mas a implantação continuará aparecendo na tabela Open Survey Instances na visualização daquela Pesquisa. + +#### Compartilhando uma Pesquisa + +Depois que uma Pesquisa é implantada, ela pode ser compartilhada com outros Usuários clicando no ícone ↗ à esquerda da Pesquisa na tabela Open Survey Instances na visualização do modelo de Pesquisa. Isso revelará um link exclusivo daquela implantação, que pode ser copiado e compartilhado com os destinatários pretendidos. + +![image](images/pq_ss5.png) + +![image](images/pq_ss9.png) + +#### Encerrando uma Pesquisa + +Para encerrar uma Pesquisa, clique no **X** vermelho à esquerda da Pesquisa na tabela Open Survey Instances na visualização do modelo de Pesquisa. + +![image](images/pq_ss13.png) + +Conforme observado na seção Responses mais adiante, isso apenas impedirá o envio de novas respostas. As Respostas enviadas anteriormente permanecerão visíveis na tabela Responses na parte inferior da visualização do modelo de Pesquisa. + +## Respondendo a Pesquisas + +Para responder a uma Pesquisa, os não Superusuários precisam ter o link compartilhado diretamente com eles, seguindo as instruções na seção [Compartilhando uma Pesquisa](#sharing-a-survey) acima. Os Superusuários também podem responder usando o mesmo link. + +#### Habilitando Respostas Anônimas + +Por padrão, as Pesquisas só são acessíveis a Usuários do DefectDojo. Para permitir que partes externas respondam a Pesquisas do DefectDojo, certifique-se de que a opção **Enable Anonymous Survey Responses** esteja ativada em **System Settings**, encontrada em **Settings > System** na barra lateral (dentro do submenu **Pro Settings** em instâncias que ainda utilizam o layout de menu anterior). + +![image](images/pq_ss6.png) + +As respostas externas aparecerão como anônimas porque não há um ID de usuário do DefectDojo associado à resposta. + +Se o escopo de uma Pesquisa incluir Usuários tanto internos quanto externos, especifique o nome do Engajamento na descrição no momento da criação, o que permitirá a filtragem dos resultados. + +![image](images/pq_ss7.png) + +![image](images/pq_ss8.png) + +## Gerenciando Respostas + +Um único modelo de Pesquisa pode ser implantado várias vezes simultaneamente. Todas as respostas de múltiplas implantações do mesmo modelo de Pesquisa serão exibidas juntas na tabela Responses na parte inferior da visualização daquela Pesquisa. + +![image](images/pq_ss11.png) + +Mesmo depois que uma implantação de Pesquisa expira ou é encerrada, suas respostas permanecem visíveis na tabela Responses na parte inferior da visualização da Pesquisa, desde que o modelo de Pesquisa em si não tenha sido excluído. Essas respostas são permanentes e não podem ser removidas. + +Como mostrado na imagem abaixo, não há atualmente nenhuma implantação de Pesquisa aberta, mas as respostas de implantações anteriores ainda estão presentes na tabela Responses. + +![image](images/pq_ss12.png) + +### Excluindo Modelos de Pesquisa + +Para excluir um Modelo de Pesquisa, navegue até a visualização All Surveys, clique no ícone de kebab ⋮ à esquerda da Pesquisa escolhida, e clique em **Delete Survey**. Isso exclui permanentemente o modelo de Pesquisa e todas as implantações e Respostas associadas. Esta ação não pode ser desfeita. diff --git a/docs/content/asset_modelling/PRO_surveys/_index.pt-br.md b/docs/content/asset_modelling/PRO_surveys/_index.pt-br.md new file mode 100644 index 0000000000..e4bdadb389 --- /dev/null +++ b/docs/content/asset_modelling/PRO_surveys/_index.pt-br.md @@ -0,0 +1,9 @@ +--- +title: Pesquisas +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.pt-br.md b/docs/content/asset_modelling/_index.pt-br.md new file mode 100644 index 0000000000..4b05b418e1 --- /dev/null +++ b/docs/content/asset_modelling/_index.pt-br.md @@ -0,0 +1,10 @@ +--- +title: Organizar o DefectDojo +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 3 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/components/PRO__components.pt-br.md b/docs/content/asset_modelling/components/PRO__components.pt-br.md new file mode 100644 index 0000000000..a32b763855 --- /dev/null +++ b/docs/content/asset_modelling/components/PRO__components.pt-br.md @@ -0,0 +1,69 @@ +--- +title: Componentes +description: Rastreamento de bibliotecas de terceiros e componentes de software no + DefectDojo Pro +audience: pro +weight: 1 +--- + +No DefectDojo, os Componentes representam bibliotecas de terceiros, componentes de software e módulos que potencialmente possuem vulnerabilidades. + + +## Visualizações de Componentes + +O DefectDojo Pro inclui uma visualização de tabela dedicada para Componentes, que pode ser encontrada na barra lateral. Essa visualização mostra os Achados Ativos, os Achados Duplicados e o Total de Achados para cada Componente. Esses números incluem todos os Ativos na instância do DefectDojo. + +Os Componentes de um Ativo individual podem ser vistos na visualização do Ativo. + +## A Tabela de Componentes + +A Tabela de Componentes exibe as seguintes colunas: + +* **Componente** — o nome do componente, preenchido a partir dos dados do scan. +* **Versão** — a versão do componente, preenchida a partir dos dados do scan. +* **Achados Ativos** — contagem de Achados Ativos associados ao componente. +* **Achados Duplicados** — contagem de Achados Duplicados associados ao componente. +* **Total de Achados** — contagem total de todos os Achados associados ao componente. + +Clicar no Nome do Componente ou nos valores de Achados Ativos, Achados Duplicados ou Total de Achados abre uma lista filtrada de Achados para o respectivo campo. + +Um Componente **Nenhum** é exibido na tabela, mostrando todos os Achados que não estão associados a nenhum Componente. + +Os Componentes importados permanecem na tabela mesmo que todos os seus Achados associados estejam Mitigados. Quando Achados são importados para um Componente específico, a Tabela de Componentes é atualizada para refletir corretamente os novos totais de Achados. + + +### Exemplo + +Um Componente importado de um scan do Dependency-Check em uma aplicação com uma dependência vulnerável do `lodash` pode aparecer na tabela como: + +| Componente | Versão | Achados Ativos | Achados Duplicados | Total de Achados | +| --- | --- | --- | --- | --- | +| npm:lodash | 4.17.15 | 3 | 1 | 5 | + +Clicar em `npm:lodash` abre a lista de todos os Achados que referenciam esse Componente. Clicar em `3` abre a mesma lista filtrada apenas para Achados Ativos. + +## Adicionando Componentes + +Os Componentes podem ser extraídos de uma importação de scan ou por meio da edição manual de um Achado. Assim que um Nome de Componente é associado a um Achado, uma entrada correspondente é adicionada automaticamente à Tabela de Componentes. Se o Componente já estiver associado a outros Achados no DefectDojo, os totais de Achados Ativos, Achados Duplicados e Total de Achados são atualizados de acordo. + +### Como os Componentes são Extraídos dos Dados do Scan + +Quando um scan é importado, os parsers preenchem os campos **Component Name** e **Component Version** de cada Achado a partir da saída do scan. A Tabela de Componentes é então construída a partir desses valores. O nível de detalhe e a convenção de nomenclatura dependem da ferramenta que gerou o scan: + +* **Ferramentas de Software Composition Analysis (SCA)** normalmente informam um nome de pacote e uma versão exata. Por exemplo, o OWASP Dependency-Check deriva o Componente a partir da [Package URL](https://github.com/package-url/purl-spec) em seu identificador — um purl `pkg:npm/lodash@4.17.15` se torna `Component Name: npm:lodash`, `Component Version: 4.17.15`. +* **Scanners de contêiner e de pacotes do SO** como Trivy, Anchore Grype e Anchore Engine informam o pacote do SO ou da linguagem afetado — por exemplo, `Component Name: curl`, `Component Version: 7.68.0`. +* **Scanners de dependências específicos de linguagem** como npm Audit, pip-audit, bundler-audit, Retire.js, Govulncheck e OSV-Scanner preenchem o pacote e a versão problemáticos a partir dos respectivos manifestos do ecossistema. + +Scanners focados em configuração, infraestrutura ou lógica de código-fonte (como ferramentas SAST e IaC) geralmente não preenchem os campos de Componente, e seus Achados aparecem sob o Componente **Nenhum**. + +Para adicionar ou alterar um Componente manualmente, edite o Achado e defina os campos **Component Name** e **Component Version** diretamente. A Tabela de Componentes é atualizada assim que o Achado é salvo. + +## Atualizando Componentes + +Para atualizar um Nome ou Versão de Componente, todos os Achados associados ao Componente devem ter seu campo Component Name ou Component Version atualizado. + +## Removendo Componentes + +Para remover um Componente da Tabela de Componentes, todos os Achados associados ao Componente devem ser atualizados para remover seus campos Component Name e Component Version. Os Componentes também são removidos se todos os seus Achados associados forem excluídos. + +Se todos os Achados de um Componente estiverem Mitigados, o Componente permanece na tabela, mas seu valor de Achados Ativos é definido como 0. diff --git a/docs/content/asset_modelling/components/_index.pt-br.md b/docs/content/asset_modelling/components/_index.pt-br.md new file mode 100644 index 0000000000..930a2f3355 --- /dev/null +++ b/docs/content/asset_modelling/components/_index.pt-br.md @@ -0,0 +1,10 @@ +--- +title: Componentes e Endpoints +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 4 +sidebar: + collapsed: false +exclude_search: true +--- diff --git a/docs/content/asset_modelling/components/services.pt-br.md b/docs/content/asset_modelling/components/services.pt-br.md new file mode 100644 index 0000000000..6ea5111aba --- /dev/null +++ b/docs/content/asset_modelling/components/services.pt-br.md @@ -0,0 +1,39 @@ +--- +title: Serviços +description: Rastreamento de Microsserviços +weight: 1 +--- + +## O que é um Serviço? + +Serviços (abreviação de Microsserviços) são um recurso opcional dentro dos Ativos que fornece contexto adicional sobre onde os Achados se originam dentro de um Ativo. Eles ajudam a isolar Achados a um componente específico de um Ativo, em vez do Ativo inteiro, proporcionando clareza e precisão nos relatórios em ambientes com arquiteturas complexas. + +Os Serviços são úteis quando você precisa segmentar ainda mais os resultados provenientes de um Teste, ou se você espera ter múltiplas instâncias do mesmo Achado dentro de um pipeline de Reimportação que você não deseja deduplicar. Algumas ferramentas de scan podem criar Achados separados para cada localização de arquivo, e se você preferir manter essas instâncias de um Achado como Achados separados, os serviços podem ser uma forma útil de rotular essas diferentes localizações. + +## Serviços no Pro + +Os Serviços estão disponíveis na versão Pro, mas são amplamente substituídos pela capacidade de estabelecer relações pai-filho entre Ativos. Os Serviços alcançam o mesmo resultado e ainda podem ser úteis quando reestruturar os Ativos não é viável ou quando é necessário um escopo de deduplicação em nível de scan sem alterar a hierarquia de Ativos, mas eles removem contexto. Por exemplo, criticidade de negócio, receita e pessoal podem ser atribuídos a Ativos, mas não a Serviços. Dessa forma, os Serviços são úteis principalmente no contexto do DefectDojo OS. + +## Como especifico um Serviço? + +A opção para especificar um Serviço está disponível nos formulários de Import Scan ou Reimport, dentro do menu suspenso de Campos Opcionais. A partir daí, a deduplicação fica restrita aos Testes que compartilham o mesmo valor de Serviço. + +É importante destacar que os Serviços diferenciam maiúsculas de minúsculas. Se o Serviço da importação inicial foi identificado como “Service 1” (S maiúsculo) e você reimportar um scan que resolveu todos os problemas anteriores, mas identificar o Serviço como “service 1” (s minúsculo), a deduplicação não será aplicada ao Serviço pretendido. + +## Como os Serviços funcionam? + +Os Serviços funcionam permitindo que você especifique a quais Testes anteriores as regras de deduplicação serão aplicadas na Reimportação. + +Se, por exemplo, você importar um scan e definir o Serviço como “Service 1,” e depois reimportar um segundo scan e definir o Serviço como “Service 2,” a deduplicação não será aplicada entre esses dois scans porque o Serviço é diferente. + +Quaisquer reimportações subsequentes só deduplicarão os resultados anteriores do primeiro scan se o Serviço tiver sido definido como “Service 1,” e só deduplicarão os resultados anteriores do segundo scan se o Serviço tiver sido definido como “Service 2.” Essencialmente, se o Serviço for diferente entre duas versões de um scan reimportado, eles serão tratados como Achados diferentes, mesmo que os scans em si sejam idênticos. + +Neste exemplo, se, na reimportação, o Serviço não for definido como Service 1 nem como Service 2, e for deixado em branco, a deduplicação não será aplicada nem ao primeiro nem ao segundo scan, e apenas os Achados sem Serviço serão encerrados. + +## Como os Serviços devem ser usados? + +Na prática, os Serviços são mais úteis quando: + +* Um único Ativo contém múltiplos componentes implantados de forma independente. +* Equipes diferentes são responsáveis por partes diferentes do mesmo Ativo. +* Os testes de segurança são realizados contra serviços individuais (por exemplo, ao escanear uma API específica ou um microsserviço). diff --git a/docs/content/asset_modelling/engagements_tests/OS__assets.pt-br.md b/docs/content/asset_modelling/engagements_tests/OS__assets.pt-br.md new file mode 100644 index 0000000000..905f192648 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__assets.pt-br.md @@ -0,0 +1,181 @@ +--- +title: Ativos +description: Entendendo os Ativos no DefectDojo OS +audience: opensource +weight: 2 +aliases: +- /pt-br/asset_modelling/engagements_tests/os__products/ +- /pt-br/en/asset_modelling/engagements_tests/os__products/ +--- + +Organizações → **ATIVOS** → Engajamentos → Testes → Achados + +## Visão Geral + +Os **Ativos** estão no centro de como o trabalho de segurança é organizado na hierarquia de objetos do DefectDojo. Os Ativos representam qualquer projeto, programa, software ou ativo físico que sua equipe de segurança esteja testando, e abrigam todo o trabalho de segurança e o histórico de testes relacionados ao objetivo do teste. Exemplos de Ativos podem incluir: +- Lançamentos de software +- Software de terceiros +- Máquinas virtuais ou ativos em produção +- Uma única aplicação +- Um microsserviço +- Uma API +- Uma plataforma SaaS +- Um aplicativo móvel +- Um sistema interno +- Um serviço de negócio +- Uma plataforma voltada para o cliente +- Um ambiente de nuvem ou domínio de infraestrutura + +Em geral, um Ativo deve representar a “coisa” cuja postura de segurança você deseja acompanhar ao longo do tempo. Isso inclui o histórico de testes associado, os Achados, as métricas, a titularidade, as integrações e os fluxos de remediação relacionados a essa “coisa”. + +### Exemplos de Ativos + +Os Ativos podem se tornar ainda mais granulares dependendo das necessidades da sua organização. Por exemplo, você pode considerar criar Ativos separados no DefectDojo nos seguintes cenários: + +- “ExampleAsset” tem uma versão para Windows, uma versão para Mac e uma versão em nuvem +- “ExampleAsset 1.0” usa componentes de software completamente diferentes de “ExampleAsset 2.0”, e ambas as versões são ativamente mantidas pela sua empresa. +- A equipe designada para trabalhar em “ExampleAsset versão A” é diferente da equipe de Ativo designada para trabalhar em “ExampleAsset versão B”, e por isso precisa ter permissões de segurança diferentes atribuídas. + +Embora você também possa optar por representar essas variações como Engajamentos dentro de um único Ativo, o RBAC só pode ser definido no nível de Ativos ou Organizações, o que pode limitar o acesso dos usuários ao Engajamento apropriado (assim como aos Testes e Achados dentro desses Engajamentos) se estiverem organizados dessa forma. Para mais informações sobre RBAC e permissões no DefectDojo, clique [aqui](/admin/user_management/about_perms_and_roles/). + +## Dados do Ativo + +Os Ativos sempre incluirão os seguintes componentes: + +- **Nome exclusivo** +- **Descrição** +- **Organização** +- **Configuração de SLA** + +Os metadados opcionais do Ativo incluem: + +- **Tags** +- **Informações de pessoal** (por exemplo, Gerente do Ativo, Gerente da Equipe, Contato Técnico, etc.) +- **Regulamentações** (por exemplo, HIPAA, GLBA, OPPA, etc.) +- **Criticidade para o negócio** +- **Plataforma** (por exemplo, API, Desktop, IoT, Mobile, Web, etc.) +- **Ciclo de vida** (por exemplo, Construção, Produção, Desativação, etc.) +- **Origem** (por exemplo, Biblioteca de Terceiros, Adquirido, Código Aberto, etc.) +- **Registros de usuários** (ou seja, o número estimado de registros de usuários no Ativo) +- **Receita** + +Esses metadados melhoram a filtragem, os relatórios e a priorização em todo o seu programa de segurança, mas, mais importante, os Ativos também contêm todos os Engajamentos, Testes e Achados relacionados aos esforços de teste em torno desse Ativo. Todos os Achados dos Testes acabam consolidados no nível do Ativo, permitindo acompanhamento de longo prazo, análise de tendências e relatórios. + +## Acessando Ativos + +Os Ativos são acessíveis pela barra lateral. O submenu também oferece a opção de criar um novo Ativo. + +![image](images/asset_ss3.png) + +### Permissões + +Os Ativos podem ter regras de Controle de Acesso Baseado em Função (RBAC) aplicadas, o que limita a capacidade dos membros da equipe de visualizá-los e interagir com eles. + +As permissões se propagam em cascata, o que significa que o acesso a um Ativo concede automaticamente acesso a todos os objetos dentro desse Ativo (por exemplo, Engajamentos, Testes e Achados). + +Para mais informações sobre funções de usuário, veja nosso [artigo de Introdução às Funções](/admin/user_management/about_perms_and_roles/). + +## Visualização do Ativo + +As visualizações de Ativo contêm uma variedade de tabelas e gráficos para interpretar rapidamente o status de um Ativo. Isso inclui: + +- **Metadados** + - Incluindo Organização, criticidade para o negócio, receita e outros detalhes adicionados nas configurações do Ativo. +- **Métricas** + - Uma lista de Achados abertos dentro do Ativo, agrupados por severidade +- **Acordo de Nível de Serviço por Severidade** + - Aplica a configuração de SLA do Ativo, definida nas configurações, aos Achados dentro do Ativo. +- **Tecnologias** + - Por exemplo, next.js, vue.js, npm v.1.2.3, Django, nginx, Hugo +- **Regulamentações** +- **Progresso de Benchmark** +- **Membros** +- **Grupos** +- **Contatos** +- **Notificações** + - Ativa e desativa notificações dependendo de eventos específicos (por exemplo, um Engajamento foi adicionado ou encerrado) + +## Trabalhando com Ativos + +### Criar Ativos + +Existem várias maneiras de criar um novo Ativo, incluindo: + +- O botão **Add Asset** na lista de Todos os Ativos + +![image](images/asset_ss2.png) + +- No menu suspenso da tabela de Ativos dentro da visualização de uma Organização + - Isso criará automaticamente o Ativo dentro dessa Organização. + +![image](images/asset_ss1.png) + +- O botão **Add Asset** na barra lateral + +![image](images/asset_ss5.png) + +### Editar Ativos + +Um Ativo pode ser editado a partir de suas configurações, que podem ser acessadas de duas formas: + +- O botão **Edit** dentro do menu kebab (⋮) à esquerda do Ativo, na visualização de Todos os Ativos + +![image](images/asset_ss6.png) + +- O botão **Edit** dentro do menu suspenso **Settings** na visualização do Ativo + +![image](images/asset_ss7.png) + +### Excluir Ativos + +A opção de excluir um Ativo pode ser encontrada na parte inferior dos mesmos menus descritos na seção **Editar Ativos** acima. Essa ação não pode ser desfeita. O Ativo não pode ser fechado e reaberto posteriormente. + +Excluir um Ativo também excluirá o seguinte: +- Quaisquer Engajamentos e Testes contidos no Ativo +- Todo o histórico de segurança associado, incluindo Achados e integrações +- Quaisquer Épicos do Jira vinculados +- Todas as notas e uploads de arquivos associados aos Engajamentos e Testes do Ativo + +## Limites do Ativo + +### Deduplicação + +Os Ativos são “isolados” e não interagem com outros Ativos. Os Smart Features do DefectDojo, como a Deduplicação, aplicam-se apenas no contexto de um único Ativo. Achados em Ativos diferentes não serão deduplicados automaticamente. + +### Métricas + +A maior parte dos relatórios e métricas agrega dados no nível do Ativo, tornando os Ativos a unidade principal para medir e acompanhar o risco. + +Como resultado, muitas métricas-chave são calculadas por Ativo, incluindo: + +- Número total de Achados (por severidade ou status) +- Tempo médio de remediação (MTTR) +- Taxas de conformidade e violação de SLA +- Tendências de risco ao longo do tempo + +Isso significa que a forma como os Ativos são estruturados impactará diretamente a precisão e a utilidade dos relatórios. Por exemplo, agrupar vários sistemas não relacionados sob um único Ativo pode obscurecer a visibilidade de risco, enquanto estruturas de Ativo excessivamente granulares podem fragmentar os relatórios, dificultando a identificação de tendências mais amplas. + +As métricas específicas do Ativo podem ser acessadas pelo botão **Metrics** na barra superior da visualização do Ativo escolhido. + +![image](images/asset_ss8.png) + +### Pipeline de CI/CD + +Os pipelines de CI/CD automatizam a importação dos resultados de varredura. Independentemente do método de integração, todas as importações de varredura devem estar associadas a um Ativo, tornando o Ativo o ponto de ancoragem para os dados de segurança orientados por pipeline. + +Quando um pipeline envia resultados de varredura, ele deve: + +- Especificar um Ativo existente (e opcionalmente um Engajamento), ou +- Estar configurado de forma a mapear consistentemente os resultados para o Ativo correto + +Todos os Achados importados herdarão o contexto do Ativo, incluindo titularidade, permissões, configuração de SLA e escopo de relatórios. + +Na prática, os Ativos devem ser definidos de forma a refletir como os sistemas são construídos e implantados dentro do CI/CD, garantindo que os resultados de segurança sejam consistentemente associados à aplicação ou serviço correto. + +### Relações com o Jira + +Os Ativos podem ser mapeados diretamente para Projetos do Jira, que enviam os Achados do Ativo para uma instância do Jira. + +Como os Achados herdam risco, prioridade e titularidade de seu Ativo pai, o Ativo determina efetivamente o contexto de remediação que flui para os tickets do Jira e para os fluxos de trabalho dos Downstream Connectors. + +É importante notar que os Ativos também são o principal fator determinante nas características de SLA de um Achado. Portanto, o SLA de um Achado depende da configuração de SLA de seu Ativo pai. Mais informações sobre configurações de SLA podem ser encontradas [aqui](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). diff --git a/docs/content/asset_modelling/engagements_tests/OS__calendar.pt-br.md b/docs/content/asset_modelling/engagements_tests/OS__calendar.pt-br.md new file mode 100644 index 0000000000..d3473583cb --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__calendar.pt-br.md @@ -0,0 +1,61 @@ +--- +title: Calendário +description: Como usar o Calendário no DefectDojo Pro +audience: opensource +weight: 9 +--- + +O Calendário do DefectDojo oferece uma visão cronológica centralizada de todos os Engajamentos e Testes com datas de início e término definidas, permitindo que os Usuários entendam rapidamente a atividade de testes entre os Produtos, identifiquem sobreposições de agenda e naveguem diretamente para os objetos relacionados. + +Quando um Usuário cria um Engajamento ou Teste e define as datas de início e término, uma entrada correspondente é adicionada automaticamente ao Calendário. As entradas aparecem em todas as datas a partir da data de início definida até a data de término definida, inclusive. + +## Acessando o Calendário + +A página do Calendário é acessível por meio do botão Calendar na barra lateral. + +![image](images/OSC_ss3.png) + +## Visibilidade e Permissões + +### Visibilidade + +A página do Calendário inclui filtros na parte superior e uma grade mensal do Calendário abaixo. Use os controles de navegação acima do Calendário para se mover entre os meses. + +A visualização mensal é exibida como uma grade fixa de seis semanas, começando pela semana que contém o primeiro dia do mês selecionado. + +As entradas visíveis no Calendário podem ser filtradas com base no tipo de objeto (Engajamentos ou Testes) e no Líder de Testes, definido nas configurações do Engajamento ou Teste. Depois de selecionar os critérios de filtro, clique em Apply para atualizar a visualização do Calendário. + +Apenas um tipo de objeto pode ser exibido por vez. Alternar entre Engajamentos e Testes atualiza a visualização do Calendário de acordo. + +### Permissões + +O Calendário respeita as permissões em nível de objeto do DefectDojo. Os Usuários só veem os Engajamentos e Testes aos quais têm autorização para acessar. + +## Visualizando e Interagindo com Entradas + +Dentro de cada célula de data, as entradas são ordenadas alfabeticamente com base no nome do objeto. Clicar em uma entrada redireciona para o objeto correspondente. + +O número de entradas visíveis em cada dia é dinâmico e varia dependendo do tamanho da tela e do nível de zoom do navegador. Se o número de entradas exceder o espaço disponível em uma célula de data, um link no formato “+X more” aparece na parte inferior da célula. + +![image](images/OSC_ss1.png) + +Clique no link “+X more” para abrir um modal exibindo todas as entradas daquela data. + +![image](images/OSC_ss2.png) + +É importante notar que o Calendário em si é uma visualização somente leitura. As datas devem ser modificadas nas configurações do próprio objeto de Engajamento ou Teste. + +### Lógica de Nomenclatura + +A nomenclatura das entradas no Calendário varia ligeiramente dependendo do tipo de objeto. + +As entradas de Engajamento incluem: +- Nome do Produto +- Nome do Engajamento +- Líder de Testes + +As entradas de Teste incluem: +- Nome do Produto +- Nome do Engajamento +- Tipo de Teste +- Líder de Testes diff --git a/docs/content/asset_modelling/engagements_tests/OS__engagements.pt-br.md b/docs/content/asset_modelling/engagements_tests/OS__engagements.pt-br.md new file mode 100644 index 0000000000..a95a35d3a5 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__engagements.pt-br.md @@ -0,0 +1,182 @@ +--- +title: Engajamentos +description: Entendendo os Engajamentos no DefectDojo OS +audience: opensource +weight: 3 +--- + +Organizações → Ativos → **ENGAJAMENTOS** → Testes → Achados + +## Visão geral + +Na hierarquia de produtos do DefectDojo, os Engajamentos são contêineres limitados por tempo ou por pipeline que representam grupos de Testes relacionados dentro de um Produto específico. Se você tiver um esforço de teste planejado e agendado, seja em uma base rotineira ou pontual, um Engajamento oferece um local para armazenar todos os resultados relacionados. + +Exemplos de Engajamentos incluem: +- Testes de penetração pontuais +- Varreduras mensais ou trimestrais recorrentes +- Períodos de revisão de bug bounty +- Execuções de pipeline de CI/CD (para equipes que tratam cada pipeline como seu próprio Engajamento) +- Ciclos de lançamento de código (por exemplo, "revisão de segurança do lançamento v4.2") + +### Tipos de Engajamento + +O DefectDojo oferece suporte a dois tipos de Engajamento: **Interativo** e **CI/CD**. Esses tipos determinam como os Testes normalmente são criados e como os resultados das varreduras são importados. + +Um Engajamento Interativo normalmente é conduzido por um engenheiro. Os Engajamentos Interativos são focados em testar uma aplicação enquanto ela está em execução, usando um teste automatizado, um testador humano, ou qualquer atividade que "interaja" com a funcionalidade da aplicação. + +Um Engajamento de CI/CD é destinado à integração automatizada com um pipeline de CI/CD. Os Engajamentos de CI/CD têm como objetivo importar dados como uma ação automatizada, acionada por uma etapa no processo de lançamento. + +| **Categoria** | **Engajamentos Interativos** | **Engajamentos de CI/CD** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **Caso de Uso Principal** | Testes de segurança manuais ou pontuais | Testes de segurança automatizados e recorrentes dentro de pipelines | +| **Duração** | Limitada no tempo e finita | Duração potencialmente infinita | +| **Frequência** | Periódica ou pontual | Contínua ou por commit | +| **Fluxo de Trabalho** | Testador humano executa a ferramenta → importa os resultados manualmente | Pipeline executa a ferramenta → envia os resultados automaticamente ao DefectDojo | +| **Método de Importação de Resultados** | Upload manual via UI ou CLI | Importação orientada por API via automação (por exemplo, CLI, conectores, cron jobs, scripts de pipeline) | +| **Tipo de Teste Típico** | Testes de penetração, exercícios de red team, avaliações manuais | Análise estática, varredura de dependências, varredura de contêineres | + +### Dados do Engajamento + +Como contêineres que organizam a atividade de teste, os Engajamentos podem armazenar ou rastrear uma variedade de dados: + +- Datas de início e término previstas +- Descrição e notas de escopo +- Status (em andamento, planejado, concluído, etc.) +- Responsável / Líder +- Testes associados (por exemplo, varreduras, testes de penetração, testes manuais, etc.) +- Achados e Tipos de Achado (por exemplo, ativo, mitigado, risco aceito, duplicado, etc.) +- Modelos de ameaça ou informações de aceitação de risco +- Tags +- Arquivos e notas +- Configurações do projeto Jira +- Detalhes do ambiente (por exemplo, staging vs. produção) +- IDs de build (se vinculado a CI/CD) +- Dados históricos de Testes anteriores dentro do Engajamento + +## Acessando Engajamentos + +Os Engajamentos são acessíveis pela barra lateral. O submenu oferece acesso a Engajamentos Ativos e Todos os Engajamentos, além da opção de visualizar os Engajamentos organizados por Produto, tipos de Teste e Ambientes. + +![image](images/engagement_ss17.png) + +Alternativamente, os Engajamentos dentro de um Produto específico podem ser acessados pelo submenu da opção Engajamentos na barra superior. + +![image](images/engagement_ss18.png) + +### Permissões + +Os Engajamentos ficam abaixo dos Produtos e acima dos Testes na hierarquia de objetos. Assim, o acesso a um Produto concede automaticamente acesso a todos os Engajamentos dentro desse Produto. Os Engajamentos não possuem listas de controle de acesso independentes. + +## Trabalhando com Engajamentos + +### Criar Engajamentos + +Existem várias abordagens para criar um Engajamento. Cada abordagem exige que você primeiro crie um Produto para contê-lo. + +Depois de criar um Produto, você pode adicionar um novo Engajamento Interativo ou de CI/CD na seção Engajamentos da barra de navegação do Produto. + +![image](images/engagement_ss4.png) + +Todo Engajamento deve ter os seguintes campos definidos: +- Tipo (Interativo ou CI/CD) +- Um nome exclusivo +- Datas de início e término previstas + - Isso determinará a aparência do Engajamento na seção Calendário +- Produto +- Status + +#### Status de Engajamento + +Os Engajamentos podem receber diferentes status no momento da criação. O status também pode ser alterado posteriormente nas configurações do Engajamento. + +Um Engajamento pode ter qualquer um dos seguintes status: +- Não iniciado +- Bloqueado +- Cancelado +- Concluído +- Em andamento +- Em espera +- Agendado +- Aguardando recurso + +Alterar o status de um Engajamento para "Concluído" significa que a maioria das operações de escrita (por exemplo, adicionar testes, importar varreduras) ficará indisponível ou oculta. Outros status não afetam materialmente a funcionalidade do Engajamento, servindo mais para fins de filtragem/informação. + +### Editar Engajamentos + +Os Engajamentos podem ser editados clicando no botão **Editar** dentro das configurações do Engajamento. Todos os campos subsequentes que podem ser editados também estão disponíveis quando o Engajamento está sendo criado. + +### Copiar Engajamentos + +Você pode duplicar facilmente os Engajamentos navegando até a lista de Engajamentos dentro de um Produto e clicando no botão **Copiar** dentro do menu kebab ⋮ ao lado do Engajamento a ser copiado. Isso criará uma cópia exata do Engajamento original dentro do Produto pai, incluindo os metadados, Testes e Achados contidos nele. + +![image](images/engagement_ss19.png) + +### Fechar Engajamentos + +Os Engajamentos podem ser fechados navegando até a lista de Engajamentos dentro de um Produto e clicando em "Fechar" dentro do menu kebab ⋮ do Engajamento escolhido. + +![image](images/engagement_ss20.png) + +Depois de fechado, o status do Engajamento será alterado para "Concluído". Ainda assim, a maioria das operações de escrita (por exemplo, adicionar testes, importar varreduras) permanecerá disponível. + +Fechar um Engajamento não altera o status dos Achados dentro de nenhum dos Testes do Engajamento. Os Achados permanecem ativos, mitigados ou com risco aceito de acordo com seu próprio ciclo de vida, e continuam acessíveis para visualização e geração de relatórios. + +Se o Engajamento estiver vinculado a um Épico do Jira (consulte **[Integração com o Jira: Habilitar Mapeamento de Épico de Engajamento](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**), fechar o Engajamento acionará uma tarefa assíncrona que fecha o Épico do Jira associado no seu Espaço Jira conectado. + +### Reabrir Engajamentos + +Se um Engajamento estiver fechado, ele pode ser reaberto clicando em **Reabrir** dentro do menu kebab ⋮ na tabela de Engajamentos Fechados. Isso tornará o Engajamento ativo novamente e retornará seu status para "Em andamento". + +![image](images/engagement_ss21.png) + +### Engajamentos Expirados + +Um Engajamento expira quando sua data de término prevista é ultrapassada. + +A expiração do Engajamento não tem impacto direto sobre sua funcionalidade, servindo principalmente como um mecanismo de monitoramento/notificação. + +Depois de expirado, uma notificação vermelha "X dias em atraso" aparecerá no campo "Duração" do Engajamento, mas isso não restringirá nenhuma funcionalidade do Engajamento. O status do Engajamento continuará aparecendo como "Em andamento". + +Embora não esteja habilitada por padrão, existe uma opção nas configurações do sistema para fechar automaticamente um Engajamento depois que ele estiver expirado por um determinado número de dias. + +![image](images/engagement_ss22.png) + +### Excluir Engajamentos + +A exclusão de um Engajamento pode ser realizada selecionando **Excluir** nas configurações do Engajamento. Essa ação não pode ser desfeita. + +Excluir um Engajamento também excluirá o seguinte: +- Quaisquer Testes associados ao Engajamento +- Todos os Achados contidos nesses Testes +- Quaisquer mapeamentos de Épico do Jira vinculados (o Épico em si permanecerá no Jira, mas o vínculo entre o DefectDojo e o Jira será removido) +- Todas as notas e arquivos enviados associados ao Engajamento + +Para fins de auditoria, recomenda-se fechar os Engajamentos concluídos, em vez de excluí-los. + +| **Operação** | **Resultados** | **Reversível** | +|----------|---------|------------| +| **Fechar** | Marca como inativo; os dados permanecem; pode ser reaberto | Sim (reabrir) | +| **Expirar** | Apenas aviso visual; fechamento automático opcional; notificações | N/A | +| **Excluir** | Remove permanentemente o Engajamento, Testes, Achados, notas, arquivos e quaisquer mapeamentos de Épico do Jira (os Épicos permanecem no Jira) | Não | + +## Integração com o Jira + +Os Engajamentos podem ser vinculados a um Espaço Jira conectado, permitindo que os Achados dentro do Engajamento sejam enviados ao Jira como Issues. Para um guia completo sobre a configuração do Jira, consulte **[Conectando o DefectDojo ao Jira](/connectors/os_jira/os__jira_guide/)**. + +### Mapeamento de Épico de Engajamento + +Quando a opção **Habilitar Mapeamento de Épico de Engajamento** está marcada nas configurações do Jira de um Produto, os Engajamentos são enviados ao Jira como Épicos. Os Achados dentro do Engajamento são enviados como Issues filhas abaixo do Épico, espelhando a hierarquia Engajamento → Achados do DefectDojo na estrutura Épico → Issue do Jira. + +Para mais informações sobre essa configuração, consulte **[Habilitar Mapeamento de Épico de Engajamento](/connectors/os_jira/os__jira_guide/#enable-engagement-epic-mapping-for-products)**. + +### Configurações do Jira em Nível de Engajamento + +Por padrão, os Engajamentos herdam suas configurações do Jira do Produto pai. No entanto, Engajamentos individuais podem substituir essas configurações para usar configurações diferentes do Jira. As seguintes configurações podem ser personalizadas por Engajamento: + +- **Chave do Projeto** — direciona os Achados para um Espaço Jira diferente +- **Template de Issue** — usa um template diferente para Issues criadas a partir deste Engajamento +- **Campos Personalizados** — aplica mapeamentos de campos personalizados diferentes +- **Labels do Jira** — marca Issues com labels específicas do Engajamento +- **Responsável Padrão** — atribui Issues a um membro diferente da equipe + +Essas configurações são acessíveis na página **Editar Engajamento**. Para mais detalhes, consulte **[Configurações do Jira em Nível de Engajamento](/connectors/os_jira/os__jira_guide/#engagement-level-jira-settings)**. diff --git a/docs/content/asset_modelling/engagements_tests/OS__findings.pt-br.md b/docs/content/asset_modelling/engagements_tests/OS__findings.pt-br.md new file mode 100644 index 0000000000..2e41aae4dd --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__findings.pt-br.md @@ -0,0 +1,302 @@ +--- +title: Achados +description: Entendendo os Achados no DefectDojo OS +audience: opensource +weight: 5 +--- + +Organizações → Ativos → Engajamentos → Testes → **ACHADOS** + +## Visão geral + +**Achados** representam o nível mais baixo da Hierarquia de Produtos, onde vulnerabilidades individuais são rastreadas e gerenciadas, e são a principal forma pela qual o DefectDojo padroniza e orienta o processo de relato e remediação das suas ferramentas de segurança. Independentemente de uma vulnerabilidade ter sido relatada no SonarQube, no Acunetix ou na ferramenta personalizada da sua equipe, os Achados permitem gerenciar cada vulnerabilidade da mesma forma. + +Exemplos de Achados incluem: +- Cookie não marcado como HttpOnly +- Versão desatualizada (PHP) +- Avaliação de código fora de banda (PHP) +- Versão desatualizada (MySQL) +- Código-fonte de backup detectado +- Cross-Site Scripting cego + +Além de armazenar os dados da vulnerabilidade e fornecer uma estrutura de remediação, o DefectDojo também aprimora seus Achados das seguintes formas: +- Adicionando automaticamente as pontuações EPSS relacionadas a um Achado para descrever sua explorabilidade +- Traduzindo automaticamente a métrica de severidade de uma ferramenta de segurança em uma pontuação de Severidade para cada Achado, o que confere um SLA ao Achado de acordo com a configuração de SLA do seu Ativo. Para mais informações sobre a configuração de SLA, clique [aqui](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). + +No geral, os Achados são projetados para funcionar em conjunto com a Hierarquia de Produtos, padronizando seus esforços e aplicando um método consistente a cada Ativo. + +## Acessando Achados + +Os Achados são acessíveis pela barra lateral. O submenu oferece acesso a Achados Abertos e Fechados, Todos os Achados (independentemente do status Aberto ou Fechado), [Achados com Risco Aceito](/triage_findings/findings_workflows/os__risk_acceptance/), além dos Templates de Achados. Achados individuais também são acessíveis a partir do Teste que os contém. + +![image](images/osfindings_ss1.png) + +### Permissões + +Todo Achado pertence a um Teste, o que permite que o DefectDojo preserve qual varredura ou avaliação identificou originalmente a vulnerabilidade. + +Como os Achados pertencem a Testes, o acesso aos Achados é determinado pelo acesso do Usuário ao Ativo que contém o Teste. Os Testes não possuem listas de controle de acesso independentes. + +## Visualização de Achados +As visualizações de Achado contêm uma variedade de tabelas para ajudar a interpretar o status de um Achado rapidamente. Isso inclui: +- **Visão geral** + - **ID**: O número de ID exclusivo desse Achado. + - **Severidade**: A classificação de severidade desse Achado, aplicada automaticamente. + - Como mencionado acima, o DefectDojo traduz automaticamente a métrica de severidade de uma ferramenta de segurança em uma pontuação de Severidade para cada Achado, o que confere um SLA ao Achado de acordo com a configuração de SLA do seu Ativo. + - **SLA**: A data limite prevista para a resolução do Achado. + - **Status**: O status do Achado (por exemplo, Ativo, Verificado, Falso positivo, Duplicado, Fora do escopo e Em revisão de defeito). + - **Tipo de Achado**: Se o Achado é Estático (SAST) ou Dinâmico (DAST). + - **Data de descoberta**: A data em que o Achado foi descoberto. + - **CWE**: A classificação CWE do Achado. + - **ID da vulnerabilidade**: IDs de vulnerabilidades em avisos de segurança associados ao Achado (por exemplo, CVE ou outras fontes). + - **Encontrado por**: A ferramenta que revelou o Achado. +- **Achados semelhantes**: Outros Achados dentro do mesmo Ativo que não são duplicatas exatas, mas possuem valores semelhantes para vulnerability ID, CWE, file_path, número de linha, etc. +- **Histórico de importação**: Lista de importações/reimportações que criaram/fecharam/reativaram esse Achado em qualquer Teste. +- **Endpoints/sistemas vulneráveis**: Endpoints/Sistemas que o Achado revela estarem vulneráveis. +- **Descrição**: A descrição do Achado (adicionada automaticamente dependendo do tipo de Achado, ou criada manualmente). +- **Mitigação**: Passos sugeridos para mitigação. +- **Impacto**: Impacto potencial de deixar o Achado sem resolução. +- **Passos para reproduzir**: Passos para reproduzir o Achado. +- **Justificativa de severidade**: Descrição escrita do motivo pelo qual uma determinada classificação de Severidade foi associada ao Achado. +- **Referências**: URL para referência cruzada com a descrição específica do Achado feita pela ferramenta de varredura de terceiros. Por exemplo, as Referências podem ser links para uma entrada relevante em um catálogo de Achados, ou uma única URL de aviso. +- **Notas**: Notas deixadas por Usuários relacionadas ao Achado. Marcar uma nota como privada significa que ela não será incluída em nenhum relatório gerado que inclua o Achado selecionado. + +## Dados dos Achados + +Os Achados exigem os seguintes metadados: +**Título** +**Data** +**Severidade** +**Descrição** + +Além dos metadados correspondentes às tabelas na visualização de um Achado, os campos de metadados opcionais incluem: +- **Grupo**: Grupos de Achados que incluem o Achado selecionado. +- **Vetor e pontuação CVSS3/CVSS4**: O vetor e a pontuação CVSS3 e CVSS4 do Achado selecionado. +- **Pares de solicitação e resposta**: Uma cópia da mensagem enviada pelo cliente e da resposta do servidor à solicitação. +- **Endpoints a adicionar**: Endpoints vulneráveis que podem ser afetados pelo Achado selecionado e que não estão refletidos na lista anterior de sistemas/endpoints. +- **Pontuação e percentil EPSS**: Pontuação e percentil EPSS para o CVE. +- **Data de adição ao KEV**: A data em que o Achado foi adicionado ao catálogo KEV. +- **Disponibilidade e versão da correção**: Define se há uma correção disponível para a vulnerabilidade, e a versão do componente afetado na qual a correção foi implementada. +- **Usuário que solicitou uma revisão de defeito**: Registra quem solicitou uma revisão de defeito para a falha em questão. +- **Número da linha**: Número da linha de origem do vetor de ataque. +- **Caminho do arquivo**: Arquivos identificados que contêm a falha. +- **Nome e versão do componente**: Nome e versão do componente afetado. +- **ID exclusivo da ferramenta**: ID técnico exclusivo da vulnerabilidade na ferramenta de origem. +- **ID de vulnerabilidade da ferramenta**: ID técnico não exclusivo na ferramenta de origem. +- **Objeto de origem SAST, número da linha e caminho do arquivo**: Objeto de origem, número da linha e caminho do arquivo do vetor de ataque. +- **Objeto de destino SAST**: Objeto de destino (sink) do vetor de ataque. +- **Número de ocorrências**: Número de ocorrências na ferramenta de origem quando várias vulnerabilidades foram encontradas e agregadas pelo scanner. +- **Data de publicação**: Data em que o Achado foi publicado. +- **Serviço**: Serviços conectados (partes autocontidas de funcionalidade dentro de um Ativo) que são afetados pelo Achado selecionado. Quando preenchido, esse campo é incluído na correspondência de deduplicação (ou seja, Achados com campos de Serviço idênticos serão deduplicados). +- **Data e versão de remediação planejada**: A data em que o Achado está planejado para ser remediado, e a versão do componente afetado na qual a correção será implementada. +- **Esforço para correção**: O nível de esforço envolvido na correção do Achado (por exemplo, Baixo, Médio ou Alto). +- **Tags**: Quaisquer tags que tenham sido adicionadas ao Achado. + +Os metadados exatos disponíveis dependerão do parser/scanner que revelou o Achado. Alguns fornecem apenas informações básicas, como título e severidade, enquanto outros incluem vetores CVSS, componentes vulneráveis, endpoints, pares de solicitação/resposta e outros metadados específicos do scanner. + +Esses metadados melhoram a filtragem, a geração de relatórios e a priorização em todo o seu programa de segurança, permitindo o rastreamento de longo prazo e a análise de tendências. Detalhes adicionais e descrições de metadados podem ser encontrados [aqui](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page). + +### Deduplicação + +O DefectDojo inclui capacidades de deduplicação que ajudam a identificar e gerenciar Achados que representam a mesma vulnerabilidade subjacente. À medida que os resultados de varredura são importados de uma ou mais ferramentas, o DefectDojo usa uma lógica de correspondência configurável para identificar Achados que representam a mesma vulnerabilidade. + +A deduplicação evita que a mesma vulnerabilidade apareça várias vezes quando descoberta repetidamente pelo mesmo scanner ou por scanners diferentes, permitindo que o histórico de remediação permaneça vinculado a um único Achado. + +Mais informações sobre deduplicação podem ser encontradas [aqui](/triage_findings/finding_deduplication/about_deduplication/). + +### Reimportação + +A função de Reimportação do DefectDojo permite que os Achados sejam atualizados à medida que novos resultados de varredura são importados. Quando uma varredura é reimportada, o DefectDojo compara os resultados recebidos com os Achados existentes e atualiza os registros correspondentes em vez de criar registros totalmente novos. Isso preserva um contexto valioso, como alterações de status, histórico de remediação, comentários e informações de propriedade, fornecendo um registro contínuo do ciclo de vida de um Achado ao longo de vários ciclos de teste. + +Mais informações sobre a função de Reimportação podem ser encontradas [aqui](/import_data/import_intro/reimport/#main-content). + +### Aceitações de Risco + +As Aceitações de Risco são um status especial que pode ser aplicado aos Achados para documentar formalmente e operacionalizar a decisão de reconhecê-los sem remediá-los imediatamente. + +Mais informações sobre Aceitações de Risco podem ser encontradas [aqui](/triage_findings/findings_workflows/os__risk_acceptance/). + +### Status + +Cada Achado criado no DefectDojo tem um Status que comunica informações relevantes e ajuda sua equipe a acompanhar o progresso na resolução dos problemas. + +Mais informações sobre Status podem ser encontradas [aqui](/triage_findings/findings_workflows/finding_status_definitions/). + +## Trabalhando com Achados + +### Criando Achados + +Embora a maioria dos Achados seja gerada automaticamente por meio de importações de varreduras e integrações, o DefectDojo também oferece suporte à criação manual de Achados. Os Achados manuais são úteis para rastrear vulnerabilidades e questões de segurança identificadas por meio de testes de penetração, revisões de arquitetura, avaliações de conformidade, programas de bug bounty, engajamentos de consultoria ou outras atividades que não produzem saída de scanner. + +Para criar um Achado manualmente: +1. Navegue até o Teste no qual deseja adicionar manualmente o Achado, clique no sinal + (mais) e depois clique em **Novo Achado**. + +![image](images/osfindings_ss2.png) + +2. Isso abre o formulário de Novo Achado, que você pode preencher com qualquer informação relevante sobre seu Achado. + +3. Selecione **Adicionar Outro Achado** para adicionar manualmente outro Achado, ou **Concluído** para finalizar o processo de criação manual do Achado. + +O Achado agora aparecerá na lista de Achados contidos no Teste original. + +É importante notar que adicionar manualmente um Achado a partir da barra superior criará automaticamente um Engajamento e um Teste ad hoc para conter o novo Achado, em vez de adicioná-lo ao Teste que está sendo visualizado no momento (veja a imagem abaixo). Isso ocorre porque a barra superior diz respeito ao Ativo como um todo. Se você deseja adicionar manualmente um Achado a um Teste específico e já existente, é melhor fazer isso a partir do próprio Teste, conforme descrito nos passos 1 a 3 acima. + +![image](images/osfindings_ss3.png) + +### Editando Achados + +#### Menu Kebab ⋮ + +O menu kebab ⋮ ao lado dos Achados contém as seguintes funções: +- **Visualizar**: Abre e exibe o Achado. +- **Editar**: Edita o Achado. +- **Copiar**: Cria uma cópia do Achado. A cópia pode ser salva em qualquer um dos Testes contidos no Engajamento correspondente. +- **Solicitar Revisão por Pares**: Inicia o processo de Revisão por Pares e altera o status do Achado para "Em revisão". Mais informações sobre Revisões por Pares podem ser encontradas [aqui](/triage_findings/findings_workflows/finding_status_definitions/#under-review). +- **Registrar Interação com o Achado**: Registra a interatividade com o Achado no histórico do Achado. +- **Transformar Achado em Template**: Cria automaticamente um Template de Achado com base no Achado selecionado. +- **Aplicar Template ao Achado**: Permite aplicar um Template de Achado pré-existente a um Achado. +- **Fechar Achado**: Inicia o processo de fechamento do Achado. +- **Adicionar Aceitação de Risco**: Inicia o processo de Aceitação de Risco. Mais informações podem ser encontradas [aqui](/triage_findings/findings_workflows/os__risk_acceptance/#main-content). +- **Ver Histórico**: Revela o histórico do Achado selecionado. +- **Excluir**: Exclui o Achado selecionado. + +#### Anexando Arquivos aos Achados +Você pode anexar arquivos a qualquer Achado para fornecer contexto visual — por exemplo, uma captura de tela de uma vulnerabilidade em ação ou uma imagem de prova de conceito. + +Os tipos de arquivo compatíveis incluem: + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +Para anexar um arquivo a um Achado: +1. Abra o Achado ao qual deseja anexar um arquivo. +2. Abra o menu de ações (o botão ☰ no canto superior direito do Achado) e clique em Gerenciar Arquivos. + +![image](images/OS_manage_files_menu.png) + +3. Na página Adicionar arquivos, digite um Título para o arquivo e escolha o arquivo do seu computador. Você pode adicionar até três arquivos por vez; salve e retorne para adicionar mais, se necessário. + +![image](images/OS_manage_files_form.png) + +4. Clique em **Salvar**. + +O arquivo é então listado no painel **Arquivos** do Achado. Arquivos de imagem aparecem como miniaturas: + +![image](images/OS_finding_files_panel.png) + +#### Edição em Massa de Achados + +Os Achados podem ser editados em massa a partir de uma lista de Achados, como a tabela de Todos os Achados acessível pela barra lateral, ou a partir da tabela de Achados dentro de um Teste específico. + +Mais informações sobre como editar Achados em massa podem ser encontradas [aqui](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings). + +### Fechando Achados + +Depois que o trabalho em um Achado é concluído, você pode fechá-lo manualmente clicando em **Fechar Achado** dentro do menu kebab ⋮ ou do menu de ações ☰ do Achado. Alternativamente, se uma varredura for reimportada no DefectDojo e não contiver um Achado registrado anteriormente, o Achado registrado anteriormente será fechado automaticamente. + +Se você não quiser que nenhum Achado seja fechado, pode desabilitar esse comportamento na Reimportação: + +- Desmarque a caixa de seleção Close Old Findings, se estiver usando a UI +- Defina close_old_findings como False, se estiver usando a API ​ + +### Excluindo Achados + +A exclusão de um Achado pode ser feita a partir do menu kebab ⋮ ou do menu de ações ☰ do Achado. Essa ação não pode ser desfeita. + +Para fins de auditoria, recomenda-se fechar os Achados remediados, em vez de excluí-los. + +## Grupos de Achados + +Os **Grupos de Achados** permitem tratar múltiplos Achados relacionados como uma única unidade lógica para triagem, geração de relatórios e coordenação de remediação. + +Por exemplo, uma varredura pode produzir 10 Achados de injeção de SQL em diferentes endpoints. Em vez de gerenciar cada um independentemente, você pode agrupá-los em um único Grupo de Achados que represente o problema mais amplo de injeção de SQL. + +Um Grupo de Achados não substitui os Achados individuais. Cada Achado continua existindo com sua própria severidade, status, metadados, comentários e histórico de remediação. Um Grupo de Achados simplesmente fornece uma camada organizacional adicional acima dos Achados que ele contém. + +### Acessando Grupos de Achados + +Os Grupos de Achados podem ser acessados pela barra lateral. O submenu oferece acesso a Grupos de Achados Abertos e Fechados, bem como a Todos os Grupos de Achados (independentemente do status Aberto). + +![image](images/osfindings_ss1.png) + +### Criando Grupos de Achados + + +Os Grupos de Achados podem ser criados manual ou automaticamente. + +Notavelmente, os Grupos de Achados só podem ser criados a partir dos Achados contidos em um único Teste. Achados de Testes, Engajamentos ou Produtos diferentes não podem ser adicionados ao mesmo Grupo de Achados. + +#### Grupos de Achados Manuais + +Para realizar manualmente ações de Grupo de Achados: +1. Navegue até uma lista de Achados dentro de um Teste. +2. Selecione o(s) Achado(s) que deseja adicionar a um Grupo de Achados clicando na caixa de seleção correspondente. +3. Clique na caixa de seleção **Grupo**. +4. Clique na ação correspondente que deseja realizar. + - **Criar**: Cria um Grupo de Achados que inclui os Achados selecionados. + - **Adicionar a**: Adiciona os Achados selecionados a um Grupo de Achados pré-existente. + - **Remover de qualquer grupo**: Remove os Achados selecionados de quaisquer Grupos de Achados dos quais faziam parte anteriormente. + - **Agrupar por**: Agrupa os Achados selecionados com base na opção escolhida (por exemplo, nome do componente, caminho do arquivo, título do Achado, etc.) +5. Clique em **Enviar**. + +![image](images/osfindings_ss4.png) + +Observe que a única ação possível ao selecionar Achados na lista Todos os Achados é remover os Achados selecionados de qualquer Grupo de Achados. Isso ocorre porque, como mencionado, os Grupos de Achados só podem ser criados a partir dos Achados contidos em um único Teste. + +#### Grupos de Achados Automáticos + +Ao importar uma varredura, o recurso "Agrupar por" pode criar automaticamente Grupos de Achados com base em um método de agrupamento escolhido. Isso é útil quando um scanner produz muitos Achados relacionados que devem ser gerenciados em conjunto. + +A caixa de seleção adjacente **Criar Grupos de Achados para todos os Achados** realiza duas funções: +- **Marcada**: Cria um Grupo de Achados para cada Achado importado, mesmo que esse Achado seja o único membro do grupo. +- **Desmarcada**: Cria Grupos de Achados somente quando há de fato múltiplos Achados para agrupar. + +![image](images/osfindings_ss5.png) + +Se nenhuma opção for selecionada no menu suspenso Agrupar por durante a importação, nenhum agrupamento ocorrerá. + +Se o critério de agrupamento (por exemplo, nome do componente, ID de vulnerabilidade, etc.) não estiver preenchido no Achado, ele não terá um grupo criado nem será adicionado a um Grupo de Achados pré-existente. + +Se uma varredura for importada revelando 10 Achados que não são agrupados, e a mesma varredura for reimportada e os Achados forem agrupados, os primeiros 10 Achados não serão adicionados a esse Grupo de Achados (ou seja, o Grupo de Achados incluirá apenas os 10 Achados da reimportação, não os 10 Achados da importação inicial e subsequente). + +## Templates de Achados + +**Templates de Achados** permitem que os Usuários criem templates reutilizáveis para vulnerabilidades e problemas de segurança comumente relatados. Um template pode incluir informações padronizadas, como título, descrição, impacto, passos para reproduzir, mitigação, referências e outros metadados de Achado. + +Os Templates de Achados são mais úteis em situações em que os Usuários precisam criar Achados manuais repetidamente e desejam evitar reinserir as mesmas informações de apoio todas as vezes. + +### Acessando Templates de Achados + +Os Templates de Achados são encontrados no submenu de Achados na barra lateral. + +![image](images/osfindings_ss6.png) + +### Criando Templates de Achados + +Os Templates de Achados podem ser criados clicando no botão + (mais) no canto superior direito da visualização de Templates de Achados. + +A página seguinte fornece uma visão geral dos metadados que serão aplicados a um Achado quando um Template de Achado for usado. + +Você também pode usar um Achado pré-existente como base para um novo Template de Achado clicando em **Transformar Achado em Template** dentro do menu kebab ⋮ do Achado. + +### Aplicando Templates de Achados + +Os Templates de Achados podem ser aplicados a Achados clicando no botão **Aplicar Template ao Achado** dentro do menu kebab ⋮ do Achado selecionado. + +![image](images/osfindings_ss7.png) + +A página seguinte permitirá que você selecione o template a ser aplicado ao Achado em questão, e então decida se deseja manter, substituir ou combinar os metadados do Achado com o template. + +### Relatórios + +O construtor de relatórios do DefectDojo permite montar um relatório personalizado a partir de um conjunto de widgets de conteúdo, executá-lo e exportar o resultado (por exemplo, imprimindo-o em PDF). Relatórios personalizados podem resumir os Achados ou Endpoints que você deseja compartilhar com um público externo, e podem incluir branding e texto padrão. + +Mais informações sobre o Construtor de Relatórios do DefectDojo podem ser encontradas [aqui](/metrics_reports/reports/using-the-report-builder/). + +#### Exportar Achados + +Páginas que exibem uma lista de Achados ou uma lista de Engajamentos têm uma opção de exportação em CSV e Excel no menu suspenso no canto superior direito. + +Em qualquer página de lista de Achados, abra o menu suspenso no canto superior direito para exportar os Achados visíveis como um arquivo CSV ou Excel. A lista de Engajamentos também pode ser exportada como CSV ou Excel usando o mesmo menu suspenso na página de lista de Engajamentos. diff --git a/docs/content/asset_modelling/engagements_tests/OS__organizations.pt-br.md b/docs/content/asset_modelling/engagements_tests/OS__organizations.pt-br.md new file mode 100644 index 0000000000..2d1002c648 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__organizations.pt-br.md @@ -0,0 +1,139 @@ +--- +title: Organizações +description: Entendendo as Organizações no DefectDojo OS +audience: opensource +weight: 1 +aliases: +- /pt-br/asset_modelling/engagements_tests/os_producttype/ +- /pt-br/en/asset_modelling/engagements_tests/os_producttype/ +--- + +**ORGANIZAÇÕES** → Ativos → Engajamentos → Testes → Achados + +## Visão geral + +**Organizações** ficam bem no topo da hierarquia de objetos do DefectDojo. As Organizações são diferentes dos objetos descendentes na hierarquia — Ativos, Engajamentos, Testes e Achados — porque não são alvos técnicos de varredura, mas servem principalmente como abstrações organizacionais que compartimentam seus esforços de segurança de acordo com: +- Domínio de negócio +- Equipe de desenvolvimento +- Equipe de segurança +- Aplicações de software +- Família de produtos abrangente +- Cliente ou subsidiária +- Estrutura de relatórios +- etc. + +O tema dos exemplos acima ilustra a utilidade essencial das Organizações: elas geralmente devem representar limites estáveis e duradouros dentro do seu programa de segurança. + +## Dados e estrutura da Organização + +Como as Organizações não são varridas diretamente, o único campo obrigatório para criá-las é um nome. Além disso, elas funcionam como contêineres para Ativos e seus Engajamentos, Testes e Achados descendentes. + +Ao criar uma Organização, considere como sua estrutura influenciará seus relatórios. Você precisa principalmente que as Organizações representem as equipes que trabalham nos projetos (Ativos) que as Organizações vão conter? Ou as Organizações representariam melhor projetos abrangentes que contêm diferentes iterações dos projetos (Ativos) dentro deles? + +Se você tem uma única Organização que contém todas as informações relevantes para um determinado domínio de negócio ou equipe de desenvolvimento, representá-la como uma Organização facilitará relatórios mais consistentes, em vez de ter que reunir um relatório a partir de vários Ativos e Organizações. + +Se um determinado projeto de software tem muitas implantações ou versões distintas, pode valer a pena criar uma única Organização que cubra o escopo de todo o projeto e deixar cada versão existir como Ativos individuais. Em alguns fluxos de trabalho, as Organizações também podem ser usadas para separar estágios do ciclo de vida do software: uma Organização para "Em Desenvolvimento", outra Organização para "Em Produção", etc. + +As Organizações podem ser usadas para determinar o acesso a subsidiárias, empresas adquiridas ou outras unidades de negócio regulamentadas para fins de RBAC. Em empresas complexas, onde há muitos projetos únicos com regras de acesso diferentes, as Organizações são particularmente relevantes. + +Em última análise, a decisão de como usar Organizações e Ativos depende de como você deseja melhor refletir sua estrutura organizacional exclusiva e as necessidades da sua equipe de segurança. + +Abaixo estão alguns exemplos de estruturas para orientar como você designa seus objetos como Organizações ou Ativos. + +- **Organização**: Divisão de Pagamentos + - Ativo: API de Pagamentos - Produção + - Ativo: API de Pagamentos - Homologação + - Ativo: Worker de Faturamento + +- **Organização**: Produto de Software A + - Ativo: Portal Web + - Ativo: Backend Mobile + +Além disso, o guia a seguir ilustra se algo é melhor representado por uma Organização ou por um Ativo: + +| Organizações | Ativos | +|--------------|--------| +| Unidades de negócio | Aplicações individuais | +| Departamentos | Implantações/ambientes | +| Domínios de propriedade de segurança | Componentes de infraestrutura | +| Famílias de produtos | Microsserviços específicos | +| Relatórios em nível de portfólio | Alvos de varredura | +| Clientes | Versões específicas de software | + +Conforme observado, sua estrutura pode variar de acordo com as necessidades de segurança exclusivas da sua equipe. + +## Acessando Organizações + +As Organizações são acessíveis pela barra lateral. O submenu também oferece a opção de criar novas Organizações. + +![image](images/organization_ss1.png) + +### Visualização da Organização + +A visualização de uma Organização contém uma variedade de tabelas e gráficos para interpretar seu status rapidamente. Isso inclui: +- **Descrição** +- **Caixa de seleção Chave/Crítica** + - Marcar Crítica ou Chave é usado somente para fins de filtragem +- **Lista de Ativos dentro da Organização** +- **Usuários autorizados** (Usuários do DefectDojo) + +## Trabalhando com Organizações + +### Criar Organizações + +Existem duas maneiras de criar Organizações: + +- Na opção **Adicionar Organização** no menu lateral +- No botão **Adicionar Organização** no topo da lista Todas as Organizações + +### Editar Organizações + +As Organizações podem ser editadas clicando em **Editar** no menu suspenso no canto superior direito da tabela de Descrição na visualização da Organização. O mesmo menu também pode ser acessado clicando no menu kebab ⋮ à esquerda da Organização na lista Todas as Organizações. + +Todos os campos subsequentes que podem ser editados também estão disponíveis quando a Organização está sendo criada. + +### Excluir Organizações + +A exclusão de uma Organização pode ser realizada selecionando **Excluir Organização** nas configurações da Organização. + +Como as Organizações ficam no topo da hierarquia, excluí-las remove todo o histórico de segurança, relacionamentos e objetos filhos a jusante, tais como: +- Quaisquer Ativos, Engajamentos e Testes contidos na Organização +- Todo o histórico de segurança associado, incluindo Achados e integrações +- Quaisquer Epics do Jira vinculados +- Todas as notas e uploads de arquivos associados aos Ativos, Engajamentos e Testes dentro dessa Organização + +A exclusão de uma Organização não pode ser desfeita. Se você quiser "desativar" uma Organização sem excluir os dados subjacentes (por exemplo, preservando registros de testes de software legados para fins de auditoria), você pode alterar o nome da Organização ou adicionar uma Tag para indicar que ela está em um estado obsoleto. + +## Organizações vs. Metadados + +As Organizações têm como objetivo representar a propriedade estrutural ou os limites de relatórios, e não classificações leves. Atributos como status de implantação, rótulos internos ou estados de fluxo de trabalho temporários podem ser melhor representados por meio de tags ou metadados, em vez de Organizações separadas. + +## Limites das Organizações + +As Organizações estabelecem tanto limites de relatórios quanto de acesso dentro do DefectDojo. Como integrações, permissões de RBAC, propriedade, métricas e modelos de deduplicação frequentemente herdam a estrutura das Organizações, projetar limites claros desde o início ajuda a evitar a expansão descontrolada da hierarquia e a fragmentação de relatórios mais tarde. + +### Achados e automação + +Embora as integrações normalmente sejam configuradas em objetos de nível inferior, como Ativos, Engajamentos ou Achados, as Organizações ainda definem os limites de propriedade, relatórios e acesso dentro dos quais essas integrações operam. + +As permissões são propagadas para baixo, o que significa que o acesso a uma Organização concede automaticamente acesso a todos os objetos dentro dessa Organização (por exemplo, Ativos, Engajamentos, Testes e Achados). + +O modelo de RBAC do DefectDojo pode ser usado para controlar o acesso de usuários humanos, mas também pode restringir o acesso de tokens de API a Organizações específicas. + +Para mais informações sobre funções de usuário, consulte nosso artigo [Permissões](/admin/user_management/os__authorized_users/). + +### Propriedade + +Como objetos de nível superior, as Organizações também implicam propriedade sobre os objetos filhos dentro delas. O acompanhamento de SLA, os fluxos de trabalho de correção, o roteamento de tickets e a governança geral fluem com mais tranquilidade quando as Organizações foram configuradas para refletir com precisão os indivíduos responsáveis por elas. + +### Métricas/Relatórios + +Os painéis, blocos e visualizações de métricas podem ser filtrados por Organização, tornando-os um componente essencial de como seus dados de segurança são calculados, visualizados e, por fim, exportados. + +Para fins de relatório, geralmente é mais fácil combinar várias Organizações em um único documento do que subdividir uma única Organização em documentos separados. Portanto, recomendamos configurar as Organizações no nível mais granular que fizer sentido para os relatórios da sua equipe. Por exemplo, não há necessidade de representar uma grande divisão de negócios como uma Organização se você for reportar principalmente para departamentos individuais dentro dessa divisão. + +Estruturar suas Organizações de forma eficaz para refletir as necessidades de relatório da sua equipe é fundamental para avaliar com precisão sua postura de segurança. Para mais informações sobre Métricas, clique [aqui](/metrics_reports/dashboards/introduction_dashboard/). + +### Deduplicação + +A deduplicação no DefectDojo ocorre no nível do Ativo e não é afetada pela Organização pai. diff --git a/docs/content/asset_modelling/engagements_tests/OS__tests.pt-br.md b/docs/content/asset_modelling/engagements_tests/OS__tests.pt-br.md new file mode 100644 index 0000000000..fa4f2d1d22 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/OS__tests.pt-br.md @@ -0,0 +1,274 @@ +--- +title: Testes +description: Entendendo os Testes no DefectDojo OS +audience: opensource +weight: 4 +--- + +Organizações → Ativos → Engajamentos → **TESTES** → Achados + +## Visão geral + +Um Teste é um contêiner para uma ou mais execuções de varredura, usadas para descobrir falhas em um Produto. Os Testes são o componente final e mais granular da hierarquia de produtos do DefectDojo, servindo como o contêiner para os Achados resultantes da execução de uma ferramenta de segurança ou de uma avaliação manual, além de adicionar o contexto em que tais Achados foram encontrados (ou seja, qual ferramenta os reportou, quando essa ferramenta foi executada pela última vez, etc.). + +Exemplos de Testes incluem: +- Teste Estático de Segurança de Aplicações +- Teste Dinâmico de Segurança de Aplicações +- Análise de Composição de Software +- Varreduras de Segurança de Contêineres +- Varreduras de Infraestrutura / Rede +- Testes de Penetração Manuais +- Varreduras de Pipeline de CI/CD + +### Tipos de Teste + +Existem duas formas principais de criar Testes no DefectDojo: +1. **Parsers específicos de fornecedor** (por exemplo, Burp, OWASP ZAP, Acunetix, Invicti) +2. **Importação Genérica de Achados** + +Cada método pode criar novos Testes ou reimportar Achados para Testes existentes, dependendo da configuração e da estratégia de deduplicação. + +Embora cada método difira principalmente na forma como os dados de varredura são analisados e ingeridos, todos eles resultam, em última instância, em Achados associados a um Teste. + +#### Parsers + +**Parsers** são componentes que processam formatos específicos de saída de varredura (por exemplo, XML, JSON, CSV) e os mapeiam para o modelo interno de Achado do DefectDojo. Quando os resultados de uma varredura são importados, o DefectDojo usa o parser selecionado para extrair os Achados e anexá-los a um Teste recém-criado ou existente. + +#### Importação Genérica de Achados + +Quando não existe um parser nativo para uma determinada ferramenta, a **Importação Genérica de Achados** permite importar achados usando um esquema JSON ou CSV padronizado, independentemente da fonte original. + +O DefectDojo analisa os dados fornecidos, cria um novo Teste (ou importa para um já existente) e anexa os Achados. Um Tipo de Teste correspondente também é criado com base no campo opcional `type` do relatório: quando `type` é omitido (ou é igual ao tipo de varredura) o Tipo de Teste é "Generic Findings Import"; quando `type` é fornecido, ele se torna "{type} Scan (Generic Findings Import)" (um `type` que já termina com o sufixo "(Generic Findings Import)" é usado literalmente). + +| | **Parsers Nativos** | **Importação Genérica de Achados** | +|----------|---------------|------------------------| +| **Objetivo principal** | Ingerir saídas de ferramentas suportadas | Ingerir dados não suportados/personalizados por meio de um esquema fixo | +| **Formato de entrada** | Específico da ferramenta (por exemplo, ZAP XML, SARIF) | Esquema estrito JSON/CSV | +| **Quem trata a normalização** | DefectDojo (parser integrado) | Usuário (deve estar em conformidade com o esquema) | +| **Gatilho de criação do Teste** | Upload manual ou importação via API | Upload manual ou importação via API | +| **Tipo de Teste** | Predefinido (por exemplo, "ZAP Scan") | Tipo "Generic" criado automaticamente | +| **Esforço de configuração** | Baixo | Moderado (é necessária transformação de dados) | +| **Flexibilidade** | Baixa (somente ferramentas suportadas) | Média | +| **Nível de automação** | Baixo a moderado | Baixo a moderado | +| **Caso de uso típico** | Scanners padrão (SAST, DAST, SCA) | Scripts personalizados, ferramentas não suportadas | + +Independentemente do método de ingestão, todos os dados de varredura no DefectDojo são, em última instância, representados como Achados anexados a um Teste, que serve como a unidade de execução e de rastreamento do ciclo de vida. + +### Dados do Teste + +Os Testes armazenam uma variedade de metadados que ajudam a documentar diversos componentes de cada esforço de teste, tais como: +- Título / nome do Teste +- Tipo de Teste +- Descrição / notas do Teste +- Data de início e término +- O Ambiente em que o Teste foi executado (por exemplo, Desenvolvimento, Homologação, Pré-Produção, Produção, etc.) +- Versão / Branch / ID de Build / Hash de Commit +- Configuração de varredura de API +- Arquivos adicionais que podem ser usados para auditorias posteriores ou reimportações +- O Engajamento, o Ativo e a Organização pais +- Histórico de importação e reimportação + +Cada Teste mantém um histórico de importação, que registra todas as importações e reimportações de varredura associadas ao Teste. Isso inclui metadados como data da varredura, versão, branch, hash de commit e ID de build. + +Esse histórico fornece rastreabilidade em várias execuções de varredura dentro do mesmo Teste. + +### Permissões + +Vários Testes podem ser armazenados dentro de um único Engajamento, e os Engajamentos são armazenados dentro dos Produtos. Assim, o acesso a um Produto concede automaticamente acesso a todos os Testes (e Engajamentos) dentro desse Produto. Os Testes não possuem listas de controle de acesso independentes. + +### Acessando Testes + +Embora os Testes existam como um objeto independente no DefectDojo OS, eles não têm uma seção específica dedicada a eles na interface. Assim, cada Teste é acessível principalmente através do Produto e/ou Engajamento que o contém. + +### Visualização do Teste + +A visualização do Teste hospeda uma variedade de tabelas, incluindo o Engajamento pai, o histórico de importação e reimportação, uma lista de Achados contidos no Teste, bem como quaisquer Grupos de Achados. + +Também há tabelas para Achados Potenciais, Arquivos e Notas, todas as quais podem ser adicionadas manualmente. + +#### Configurações do Teste + +As seguintes configurações estão disponíveis em cada visualização de Teste: +- **Editar Teste** + - Permite a edição dos dados do Teste, como título, agendamento, ambiente e outros detalhes diversos. +- **Copiar Teste** + - Duplica um Teste, junto com todos os metadados e Achados associados, e permite atribuí-lo a um Engajamento diferente. +- **Reenviar Varredura** + - Inicia o processo de reimportação. Mais informações sobre Reimportação estão disponíveis mais adiante neste artigo. +- **Adicionar Notas** + - Permite que o usuário adicione uma Nota. Uma tabela de Notas também está presente na parte inferior da página. + - Uma Nota pode ser marcada como Privada, caso em que fica impedida de ser enviada para o Jira, Relatórios e exportações de Achados. +- **Relatório** + - Inicia o processo de geração de um Relatório, no qual inúmeros filtros podem ser aplicados para criar um relatório apenas com os Achados filtrados. +- **Adicionar ao Calendário** + - Baixa um arquivo .ics do Teste escolhido, que pode ser adicionado ao seu aplicativo de calendário de terceiros. +- **Ver Histórico** + - Abre um histórico das edições feitas no Teste para fins de rastreamento, relatórios e auditoria. + +## Trabalhando com Testes + +### Criar Testes + +Os Testes podem ser criados automaticamente quando dados de varredura são importados diretamente em um Engajamento, resultando em um novo Teste contendo os dados da varredura. Os Testes também podem ser criados em antecipação ao planejamento de futuros Engajamentos, ou para achados de segurança inseridos manualmente que exigem rastreamento e correção. + +#### Fluxos de Trabalho Manuais + +Existem várias maneiras de criar um Teste na versão OS: + +- Selecione um Produto e clique em "Importar Resultados de Varredura" no menu Achados na barra de navegação + - Isso criará um Engajamento ad hoc para conter o Teste + +![image](images/tests_ss5.png) + +- Selecione um Engajamento dentro de um Produto, clique no menu suspenso na subseção Testes e clique em "Adicionar Testes" ou "Importar Resultados de Varredura" + - Isso criará o Teste resultante diretamente dentro do Engajamento escolhido + +![image](images/tests_ss6.png) + +- Durante a criação de um Engajamento + +![image](images/tests_ss7.png) + +Usando o terceiro método acima, você pode fazer o seguinte durante a criação de um Engajamento: + +- Importar imediatamente os resultados da varredura +- Criar um shell de Teste (no qual você importará uma varredura posteriormente) +- Não fazer nenhum dos dois e simplesmente criar o Engajamento clicando em "Concluído" + +Você terá a oportunidade de adicionar metadados tanto ao importar uma varredura quanto ao criar um shell de Teste. Quaisquer metadados serão refletidos na seção Histórico de Importação da Visualização do Teste. + +#### Fluxos de Trabalho Automatizados + +Em fluxos de trabalho automatizados, os Testes podem ser criados programaticamente como parte do processo de importação de varredura, permitindo que os pipelines enviem resultados sem exigir que um Teste seja criado manualmente com antecedência. + +Ao usar a API para importar resultados de varredura, um novo Teste pode ser criado automaticamente fornecendo um engagement em vez de um test. + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +Diante do exposto acima, um novo Teste é criado sob o Engajamento especificado, e os resultados da varredura são anexados a esse Teste. + +Se um ID de `test` for fornecido em vez disso, os resultados da varredura serão adicionados a um Teste existente, o que é comum em fluxos de trabalho de reimportação. + +### Editar Testes + +Os Testes podem ser editados clicando em **Editar Teste** no menu kebab ⋮ na tabela de Testes dentro da visualização do Engajamento pai, ou no menu de configurações dentro da visualização do Teste. Todos os campos subsequentes que podem ser editados também estão disponíveis quando o Teste está sendo criado. + +![image](images/tests_ss24.png) + +![image](images/tests_ss12.png) + +#### Adicionar Achados Manualmente a um Teste + +Um Achado pode ser adicionado manualmente a um Teste clicando em **Adicionar Achado ao Teste** no menu kebab ⋮ ao lado do Teste na visualização do Engajamento pai, ou nas configurações da tabela de Achados na visualização do Teste. + +![image](images/tests_ss29.png) + +![image](images/tests_ss30.png) + +### Excluir Testes + +A exclusão de um Teste pode ser realizada selecionando **Excluir Teste** no menu kebab ⋮ ao lado do Teste na visualização do Engajamento pai, ou no menu de configurações dentro da visualização do Teste. Essa ação não pode ser desfeita. + +A exclusão de um Teste também excluirá quaisquer Achados contidos nesse Teste. + +![image](images/tests_ss25.png) + +![image](images/tests_ss26.png) + +## Reimportação + +A reimportação de varreduras dentro de Testes é fundamental para uma deduplicação eficaz. Quando os resultados de uma varredura são reimportados no mesmo Teste: + +- Os Achados existentes podem ser atualizados +- Achados duplicados podem ser suprimidos +- Novos Achados podem ser criados se nenhuma correspondência for encontrada + +Esse comportamento depende das regras de deduplicação configuradas e do tipo de varredura. + +Criar um novo Teste em vez de reimportar em um já existente pode resultar na criação de Achados duplicados em vez de atualizados. + +#### Reimportação vs. Importação + +A Reimportação é normalmente usada quando: + +- Você executa varreduras recorrentes contra o mesmo alvo +- Você rastreia como os Achados evoluem ao longo do tempo +- Você mantém uma visão contínua da postura de segurança da aplicação + +Em contraste, a importação (criação de um novo Teste) é mais adequada para execuções de varredura únicas ou independentes. + +### Reimportando Resultados de Varredura (Interface) + +Para adicionar novos dados a um Teste existente, você pode clicar em **Reenviar Resultados de Varredura** no menu kebab ⋮ ao lado do Teste na visualização do Engajamento pai, ou clicar em **Reenviar Varredura** no menu de configurações dentro da visualização do Teste. + +![image](images/tests_ss27.png) + +![image](images/tests_ss10.png) + +Ao preencher o formulário de Reimportar Varredura, você terá a opção de atualizar os metadados da varredura sendo reimportada, incluindo a versão, a tag de branch, o hash de commit e o ID de build. + +Essas alterações são refletidas na seção Histórico de Importação da Visualização do Teste, que também incluirá os mesmos metadados das importações de varredura anteriores. + +Por exemplo, na captura de tela abaixo, a tag de branch, o ID de build, o hash de commit e a versão foram todos atualizados manualmente entre a importação inicial e a reimportação subsequente. + +![image](images/tests_ss28.png) + +Para editar os metadados da varredura reimportada mais recentemente, siga as instruções anteriores na seção Editar Testes acima e atualize os metadados conforme desejado. Somente os metadados da importação mais recente podem ser editados. + +### Reimportando Resultados de Varredura (API) + +Quando os Testes são criados ou atualizados por meio de um pipeline de CI/CD, você pode incluir metadados da execução do pipeline para que os Testes sejam corretamente vinculados ao código que varreram. Isso permite que você: +- Associe os resultados da varredura a um commit ou branch específico. +- Rastreie como os Achados evoluem entre as alterações de código. +- Melhore a Deduplicação, entendendo quando duas varreduras se aplicam à mesma versão do código ou a versões diferentes. +- Ofereça suporte à auditabilidade, mostrando exatamente qual código foi varrido e quando. + +A API do DefectDojo aceita esses valores durante a importação ou reimportação, para que possam ser armazenados como parte da importação da varredura e refletidos no histórico de importação do Teste. Esses metadados podem ser usados para identificar hashes de commit ou qualquer informação de repositório relevante associada a uma execução de CI/CD. + +#### Campos de Metadados Suportados + +A API suporta um conjunto definido de campos de metadados que podem ser incluídos durante a reimportação. Estes incluem: + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- sinalizadores `active / verified` + +Esses campos representam o principal mecanismo para anexar metadados contextuais durante uma operação de reimportação. + +Em pipelines automatizados, os metadados mais comumente fornecidos incluem: +- build_id (identificador do job de CI) +- commit_hash (referência de controle de versão) +- branch_tag (contexto de branch ou ambiente) +- tags (por exemplo, nightly, staging, production) + +Esses campos fornecem rastreabilidade entre varreduras sem exigir intervenção manual. + +Embora os metadados possam ser atualizados manualmente por meio do formulário Reimportar Varredura, a maioria dos ambientes automatizados trata isso chamando diretamente o endpoint `/api/v2/reimport-scan/`. Essa abordagem permite que o pipeline anexe automaticamente os metadados na reimportação. + +##### Reimportação via API com Metadados + +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"` + +##### Metadados, Reimportação e Varreduras Agendadas + +As varreduras também podem ser agendadas para serem executadas em intervalos rotineiros, como as acionadas por cron jobs. As varreduras agendadas não estão vinculadas à atividade do repositório, tornando metadados como hashes de commit ou nomes de branch irrelevantes, a menos que sejam explicitamente injetados pelo próprio script. Ainda assim, usar a reimportação pode ser útil se você preferir manter um registro contínuo da sua postura de segurança dentro de um único Teste. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__assets.pt-br.md b/docs/content/asset_modelling/engagements_tests/PRO__assets.pt-br.md new file mode 100644 index 0000000000..18e2d8c380 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__assets.pt-br.md @@ -0,0 +1,186 @@ +--- +title: Ativos +description: Entendendo os Ativos no DefectDojo Pro +audience: pro +weight: 2 +--- + +Organizações → **ATIVOS** → Engajamentos → Testes → Achados + +## Visão geral + +**Ativos** estão no centro de como o trabalho de segurança é organizado dentro da hierarquia de objetos do DefectDojo. Os Ativos representam qualquer projeto, programa, software ou ativo físico que sua equipe de segurança esteja testando, e hospedam todo o trabalho de segurança e o histórico de testes relacionados ao objetivo do teste. Exemplos de Ativos podem incluir: +- Versões de software +- Software de terceiros +- Máquinas virtuais ou ativos em produção +- Uma única aplicação +- Um microsserviço +- Uma API +- Uma plataforma SaaS +- Um aplicativo móvel +- Um sistema interno +- Um serviço de negócio +- Uma plataforma voltada para o cliente +- Um ambiente de nuvem ou domínio de infraestrutura + +Em geral, um Ativo deve representar a "coisa" cuja postura de segurança você deseja acompanhar ao longo do tempo. Isso inclui o histórico de testes associado, os Achados, as métricas, a propriedade, as integrações e os fluxos de trabalho de correção relacionados a essa "coisa". + +### Exemplos de Ativos + +Os Ativos podem se tornar ainda mais granulares, dependendo das necessidades da sua organização. Por exemplo, você pode considerar criar Ativos separados no DefectDojo nos seguintes cenários: + +- "AtivoExemplo" tem uma versão para Windows, uma versão para Mac e uma versão para Nuvem +- "AtivoExemplo 1.0" usa componentes de software completamente diferentes de "AtivoExemplo 2.0", e ambas as versões são ativamente suportadas pela sua empresa. +- A equipe designada para trabalhar na "versão A do AtivoExemplo" é diferente da equipe de Ativo designada para trabalhar na "versão B do AtivoExemplo", e, como resultado, precisa ter permissões de segurança diferentes atribuídas. + +Embora você também possa optar por representar essas variações como Engajamentos dentro de um único Ativo, o RBAC só pode ser definido no nível de Ativos ou Organizações, o que pode limitar o acesso dos usuários ao Engajamento apropriado (bem como aos Testes e Achados dentro desses Engajamentos) caso estejam organizados dessa forma. Para mais informações sobre RBAC e permissões no DefectDojo, clique [aqui](/admin/user_management/about_perms_and_roles/). + +## Dados do Ativo + +Os Ativos sempre incluirão os seguintes componentes: + +- **Organização** +- **Nome exclusivo** +- **Descrição** +- **Configuração de SLA** +- **Motor de Priorização** + +Os metadados opcionais do Ativo incluem: + +- **Tags** +- **Criticidade de negócio** +- **Registros de usuários** (ou seja, o número estimado de registros de usuários no Ativo) +- **Receita** +- **Informações de pessoal** (por exemplo, Gerente do Ativo, Gerente da Equipe, Contato Técnico, etc.) +- **Regulamentações** (por exemplo, HIPAA, GLBA, OPPA, etc.) +- **Plataforma** (por exemplo, API, Desktop, IoT, Mobile, Web, etc.) +- **Ciclo de vida** (por exemplo, Construção, Produção, Desativação, etc.) +- **Origem** (por exemplo, Biblioteca de Terceiros, Adquirido, Código Aberto, etc.) + +Esses metadados melhoram a filtragem, os relatórios e a priorização em todo o seu programa de segurança, mas o mais importante é que os Ativos também contêm todos os Engajamentos, Testes e Achados relacionados aos esforços de teste em torno desse Ativo. Todos os Achados dos Testes, em última instância, são consolidados no nível do Ativo, permitindo o acompanhamento de longo prazo, a análise de tendências e a geração de relatórios. + +## Acessando Ativos + +Os Ativos são acessíveis pela barra lateral. O submenu oferece acesso à [Hierarquia de Ativos](/asset_modelling/engagements_tests/pro__assets/#asset-nesting) e a Todos os Ativos, além da opção de criar um novo Ativo. + +![image](images/assets_ss1.png) + +### Permissões + +Os Ativos podem ter regras de Controle de Acesso Baseado em Função (RBAC) aplicadas, que limitam a capacidade dos membros da equipe de visualizá-los e interagir com eles. + +As permissões são propagadas para baixo, o que significa que o acesso a um Ativo concede automaticamente acesso a todos os objetos dentro desse Ativo (por exemplo, Engajamentos, Testes e Achados). + +Para mais informações sobre funções de usuário, consulte nosso artigo [Introdução às Funções](/admin/user_management/set_user_permissions/#introduction-to-permission-types). + +## Visualização do Ativo + +As visualizações de Ativo contêm uma variedade de tabelas e gráficos para interpretar o status de um Ativo rapidamente. Isso inclui: + +- **Severidade dos Achados Abertos** + - Uma lista dos Achados abertos dentro do Ativo, agrupados por severidade +- **Visão Geral do Ativo** + - Um detalhamento de vários recursos do Ativo, incluindo Descrição, Componentes, Contatos, [Grupos de Usuários](/admin/user_management/create_user_group/ +), Membros, Tecnologias e Regulamentações. + - Tecnologias: next.js, vue.js, npm v.1.2.3, Django, nginx, Hugo +- **Metadados** + - Incluindo Ativos pais e filhos, Organização, criticidade de negócio, receita e outros detalhes adicionados nas configurações do Ativo. +- **Acordo de Nível de Serviço por Severidade** + - Aplica a configuração de SLA do Ativo, definida nas configurações, aos Achados dentro do Ativo. +- **Detalhamento de Severidade dos Achados** + - Um gráfico dos Achados dentro do Ativo, organizados por severidade. +- **Distribuição de Achados** + - Um detalhamento dos Achados dentro do Ativo, organizados por status (por exemplo, Ativo, Mitigado, Estático e Dinâmico) +- **Todos os Engajamentos** + - Uma lista dos Engajamentos contidos no Ativo. + +## Trabalhando com Ativos + +### Criar Ativos + +Existem duas maneiras de criar Ativos: + +- Na opção **Novo Ativo** no menu lateral +- No botão **Novo Ativo** no topo da lista Todos os Ativos + +## Editar Ativos + +Os Ativos podem ser editados clicando em **Editar Ativo** no menu de engrenagem no canto superior direito da visualização do Ativo. O mesmo menu também pode ser acessado clicando no menu kebab ⋮ à esquerda do Ativo na visualização Todos os Ativos. + +Todos os campos subsequentes que podem ser editados também estão disponíveis quando o Ativo está sendo criado. + +![image](images/assets_ss2.png) + +### Excluir Ativos + +A exclusão de um Ativo pode ser realizada selecionando **Excluir Ativo** nas configurações do Ativo. Essa ação não pode ser desfeita. Os Ativos não podem ser fechados e reabertos posteriormente. + +A exclusão de um Ativo também excluirá o seguinte: +- Quaisquer Engajamentos e Testes contidos no Ativo +- Todo o histórico de segurança associado, incluindo Achados e integrações +- Quaisquer Epics do Jira vinculados +- Todas as notas e uploads de arquivos associados aos Engajamentos e Testes do Ativo + +## Limites do Ativo + +### Deduplicação + +Os Ativos são "isolados" e não interagem com outros Ativos. Os Recursos Inteligentes do DefectDojo, como a Deduplicação, aplicam-se apenas no contexto de um único Ativo. Os Achados de diferentes Ativos não serão deduplicados automaticamente. + +### Relatórios e Métricas + +A maioria dos relatórios e métricas agrega dados no nível do Ativo, tornando os Ativos a unidade principal para medir e acompanhar o risco. + +Como resultado, muitas métricas importantes são calculadas por Ativo, incluindo: + +- Número total de Achados (por severidade ou status) +- Tempo médio de correção (MTTR) +- Conformidade e taxas de violação de SLA +- Tendências de risco ao longo do tempo + +Isso significa que a forma como os Ativos são estruturados impactará diretamente a precisão e a utilidade dos relatórios. Por exemplo, agrupar vários sistemas não relacionados em um único Ativo pode obscurecer a visibilidade do risco, enquanto estruturas de Ativo excessivamente granulares podem fragmentar os relatórios, dificultando a identificação de tendências mais amplas. + +### Connectors + +No DefectDojo Pro, os Connectors são mapeados para diferentes Ativos, tornando-os o principal ponto de integração entre o DefectDojo e seu ecossistema de segurança mais amplo. + +Depois que um Connector é anexado a um Ativo, ele importará os resultados da varredura e criará ou atualizará Engajamentos, Testes e Achados dentro desse Ativo. + +Para mais informações sobre Connectors, clique [aqui](/connectors/upstream/about/#main-content). + +### Pipelines de CI/CD + +Os pipelines de CI/CD automatizam a importação dos resultados de varredura. Independentemente do método de integração, todas as importações de varredura devem estar associadas a um Ativo, tornando o Ativo o ponto de ancoragem para os dados de segurança orientados por pipeline. + +Quando um pipeline envia resultados de varredura, ele deve: + +- Especificar um Ativo existente (e, opcionalmente, um Engajamento), ou +- Estar configurado de forma a mapear consistentemente os resultados para o Ativo correto + +Todos os Achados importados herdarão o contexto do Ativo, incluindo propriedade, permissões, configuração de prioridade/risco e escopo de relatórios. + +Na prática, os Ativos devem ser definidos de forma a refletir como os sistemas são construídos e implantados dentro do CI/CD, a fim de garantir que os resultados de segurança sejam consistentemente associados à aplicação ou ao serviço correto. + +### SLAs, Prioridade e Risco + +No DefectDojo Pro, os Achados herdam suas metas de SLA, Prioridade e Risco do Ativo que os contém. Os metadados do Ativo (por exemplo, criticidade de negócio, receita, etc.) são usados para calcular automaticamente os valores de Prioridade e Risco. + +Isso significa que a mesma vulnerabilidade pode receber uma pontuação de Prioridade ou Risco diferente, dependendo se ela afeta um sistema de desenvolvimento interno ou um ativo de produção que suporta operações de negócio críticas. + +### Relacionamentos com Jira / Connectors Downstream + +Os Ativos podem ser mapeados diretamente para instâncias do [Jira](/connectors/downstream/pro__jira_guide/#main-content) ou [Integrators](/connectors/downstream/downstream_toolreference/#main-content) (por exemplo, GitHub, GitLab, ServiceNow, etc.), que enviam os Achados do Ativo para fora, rumo a sistemas externos de tickets/gerenciamento de trabalho. + +Como os Achados herdam risco, prioridade e propriedade do Ativo pai, o Ativo efetivamente determina o contexto de correção que flui para os tickets do Jira e para os fluxos de trabalho dos Connectors Downstream. + +É importante destacar que os Ativos também são o principal fator determinante nas características de SLA de um Achado. Portanto, o SLA de um Achado depende da configuração de SLA do seu Ativo pai. Mais informações sobre configurações de SLA podem ser encontradas [aqui](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas). + +## Aninhamento de Ativos + +O DefectDojo oferece suporte a um relacionamento pai-filho entre dois Ativos dentro da mesma Organização. Isso pode ser configurado durante a criação do Ativo ou nas configurações do Ativo. + +Você pode visualizar a estrutura dos Ativos no DefectDojo e alterar relacionamentos usando a opção **Hierarquia de Ativos** na barra lateral. + +Depois de selecionar os Ativos a serem visualizados na tabela correspondente, clique em **Ver Hierarquia de Ativos** para gerar um fluxograma do relacionamento entre os Ativos escolhidos, se houver algum. + +Mais informações sobre o efeito do aninhamento de Ativos na deduplicação, no RBAC e em outros detalhes, bem como exemplos de casos de uso, podem ser encontradas [aqui](/asset_modelling/pro_hierarchy/asset_hierarchy/#asset-nesting-examples). diff --git a/docs/content/asset_modelling/engagements_tests/PRO__calendar.pt-br.md b/docs/content/asset_modelling/engagements_tests/PRO__calendar.pt-br.md new file mode 100644 index 0000000000..56c76f908f --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__calendar.pt-br.md @@ -0,0 +1,62 @@ +--- +title: Calendário +description: Como usar o Calendário no DefectDojo Pro +audience: pro +weight: 9 +--- + +O DefectDojo conta com um Calendário integrado para que você possa acompanhar todos os Engajamentos e Testes anteriores e ativos em sua organização. Sempre que um Usuário cria um novo Engajamento ou Teste e define as datas de início e término, uma entrada correspondente é adicionada automaticamente ao Calendário. + +### Página Inicial + +A página do Calendário inclui filtros na parte superior e um calendário mensal abaixo. Os filtros podem ajustar quais resultados aparecem no calendário com base em: +- Engajamento e/ou Teste +- Data de início e término +- Status do Engajamento (por exemplo, Concluído, Em andamento, Em espera, etc.) +- Responsável pelo Engajamento/Teste (ou seja, a quem o Engajamento/Teste está atribuído?) +- Tipo de Engajamento (por exemplo, Interativo ou CI/CD) +- Tipo de Teste (por exemplo, Pen Test, Acunetix Scan, Tenable Scan, etc.) + +![image](images/calendar1.png) + +Depois de filtrados, os resultados podem ser exportados e compartilhados como um arquivo ICS. + +É importante notar que o Calendário exibirá apenas os Engajamentos e Testes aos quais o Usuário que está visualizando o calendário tem acesso. Ele não exibirá Engajamentos e Testes que o Usuário não tem permissão para visualizar. + +## Recursos + +### Visualização Mensal + +O calendário mensal exibe uma prévia de cinco entradas por dia. Entradas adicionais que ocorram naquele dia ficarão ocultas, a menos que **"+ [X] events"** seja clicado dentro da célula de uma determinada data. Uma vez clicado, o calendário mudará da visualização mensal para a visualização diária. + +Clicar em uma entrada de Teste ou Engajamento abrirá uma janela modal com informações adicionais sobre essa entrada, incluindo: +- Data de início e término +- Tipo de Teste ou Engajamento +- Responsável +- Status +- Asset +- Engajamento +- Teste + +A partir daí, o Asset, Engajamento ou Teste pode ser acessado por meio de um hyperlink. + +### Visualização Diária + +Na visualização diária, todos os Engajamentos e Testes atualmente ativos aparecem em ordem cronológica decrescente (ou seja, um Engajamento ou Teste recém-criado aparecerá na parte inferior das entradas daquele dia). Os Engajamentos aparecem em azul, enquanto os Testes aparecem em laranja. + +Se definido dentro do Engajamento/Teste aplicável, o título de cada entrada no calendário diário incluirá o seguinte: +- Status +- Produto +- Engajamento +- Teste +- Responsável + +#### Setas + +As setas nos lados esquerdo e direito de cada entrada indicam se aquele Teste ou Engajamento específico está presente no dia anterior e/ou no dia seguinte. + +Por exemplo, um Teste criado no mesmo dia em que está sendo visualizado não terá setas à esquerda, pois esse Teste não existia no dia anterior. Por outro lado, um Teste que termina no mesmo dia em que está sendo visualizado não terá setas à direita, pois a entrada não existirá no dia seguinte. + +Por exemplo, como o último Engajamento na captura de tela abaixo (**In Progress** Example Product A ▶ **Sample Engagement** (Unassigned)) está sendo visualizado no dia em que foi criado, e a Data de Término Alvo foi definida para o dia seguinte, não há setas presentes em nenhum dos lados. + +![image](images/calendar2.png) diff --git a/docs/content/asset_modelling/engagements_tests/PRO__engagements.pt-br.md b/docs/content/asset_modelling/engagements_tests/PRO__engagements.pt-br.md new file mode 100644 index 0000000000..11499cd987 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__engagements.pt-br.md @@ -0,0 +1,193 @@ +--- +title: Engajamentos +description: Entendendo Engajamentos no DefectDojo Pro +audience: pro +weight: 3 +--- + +Organizações → Assets → **ENGAJAMENTOS** → Testes → Achados + +## Visão Geral + +Na Hierarquia de Assets do DefectDojo, os Engajamentos são contêineres limitados por tempo ou por pipeline que representam grupos de Testes relacionados dentro de um Asset específico. Se você tem um esforço de teste planejado, seja em uma base rotineira ou pontual, um Engajamento oferece um local para armazenar todos os resultados relacionados. + +Exemplos de Engajamentos incluem: +- Testes de penetração pontuais +- Varreduras recorrentes mensais ou trimestrais +- Períodos de revisão de bug bounty +- Execuções de pipeline de CI/CD (para equipes que tratam cada pipeline como seu próprio Engajamento) +- Ciclos de lançamento de código (por exemplo, "revisão de segurança do lançamento v4.2") + +### Tipos de Engajamento + +O DefectDojo suporta dois tipos de Engajamento: **Interativo** e **CI/CD**. Esses tipos determinam como os Testes são normalmente criados e como os resultados de varredura são importados. + +Um Engajamento Interativo é normalmente executado por um engenheiro. Engajamentos Interativos são focados em testar uma aplicação enquanto ela está em execução, usando um teste automatizado, um testador humano ou qualquer atividade que "interaja" com a funcionalidade da aplicação. + +Um Engajamento de CI/CD é destinado à integração automatizada com um pipeline de CI/CD. Engajamentos de CI/CD têm como objetivo importar dados como uma ação automatizada, acionada por uma etapa do processo de lançamento. + +| **Categoria** | **Engajamentos Interativos** | **Engajamentos de CI/CD** | +|------------------------|--------------------------------------------------------------|--------------------------------------------------------------------| +| **Caso de Uso Principal** | Testes de segurança manuais ou pontuais | Testes de segurança automatizados e recorrentes dentro de pipelines | +| **Duração** | Limitada no tempo e finita | Duração potencialmente infinita | +| **Frequência** | Periódica ou pontual | Contínua ou a cada commit | +| **Fluxo de Trabalho** | Testador humano executa a ferramenta → importa os resultados manualmente | Pipeline executa a ferramenta → envia os resultados automaticamente para o DefectDojo | +| **Método de Importação de Resultados** | Upload manual via UI ou CLI | Importação orientada por API via automação (por exemplo, CLI, conectores, cron jobs, scripts de pipeline) | +| **Tipo de Teste Típico** | Testes de penetração, exercícios de red team, avaliações manuais | Análise estática, varredura de dependências, varredura de contêineres | + +### Dados do Engajamento + +Como os contêineres que organizam a atividade de teste, os Engajamentos podem armazenar ou rastrear uma variedade de dados: + +- Datas de início e término alvo +- Descrição e notas de escopo +- Status (em andamento, planejado, concluído, etc.) +- Responsável / Lead +- Testes associados (por exemplo, varreduras, pen tests, testes manuais, etc.) +- Achados e Tipos de Achado (por exemplo, ativo, mitigado, risco aceito, duplicado, etc.) +- Modelos de ameaça ou informações de aceitação de risco +- Tags +- Arquivos e notas +- Configurações de projeto do Jira +- Detalhes do ambiente (por exemplo, staging vs. produção) +- IDs de build (se vinculado a CI/CD) +- Dados históricos de Testes anteriores dentro do Engajamento + +## Acessando Engajamentos + +Os Engajamentos são acessíveis pela barra lateral. O submenu fornece acesso a Engajamentos Ativos e Todos os Engajamentos, além da opção de criar novos Engajamentos. + +![image](images/engagement_ss13.png) + +Alternativamente, os Engajamentos dentro de um Asset podem ser acessados na janela na parte inferior da visualização do Asset. + +![image](images/engagement_ss14.png) + +### Permissões + +Os Engajamentos ficam abaixo dos Assets e acima dos Testes na hierarquia de objetos. Dessa forma, o acesso a um Asset concede automaticamente acesso a todos os Engajamentos dentro desse Asset. Os Engajamentos não possuem listas de controle de acesso independentes. + +## Trabalhando com Engajamentos + +### Criar Engajamentos + +Antes de criar um Engajamento, você deve primeiro ter [criado um Asset](/asset_modelling/engagements_tests/pro__assets/#create-assets) para contê-lo. + +Existem várias maneiras de criar um Engajamento: + +- No menu suspenso de Engajamentos na seção Gerenciar da barra lateral + - Você precisará selecionar o Asset ao qual atribuir o Engajamento ao preencher o formulário de Novo Engajamento + +![image](images/engagement_ss1.png) + +- O ícone de engrenagem localizado no canto superior direito da visualização de um Asset + +![image](images/engagement_ss9.png) + +- O botão "+ New Engagement" encontrado na lista de Engajamentos dentro de um Asset + +![image](images/engagement_ss2.png) + +- Se você ainda não criou um Engajamento dentro de um Asset, pode fazê-lo durante a importação de uma varredura. + +![image](images/engagement_ss3.png) + +Todo Engajamento deve ter os seguintes campos definidos: +- Tipo (Interativo ou CI/CD) +- Um nome exclusivo +- Datas de início e término alvo + - Isso determinará a aparência do Engajamento na seção Calendário +- Asset +- Status + +#### Status do Engajamento + +Os Engajamentos podem ser marcados com diferentes status no momento da criação. O status também pode ser alterado posteriormente nas configurações do Engajamento. + +Um Engajamento pode ter qualquer um dos seguintes status: +- Não Iniciado +- Bloqueado +- Cancelado +- Concluído +- Em Andamento +- Em Espera +- Agendado +- Aguardando Recurso + +Alterar o status de um Engajamento para "Concluído" significa que a maioria das operações de escrita (por exemplo, adicionar testes, importar varreduras) ficará indisponível ou oculta. Outros status não afetam materialmente a funcionalidade do Engajamento, servindo mais para fins de filtragem/informação. + +### Editar Engajamentos + +Os Engajamentos podem ser editados clicando em **Edit Engagement** no menu de engrenagem. O mesmo menu também pode ser acessado clicando no menu kebab ⋮ à esquerda do Asset na visualização Todos os Assets. + +Todos os campos subsequentes que podem ser editados também estão disponíveis quando o Engajamento está sendo criado. + +![image](images/engagements_ss99.png) + +### Copiar Engajamentos + +Você pode duplicar Engajamentos facilmente selecionando "Copy Engagement" nas configurações do Engajamento. Isso criará uma cópia exata do Engajamento original dentro do Asset pai, incluindo os metadados, Testes e Achados presentes nele. + +### Fechar Engajamentos + +Os Engajamentos são fechados selecionando **Close Engagement** nas configurações do Engajamento. Uma vez fechado, o status do Engajamento será alterado para "Concluído". Ainda assim, a maioria das operações de escrita (por exemplo, adicionar testes, importar varreduras) permanecerá disponível. + +Fechar um Engajamento não altera o status dos Achados em nenhum dos Testes do Engajamento. Os Achados permanecem ativos, mitigados ou com risco aceito de acordo com seu próprio ciclo de vida, e continuam acessíveis para visualização e geração de relatórios. + +Se o Engajamento estiver vinculado a um Épico do Jira (veja **[Integração com o Jira: Habilitar Mapeamento de Épico de Engajamento](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**), fechar o Engajamento acionará uma tarefa assíncrona que fecha o Épico do Jira associado em seu Espaço do Jira conectado. + +### Reabrir Engajamentos + +Se um Engajamento estiver fechado, ele pode ser reaberto selecionando **Reopen Engagement** em suas configurações. Isso tornará o Engajamento ativo novamente e retornará seu status para "Em Andamento". + +### Engajamentos Expirados + +Um Engajamento expira assim que sua data de término alvo é ultrapassada. + +Em comparação com fechar ou excluir um Engajamento, a expiração de um Engajamento não tem impacto direto em sua funcionalidade, servindo principalmente como um mecanismo de monitoramento/notificação. + +Uma vez expirado, uma tag "Overdue" aparecerá ao lado do Engajamento, mas isso não restringirá nenhuma de suas funcionalidades. O status do Engajamento continuará aparecendo como "Em Andamento". + +Embora não esteja habilitada por padrão, há uma opção nas configurações do sistema para fechar automaticamente um Engajamento depois que ele tiver expirado por um determinado número de dias. + +![image](images/engagement_ss15.png) + +### Excluir Engajamentos + +A exclusão de um Engajamento pode ser realizada selecionando **Delete Engagement** nas configurações do Engajamento. Essa ação não pode ser desfeita. + +Excluir um Engajamento também excluirá o seguinte: +Qualquer Teste associado ao Engajamento +Todos os Achados dentro desses Testes +Qualquer mapeamento de Épico do Jira vinculado (o Épico em si permanecerá no Jira, mas o vínculo entre o DefectDojo e o Jira será removido) +Todas as notas e uploads de arquivos associados ao Engajamento + +Para fins de auditoria, recomenda-se fechar quaisquer Engajamentos concluídos, em vez de excluí-los. + +| **Operação** | **Resultados** | **Reversível** | +|----------|---------|------------| +| **Fechar** | Marca como inativo; os dados permanecem; pode ser reaberto | Sim (reabrir) | +| **Expirar** | Apenas aviso visual; fechamento automático opcional; notificações | N/A | +| **Excluir** | Remove permanentemente o Engajamento, Testes, Achados, notas, arquivos e quaisquer mapeamentos de Épico do Jira (os Épicos permanecem no Jira) | Não | + +## Integração com o Jira + +Os Engajamentos podem ser vinculados a um Espaço do Jira conectado, permitindo que os Achados dentro do Engajamento sejam enviados ao Jira como Issues. Para obter um guia completo sobre a configuração do Jira, veja **[Conectando o DefectDojo ao Jira](/connectors/downstream/pro__jira_guide/)**. + +### Mapeamento de Épico de Engajamento + +Quando **Enable Engagement Epic Mapping** está marcado nas configurações do Jira de um Produto, os Engajamentos serão enviados ao Jira como Épicos. Os Achados dentro do Engajamento são enviados como Issues filhas do Épico, espelhando a hierarquia Engajamento → Achados do DefectDojo na estrutura Épico → Issue do Jira. + +Para mais informações sobre essa configuração, veja **[Habilitar Mapeamento de Épico de Engajamento](/connectors/downstream/pro__jira_guide/#enable-engagement-epic-mapping)**. + +### Configurações do Jira em Nível de Engajamento + +Por padrão, os Engajamentos herdam suas configurações do Jira do Asset pai (Produto). No entanto, Engajamentos individuais podem sobrepor essas configurações para usar configurações diferentes do Jira. As seguintes configurações podem ser personalizadas por Engajamento: + +- **Project Key** — direciona os Achados para um Espaço do Jira diferente +- **Issue Template** — usa um modelo diferente para Issues criadas a partir deste Engajamento +- **Custom Fields** — aplica mapeamentos de campos personalizados diferentes +- **Jira Labels** — marca Issues com labels específicas do Engajamento +- **Default Assignee** — atribui Issues a um membro diferente da equipe + +Essas configurações são acessíveis na página **Edit Engagement**. Para mais detalhes, veja **[Configurações do Jira em Nível de Engajamento](/connectors/downstream/pro__jira_guide/#engagement-level-jira-settings)**. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__findings.pt-br.md b/docs/content/asset_modelling/engagements_tests/PRO__findings.pt-br.md new file mode 100644 index 0000000000..47f2872db7 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__findings.pt-br.md @@ -0,0 +1,275 @@ +--- +title: Achados +description: Entendendo os Achados no DefectDojo Pro +audience: pro +weight: 5 +--- + +Organizations → Assets → Engagements → Tests → **FINDINGS** + +## Overview +**Achados** representam o nível mais baixo da Hierarquia de Produtos, onde vulnerabilidades individuais são rastreadas e gerenciadas, e servem como a principal forma pela qual o DefectDojo padroniza e orienta o processo de reporte e remediação das suas ferramentas de segurança. Independentemente de uma vulnerabilidade ter sido reportada no SonarQube, Acunetix ou na ferramenta personalizada da sua equipe, os Achados oferecem a capacidade de gerenciar cada vulnerabilidade da mesma forma. + +Exemplos de Achados incluem: +- **Cookie Não Marcado como HttpOnly** +- **Versão Desatualizada (PHP)** +- **Avaliação de Código Fora de Banda (PHP)** +- **Versão Desatualizada (MySQL)** +- **Código-Fonte de Backup Detectado** +- **Cross-Site Scripting Cego** + +Além de armazenar os dados da vulnerabilidade e fornecer um framework de remediação, o DefectDojo também aprimora seus Achados das seguintes formas: +- Adicionando automaticamente as pontuações EPSS relacionadas a um Achado para descrever sua explorabilidade +- Traduzindo automaticamente a métrica de severidade de uma ferramenta de segurança em uma pontuação de Severidade para cada Achado, o que atribui um SLA ao Achado de acordo com a configuração de SLA do seu Ativo. Para mais informações sobre a configuração de SLA, clique [aqui](/asset_modelling/pro_hierarchy/priority_sla/#working-with-slas). + +No geral, os Achados são projetados para funcionar com a Hierarquia de Produtos, padronizando seus esforços e aplicando um método consistente a cada Ativo. + +## Accessing Findings +Os Achados são acessíveis pela barra lateral. O submenu oferece acesso aos Achados Ativos e Mitigados, Todos os Achados (independentemente do status Aberto ou Fechado), Grupos de Achados, Modelos de Achados e o fluxo de Novo Achado. Achados individuais também são acessíveis a partir do Teste que os contém. + +[Achados com Risco Aceito] (/triage_findings/findings_workflows/os__risk_acceptance/) são acessíveis a partir da seção **Aceitações de Risco** da barra lateral. + +![image](images/profindings_ss1.png) + +### Permissions +Todo Achado pertence a um Teste, o que permite que o DefectDojo preserve qual scan ou avaliação identificou originalmente a vulnerabilidade. + +Como os Achados pertencem a Testes, o acesso aos Achados é determinado pelo acesso do Usuário ao Ativo que contém o Teste. Os Testes não possuem listas de controle de acesso independentes. + +## Findings View +As visualizações de Achado contêm uma variedade de tabelas para ajudar a interpretar o status de um Achado rapidamente. + +### Finding Overview +- **Descrição**: A descrição do Achado (adicionada automaticamente dependendo do tipo de Achado, ou criada manualmente). +- **Mitigação**: Passos sugeridos para mitigar. +- **Política de Mitigação Geral**: A política de mitigação padronizada para o Achado selecionado. +As políticas de mitigação podem ser encontradas e editadas na barra lateral em **Configuration** → **Mitigation Policies**. +- **Impacto**: Impacto potencial de deixar o Achado sem solução. +- **Referências**: URL para referência cruzada com a descrição específica que a ferramenta de scan de terceiros dá ao Achado. Por exemplo, as Referências podem ser links para uma entrada relevante em um catálogo de Achados, ou uma única URL de advisory. +- **Arquivos**: Quaisquer arquivos que tenham sido adicionados para contextualizar o Achado. +- **Notas**: Notas deixadas por Usuários relacionadas ao Achado. Marcar uma nota como Privada significa que ela não será incluída em nenhum relatório gerado que contenha o Achado selecionado. + +### Metadata +- **ID**: O ID exclusivo do Achado no DefectDojo. +- **Organização, Ativo, Engajamento e Teste**: Os objetos pai do Achado selecionado. +- **Status**: O status do Achado (por exemplo, Ativo, Verificado, Falso positivo, Duplicado, Fora do escopo e Em Revisão de Defeito). +- **Severidade**: A classificação de severidade daquele Achado, aplicada automaticamente. + - Como mencionado acima, o DefectDojo traduz automaticamente a métrica de severidade de uma ferramenta de segurança em uma pontuação de Severidade para cada Achado, o que atribui um SLA ao Achado de acordo com a configuração de SLA do seu Ativo. +- **Risco**: Um sistema de classificação de 4 níveis que leva em conta a explorabilidade de um Achado e é aplicado automaticamente. + - Detalhes sobre como a prioridade, o risco e os SLAs são calculados podem ser encontrados [aqui](/asset_modelling/pro_hierarchy/priority_sla/#main-content). Mais detalhes sobre as definições de status e nível de risco do Achado podem ser encontrados [aqui](/triage_findings/findings_workflows/finding_status_definitions/). +- **Prioridade**: Uma classificação numérica calculada, aplicada a todos os Achados, que permite entender rapidamente as vulnerabilidades em contexto. +- **Idade**: Há quanto tempo existe o Achado selecionado. +- **SLA**: A data limite prevista para a resolução do Achado. +- **Tipo**: Se o Achado foi detectado por uma ferramenta de segurança de aplicação estática ou dinâmica (Static, Dynamic ou Static/Dynamic). +- **Localização e Linha**: O arquivo e o número da linha em que o Achado selecionado foi encontrado. +- **Nome e Versão do Componente**: O nome e a versão do componente em que o Achado selecionado foi encontrado. +- **Data de Descoberta**: A data em que o Achado foi descoberto. +- **Data e Versão de Remediação Planejada**: A data em que o Achado deve ser remediado, e a versão do componente afetado na qual a correção será implementada. +- **Serviço**: Serviços Conectados (partes autocontidas de funcionalidade dentro de um Ativo) que são afetados pelo Achado selecionado. Quando preenchido, esse campo é incluído na correspondência de deduplicação (ou seja, Achados com campos de Serviço idênticos serão deduplicados). +- **Relator**: O Usuário que revelou o Achado. +- **CWE**: A classificação de fraqueza CWE do Achado. Um Achado pode ter **múltiplos CWEs** — um CWE primário, mais quaisquer CWEs adicionais fornecidos pela ferramenta de reporte. O CWE primário é o utilizado para deduplicação legada e cálculo de hash code; o conjunto completo de CWEs também pode ser usado para correspondência por meio dos Hash Code Fields baseados em conjunto do Pro (veja [Ajuste de Deduplicação](/triage_findings/finding_deduplication/pro__deduplication_tuning/#set-based-hash-code-fields-vulnerability-ids-and-cwes)). + - Um CWE descreve uma *classe* de fraqueza (por exemplo, "SQL Injection"), não uma instância específica de vulnerabilidade — é para isso que servem os IDs de Vulnerabilidade. +- **IDs de Vulnerabilidade**: Identificadores de vulnerabilidade publicamente reconhecidos associados ao Achado, como CVE, GHSA, ou outras referências de advisory padronizadas. No DefectDojo Pro, eles também são usados para realizar consultas de EPSS e KEV. + - Os IDs de Vulnerabilidade são armazenados como registros de primeira classe, de modo que o mesmo CVE é rastreado uma única vez e compartilhado por todo Achado que o referencia. Você pode revisá-los — junto com seus valores de EPSS e KEV — no **Vulnerability Explorer**. Veja [EPSS / KEV](/triage_findings/finding_scoring/epss_kev/#viewing-kevepss-in-the-vulnerability-explorer). +- **Unique ID From Tool**: Um identificador estável atribuído pela ferramenta de origem a uma instância específica de Achado. Os Unique IDs devem permanecer consistentes entre scans repetidos, permitindo que a ferramenta reconheça o mesmo Achado ao longo do tempo. + - Diferentemente dos IDs de Vulnerabilidade, esse valor é proprietário da ferramenta de reporte e não é uma referência pública de vulnerabilidade. + - Exemplo: `finding-12345` +- **Vulnerability ID From Tool**: Um identificador proprietário de vulnerabilidade ou regra, atribuído pela ferramenta de origem para descrever o tipo de vulnerabilidade detectada. + - Diferentemente do Unique ID From Tool, esse identificador não é exclusivo de um Achado individual e pode aparecer em vários Achados que correspondem à mesma regra de detecção. + - Diferentemente dos IDs de Vulnerabilidade, esses identificadores são específicos da ferramenta de reporte e não são padronizados publicamente. + - Exemplo: `semgrep.rule.lang.security.sql-injection` +- **EPSS Score / Percentile**: A pontuação e o percentil de EPSS para o CVE. +- **Known Exploited**: Se há confirmação de que a vulnerabilidade foi explorada. +- **Ransomware Used**: Se houve uso de ransomware na exploração da vulnerabilidade. +- **KEV Date**: A data em que o Achado foi adicionado ao catálogo KEV. +- **Found By**: O tipo de ferramenta que identificou a vulnerabilidade. +- **CVSSv3 and CVSSv4 Vector and Score**: O vetor e a pontuação CVSS3 e CVSS4 do Achado selecionado. +- **Integrator Tickets**: Números de tickets de rastreadores de issues de terceiros associados ao Achado. + +### Vulnerable Endpoints +Esta seção inclui uma tabela dos Endpoints afetados pelo Achado selecionado, junto com quaisquer metadados relevantes. + +### Additional Details +- **Request/Response Pairs**: Uma cópia da mensagem enviada pelo cliente e da resposta do servidor à requisição. +- **Steps to Reproduce**: Passos para reproduzir o Achado. +- **Severity Justification**: Descrição por escrito de por que uma determinada classificação de Severidade foi associada ao Achado. + +## Findings Data +Os Achados exigem os seguintes metadados: +- **Nome** +- **Data** +- **Severidade** +- **Descrição** + +Além dos metadados correspondentes às tabelas na visualização de um Achado, os campos de metadados opcionais incluem: +- **Tags**: Quaisquer tags que tenham sido adicionadas ao Achado. +- **Owners**: O grupo de usuários que será responsável pelo Achado selecionado. +- **Push to Jira**: Envia o Achado para o Jira para fins de emissão de tickets. +- **Push to Integrator**: Envia o Achado para quaisquer rastreadores de issues de terceiros integrados. +- **Configurações de risco e prioridade**: Oferece a opção de substituir o cálculo automático que o DefectDojo faz do risco e da prioridade do Achado. +- **Endpoints a adicionar**: Endpoints vulneráveis que podem ser afetados pelo Achado selecionado e que não estão refletidos na lista anterior de sistemas/endpoints. +- **Revisão de defeito solicitada por**: Registra quem solicitou uma revisão de defeito para a falha em questão. +- **Objeto de origem SAST, número da linha e caminho do arquivo**: Objeto de origem, número da linha e caminho do arquivo do vetor de ataque. +- **Objeto de destino (sink) SAST**: Objeto de destino do vetor de ataque. +- **Número de ocorrências**: Número de ocorrências na ferramenta de origem quando várias vulnerabilidades foram encontradas e agregadas pelo scanner. +- **Data de publicação**: A data em que a vulnerabilidade foi publicada. +- **Estimativa de esforço**: O nível de esforço envolvido na correção do Achado (por exemplo, Baixo, Médio ou Alto). + +Os metadados exatos disponíveis dependerão do parser/scanner que revelou o Achado. Alguns fornecem apenas informações básicas, como título e severidade, enquanto outros incluem vetores CVSS, componentes vulneráveis, endpoints, pares de requisição/resposta e outros metadados específicos do scanner. + +Esses metadados melhoram a filtragem, os relatórios e a priorização em todo o seu programa de segurança, permitindo o rastreamento de longo prazo e a análise de tendências. Detalhes adicionais e descrições de metadados podem ser encontrados [aqui](/triage_findings/findings_workflows/intro_to_findings/#a-finding-page). + +### Deduplication +O DefectDojo inclui recursos de deduplicação que ajudam a identificar e gerenciar Achados que representam a mesma vulnerabilidade subjacente. À medida que os resultados de scan são importados de uma ou mais ferramentas, o DefectDojo usa uma lógica de correspondência configurável para identificar Achados que representam a mesma vulnerabilidade. + +A deduplicação evita que a mesma vulnerabilidade apareça múltiplas vezes quando descoberta repetidamente pelo mesmo scanner ou por scanners diferentes, permitindo que o histórico de remediação permaneça vinculado a um único Achado. + +Mais informações sobre deduplicação podem ser encontradas [aqui](/triage_findings/finding_deduplication/about_deduplication/). + +### Reimport +A função de Reimportação do DefectDojo permite que os Achados sejam atualizados à medida que novos resultados de scan são importados. Quando um scan é reimportado, o DefectDojo compara os resultados recebidos com os Achados existentes e atualiza os registros correspondentes em vez de criar registros inteiramente novos. Isso preserva contexto valioso, como mudanças de status, histórico de remediação, comentários e informações de propriedade, fornecendo um registro contínuo do ciclo de vida de um Achado ao longo de múltiplos ciclos de teste. + +Mais informações sobre a função de Reimportação podem ser encontradas [aqui](/import_data/import_intro/reimport/). + +### Risk Acceptances +As Aceitações de Risco são um status especial que pode ser aplicado aos Achados para documentar formalmente e operacionalizar a decisão de reconhecê-los sem remediá-los imediatamente. + +Mais informações sobre Aceitações de Risco podem ser encontradas [aqui](/triage_findings/findings_workflows/pro__risk_acceptance/). + +### Statuses +Cada Achado criado no DefectDojo possui um Status que comunica informações relevantes e ajuda sua equipe a acompanhar o progresso na resolução dos problemas. + +Mais informações sobre Status podem ser encontradas [aqui](/triage_findings/findings_workflows/finding_status_definitions/). + +## Working with Findings + +### Creating Findings +Embora a maioria dos Achados seja gerada automaticamente por meio de importações de scan e integrações, o DefectDojo também oferece suporte à criação manual de Achados. Achados manuais são úteis para rastrear vulnerabilidades e questões de segurança identificadas por meio de testes de penetração, revisões de arquitetura, avaliações de conformidade, programas de bug bounty, engajamentos de consultoria ou outras atividades que não produzem saída de scanner. + +Os Achados podem ser adicionados manualmente clicando em **Novo Achado** na seção **Findings** da barra lateral, ou selecionando **Adicionar Achado** no menu de engrenagem do Teste ao qual você deseja adicionar o Achado. + +### Editing Findings +O menu kebab ⋮ ao lado dos Achados contém as seguintes funções: +- **Editar Achado**: Edita o Achado. +- **Copiar Achado**: Cria uma cópia do Achado em outro Teste. A cópia pode ser salva em qualquer Teste dentro do mesmo Engajamento para o qual você tenha permissão de edição. Copiar é útil quando a mesma vulnerabilidade precisa ser rastreada separadamente em mais de um contexto de Teste. +- **Fechar Achado**: Inicia o processo de fechamento do Achado. +- **Solicitar Revisão**: Inicia o processo de Revisão por Pares e altera o status do Achado para "Under Review." Mais informações sobre Revisões por Pares podem ser encontradas [aqui](/triage_findings/findings_workflows/finding_status_definitions/#under-review). +- **Adicionar Aceitação de Risco**: Inicia o processo de Aceitação de Risco. Mais informações podem ser encontradas [aqui](/triage_findings/findings_workflows/pro__risk_acceptance/). +- **Adicionar Arquivo**: Inicia o processo de adicionar um arquivo ao Achado (veja a seção abaixo). +- **Adicionar Nota**: Inicia o processo de adicionar uma nota ao Achado. +- **Adicionar Campo Personalizado**: Abre um pop-up que permite adicionar e definir um campo personalizado para aplicar ao Achado. +- **Push to Jira**: Envia o Achado para o Jira para fins de emissão de tickets. +- **Push to Integrator**: Envia o Achado para quaisquer rastreadores de issues de terceiros integrados. +- **Excluir Achado**: Exclui o Achado selecionado. +- **Histórico do Achado**: Revela o histórico do Achado selecionado. + +#### Attaching Files to Findings +Você pode anexar arquivos a qualquer Achado para fornecer contexto adicional — por exemplo, uma captura de tela de uma vulnerabilidade em ação ou uma imagem de prova de conceito. + +Os tipos de arquivo suportados incluem: + +``` +.txt .pdf .json .xml .csv .yml .png .jpeg +.sarif .xlsx .doc .html .js .nessus .zip .fpr +``` + +Para anexar um arquivo a um Achado, clique em **Adicionar Arquivo** no menu kebab ⋮ ou no menu de engrenagem do Achado selecionado. Digite um Título para o arquivo, escolha o arquivo no seu computador e clique em **Enviar**. + +O arquivo então aparecerá na seção Arquivos da tabela **Test Overview** dentro da visualização do Achado. + +#### Bulk Edit Findings +Os Achados podem ser editados em massa a partir de uma Lista de Achados, como a tabela de Todos os Achados acessível pela barra lateral, ou a partir da tabela de Achados dentro de um Teste específico. + +Mais informações sobre como editar Achados em massa podem ser encontradas [aqui](/triage_findings/findings_workflows/editing_findings/#bulk-edit-findings). + +### Closing Findings +Depois que o trabalho em um Achado for concluído, você pode fechá-lo manualmente clicando em **Fechar Achado** no menu kebab ⋮ ou no menu de engrenagem do Achado. Alternativamente, se um scan for reimportado no DefectDojo e não contiver um Achado registrado anteriormente, esse Achado registrado anteriormente será fechado automaticamente. + +Se você não quiser que nenhum Achado seja fechado, é possível desabilitar esse comportamento no formulário de Reimportação de Scan: + +- Desmarque a caixa de seleção Close Old Findings se estiver usando a UI +- Defina close_old_findings como False se estiver usando a API ​ + +### Deleting Findings +A exclusão de um Achado pode ser feita a partir do menu kebab ⋮ ou do menu de engrenagem do Achado. Essa ação não pode ser desfeita. + +Para fins de auditoria, recomenda-se fechar os Achados remediados em vez de excluí-los. + +## Finding Groups +**Grupos de Achados** permitem tratar múltiplos Achados relacionados como uma única unidade lógica para triagem, relatórios e coordenação de remediação. + +Por exemplo, um scan pode produzir 10 Achados de SQL injection em diferentes endpoints. Em vez de gerenciar cada um independentemente, você pode agrupá-los em um único Grupo de Achados que represente o problema mais amplo de SQL injection. + +Um Grupo de Achados não substitui os Achados individuais. Cada Achado continua existindo com sua própria severidade, status, metadados, comentários e histórico de remediação. Um Grupo de Achados simplesmente fornece uma camada organizacional adicional acima dos Achados que ele contém. + +### Accessing Finding Groups +Os Grupos de Achados podem ser acessados pela barra lateral. O submenu oferece acesso aos Grupos de Achados Abertos e Fechados, bem como a Todos os Grupos de Achados (independentemente do status de Aberto). + +![image](images/profindings_ss1.png) + +### Creating Finding Groups +Os Grupos de Achados podem ser criados manualmente ou automaticamente. + +Vale destacar que os Grupos de Achados só podem ser criados a partir dos Achados contidos em um único Teste. Achados de Testes, Engajamentos ou Produtos diferentes não podem ser adicionados ao mesmo Grupo de Achados. + +#### Manual Finding Groups +Para realizar ações de Grupo de Achados manualmente: +1. Navegue até uma lista de Achados dentro de um Teste. +2. Selecione o(s) Achado(s) que deseja adicionar a um Grupo de Achados clicando na caixa de seleção correspondente do Achado. +3. Clique no botão **Finding Group** que aparece no topo da lista de Achados. +4. Clique na ação correspondente que deseja realizar. + - **Adicionar a Novo Grupo de Achados**: Cria um novo Grupo de Achados que inclui os Achados selecionados. + - **Adicionar a Grupo de Achados Existente**: Adiciona os Achados selecionados a um Grupo de Achados pré-existente. + - **Remover de Grupo de Achados**: Remove os Achados selecionados de quaisquer Grupos de Achados dos quais faziam parte anteriormente. +5. Clique em **Enviar**. + +Observe que o agrupamento ficará desabilitado a menos que todo achado selecionado seja editável, não esteja agrupado e esteja no mesmo Teste. + +Além disso, observe que a única ação possível ao selecionar Achados na lista Todos os Achados é remover os Achados selecionados de qualquer Grupo de Achados. Isso ocorre porque, como mencionado, os Grupos de Achados só podem ser criados a partir dos Achados contidos em um único Teste. + +#### Automatic Finding Groups +Ao importar um scan, o recurso **Group By** dentro do menu recolhível **Optional Fields** pode criar Grupos de Achados automaticamente com base em um método de agrupamento escolhido. Isso é útil quando um scanner produz muitos Achados relacionados que devem ser gerenciados em conjunto. + +A caixa de seleção adjacente **Create Finding Groups for all Findings** desempenha duas funções: +- **Marcada**: Cria um Grupo de Achados para cada Achado importado, mesmo que esse Achado seja o único membro do grupo. +- **Desmarcada**: Cria Grupos de Achados somente quando há de fato múltiplos Achados para agrupar. + +![image](images/profindings_ss2.png) + +Se nenhuma opção for selecionada no menu suspenso Group By durante a importação (por exemplo, **Finding Title** na captura de tela acima, etc.), nenhum agrupamento ocorrerá. + +Se o critério de agrupamento (por exemplo, nome do componente, ID de vulnerabilidade, título do Achado, etc.) não estiver preenchido no Achado, nenhum grupo será criado para ele, nem ele será adicionado a um Grupo de Achados pré-existente. + +Se um scan for importado e revelar 10 Achados que não são agrupados, e o mesmo scan for reimportado com os Achados agrupados, os 10 primeiros Achados não serão adicionados a esse Grupo de Achados (ou seja, o Grupo de Achados incluirá apenas os 10 Achados da reimportação, não os 10 Achados da importação inicial). + +## Finding Templates +**Modelos de Achado** permitem que os Usuários criem modelos reutilizáveis para vulnerabilidades e questões de segurança relatadas com frequência. Um modelo pode incluir informações padronizadas, como título, descrição, impacto, passos para reproduzir, mitigação, referências e outros metadados do Achado. + +Os Modelos de Achado são mais úteis em situações em que os Usuários precisam criar Achados manuais repetidamente e desejam evitar reinserir as mesmas informações de apoio a cada vez. + +### Accessing Finding Templates +Os Modelos de Achado são encontrados no submenu Findings, na barra lateral. + +![image](images/profindings_ss1.png) + +### Creating Finding Templates +Os Modelos de Achado podem ser criados clicando no botão **New Finding Template** no canto superior esquerdo da visualização de Modelos de Achado. + +A página seguinte fornece uma visão geral dos metadados que serão aplicados a um Achado quando um Modelo de Achado for usado. + +### Applying Finding Templates +Os Modelos de Achado diferem entre o DefectDojo OS e o DefectDojo Pro. No Pro, os Modelos de Achado não podem ser aplicados a Achados pré-existentes, nem podem ser criados a partir de Achados pré-existentes. + +No entanto, você pode adicionar manualmente um Achado a um Teste com base em um Modelo de Achado usando o menu kebab ⋮ ao lado do Teste na visualização do Engajamento pai, ou usando o menu de engrenagem na visualização do Teste. + +![image](images/profindings_ss3.png) + +![image](images/profindings_ss4.png) + +## Reporting +O construtor de relatórios do DefectDojo permite montar um relatório personalizado a partir de um conjunto de widgets de conteúdo, executá-lo e exportar o resultado (por exemplo, imprimindo-o em PDF). Relatórios personalizados podem resumir os Achados ou Endpoints que você deseja compartilhar com um público externo, e podem incluir branding e texto padrão. + +Mais informações sobre o Report Builder do DefectDojo podem ser encontradas [aqui](/metrics_reports/reports/report-builder/). + +### Export Findings +Páginas que exibem uma lista de Achados ou uma lista de Engajamentos possuem uma opção de exportação em CSV e Excel no canto superior esquerdo. Para Achados, também há a opção de realizar uma Exportação Rápida, que abrirá uma nova aba com tabelas de metadados referentes a cada Achado. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__organizations.pt-br.md b/docs/content/asset_modelling/engagements_tests/PRO__organizations.pt-br.md new file mode 100644 index 0000000000..16be9bff65 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__organizations.pt-br.md @@ -0,0 +1,140 @@ +--- +title: Organizações +description: Entendendo as Organizações no DefectDojo Pro +audience: pro +weight: 1 +--- + +**ORGANIZAÇÕES** → Assets → Engagements → Tests → Findings + +## Overview + +**Organizações** ficam no topo da hierarquia de produtos do DefectDojo. As Organizações são distintas dos objetos descendentes na hierarquia — Ativos, Engajamentos, Testes e Achados — porque não são alvos técnicos de scan, mas sim servem principalmente como abstrações organizacionais que compartimentam seus esforços de segurança de acordo com: +- Domínio de negócio +- Equipe de desenvolvimento +- Equipe de segurança +- Aplicações de software +- Família de produtos abrangente +- Cliente ou subsidiária +- Estrutura de relatórios +- etc. + +O tema dos exemplos acima ilustra a utilidade essencial das Organizações: elas devem, de modo geral, representar limites estáveis e duradouros dentro do seu programa de segurança. + +## Organization Data and Structure + +Como as Organizações não são escaneadas diretamente, o único campo obrigatório para criá-las é um nome. Além disso, elas atuam como contêineres para Ativos e seus Engajamentos, Testes e Achados descendentes. + +Ao criar uma Organização, considere como sua estrutura vai influenciar seus relatórios. Você precisa principalmente que as Organizações representem as equipes que trabalham nos projetos (Ativos) que as Organizações conterão? Ou as Organizações representariam melhor projetos abrangentes que contêm diferentes iterações dos projetos (Ativos) dentro deles? + +Se você tiver uma única Organização que contenha todas as informações relevantes para um determinado domínio de negócio ou equipe de desenvolvimento, representar isso como uma Organização facilitará relatórios mais fluidos, em vez de precisar reunir um relatório a partir de vários Ativos e Organizações. + +Se um projeto de software específico tiver muitos deployments ou versões distintas, pode valer a pena criar uma única Organização que cubra o escopo de todo o projeto, com cada versão existindo como Ativos individuais. Em alguns fluxos de trabalho, as Organizações também podem ser usadas para separar estágios do ciclo de vida do software: uma Organização para “Em Desenvolvimento”, uma Organização para “Em Produção”, etc. +​ +As Organizações podem ser usadas para determinar o acesso a subsidiárias, empresas adquiridas ou outras unidades de negócio regulamentadas para fins de RBAC. Em empresas complexas, onde há muitos projetos exclusivos com diferentes regras de acesso, as Organizações são particularmente relevantes. + +Em última análise, a decisão de como usar Organizações e Ativos depende de como você deseja refletir melhor sua estrutura organizacional exclusiva e as necessidades da sua equipe de segurança. + +Abaixo estão algumas estruturas de exemplo para orientar como você designa seus objetos como Organizações ou Ativos. + +- **Organização**: Divisão de Pagamentos + - Ativo: Payments API - Production + - Ativo: Payments API - Staging + - Ativo: Billing Worker + +- **Organização**: Software Product A + - Ativo: Web Portal + - Ativo: Mobile Backend + +Além disso, o guia a seguir ilustra se algo é melhor representado por uma Organização ou por um Ativo: + +| Organizações | Ativos | +|--------------|--------| +| Unidades de negócio | Aplicações individuais | +| Departamentos | Deployments/ambientes | +| Domínios de propriedade de segurança | Componentes de infraestrutura | +| Famílias de produtos | Microsserviços específicos | +| Relatórios em nível de portfólio | Alvos de scan | +| Clientes | Versões específicas de software | + +Como observado, sua estrutura pode variar de acordo com as necessidades exclusivas de segurança da sua equipe. + +## Accessing Organizations + +As Organizações são acessíveis pela barra lateral. O submenu oferece acesso a Todas as Organizações, bem como a opção de criar uma nova Organização. + +![image](images/org_ss1.png) + +## Organization View + +A visualização de uma Organização contém uma variedade de tabelas e gráficos para interpretar seu status rapidamente. Isso inclui: + +- **Descrição** +- **Commerce** + - Se a Organização foi determinada como Crítica ou Chave + - Marcar Crítica ou Chave é usado exclusivamente para fins de filtragem +- **Membros Atribuídos** (Usuários do DefectDojo) +- **Grupos de Usuários Atribuídos** + - Grupos de usuários que foram atribuídos à Organização para controle de permissões. Mais informações sobre grupos de usuários podem ser encontradas [aqui](/admin/user_management/create_user_group/). +- **Lista de Ativos dentro da Organização** + +## Working with Organizations + +### Create Organizations + +Existem duas formas de criar Organizações: + +- Pela opção **Nova Organização** no menu lateral +- Pelo botão **Nova Organização** no topo da lista de Todas as Organizações + +### Edit Organizations + +As Organizações podem ser editadas clicando em **Editar Organização** no menu de engrenagem no canto superior direito da visualização da Organização. O mesmo menu também pode ser acessado clicando no menu kebab ⋮ à esquerda da Organização na visualização de Todas as Organizações. + +Todos os campos subsequentes que podem ser editados também estão disponíveis quando a Organização está sendo criada. + +### Delete Organizations + +A exclusão de uma Organização pode ser realizada selecionando **Excluir Organização** nas configurações da Organização. + +Como as Organizações ficam no topo da hierarquia, excluí-las remove todo o histórico de segurança, relacionamentos e objetos filhos posteriores, tais como: +- Quaisquer Ativos, Engajamentos e Testes contidos na Organização +- Todo o histórico de segurança associado, incluindo Achados e integrações +- Quaisquer Jira Epics vinculados +- Todas as notas e uploads de arquivos associados aos Ativos, Engajamentos e Testes dentro dessa Organização + +A exclusão de uma Organização não pode ser desfeita. Se você quiser “desativar” uma organização sem excluir os dados subjacentes (por exemplo, preservando registros legados de testes de software para fins de auditoria), você pode alterar o nome da Organização ou adicionar uma Tag para indicar que ela está em um estado obsoleto. + +## Organiations vs. Metadata + +As Organizações têm como objetivo representar limites estruturais de propriedade ou de relatório, e não classificações leves. Atributos como status de deployment, rótulos internos ou estados temporários de fluxo de trabalho podem ser melhor representados por meio de tags ou metadados, em vez de Organizações separadas. + +## Organization Boundaries + +As Organizações estabelecem limites de relatório e de acesso dentro do DefectDojo. Como integrações, permissões de RBAC, propriedade, métricas e modelos de deduplicação frequentemente herdam a estrutura das Organizações, projetar limites claros desde o início ajuda a evitar a expansão descontrolada da hierarquia e a fragmentação de relatórios mais tarde. + +### Findings and Automation + +Embora as integrações geralmente sejam configuradas em objetos de nível inferior, como Ativos, Engajamentos ou Achados, as Organizações ainda definem os limites de propriedade, relatório e acesso dentro dos quais essas integrações operam. + +As permissões são propagadas em cascata para baixo, o que significa que o acesso a uma Organização concede automaticamente acesso a todos os objetos dentro dessa Organização (por exemplo, Ativos, Engajamentos, Testes e Achados). + +O modelo de RBAC do DefectDojo pode ser usado para controlar o acesso de usuários humanos, mas também pode restringir o acesso de tokens de API a Organizações específicas. + +Para mais informações sobre papéis de usuário, veja nosso artigo [Introdução aos Tipos de Permissão](/admin/user_management/set_user_permissions/#introduction-to-permission-types). + +### Ownership + +Como objetos de nível superior, as Organizações também implicam a propriedade sobre os objetos filhos que contêm. O rastreamento de SLA, os fluxos de trabalho de remediação, o roteamento de tickets e a governança geral fluem de forma mais tranquila quando as Organizações são configuradas para refletir com precisão os indivíduos responsáveis por elas. + +### Metrics/Reporting + +Painéis, tiles e visualizações de métricas podem ser filtrados por Organização, o que os torna um componente crítico na forma como seus dados de segurança são calculados, visualizados e, por fim, exportados. + +Para fins de relatório, geralmente é mais fácil combinar várias Organizações em um único documento do que subdividir uma única Organização em documentos separados. Por isso, recomendamos configurar as Organizações no nível de granularidade que fizer mais sentido para os relatórios da sua equipe. Por exemplo, não há necessidade de representar uma grande divisão de negócios como uma Organização se você for reportar principalmente para departamentos individuais dentro dessa divisão. + +Estruturar efetivamente suas Organizações para refletir suas necessidades de relatório é fundamental para avaliar com precisão sua postura de segurança. Para mais informações sobre Métricas, clique [aqui](/metrics_reports/pro_metrics/pro__overview/). + +### Deduplication + +A deduplicação no DefectDojo ocorre no nível do Ativo, e não é afetada pela Organização pai. diff --git a/docs/content/asset_modelling/engagements_tests/PRO__tests.pt-br.md b/docs/content/asset_modelling/engagements_tests/PRO__tests.pt-br.md new file mode 100644 index 0000000000..03d245b9ce --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/PRO__tests.pt-br.md @@ -0,0 +1,285 @@ +--- +title: Testes +description: Entendendo os Testes no DefectDojo Pro +audience: pro +weight: 4 +--- + +Organizações → Ativos → Engajamentos → **TESTES** → Achados + +## Visão geral + +Um Teste é um contêiner para uma ou mais execuções de scan, usadas para descobrir falhas em um Ativo. Os Testes são o componente final e mais granular da hierarquia de objetos do DefectDojo, servindo como o contêiner para os Achados resultantes da execução de uma ferramenta de segurança ou de uma avaliação manual, além de adicionar o contexto no qual esses Achados foram encontrados (ou seja, qual ferramenta os reportou, quando essa ferramenta foi executada pela última vez, etc.). + +Exemplos de Testes incluem: +- Teste Estático de Segurança de Aplicações +- Teste Dinâmico de Segurança de Aplicações +- Análise de Composição de Software +- Varreduras de Segurança de Contêineres +- Varreduras de Infraestrutura / Rede +- Testes de Penetração Manuais +- Varreduras de Pipeline de CI/CD + +### Tipos de Teste + +Existem várias maneiras de criar Testes no DefectDojo, incluindo **parsers específicos de fornecedor** (por exemplo, Burp, OWASP ZAP, Acunetix, Invicti), **Generic Findings Import**, **Universal Parser** e **Connectors**. + +Esses métodos podem criar novos Testes ou reimportar Achados em Testes existentes, dependendo da configuração e da estratégia de deduplicação. + +Embora cada método difira principalmente na forma como os dados de scan são analisados e ingeridos, todos eles resultam, em última instância, na associação de Achados a um Teste. + +#### Parsers + +**Parsers** são componentes que processam formatos específicos de saída de scan (por exemplo, XML, JSON, CSV) e os mapeiam para o modelo interno de Achado do DefectDojo. Quando os resultados de um scan são importados, o DefectDojo usa o parser selecionado para extrair os Achados e anexá-los a um Teste recém-criado ou existente. + +#### Generic Findings Import + +Quando não existe um parser nativo para uma determinada ferramenta, o [**Generic Findings Import**](/supported_tools/parsers/generic_findings_import) permite importar achados usando um schema padronizado em JSON ou CSV, independentemente da origem original. + +O DefectDojo analisa os dados fornecidos, cria um novo Teste (ou importa para um já existente) e anexa os Achados. Um Tipo de Teste correspondente também é criado com base no campo opcional `type` do relatório: quando `type` é omitido (ou é igual ao tipo de scan) o Tipo de Teste é "Generic Findings Import"; quando `type` é fornecido, ele se torna "`{type}` Scan (Generic Findings Import)" (um `type` que já termina com o sufixo "(Generic Findings Import)" é usado literalmente). + +#### Universal Parser + +O [**Universal Parser**](/supported_tools/parsers/universal_parser) permite que os usuários definam como dados de entrada arbitrários são mapeados para o modelo de Achado do DefectDojo. Depois de configurar o parser e enviar os dados do scan, o DefectDojo aplica as regras de mapeamento para extrair os Achados, cria um Teste (ou atualiza um já existente) e associa os Achados a esse Teste. + +#### Connectors + +Os [**Connectors**](/connectors/upstream/about/) podem ser usados para ingerir e organizar automaticamente dados de vulnerabilidades de ferramentas externas por meio de chamadas de API. Uma vez configurado, um Connector busca os resultados do scan, analisa os dados e cria novos Testes ou atualiza Testes existentes, dependendo de sua configuração. Os Achados são então anexados ao Teste correspondente. + +#### Comparação dos Mecanismos de Criação de Teste + +| | **Parsers Nativos** | **Generic Findings Import** | **Universal Parser (Pro)** | **Connectors** | +|----------|---------------|------------------------|------------------------|------------| +| **Finalidade principal** | Ingerir saídas de ferramentas suportadas | Ingerir dados não suportados/personalizados por meio de um schema fixo | Ingerir formatos arbitrários por meio de mapeamentos configuráveis | Sincronizar continuamente sistemas externos | +| **Formato de entrada** | Específico da ferramenta (por exemplo, ZAP XML, SARIF) | Schema JSON/CSV rígido | Arbitrário (JSON, XML etc.) | Respostas de API externas | +| **Quem realiza a normalização** | DefectDojo (parser integrado) | Usuário (deve seguir o schema) | DefectDojo (via configuração do parser) | Ferramenta externa + DefectDojo | +| **Gatilho de criação do Teste** | Upload manual ou importação via API | Upload manual ou importação via API | Upload manual ou importação via API | Sincronização automatizada (agendada ou orientada por evento) | +| **Tipo de Teste** | Predefinido (por exemplo, "ZAP Scan") | Tipo "Generic" criado automaticamente | Derivado da configuração do parser | Depende do connector / parser subjacente | +| **Esforço de configuração** | Baixo | Moderado (requer transformação de dados) | Alto (configuração do parser) | Moderado–Alto (configuração da integração) | +| **Flexibilidade** | Baixa (apenas ferramentas suportadas) | Média | Alta | Média–Alta | +| **Nível de automação** | Baixo–Moderado | Baixo–Moderado | Baixo–Moderado | Alto | +| **Caso de uso típico** | Scanners padrão (SAST, DAST, SCA) | Scripts personalizados, ferramentas não suportadas | Formatos complexos/personalizados em escala | Integrações de CI/CD, SCM ou plataforma | + +Independentemente do método de ingestão, todos os dados de scan no DefectDojo são, em última instância, representados como Achados anexados a um Teste, que serve como a unidade de execução e de acompanhamento do ciclo de vida. + +### Dados do Teste + +Os Testes armazenam uma variedade de metadados que ajudam a documentar vários componentes de cada esforço de teste, como: +- Título / nome do Teste +- Tipo de Teste +- Descrição / notas do Teste +- Data de início e término +- O Ambiente em que o Teste foi executado (por exemplo, Development, Staging, Pre-Production, Production, etc.) +- Versão / Branch / Build ID / Commit Hash +- Configuração de scan de API +- Pessoal associado ao Teste +- Arquivos adicionais que podem ser usados para auditorias ou reimportações futuras +- O Engajamento, o Ativo e a Organização pai +- Histórico de importação e reimportação + +Cada Teste mantém um histórico de importação, que registra todas as importações e reimportações de scan associadas ao Teste. Cada item do histórico inclui metadados como data do scan, versão, branch, commit hash e build ID. + +Esse histórico proporciona rastreabilidade entre múltiplas execuções de scan dentro do mesmo Teste. + +### Permissões + +Vários Testes podem ser armazenados dentro de um único Engajamento, e os Engajamentos são armazenados dentro de Ativos. Assim, o acesso a um Ativo concede automaticamente acesso a todos os Testes (e Engajamentos) dentro desse Ativo. Os Testes não possuem listas de controle de acesso independentes. + +## Acessando Testes + +Os Testes podem ser acessados em várias seções da interface do DefectDojo. + +- A barra lateral + +![image](images/tests_ss13.png) + +- Dentro de um Engajamento + +![image](images/tests_ss14.png) + +- A barra superior de um Ativo + +![image](images/tests_ss15.png) + +- A tabela de Metadados na visualização de um Achado + +![image](images/tests_ss16.png) + +## Trabalhando com Testes + +### Criar Testes + +Os Testes podem ser criados automaticamente quando os dados de um scan são importados diretamente em um Engajamento, resultando em um novo Teste contendo os dados do scan. Os Testes também podem ser criados antecipadamente, para planejar futuros Engajamentos, ou para achados de segurança inseridos manualmente que exijam acompanhamento e remediação. + +#### Fluxos de Trabalho Manuais + +Para criar um Teste, é necessário que exista um Engajamento para contê-lo, bem como um Ativo que conterá esse Engajamento. Depois disso, há várias maneiras de criar um Teste: + +- Na barra lateral, em Testes, dentro da subseção **Manage** + - Você precisará selecionar o Engajamento pré-existente ao qual atribuir o Teste ao preencher o formulário de Novo Teste. + +![image](images/tests_ss1.png) + +- O menu suspenso de configurações no canto superior direito da visualização de um Ativo + - **Import Scan** criará automaticamente um Teste assim que um arquivo de scan for adicionado ao formulário de Import Scan. Você terá a opção de atribuir o Teste a um Engajamento pré-existente ou criar e nomear um novo Engajamento para conter o novo Teste. + - Ao preencher o formulário de Import Scan, você pode adicionar metadados como a versão, a branch tag, o commit hash e o build ID. Isso será refletido na seção de Histórico de Importação da visualização do Teste. + +![image](images/tests_ss2.png) + +- O menu suspenso de configurações no canto superior direito da visualização de um Engajamento + - **Import Scan** seguirá o mesmo fluxo de trabalho dos Ativos, mas colocará automaticamente o objeto Teste dentro do Engajamento no qual você clicou em Import Scan. + - **Add Test** criará um objeto Teste, mas não exige que um scan seja enviado para o próprio Teste, o que é útil para planejar futuros Testes antecipadamente ou para achados de segurança inseridos manualmente que exijam acompanhamento e remediação. + +![image](images/tests_ss3.png) + +Se você selecionar Add Test e mais tarde desejar importar manualmente os resultados de um scan para um Teste, você pode fazer isso abrindo o Teste e clicando no botão Reimport Findings nas configurações do Teste ou no botão Reimport Scan na tabela de Achados. + +![image](images/tests_ss21.png) + +#### Fluxos de Trabalho Automatizados + +Em fluxos de trabalho automatizados, os Testes podem ser criados programaticamente como parte do processo de importação de scan, permitindo que os pipelines enviem resultados sem exigir que um Teste seja criado manualmente com antecedência. + +Ao usar a API ou a CLI para importar resultados de scan, um novo Teste pode ser criado automaticamente fornecendo um `engagement` em vez de um `test`. + +##### API + +curl -X POST `"https:///api/v2/import-scan/"` \ + -H `"Authorization: Token "` \ + -F `"engagement=45"` \ + -F `"scan_type=ZAP Scan"` \ + -F `"file=@report.xml"` + +Diante do exemplo acima, um novo Teste é criado dentro do Engajamento especificado, e os resultados do scan são anexados a esse Teste. + +Se um ID de `test` for fornecido em vez disso, os resultados do scan serão adicionados a um Teste existente, o que é comum em fluxos de trabalho de reimportação. + +##### CLI + +Usando a CLI do DefectDojo, esse comportamento é tratado automaticamente com base nos argumentos fornecidos. + +defectdojo-cli import \ + --engagement-id 45 \ + --scan-type `"ZAP Scan"` \ +GOog --file report.xml + +Diante do exemplo acima, fornecer um `engagement-id` cria um novo Teste, e fornecer um `test-id` reutiliza um Teste existente e reimporta os resultados do scan nesse Teste. + +Consulte [DefectDojo-CLI](/import_data/pro/specialized_import/external_tools/#defectdojo-cli) para mais detalhes sobre as flags necessárias. + +### Editar Testes + +Os Testes podem ser editados clicando em **Edit Test** no menu de engrenagem. Todos os campos subsequentes que podem ser editados também estão disponíveis quando o Teste está sendo criado. + +### Excluir Testes + +A exclusão de um Teste pode ser realizada selecionando **Delete Test** nas configurações do Teste. Essa ação não pode ser desfeita. + +Excluir um Teste também excluirá todos os Achados contidos nesse Teste. + +### Reimportando Resultados de Scan (UI) + +Para adicionar novos dados a um Teste existente, abra o Teste ao qual deseja adicionar novos dados e clique no botão Reimport Findings nas configurações do Teste ou no botão Reimport Scan na tabela de Achados. + +![image](images/tests_ss21.png) + +Ao preencher o formulário de Reimport Scan, você terá a opção de atualizar os metadados do scan sendo reimportado, incluindo a versão, a branch tag, o commit hash e o build ID. Essas alterações são refletidas na seção de Histórico de Importação da visualização do Teste, que também incluirá os mesmos metadados das importações de scan anteriores. + +Por exemplo, na captura de tela abaixo, a branch tag, o build ID, o commit hash e a versão foram todos atualizados manualmente entre a importação inicial e a reimportação subsequente. + +![image](images/tests_ss23.png) + +Para editar os metadados do scan reimportado mais recentemente, clique no ícone de engrenagem localizado no canto superior direito da visualização de um Engajamento e selecione "Edit Test". Apenas os metadados da importação mais recente podem ser editados. + +### Reimportando Resultados de Scan (API/CLI) + +Quando os Testes são criados ou atualizados por meio de um pipeline de CI/CD, é possível incluir metadados da execução do pipeline para que os Testes possam ser corretamente vinculados ao código que analisaram. Isso permite que você: +- Associe os resultados do scan a um commit ou branch específico. +- Acompanhe como os Achados evoluem ao longo das alterações de código. +- Melhore a Deduplicação entendendo quando dois scans se aplicam à mesma versão do código ou a versões diferentes. +- Dê suporte à auditabilidade, mostrando exatamente qual código foi analisado e quando. + +A CLI e a API do DefectDojo aceitam esses valores durante a importação ou reimportação, para que possam ser armazenados como parte da importação do scan e refletidos no histórico de importação do Teste. Esses metadados podem ser usados para identificar commit hashes ou qualquer informação relevante de repositório associada a uma execução de CI/CD. + +#### Campos de Metadados Suportados + +A API e a CLI oferecem suporte a um conjunto definido de campos de metadados que podem ser incluídos durante a reimportação. Estes incluem: + +- `tags` +- `version` +- `build_id` +- `branch_tag` +- `commit_hash` +- `scan_date` +- `minimum_severity` +- flags `active / verified` + +Esses campos representam o mecanismo principal para anexar metadados contextuais durante uma operação de reimportação. + +Em pipelines automatizados, os metadados mais comumente fornecidos incluem: +- `build_id` (identificador do job de CI) +- `commit_hash` (referência de controle de versão) +- `branch_tag` (contexto de branch ou ambiente) +- `tags` (por exemplo, `nightly`, `staging`, `production`) + +Esses campos fornecem rastreabilidade entre os scans sem exigir intervenção manual. + +Embora os metadados possam ser atualizados manualmente por meio do formulário de Reimport Scan, a maioria dos ambientes automatizados fará isso chamando diretamente o endpoint `/api/v2/reimport-scan/` ou usando a CLI do DefectDojo (`defectdojo-cli reimport`) como parte do processo de build. Essa abordagem permite que o pipeline anexe automaticamente os metadados durante a reimportação. + +##### Reimportação via API com Metadados + +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"` + +##### Reimportação via CLI com Metadados + +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 + +A CLI mapeia diretamente para o mesmo endpoint da API e oferece suporte ao mesmo conjunto de campos de metadados. + +Há algumas limitações a serem consideradas ao trabalhar com metadados durante a reimportação: +- A API/CLI oferece suporte apenas a parâmetros predefinidos. Metadados personalizados no formato chave-valor não podem ser adicionados durante a reimportação +- Metadados adicionais podem ser extraídos do próprio arquivo de scan, dependendo do tipo de scan e do parser. +- Os metadados fornecidos durante a reimportação não se comportam como uma atualização direta do objeto Teste, da mesma forma que as edições manuais feitas na UI. + +##### Metadados, Reimportação e Scans Agendados + +Os scans também podem ser agendados para serem executados em intervalos rotineiros, como os disparados por cron jobs. Scans agendados não estão vinculados à atividade do repositório, o que torna metadados como commit hashes ou nomes de branch irrelevantes, a menos que sejam explicitamente injetados pelo próprio script. Ainda assim, usar a reimportação pode ser útil se você preferir manter um registro contínuo da sua postura de segurança dentro de um único Teste. + +## Reimportação e Deduplicação + +Reimportar scans dentro dos Testes é fundamental para uma deduplicação eficaz. Quando os resultados de um scan são reimportados no mesmo Teste: + +- Achados existentes podem ser atualizados +- Achados duplicados podem ser suprimidos +- Novos Achados podem ser criados se nenhuma correspondência for encontrada + +Esse comportamento depende das regras de deduplicação configuradas e do tipo de scan. + +Criar um novo Teste em vez de reimportar em um já existente pode resultar na criação de Achados duplicados em vez de sua atualização. + +### Reimportação vs. Importação + +A reimportação é normalmente usada quando: + +- Executando scans recorrentes contra o mesmo alvo +- Acompanhando como os Achados evoluem ao longo do tempo +- Mantendo uma visão contínua da postura de segurança da aplicação + +Em contraste, a importação (criação de um novo Teste) é mais adequada para execuções de scan únicas ou independentes. diff --git a/docs/content/asset_modelling/engagements_tests/_index.pt-br.md b/docs/content/asset_modelling/engagements_tests/_index.pt-br.md new file mode 100644 index 0000000000..3b19d8d713 --- /dev/null +++ b/docs/content/asset_modelling/engagements_tests/_index.pt-br.md @@ -0,0 +1,8 @@ +--- +title: Engajamentos e Testes +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.pt-br.md b/docs/content/asset_modelling/locations/PRO__locations_overview.pt-br.md new file mode 100644 index 0000000000..d04db72c3d --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__locations_overview.pt-br.md @@ -0,0 +1,80 @@ +--- +title: Visão Geral das Locations +description: O que são as Locations e por que elas substituem os Endpoints +audience: pro +weight: 1 +--- + +**Locations** são uma nova ferramenta de modelagem de ativos no DefectDojo Pro. Elas substituem o modelo legado de **Endpoints** e absorvem os dados anteriores de **Components** (biblioteca), dando ao DefectDojo uma forma única e polimórfica de descrever *onde* um Achado vive — seja isso uma URL, uma dependência de software de um **SBOM**, ou, no futuro, um **ID de recurso em nuvem**, uma **imagem de contêiner** ou um **repositório de código**. + +As Locations precisam estar habilitadas na sua instância antes que você possa usá-las. Você mesmo pode ativar as Locations na [página de Feature Flags](/admin/feature_flags/pro__feature_flags/) — não é necessário abrir uma solicitação de Suporte. Observe que as Locations não podem ser desativadas novamente depois de habilitadas. + +## Por que Substituir os Endpoints? + +O modelo original de Endpoints foi construído em torno de URLs e endereços IP — ele carregava campos de aplicação web como `protocol`, `host`, `port`, `path`, e uma tabela de status fixa que estava fortemente acoplada aos Achados. Três problemas surgiram a partir disso: + +1. **Fidelidade limitada.** Os Endpoints não conseguiam descrever de forma clara ativos que não fossem URLs, como bibliotecas de terceiros, imagens de contêiner ou recursos em nuvem, mesmo com os scanners produzindo cada vez mais achados sobre essas coisas. +2. **Teto de desempenho.** As linhas de Endpoint_Status por Achado e o schema com formato de URL não escalavam bem em grandes volumes de clientes. +3. **Components eram cidadãos de segunda classe.** As bibliotecas de software existiam apenas como campos desnormalizados em um Achado, de modo que uma biblioteca não podia existir independentemente de uma vulnerabilidade — o que tornava impossível uma verdadeira gestão de SBOM. + +As Locations resolvem os três problemas ao introduzir um **objeto `Location` base** com um payload tipado, além de **subtipos** dedicados para cada formato de ativo: + +- **URL Locations** — equivalente funcional aos antigos Endpoints, com os mesmos campos de protocol/host/port/path/query/fragment. +- **Dependency Locations** — bibliotecas de software identificadas por [Package URL (pURL)](https://github.com/package-url/purl-spec), usadas para modelar o conteúdo de SBOMs. +- **[Source Code Locations](/asset_modelling/locations/pro__source_code_locations/)** — onde um achado de análise estática vive no código-fonte, identificado por caminho de arquivo e número de linha. Gerenciado pelo scan, e a base para [rastrear achados à medida que seu código se move](/triage_findings/finding_deduplication/pro__location_drift_matching/). + +Entre os futuros tipos de Location em consideração estão IDs de recursos de provedores de nuvem (AWS ARN, Azure Resource ID, GCP Full Resource Name) e imagens de contêiner (registry/repository:tag e impressões digitais SHA256). + +## Conceitos-Chave + +### Locations e Subtipos + +Uma **Location** é o pai compartilhado. Ela carrega: + +- Um `Location Type` (por exemplo, `"url"`, `"dependency"`) +- Uma string canônica `Location Value` usada para exibição, busca e deduplicação +- `Tags` e tags herdadas do Ativo pai +- Metadados (pares personalizados de chave/valor) + +Um **subtipo** (URL ou Dependency) contém os campos estruturados específicos daquele tipo de location. URLs e Dependencies sempre existem junto a um objeto Location pai; o `Location Value` do subtipo é gerado a partir de seus campos estruturados. + +### References + +As Locations não são anexadas diretamente a Produtos ou Achados. Em vez disso, dois objetos **Reference** as conectam: + +- **Asset References** — relações que a Location tem com Ativos (por exemplo, `libFoo` é *de propriedade de* (owned by) o Ativo 6, *usada por* (used by) o Ativo 9). Cada referência carrega um status (`Active` ou `Mitigated`) e um **relacionamento** opcional ("Used By" ou "Owned By"). +- **Finding References** — relações que a Location tem com Achados. Cada referência carrega um status mais detalhado (`Active`, `Mitigated`, `False Positive`, `Risk Accepted`, `Out of Scope`), além do auditor e do horário da auditoria. + +Essa separação é o que permite que uma biblioteca exista em um Produto *sem* precisar de um Achado — uma capacidade que faltava no antigo modelo de Components. + +### Associação Automática no Momento da Importação + +Quando um parser produz um Achado que referencia uma URL ou biblioteca, o importador: + +1. Procura uma Location existente que corresponda à URL ou ao pURL; se nenhuma existir, cria uma. +2. Cria uma Finding Reference vinculando o Achado à Location com status `Active`. +3. Cria (ou reutiliza) uma Asset Reference para que a Location também exista no Ativo pai. + +Os parsers existentes foram atualizados para emitir dados de Location quando a feature flag está ativada, e para retornar ao modelo legado de Endpoint quando ela está desativada. Nenhuma reconfiguração é necessária quando as Locations estão habilitadas — a próxima importação será automaticamente roteada pelo pipeline de Locations. + +## O que Está no MVP + +| Capability | Status | +| --- | --- | +| Foundational `Location`, `URL`, `Dependency` models | Shipped | +| REST API for Locations and References | Shipped (read-only `Location`, full CRUD on References) | +| Endpoint API read-compatibility shim | Shipped | +| Endpoint → URL one-way migration command | Shipped | +| Parser updates (URLs and dependencies) | Shipped for the major parsers | +| SBOM upload (CycloneDX, SPDX v2/v3) | Shipped via `/api/v2/sbom-import/` | +| Pro UI for Locations, URLs, Dependencies | Shipped | +| pURL search/filter | Shipped | +| License tracking on dependencies | Partial (`license_expression` field) | +| SWID Tag SBOM format | Not in MVP | + +## Para Onde Ir a Seguir + +- **Habilite o recurso** — entre em contato com [support@defectdojo.com](mailto:support@defectdojo.com) para ativar as Locations na sua instância. +- **Migre a partir dos Endpoints** — veja [Migrando dos Endpoints](../pro__migrating_from_endpoints) para saber o que a migração preserva e como a API legada de Endpoint se comporta depois. +- **Fluxos de trabalho do dia a dia com URLs** — veja [Trabalhando com URLs](../pro__working_with_urls). +- **SBOMs e dependências** — veja [Trabalhando com SBOMs](../pro__working_with_sboms). diff --git a/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.pt-br.md b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.pt-br.md new file mode 100644 index 0000000000..c9861dcf52 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__migrating_from_endpoints.pt-br.md @@ -0,0 +1,70 @@ +--- +title: Migração a partir de Endpoints +description: O que acontece quando você migra dados existentes de Endpoint para Localizações +audience: pro +weight: 3 +--- + +Quando você habilita as Localizações em uma instância existente do DefectDojo Pro, os dados já armazenados como Endpoints precisam ser transportados para o novo modelo de Localizações. Esta página descreve a migração, o que ela preserva e como a API legada de Endpoint se comporta depois que a migração é executada. + +Observe que a migração é **de mão única**. Não existe um caminho de rollback automatizado que recrie Endpoints a partir de Localizações. + +## O Que a Migração Faz + +Para cada Endpoint existente, a migração vai: + +1. **Criar uma Localização de URL** (ou reutilizar uma existente) usando os campos `protocol`, `userinfo`, `host`, `port`, `path`, `query` e `fragment` do Endpoint. A nova URL é automaticamente anexada a um objeto `Location` pai. +2. **Transferir as tags.** Cada tag do Endpoint é adicionada ao conjunto de tags da Localização. +3. **Transferir os metadados.** Cada linha `DojoMeta` anexada ao Endpoint é redirecionada para a nova Localização. +4. **Criar uma `LocationProductReference`** para que a URL apareça sob o Ativo (Produto) correto. +5. **Criar uma `LocationFindingReference` para cada `Endpoint_Status`**: + + | Flag do Endpoint_Status | Status resultante da Localização | + | --- | --- | + | `risk_accepted=True` | **Risco aceito** | + | `false_positive=True` | **Falso positivo** | + | `out_of_scope=True` | **Fora do escopo** | + | `mitigated=True` | **Mitigado** | + | (nenhum dos anteriores) | **Ativo** | + + O mapeamento é sensível à ordem: a *primeira* flag correspondente prevalece. Isso reduz intencionalmente as antigas combinações de múltiplas flags a um único status canônico usado pelas Localizações. + + +## O Que a Migração Não Faz + +- Ela **não** cria Localizações de Dependência. Dados de SBOM e de bibliotecas nunca existiram como Endpoints, então não há nada para a migração converter. Para popular Dependências, faça upload de SBOMs (veja [Trabalhando com SBOMs](../pro__working_with_sboms)) ou execute novamente as varreduras com parsers que emitam dados de dependência. +- Ela **não** exclui as linhas originais de Endpoint ou Endpoint_Status. Elas permanecem no banco de dados para sustentar a API legada somente leitura. Não são usadas pela nova interface nem pelas importações após o recurso ser habilitado. + +## API de Endpoint Após a Migração + +Depois que as Localizações são habilitadas, a API legada de Endpoint entra em um modo de **compatibilidade de leitura**, projetado para manter as automações existentes funcionando sem alterações de código — mas apenas para tráfego de leitura. + +### O Que Ainda Funciona + +- `GET /api/v2/endpoints/` — Retorna linhas que *parecem* Endpoints, mas na verdade são projetadas a partir de linhas de Location Product Reference unidas a Localizações de URL. Os campos conhecidos (`protocol`, `host`, `port`, `path`, `query`, `fragment`, `tags`, `product`, `active_finding_count`) estão todos presentes. +- `GET /api/v2/endpoints/{id}/` — A busca de um único Endpoint funciona da mesma forma. O `id` é o ID original do Endpoint e é preservado ao longo da migração por meio do mapeamento de Asset Reference. +- `GET /api/v2/endpoint_status/` e `GET /api/v2/endpoint_status/{id}/` — Retornam linhas projetadas a partir de `LocationFindingReference`. Os campos booleanos legados `mitigated`, `false_positive`, `out_of_scope` e `risk_accepted` são reconstruídos. +- A filtragem por `protocol`, `host`, `port`, `path`, `query`, `fragment`, `product` e `tag(s)` continua funcionando. +- A ação `generate_report` em Endpoints individuais continua funcionando. + +### O Que Retorna 403 + +- `POST`, `PUT`, `PATCH` e `DELETE` em `/api/v2/endpoints/` e `/api/v2/endpoint_status/` retornam todos `HTTP 403` com o corpo: + + > Writes to this endpoint are deprecated when V3_FEATURE_LOCATIONS is enabled + + Os clientes que gravam dados de Endpoint devem migrar para os novos endpoints de referência (`POST /api/v2/location_findings/`, `POST /api/v2/location_products/`) e para o endpoint de URL (`POST /api/v2/urls/`). + +### Diferenças de Comportamento a Observar + +Algumas coisas se comportam de maneira diferente em relação à API original de Endpoint: + +- **Status único em vez de flags.** As Localizações têm apenas um status por vez. Se o seu código dependia de um Achado ser *ao mesmo tempo* `mitigated=True` *e* `false_positive=True` em um Endpoint_Status, isso deixa de ser representável — a migração escolhe a flag de maior prioridade (a ordem mostrada na tabela acima). +- **Campo `endpoint` no Endpoint_Status.** O campo legado `endpoint` é reconstruído buscando a Asset Reference correspondente. Em casos raros, quando o Ativo de um Achado não corresponde mais às referências de Ativo de sua Localização, esse campo pode ser nulo. +- **Paginação e ordenação.** Os campos de ordenação disponíveis na camada de compatibilidade de leitura são `host`, `product`, `id` e `active_finding_count`. Se o seu cliente ordena por outro campo, mude para um destes ou migre para os novos endpoints de Localizações. + +## Tags e Metadados + +As tags aplicadas a Endpoints se tornam tags no objeto Localização (não no subtipo URL). Os filtros baseados em tags na API legada continuam funcionando. + +Os metadados de Endpoint são redirecionados para a Localização durante a migração. As automações existentes que leem metadados por meio de `/api/v2/endpoint_meta/` devem continuar funcionando; novos metadados devem ser gravados por meio dos endpoints de Localização. diff --git a/docs/content/asset_modelling/locations/PRO__source_code_locations.pt-br.md b/docs/content/asset_modelling/locations/PRO__source_code_locations.pt-br.md new file mode 100644 index 0000000000..63bd06bb99 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__source_code_locations.pt-br.md @@ -0,0 +1,46 @@ +--- +title: Localizações de Código-Fonte +description: Localizações de código modelam onde um achado de análise estática vive + no código-fonte e registram seu histórico de movimentação à medida que o código + evolui +weight: 6 +audience: pro +--- + +As **Localizações de Código-Fonte** estendem o modelo de Localizações à análise estática: além de URLs (DAST) e Dependências (SCA), uma localização do tipo **Código** descreve onde um achado de SAST vive no código-fonte — identificado pelo **caminho do arquivo e número da linha**. + +> As Localizações de Código-Fonte exigem o recurso de Localizações (Beta). Para habilitar as Localizações na sua instância, entre em contato com [support@defectdojo.com](mailto:support@defectdojo.com). + +## O Que Elas Modelam + +Todo achado estático que reporta um caminho de arquivo recebe uma localização de Código. O valor canônico da localização é `path/to/file.py:42` (ou apenas o caminho do arquivo quando a ferramenta não reporta uma linha). Como todas as Localizações, as localizações de código são objetos compartilhados: dois achados no mesmo arquivo e linha referenciam a mesma localização, e a localização carrega status de referência por achado e por ativo. + +As localizações de código são **gerenciadas por varredura**: são criadas e atualizadas por importações e reimportações, não manualmente. Não existe uma ação "Nova Localização de Código-Fonte" — o scanner é a fonte da verdade sobre onde os achados de código vivem. + +## Onde Encontrá-las + +- **All Source Code** na barra lateral lista todas as localizações de código da instância, com a mesma filtragem e marcação por tags que URLs e Dependências. +- **View Source Code** no menu de Localizações de um Ativo restringe a lista a um único ativo. +- A página de um achado mostra sua localização de código atual e, quando o achado se moveu, seu **histórico de localização**. + +## Histórico de Movimentação + +O código-fonte se move constantemente: commits deslocam números de linha, refatorações renomeiam arquivos. Quando o [Location Drift Matching](/triage_findings/finding_deduplication/pro__location_drift_matching/) está habilitado para uma ferramenta, um achado que se move mantém sua identidade, e suas referências de localização de código registram o rastro: + +- A referência do achado à localização **antiga** é mitigada e marcada com *para onde o achado se moveu* e *por que a correspondência foi feita* (linha mais próxima, fluxo de dados, renomeação de arquivo...). +- Uma referência à localização **nova** é criada e permanece ativa. + +O resultado é uma cadeia de substituição navegável — "este achado viveu em `auth.py:42`, depois em `auth.py:57`, depois em `session.py:31`" — renderizada como uma linha do tempo na página do achado. O mesmo mecanismo de histórico cobre movimentações de URL e atualizações de versão de dependência, então os três tipos de localização compartilham uma única interface de linha do tempo. + +O histórico é registrado a partir do momento em que as Localizações são habilitadas na instância. Achados que se moveram antes disso mantêm sua localização atual; os saltos anteriores foram aplicados, mas não registrados. Para instâncias com anos de histórico anterior ao recurso, o [comando de consolidação de churn](/triage_findings/finding_deduplication/pro__location_drift_matching/#consolidating-historical-churn) pode reconstruir os rastros ao mesclar cadeias históricas de fechar-e-recriar. + +## Correção de Status + +Os status de referência de localização de código são mantidos fiéis por meio da reimportação em **todos** os algoritmos de correspondência, independentemente de a correspondência por deriva (drift matching) estar habilitada: + +- A referência de código atual de um achado correspondido é sincronizada a cada reimportação, de modo que um achado que se moveu não deixe sua referência antiga ativa para sempre. +- A mesma sincronização independente de configuração se aplica às referências de dependência: quando a versão do pacote de um achado de SCA é atualizada, a referência da versão antiga é mitigada em vez de permanecer ativa junto com a nova. + +## Relação com os Campos do Achado + +Os próprios campos `file_path` / `line` do achado continuam sendo os valores escalares autoritativos (são eles que os filtros, os hashes e a API expõem); a localização de Código é a visão compartilhada e com contagem de referências dessa mesma coordenada. A reimportação atualiza os escalares a partir da varredura mais recente, e o mecanismo de localizações deriva as localizações a partir deles — os dois não podem divergir. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_sboms.pt-br.md b/docs/content/asset_modelling/locations/PRO__working_with_sboms.pt-br.md new file mode 100644 index 0000000000..773176a729 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_sboms.pt-br.md @@ -0,0 +1,107 @@ +--- +title: Trabalhando com SBOMs +description: Gerencie dependências de software e SBOMs como Localizações +audience: pro +weight: 5 +--- + +O DefectDojo Pro modela bibliotecas de software como **Localizações de Dependência**. Uma Dependência é um subtipo de Localização identificado por uma [Package URL (pURL)](https://github.com/package-url/purl-spec) e destinado a representar uma única biblioteca ou pacote — `org.apache.logging.log4j:log4j-core@2.17.0`, `pypi/django@5.0.2`, `npm/react@18.2.0`, e assim por diante. + +As Dependências substituem o antigo modelo de **Componentes**, que era anexado apenas a Achados. Com as Localizações, as bibliotecas podem existir independentemente de qualquer vulnerabilidade — você pode fazer upload de um SBOM para um Ativo e deixar que os Achados se anexem automaticamente às dependências que referenciam à medida que as varreduras chegam. + +## O Que Uma Dependência Contém + +Toda Dependência é identificada de forma exclusiva por uma pURL, decomposta em campos atômicos nos quais você pode pesquisar e filtrar: + +| Campo | Significado | Exemplo | +| --- | --- | --- | +| `purl_type` | Ecossistema da biblioteca | `npm`, `pypi`, `maven`, `cargo`, `nuget`, `gem` | +| `namespace` | Fornecedor ou organização | `org.apache.logging` | +| `name` | Nome da biblioteca | `log4j-core` | +| `version` | Versão específica | `2.17.0` | +| `qualifiers` *(opcional)* | Detalhes de implementação | `arch=amd64` | +| `subpath` *(opcional)* | Caminho dentro de um arquivo compactado ou monorepo | `src/lib/foo` | +| `artifact_hashes` *(opcional)* | Fingerprints | Somas SHA256 | +| `license_expression` *(opcional)* | Expressão de licença SPDX | `Apache-2.0`, `MIT` | +| `file_path` *(opcional)* | Onde a biblioteca foi encontrada no projeto | `package-lock.json` | + +Essa decomposição atômica é o que torna útil a pesquisa baseada em pURL: você pode perguntar *"todos os pacotes `pypi` no namespace `django` na versão 4.x"* e o DefectDojo consegue responder isso sem analisar uma string de texto livre. + +## Owned-By vs Used-By + +Quando uma Dependência é associada a um Ativo, a Asset Reference carrega um **relacionamento** opcional que descreve *como* a biblioteca pertence ao Ativo: + +- **`owned_by`** — *"esta biblioteca é de propriedade deste Ativo"*. Use isso para bibliotecas próprias (first-party) que um Ativo publica ou mantém. +- **`used_by`** — *"esta biblioteca é usada por este Ativo"*. Use isso para dependências de terceiros que um Ativo consome. + +A mesma biblioteca pode ser `owned_by` de um Ativo e `used_by` de vários outros, que é exatamente o relacionamento necessário para responder *"quem consome o pacote que minha equipe publica?"* durante a triagem de vulnerabilidades. + +## Fazendo Upload de um SBOM + +Para popular Dependências em massa, faça upload de um arquivo SBOM em relação a um Produto. O endpoint é: + +``` +POST /api/v2/sbom-import/ +``` + +| Campo | Descrição | +| --- | --- | +| `product` | O ID do Produto (Ativo) de destino | +| `file` | O arquivo SBOM | +| `scan_type` | O formato do SBOM — veja os formatos suportados abaixo | +| `replace` *(opcional)* | Se `true`, associações de Produto obsoletas que não têm o suporte de uma referência de Achado existente são removidas. Padrão: `false` (cumulativo) | + +O importador analisa o arquivo, extrai os registros `Dependency`, deduplica-os em relação às Localizações existentes (criando novas conforme necessário) e cria Asset References vinculando cada Dependência ao Produto. A interface do Pro expõe o mesmo fluxo de upload — veja a ação **Upload SBOM** na aba de Localizações de um Produto. + +### Formatos Suportados + +O MVP inclui parsers para os dois formatos de SBOM dominantes: + +- **CycloneDX** — JSON e XML +- **SPDX** — JSON (v2 e v3), XML e tag-value + +O formato SWID Tag ainda não é suportado. + +### Substituir vs Anexar + +Por padrão, uploads repetidos são **aditivos**: as dependências que já existem no Ativo são mantidas, novas são adicionadas e nada é removido. Isso corresponde ao fluxo de trabalho típico de atualizações incrementais de SBOM. + +Defina `replace=true` para podar (prune). Quando o modo replace está ativado, após uma importação bem-sucedida o importador remove as associações de Produto que não estavam presentes no novo SBOM **e** que não são referenciadas atualmente por um Achado ativo. As referências vinculadas a Achados ativos são preservadas mesmo no modo replace, para que você não perca o contexto de vulnerabilidade apenas porque um novo SBOM omite um pacote. + +## Achados Que Referenciam Bibliotecas + +Quando um parser ingere uma vulnerabilidade vinculada a uma biblioteca — por exemplo, uma ferramenta de SCA reportando `CVE-2021-44228` contra `log4j-core@2.14.1` — o importador: + +1. Procura uma Localização de Dependência existente pela pURL, ou cria uma nova. +2. Cria uma `LocationFindingReference` vinculando o Achado à Dependência com status **Ativo**. +3. Cria uma `LocationProductReference` para que a Dependência também apareça no Produto pai, caso ainda não apareça. + +Como os Achados e os uploads de SBOM compartilham os mesmos objetos de Dependência subjacentes, um Achado ingerido *antes* de um upload de SBOM ficará visível retroativamente na visualização do SBOM, e vice-versa. + +## API REST + +| Tarefa | Endpoint | +| --- | --- | +| Fazer upload de um SBOM | `POST /api/v2/sbom-import/` | +| Listar Dependências | `GET /api/v2/dependencies/` | +| Criar uma Dependência manualmente | `POST /api/v2/dependencies/` | +| Listar Localizações de Dependência | `GET /api/v2/location/?location_type=dependency` | +| Vincular uma Dependência a um Achado | `POST /api/v2/location_findings/` | +| Vincular uma Dependência a um Produto (com `owned_by` / `used_by`) | `POST /api/v2/location_products/` | + +Os filtros em `/api/v2/dependencies/` incluem os campos de componente da pURL, tags e ordenação por `name`, `version` e contagem de achados ativos. + +## Na Interface do Pro + +Quando as Localizações estão habilitadas, a navegação expõe: + +- **Locations / Dependencies** — Lista global de todas as Dependências na instância, com filtros de pURL. +- **Locations on a Product/Asset** — Visualização por Ativo que mostra tanto URLs quanto Dependências, com a ação **Upload SBOM** disponível na aba Dependencies. +- **New Dependency** — Formulário para criar uma única biblioteca inserindo manualmente os componentes de sua pURL. +- **Findings detail** — Um Achado que envolve uma biblioteca mostra suas Localizações de Dependência ao lado de quaisquer Localizações de URL, para que você possa ver *"este CVE afeta `log4j-core@2.14.1` no Ativo 6 e no Ativo 9"* em um só lugar. + +## O Que Não Está no MVP + +- **Formato de SBOM SWID Tag** — Não é analisado. CycloneDX ou SPDX é obrigatório. +- **Pontuação de risco de licença** — O campo `license_expression` é capturado quando presente no SBOM, mas o DefectDojo ainda não sinaliza achados por incompatibilidade de licença. Relatórios baseados em licença estão no roadmap como um follow-up ao MVP de Localizações. +- **Localizações de imagem de contêiner e recurso de nuvem** — Subtipos futuros de Localização. Por enquanto, bibliotecas descobertas dentro de uma imagem de contêiner são registradas como Dependências; a própria imagem de contêiner ainda não é uma Localização de primeira classe. diff --git a/docs/content/asset_modelling/locations/PRO__working_with_urls.pt-br.md b/docs/content/asset_modelling/locations/PRO__working_with_urls.pt-br.md new file mode 100644 index 0000000000..2c550635d9 --- /dev/null +++ b/docs/content/asset_modelling/locations/PRO__working_with_urls.pt-br.md @@ -0,0 +1,88 @@ +--- +title: Trabalhando com URLs +description: Uso cotidiano de Localizações de URL como substituição dos Endpoints +audience: pro +weight: 4 +--- + +As Localizações de URL são a substituição funcional do antigo modelo de Endpoints. Elas armazenam os mesmos campos no formato de URL aos quais você já está acostumado — `protocol`, `host`, `port`, `path`, `query`, `fragment` — e cumprem o mesmo papel: identificar *onde* vive um Achado de aplicação web. + +Esta página aborda o que muda quando você passa a usar Localizações de URL no dia a dia, as novas telas da interface e os endpoints de API a usar no lugar da antiga API de Endpoint. + +## O Subtipo URL + +Toda URL é uma Localização. Isso significa que uma URL tem, ao mesmo tempo: + +- Os campos estruturados de URL (`protocol`, `user_info`, `host`, `port`, `path`, `query`, `fragment`, além de um `hash` usado para deduplicação). +- Os campos compartilhados de Localização (`location_type="url"`, uma string canônica `location_value` para exibição e busca, tags, tags herdadas, metadados e vínculos de referência com Ativos e Achados). + +Quando você cria ou faz upload de uma URL, o DefectDojo a analisa nos campos estruturados e grava tanto a linha de URL quanto sua linha de Localização pai em uma única transação. A deduplicação de URL é uma correspondência exata entre os campos estruturados — duas URLs são consideradas iguais se todos os componentes coincidirem, com o colapso padrão de porta default (`http://example.com:80/` e `http://example.com/` resolvem para a mesma URL). + +## Na Interface do Pro + +Quando o recurso de Localizações está habilitado, a navegação expõe: + +- **Locations / All** — Uma lista de todas as Localizações, tanto do subtipo URL quanto do subtipo Dependência. Filtre por tipo, status, Ativo, Achado ou tag. +- **Locations / URLs** — Uma lista restrita apenas às Localizações de URL. É o análogo mais próximo da antiga página de Endpoints. +- **New URL** — Um formulário para criar uma única URL com campos estruturados, tags e associações opcionais de Ativo/Achado. +- **Locations on an Asset** — A partir de qualquer Ativo, a aba **Locations** mostra as URLs e Dependências anexadas a esse Ativo, com contagens de status e ações rápidas. + +Os fluxos de trabalho comuns da interface de Endpoints são preservados: + +- **Atualizações de status em massa.** Selecione várias Localizações de URL e aplique um status (Ativo, Mitigado, Falso positivo, Risco aceito, Fora do escopo) às suas referências de Achado em uma única ação. +- **Adicionando URLs existentes a um Ativo.** Use **Add Existing** na aba Locations de um Ativo para vincular URLs já existentes no sistema, em vez de criar duplicatas. +- **Tags.** As tags aplicadas a uma Localização de URL propagam-se como tags herdadas nos Achados que a referenciam, da mesma forma que as tags de Endpoint faziam anteriormente. + +## Modelo de Status + +As Localizações de URL usam os mesmos rótulos de status único que todas as outras Localizações: + +| Status | Significado | +| --- | --- | +| **Ativo** | O Achado nesta URL está aberto. | +| **Mitigado** | O Achado foi corrigido para esta URL. | +| **Falso positivo** | O Achado não é uma vulnerabilidade real para esta URL. | +| **Risco aceito** | O Achado é reconhecido, mas aceito nesta URL. | +| **Fora do escopo** | Esta URL está excluída do engajamento. | + +Observe que o antigo modelo de Endpoint Status permitia múltiplas flags simultaneamente (por exemplo, `mitigated=True` e `false_positive=True`). As Localizações impõem apenas um status por vez. Se você migrou a partir de Endpoints, a flag mais específica foi preservada (veja a tabela de mapeamento em [Migração a partir de Endpoints](../pro__migrating_from_endpoints)). + +As Asset References usam um status mais simples: apenas **Ativo** ou **Mitigado**, já que o status em nível de Ativo não precisa do mesmo detalhamento de auditoria. + +## API REST + +Use estes endpoints no lugar da antiga API de Endpoint: + +| Tarefa | Endpoint | +| --- | --- | +| Listar URLs | `GET /api/v2/urls/` | +| Criar uma URL | `POST /api/v2/urls/` | +| Atualizar as tags ou metadados de uma URL | `PATCH /api/v2/urls/{id}/` | +| Listar todas as Localizações (URLs + Dependências) | `GET /api/v2/location/?location_type=url` | +| Vincular uma URL a um Achado | `POST /api/v2/location_findings/` | +| Vincular uma URL a um Ativo | `POST /api/v2/location_Assets/` | +| Atualizar o status de um vínculo de Achado | `PATCH /api/v2/location_findings/{id}/` | +| Remover um vínculo de Achado | `DELETE /api/v2/location_findings/{id}/` | + +Os filtros em `/api/v2/urls/` incluem os campos estruturados de URL, além de `tag(s)`, `has_tags`, `Asset`, e ordenação por `host`, `Asset` ou contagem de achados ativos. + +O antigo endpoint `/api/v2/endpoints/` ainda atende tráfego de **leitura** por meio de uma camada de compatibilidade — veja [Migração a partir de Endpoints](../pro__migrating_from_endpoints) para saber o que é preservado e onde essa camada difere do comportamento original. **Gravações** nos endpoints legados retornam `403` e devem ser migradas para os endpoints acima. + +## Importando URLs a partir de Varreduras + +As importações de scanner criam Localizações de URL automaticamente. Quando um parser emite uma URL para um Achado (da mesma forma que antes emitia um Endpoint), o importador: + +1. Procura uma URL existente com campos estruturados correspondentes, ou cria uma. +2. Cria uma Finding Reference vinculando o Achado à URL com status **Ativo**. +3. Cria (ou reutiliza) uma Asset Reference para que a URL também apareça no Ativo pai. + +Os parsers do DefectDojo que anteriormente criavam Endpoints foram atualizados para criar Localizações automaticamente no Pro. + +## Coisas Que Se Comportam de Forma Diferente + +Vale destacar algumas pequenas mudanças de comportamento: + +- **Um status por par URL/Achado.** Como descrito acima, o modelo de múltiplas flags do Endpoint_Status é reduzido a um único status. Fluxos de trabalho que alternavam flags de forma independente precisam escolher uma única transição. +- **As tags residem na Localização, não na URL.** O subtipo URL não possui seu próprio conjunto de tags; as tags pertencem à Localização pai. Se você ler uma URL pela API, o campo `tags` vem de `location.tags`. +- **A deduplicação é por URL canônica, não por Ativo.** Dois Ativos que têm a mesma URL compartilham uma única Localização de URL subjacente e a referenciam duas vezes (uma Asset Reference cada). Isso é intencional e é o que permite relatórios entre Ativos. +- **O campo `endpoints` nos Achados.** Quando a flag está ativada, esse campo na API de Achado ainda retorna linhas, mas elas são projetadas a partir de Localizações de URL, em vez da tabela de Endpoint. Trate-o como somente leitura e grave por meio de `/api/v2/location_findings/`. diff --git a/docs/content/asset_modelling/locations/_index.pt-br.md b/docs/content/asset_modelling/locations/_index.pt-br.md new file mode 100644 index 0000000000..e16a4e98a9 --- /dev/null +++ b/docs/content/asset_modelling/locations/_index.pt-br.md @@ -0,0 +1,12 @@ +--- +title: Localizações +description: Modelagem de ativos com maior fidelidade — URLs, SBOMs e muito mais +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.pt-br.md b/docs/content/asset_modelling/tags/OS__tagging_objects.pt-br.md new file mode 100644 index 0000000000..217fc6c822 --- /dev/null +++ b/docs/content/asset_modelling/tags/OS__tagging_objects.pt-br.md @@ -0,0 +1,149 @@ +--- +title: Aplicando Tags a Objetos +description: Use Tags para criar um novo recorte do seu modelo de dados +draft: false +weight: 2 +exclude_search: false +audience: opensource +--- + +As Tags são ideais para agrupar objetos de uma forma que pode ser filtrada em partes menores e mais digeríveis. Elas podem ser usadas para indicar status ou para criar conjuntos personalizados de Organizações, Ativos, Engajamentos ou Achados em todo o modelo de dados. + +No DefectDojo, as tags são um elemento de primeira classe e são reconhecidas como facilitadoras +da organização em cada nível do modelo de dados. + +Aqui está um exemplo de um Ativo com duas tags e quatro achados, cada um com uma única tag: + +![Exemplo de alto nível do uso de tags](images/tags-high-level-example.png) + +### Formatos de Tag + +As tags podem ser formatadas de qualquer uma das seguintes maneiras: +- StringWithNoSpaces +- string-with-hyphens +- string_with_underscores +- colons:acceptable + +## Gerenciamento de Tags + +### Adicionando e Removendo + +As tags podem ser gerenciadas das seguintes formas: + +1. Criando ou Editando novos objetos + + Quando um novo objeto é criado ou editado pela UI ou pela API, há um campo para especificar + as tags a serem definidas em um determinado objeto. Esse campo é um campo de múltipla seleção que também + conta com autocompletar, tornando muito mais fácil buscar e adicionar tags existentes. Veja como o campo + aparece no Ativo do print de tela da seção anterior: + + ![Gerenciamento de tags em um objeto](images/tags-management-on-object.png) + +2. Importação e Reimportação + + As tags também podem ser aplicadas a um determinado teste no momento da importação ou reimportação. Esse é + um caso de uso muito útil ao importar via API com automação, pois oferece a oportunidade de anexar + detalhes da execução da automação e informações da ferramenta que talvez não sejam capturadas + diretamente no objeto de teste ou de achado. + + O campo tem a mesma aparência e o mesmo comportamento de quando está em um objeto qualquer + +3. Menu de Edição em Massa (somente achados) + + Quando é necessário atualizar muitos Achados com o mesmo conjunto de tags, o menu de edição em massa pode + ser usado para facilitar o trabalho. + + No exemplo a seguir, digamos que eu queira atualizar as tags dos dois achados com a tag "tag-group-alpha" para uma nova lista de tags como esta ["tag-group-charlie", "tag-group-delta"]. + Primeiro, eu selecionaria as tags a serem atualizadas: + + ![Selecionar achados para atualização de tags em massa](images/tags-select-findings-for-bulk-edit.png) + + Depois que um achado é selecionado, um novo botão aparece com o nome "Bulk Edit". Ao clicar nesse botão, + aparece um menu suspenso com várias opções, mas o foco por enquanto é apenas nas tags. Atualize o + campo com a lista de tags desejada, como a seguir, e clique em enviar + + ![Aplicar alterações da atualização de tags em massa](images/tags-bulk-edit-submit.png) + + As tags dos Achados selecionados serão atualizadas para o que foi especificado no campo de tags + dentro do menu de edição em massa + + ![Atualização de tags em massa concluída](images/tags-bulk-edit-complete.png) + +## Herança de Tags + +Quando a Herança de Tags está habilitada, as tags aplicadas a um determinado Ativo serão automaticamente aplicadas a todos os objetos abaixo dos Ativos na [Hierarquia de Ativos](/asset_modelling/os_hierarchy/os__asset_hierarchy/). + +### Configuração + +A Herança de Tags pode ser habilitada nos seguintes níveis de escopo: +- Escopo Global + - Todo Ativo em todo o sistema passará a aplicar tags a todos os objetos filhos (Engajamentos, Testes e Achados) + - Isso é definido nas Configurações do Sistema +- Escopo de Ativo + - Somente o Ativo selecionado passará a aplicar tags a todos os objetos filhos (Engajamentos, Testes e Achados) + - Isso é definido na página de criação/edição do Ativo + +### Comportamentos + +Quando a Herança de Tags está habilitada, as Tags padrão podem ser adicionadas e removidas dos objetos da forma usual. +No entanto, as tags herdadas não podem ser removidas de um objeto filho sem removê-las do objeto pai +Veja o exemplo a seguir de adição de uma tag "test_only_tag" ao objeto Teste e uma tag "engagement_only_tag" ao Engajamento. + +![Exemplo de tags herdadas](images/tags-inherit-exmaple.png) + +Quando são feitas atualizações na lista de tags de um Ativo, as mesmas alterações são aplicadas de forma assíncrona a todos os objetos dentro do Ativo. A duração dessa tarefa está diretamente relacionada à quantidade de objetos contidos em um achado. + +**Open Source:** Se as alterações de tags não forem observadas em um período de tempo razoável, consulte os logs do worker do celery para identificar onde possíveis problemas podem ter ocorrido. + + +### Filtragem por Tags (UI Clássica) + +As tags podem ser filtradas de várias formas, tanto pela UI quanto pela API. Por exemplo, aqui está um trecho +dos filtros de Achado: + +![Trecho dos filtros de achado](images/tags-finding-filter-snippet.png) + +Há dez campos relacionados a tags: + + - Tags: filtra por quaisquer tags que estejam anexadas a um determinado Achado + - Exemplos: + - O Achado será retornado + - Tags do Achado: ["A", "B", "C"] + - Consulta de Filtro: "B" + - O Achado *não* será retornado + - Tags do Achado: ["A", "B", "C"] + - Consulta de Filtro: "F" + - Not Tags: filtra por quaisquer tags que *não* estejam anexadas a um determinado Achado + - Exemplos: + - O Achado será retornado + - Tags do Achado: ["A", "B", "C"] + - Consulta de Filtro: "F" + - O Achado *não* será retornado + - Tags do Achado: ["A", "B", "C"] + - Consulta de Filtro: "B" + - Tag Name Contains: filtra por quaisquer tags que contenham parte ou toda a consulta no Achado em questão + - Exemplos: + - O Achado será retornado + - Tags do Achado: ["Alpha", "Beta", "Charlie"] + - Consulta de Filtro: "et" (parte de "Beta") + - O Achado *não* será retornado + - Tags do Achado: ["Alpha", "Beta", "Charlie"] + - Consulta de Filtro: "meg" (parte de "Omega") + - Not Tags: filtra por quaisquer tags que *não* contenham parte ou toda a consulta no Achado em questão + - Exemplos: + - O Achado será retornado + - Tags do Achado: ["Alpha", "Beta", "Charlie"] + - Consulta de Filtro: "meg" (parte de "Omega") + - O Achado *não* será retornado + - Tags do Achado: ["Alpha", "Beta", "Charlie"] + - Consulta de Filtro: "et" (parte de "Beta") + +Os outros seis filtros de tags seguem as mesmas regras que "Tags" e "Not Tags" acima, +mas em níveis diferentes do modelo de dados: + + - Tags (Teste): filtra por quaisquer tags anexadas ao Teste de um determinado Achado + - Not Tags (Teste): filtra por quaisquer tags que *não* estejam anexadas ao Teste de um determinado Achado + - Tags (Engajamento): filtra por quaisquer tags anexadas ao Engajamento de um determinado Achado + - Not Tags (Engajamento): filtra por quaisquer tags que *não* estejam anexadas ao Engajamento de um determinado Achado + - Tags (Ativo): filtra por quaisquer tags anexadas ao Ativo de um determinado Achado + - Not Tags (Ativo): filtra por quaisquer tags que *não* estejam anexadas ao Ativo de um determinado Achado diff --git a/docs/content/asset_modelling/tags/PRO__tagging_objects copy.pt-br.md b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.pt-br.md new file mode 100644 index 0000000000..7b970ce8ea --- /dev/null +++ b/docs/content/asset_modelling/tags/PRO__tagging_objects copy.pt-br.md @@ -0,0 +1,179 @@ +--- +title: Marcação de Objetos +description: Use Tags para criar um novo recorte do seu modelo de dados +draft: false +weight: 2 +exclude_search: false +audience: pro +aliases: +- /pt-br/en/working_with_findings/organizing_engagements_tests/tagging_objects +--- + +Tags são ideais para agrupar objetos de forma que possam ser filtrados em blocos menores e mais fáceis de analisar. Podem ser usadas para indicar status ou para criar conjuntos personalizados de Tipo de Produto, Produtos, Engajamentos ou Achados em todo o modelo de dados. + +No DefectDojo, as tags são um cidadão de primeira classe e são reconhecidas como as facilitadoras +da organização em cada nível do modelo de dados. + +Aqui está um exemplo com um Produto com duas tags e quatro achados, cada um com uma única tag: + +![High level example of usage with tags](images/tags-high-level-example.png) + +### Formatos de Tag + +As tags podem ser formatadas de qualquer uma das seguintes maneiras: +- StringWithNoSpaces +- string-with-hyphens +- string_with_underscores +- colons:acceptable + +## Gerenciamento de Tags (Pro UI) + +### Adicionando e Removendo + +As tags podem ser gerenciadas das seguintes formas: + +1. **Criando ou Editando novos objetos** + + Quando um novo objeto é criado ou editado pela UI ou pela API, há um campo para especificar + as tags a serem definidas em um determinado objeto. + + ![tag](images/tags_product.png) + +2. **Ao Importar/Reimportar Achados** + + As tags estão disponíveis no formulário de Importação/Reimportação, tanto na UI quanto via API. Quando esse formulário é enviado, o **Teste** será marcado com `[tag]` e `[daily-import]`. Se "Apply Tags to Findings" ou "Apply Tags to Endpoints" estiver selecionado, esses objetos também serão marcados. As tags oferecem a oportunidade de anexar detalhes de execução de automação e informações da ferramenta que talvez não sejam capturadas diretamente no objeto Teste ou Achado. + + ![tag](images/tags_importscan.png) + +3. **Via Edição em Massa** + + Quando muitos Achados são selecionados em uma tabela, você pode usar o menu de Edição em Massa para alterar as Tags associadas a vários Achados simultaneamente. Observe que isso substituirá todas as Tags no nível do Achado pelas Tags especificadas; as Tags existentes do Achado serão sobrescritas. + + ![bulk editing findings](images/Bulk_Editing_Findings.png) + + +## Gerenciamento de Tags (Classic UI / OpenSource) + +### Adicionando e Removendo + +As tags podem ser gerenciadas das seguintes formas: + +1. Criando ou Editando novos objetos + + Quando um novo objeto é criado ou editado pela UI ou pela API, há um campo para especificar + as tags a serem definidas em um determinado objeto. Esse campo é um campo de seleção múltipla que também conta com + preenchimento automático, tornando fácil buscar e adicionar tags existentes. Veja como o campo + se parece no Produto a partir da captura de tela da seção anterior: + + ![Tag management on an object](images/tags-management-on-object.png) + +2. Importar e Reimportar + + As tags também podem ser aplicadas a um determinado teste no momento da importação ou reimportação. Esse é um caso de uso muito + útil ao importar via API com automação, pois oferece a oportunidade de + anexar detalhes de execução de automação e informações da ferramenta que talvez não sejam capturadas diretamente no objeto teste + ou achado. + + O campo se parece e se comporta exatamente como em um determinado objeto + +3. Menu de Edição em Massa (apenas Achados) + + Quando é necessário atualizar muitos Achados com o mesmo conjunto de tags, o menu de edição em massa pode ser + usado para facilitar essa tarefa. + + No exemplo a seguir, digamos que eu queira atualizar as tags dos dois achados com a tag "tag-group-alpha" para uma nova lista de tags como esta ["tag-group-charlie", "tag-group-delta"]. + Primeiro eu selecionaria as tags a serem atualizadas: + + ![Select findings for bulk edit tag update](images/tags-select-findings-for-bulk-edit.png) + + Uma vez selecionado um achado, um novo botão aparece com o nome "Bulk Edit". Clicar nesse botão + exibe um menu suspenso com muitas opções, mas por enquanto o foco é apenas nas tags. Atualize o + campo com a lista de tags desejada, conforme a seguir, e clique em enviar + + ![Apply changes for bulk edit tag update](images/tags-bulk-edit-submit.png) + + As tags nos Achados selecionados serão atualizadas para o que foi especificado no campo de tags + dentro do menu de edição em massa + + ![Completed bulk edit tag update](images/tags-bulk-edit-complete.png) + +## Herança de Tags + +**Nota da Pro UI: embora a herança de Tags possa ser configurada usando a Pro UI, as Tags herdadas atualmente só podem ser acessadas e filtradas pela Classic UI ou pela API.** + +Quando a Herança de Tags está habilitada, as tags aplicadas a um determinado Produto serão automaticamente aplicadas a todos os objetos abaixo de Produtos na [Hierarquia de Produtos](/asset_modelling/os_hierarchy/product_hierarchy/). + +### Configuração + +A Herança de Tags pode ser habilitada nos seguintes níveis de escopo: +- Escopo Global + - Todo Produto do sistema passará a aplicar tags a todos os objetos filhos (Engajamentos, Testes e Achados) + - Isso é definido nas Configurações do Sistema +- Escopo de Produto + - Apenas o Produto selecionado passará a aplicar tags a todos os objetos filhos (Engajamentos, Testes e Achados) + - Isso é definido na página de criação/edição do Produto + +### Comportamentos + +Quando a Herança de Tags está habilitada, as Tags padrão podem ser adicionadas e removidas dos objetos da forma usual. +No entanto, as tags herdadas não podem ser removidas de um objeto filho sem removê-las do objeto pai +Veja o exemplo a seguir de adição de uma tag "test_only_tag" ao objeto Teste e de uma tag "engagement_only_tag" ao Engajamento. + +![Example of inherited tags](images/tags-inherit-exmaple.png) + +Quando são feitas atualizações na lista de tags de um Produto, as mesmas alterações são feitas de forma assíncrona em todos os objetos dentro do Produto. A duração dessa tarefa está diretamente relacionada ao número de objetos contidos em um achado. + +**Open-Source:** Se as alterações de Tag não forem observadas dentro de um período razoável, consulte os logs do celery worker para identificar onde possam ter surgido problemas. + + +### Filtrando por Tags (Classic UI) + +As tags podem ser filtradas de várias maneiras, tanto pela UI quanto pela API. Por exemplo, aqui está um trecho +dos filtros de Achado: + +![Snippet of the finding filters](images/tags-finding-filter-snippet.png) + +Existem dez campos relacionados a tags: + + - Tags: filtra por quaisquer tags que estejam anexadas a um determinado Achado + - Exemplos: + - O Achado será retornado + - Tags do Achado: ["A", "B", "C"] + - Consulta do Filtro: "B" + - O Achado *não* será retornado + - Tags do Achado: ["A", "B", "C"] + - Consulta do Filtro: "F" + - Not Tags: filtra por quaisquer tags que *não* estejam anexadas a um determinado Achado + - Exemplos: + - O Achado será retornado + - Tags do Achado: ["A", "B", "C"] + - Consulta do Filtro: "F" + - O Achado *não* será retornado + - Tags do Achado: ["A", "B", "C"] + - Consulta do Filtro: "B" + - Tag Name Contains: filtra por quaisquer tags que contenham parte ou a totalidade da consulta no Achado em questão + - Exemplos: + - O Achado será retornado + - Tags do Achado: ["Alpha", "Beta", "Charlie"] + - Consulta do Filtro: "et" (parte de "Beta") + - O Achado *não* será retornado + - Tags do Achado: ["Alpha", "Beta", "Charlie"] + - Consulta do Filtro: "meg" (parte de "Omega") + - Not Tags: filtra por quaisquer tags que *não* contenham parte ou a totalidade da consulta no Achado em questão + - Exemplos: + - O Achado será retornado + - Tags do Achado: ["Alpha", "Beta", "Charlie"] + - Consulta do Filtro: "meg" (parte de "Omega") + - O Achado *não* será retornado + - Tags do Achado: ["Alpha", "Beta", "Charlie"] + - Consulta do Filtro: "et" (parte de "Beta") + +Quanto aos outros seis filtros de tag, eles seguem as mesmas regras de "Tags" e "Not Tags" como acima, +mas em níveis diferentes do modelo de dados: + + - Tags (Test): filtra por quaisquer tags que estejam anexadas ao Teste de um determinado Achado + - Not Tags (Test): filtra por quaisquer tags que *não* estejam anexadas ao Teste de um determinado Achado + - Tags (Engagement): filtra por quaisquer tags que estejam anexadas ao Engajamento de um determinado Achado + - Not Tags (Engagement): filtra por quaisquer tags que *não* estejam anexadas ao Engajamento de um determinado Achado + - Tags (Product): filtra por quaisquer tags que estejam anexadas ao Produto de um determinado Achado + - Not Tags (Product): filtra por quaisquer tags que *não* estejam anexadas ao Produto de um determinado Achado diff --git a/docs/content/asset_modelling/tags/_index.pt-br.md b/docs/content/asset_modelling/tags/_index.pt-br.md new file mode 100644 index 0000000000..e14bb290d3 --- /dev/null +++ b/docs/content/asset_modelling/tags/_index.pt-br.md @@ -0,0 +1,8 @@ +--- +title: Tags +date: 2021-02-02 20:46:29+01:00 +draft: false +type: docs +weight: 1 +exclude_search: true +--- diff --git a/docs/content/automation/api/_index.pt-br.md b/docs/content/automation/api/_index.pt-br.md new file mode 100644 index 0000000000..b72c2b4d9e --- /dev/null +++ b/docs/content/automation/api/_index.pt-br.md @@ -0,0 +1,16 @@ +--- +title: Automação +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.pt-br.md b/docs/content/automation/api/api-v2-docs.pt-br.md new file mode 100644 index 0000000000..292c629055 --- /dev/null +++ b/docs/content/automation/api/api-v2-docs.pt-br.md @@ -0,0 +1,398 @@ +--- +title: DefectDojo API v2 +description: A API do DefectDojo permite automatizar tarefas, por exemplo, enviar + relatórios de scan em pipelines de CI/CD. +draft: false +weight: 2 +aliases: +- /pt-br/en/api/api-v2-docs +--- + +A API do DefectDojo é criada usando o [Django Rest +Framework](http://www.django-rest-framework.org/). A documentação de +cada endpoint está disponível em cada instalação do DefectDojo em +[`/api/v2/oa3/swagger-ui`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/) e pode ser acessada escolhendo o link API v2 +Docs no menu suspenso do usuário no cabeçalho. + +![image](images/api_v2_1.png) + +A documentação é gerada usando o [drf-spectacular](https://drf-spectacular.readthedocs.io/) em [`/api/v2/oa3/swagger-ui/`](https://demo.defectdojo.org/api/v2/oa3/swagger-ui/) e é +interativa. No topo da documentação da API v2 há um link que gera uma especificação OpenAPI v3. + +Para interagir com a documentação, é necessário um valor válido de +cabeçalho Authorization. Acesse a view `/api/key-v2` para gerar sua +API Key (`Token `) e copie o valor de cabeçalho fornecido. + +![image](images/api_v2_2.png) + +Cada seção permite que você faça chamadas à API e visualize a Request +URL, o Response Body, o Response Code e os Response Headers. + +![image](images/api_v2_3.png) + +Se você estiver logado na interface web do Defect Dojo, não é necessário fornecer o token de autorização. + +## Autenticação + +A API usa autenticação por cabeçalho com API key. O formato do +cabeçalho deve ser: : + + Authorization: Token + +Por exemplo: : + + Authorization: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +### Método de autenticação alternativo + +Se você usa [um método de autenticação alternativo](/admin/sso/) para os usuários, talvez queira desabilitar os tokens de API do DefectDojo, pois isso pode contornar seu esquema de autenticação. \ +A utilização dos tokens de API do DefectDojo pode ser desabilitada especificando a variável de ambiente `DD_API_TOKENS_ENABLED` como `False`. +Ou apenas o endpoint `api/v2/api-token-auth/` pode ser desabilitado definindo `DD_API_TOKEN_AUTH_ENDPOINT_ENABLED` como `False`. + +## Código de exemplo + +Seguem alguns exemplos simples em python e seus resultados produzidos +contra o endpoint `/users`: : + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +Esse código retornará a lista de todos os usuários definidos no DefectDojo. +O objeto json resultante se parece com: : + +{{< 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 >}} + +Aqui está outro exemplo contra o endpoint `/users`; desta vez +filtraremos os resultados para incluir apenas os usuários cujo nome de +usuário contém `jay`: + +{{< highlight python >}} +import requests + +url = 'http://127.0.0.1:8000/api/v2/users/?username__contains=jay' +headers = {'content-type': 'application/json', + 'Authorization': 'Token c8572a5adf107a693aa6c72584da31f4d1f1dcff'} +r = requests.get(url, headers=headers, verify=True) # set verify to False if ssl cert is self-signed + +for key, value in r.__dict__.items(): + print(f"'{key}': '{value}'") + print('------------------') +{{< /highlight >}} + +O objeto json resultante é: : + +{{< highlight json >}} +[ + { + "first_name": "Jay", + "id": 22, + "last_login": "2015-10-28T08:05:51.925743", + "last_name": "Paz", + "username": "jay7958" + }, + { + "first_name": "", + "id": 31, + "last_login": "2015-10-13T11:44:32.533035", + "last_name": "", + "username": "jay.paz" + } +] +{{< /highlight >}} + +Consulte a [documentação do Django Rest Framework sobre como interagir +com uma API](https://www.django-rest-framework.org/) para +exemplos e dicas adicionais. + +## Chamando a API manualmente + +Ferramentas como o Postman podem ser usadas para testar a API. + +Exemplo de importação de um resultado de scan: + +- Verbo: POST +- URI: +- Aba Headers: + + adicione o cabeçalho de autenticação + : - Chave: Authorization + - Valor: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff + +- Aba Body + + - selecione \"form-data\", clique em \"bulk edit\". Exemplo para um scan ZAP: + + + + engagement:3 + verified:true + active:true + lead:1 + tags:test + scan_type:ZAP Scan + minimum_severity:Info + close_old_findings:false + +- Aba Body + + - Clique em \"Key-value\" edit + - Adicione um parâmetro \"file\" do tipo \"file\". Isso acionará o + envio de dados de formulário multi-part para enviar o conteúdo do arquivo + - Navegue até o arquivo a ser enviado + +- Clique em enviar + +## Clientes / Wrappers de API + +| Wrapper | Status | Notes | +| -----------------------------| ------------------------| ------------------------| +| [Specific python wrapper](https://github.com/DefectDojo/defectdojo_api) | funcionando (2021-01-21) | Wrapper de API incluindo scripts para envio contínuo em CI/CD. Está um pouco atrasado em relação aos recursos mais recentes da API, pois planejamos reformular o wrapper | +| [Openapi python wrapper](https://github.com/alles-klar/defectdojo-api-v2-client) | | apenas prova de conceito, na qual descobrimos que a especificação OpenAPI ainda não está perfeita | +| [Java library](https://github.com/secureCodeBox/defectdojo-client-java) | funcionando (2021-08-30) | Criado pelas gentis pessoas do [SecureCodeBox](https://github.com/secureCodeBox/secureCodeBox) | +| [Image using the Java library](https://github.com/SDA-SE/defectdojo-client) | funcionando (2021-08-30) | | +| [.Net/C# library](https://www.nuget.org/packages/DefectDojo.Api/) | funcionando (2021-06-08) | | +| [dd-import](https://github.com/MaibornWolff/dd-import) | funcionando (2021-08-24) | dd-import não é diretamente um wrapper de API. Ele oferece algumas funções de conveniência para facilitar a importação de achados e dados de linguagem a partir de pipelines de CI/CD. | + +Alguns dos wrappers de API contêm bastante lógica para facilitar o escaneamento e a importação em ambientes de CI/CD. Estamos no processo de simplificar isso tornando a API do DefectDojo mais inteligente (para que os wrappers/scripts de API possam ser mais simples). + +## Notas sobre a API + +### Import / Reimport + +**Reimport** é, na verdade, a forma mais fácil de começar, pois ele cria as entidades necessárias dinamicamente e detecta automaticamente se é o primeiro upload ou um novo envio. + +## Importação +A importação via API é realizada através do endpoint [import-scan](https://demo.defectdojo.org/api/v2/doc/). + +Conforme descrito em [Product Hierarchy](/asset_modelling/os_hierarchy/product_hierarchy/), o Teste é criado dentro de um Engajamento, dentro de um Produto, dentro de um Tipo de Produto. + +Uma importação pode ser realizada especificando os nomes dessas entidades na requisição da API: + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, +} +``` + +Quando `auto_create_context` é `True`, o produto, o engajamento e o ambiente serão criados se necessário. Certifique-se de que seu usuário tenha [permissões](/admin/user_management/about_perms_and_roles/) suficientes para isso. + +Uma forma clássica de importar um scan é especificando o ID do engajamento em vez disso: + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "engagement": 123, +} +``` + +## Reimportação +A reimportação via API é realizada através do endpoint [reimport-scan](https://demo.defectdojo.org/api/v2/doc/). + +Uma reimportação pode ser realizada especificando os nomes dessas entidades na requisição da API: + + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test_title": 'Manual ZAP Scan by John', + "product_type_name": 'Good Products', + "product_name": 'My little product', + "engagement_name": 'Important import', + "auto_create_context": True, + "do_not_reactivate": False, +} +``` + +Quando `auto_create_context` é `True`, o Tipo de Produto, o Produto e o Engajamento serão criados caso ainda não existam. Certifique-se de que seu usuário tenha [permissões](/admin/user_management/about_perms_and_roles/) suficientes para criar um Produto/Tipo de Produto. + +Quando `do_not_reactivate` é `True`, a importação/reimportação ignorará os achados ativos enviados e não reativará achados anteriormente fechados, embora ainda crie novos achados caso haja novidades. Você receberá uma nota no achado explicando que ele não foi reativado por esse motivo. + +Uma reimportação selecionará automaticamente o teste mais recente dentro do engajamento fornecido que satisfaça o `scan_type` informado e (opcionalmente) o `test_title` informado. + +Se nenhum Teste existente for encontrado, o endpoint de reimportação usará a função de importação para importar o relatório fornecido em um novo Teste. Isso significa que um script (de CI/CD) que usa a API não precisa saber se um Teste já existe, ou se é o primeiro upload para esse Produto/Engajamento. + +Uma forma clássica de reimportar um scan é especificando o ID do teste em vez disso: + +```JSON +{ + "minimum_severity": 'Info', + "active": True, + "verified": True, + "scan_type": 'ZAP Scan', + "test": 123, +} +``` + +## Gerando relatórios + +O DefectDojo pode gerar um relatório de achados através da API nos formatos **JSON**, **HTML**, **CSV** ou **Excel**. + +Um relatório é gerado com uma requisição `POST` para uma ação `generate_report/`. O endpoint de achados gera relatórios em toda a sua instância, e a maioria dos outros objetos expõe uma ação por objeto: + +| Endpoint | Scope | +|---|---| +| `POST /api/v2/findings/generate_report/` | Todo achado que você tenha permissão para visualizar | +| `POST /api/v2/products/{id}/generate_report/` | Um produto | +| `POST /api/v2/engagements/{id}/generate_report/` | Um engajamento | +| `POST /api/v2/tests/{id}/generate_report/` | Um teste | +| `POST /api/v2/product_types/{id}/generate_report/` | Um tipo de produto | +| `POST /api/v2/endpoints/{id}/generate_report/` | Um endpoint | + +Os aliases de objeto do Pro expõem a mesma ação: `/api/v2/assets/{id}/generate_report/`, `/api/v2/organizations/{id}/generate_report/` e `/api/v2/location/{id}/generate_report/`. + +### Opções da requisição + +Todos os campos são opcionais — enviar um corpo vazio (`{}`) retorna um relatório JSON. + +| Field | Type | Default | Description | +|---|---|---|---| +| `report_type` | string | `JSON` | Um de `JSON`, `HTML`, `CSV`, `Excel`. | +| `include_finding_notes` | boolean | `false` | Inclui as notas de cada achado. | +| `include_finding_images` | boolean | `false` | Inclui as imagens anexadas aos achados. | +| `include_executive_summary` | boolean | `false` | Inclui uma seção de resumo executivo. | +| `include_table_of_contents` | boolean | `false` | Inclui um sumário. | + +Um `report_type` não suportado (por exemplo, `PDF`) retorna `400 Bad Request` com um erro no campo `report_type`. + +### Exemplo + +Gere um relatório CSV de todos os achados que você pode visualizar e salve-o em um arquivo: + +```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 +``` + +### Formatos de resposta + +| `report_type` | Content type | Response | +|---|---|---| +| `JSON` (default) | `application/json` | Corpo do relatório na resposta | +| `HTML` | `text/html` | Página de relatório renderizada | +| `CSV` | `text/csv` | Anexo de arquivo | +| `Excel` | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` | Anexo de arquivo `.xlsx` | + +CSV e Excel são retornados como anexos de arquivo com um cabeçalho `Content-Disposition`, em vez de um corpo JSON. O nome do arquivo é derivado do objeto a partir do qual o relatório foi gerado — por exemplo, `product_1_findings.csv` ou `test_42_findings.xlsx`. O endpoint `/findings/generate_report/` não está restrito a um único objeto, portanto seus downloads recebem os nomes `findings.csv` e `findings.xlsx`. + +### Notas e limitações + +* As opções `include_*` afetam apenas os relatórios **JSON** e **HTML**. As exportações **CSV** e **Excel** sempre contêm as linhas de achados. +* A geração de relatórios requer permissão de **visualização** nos objetos envolvidos, e um relatório sempre contém apenas os achados que você está autorizado a ver. +* **Os filtros de parâmetros de consulta padrão não são aplicados a esta ação.** Diferente de `GET /api/v2/findings/`, a ação `generate_report/` não aplica os filtros de achados, portanto uma requisição como `POST /api/v2/findings/generate_report/?severity=High` ainda gera relatório sobre todos os achados que você pode visualizar. Para restringir um relatório, gere-o a partir de um produto, engajamento ou teste específico. + +## Comportamento de exclusão assíncrona + +As exclusões no DefectDojo (tanto pela API quanto pela UI) são processadas de forma **assíncrona** por workers em segundo plano do Celery. Quando você exclui um Engajamento, Teste ou outro objeto, a API ou a UI retorna uma resposta de sucesso imediatamente, mas a exclusão de fato é executada em segundo plano. + +Isso significa que: +- Os objetos ainda podem aparecer em consultas por um período após a exclusão ser confirmada. +- As exclusões em cascata (por exemplo, excluir um Engajamento também exclui seus Testes e Achados) são processadas como uma cadeia de tarefas em segundo plano. Os objetos filhos são removidos em ordem de dependência: Achados, depois Testes, depois Engajamentos. +- Para Engajamentos grandes com muitos Achados, esse processo pode levar vários minutos para ser concluído. + +Não há necessidade de criar scripts personalizados para excluir objetos em ordem de dependência. Uma única requisição `DELETE` em um Engajamento se propagará automaticamente em cascata para todos os objetos filhos. Basta aguardar o tempo necessário para que as tarefas em segundo plano sejam concluídas. + +## Limites de paginação da API + +O DefectDojo Pro impõe um tamanho máximo de página de **250** resultados por requisição de API. Definir `limit` acima de 250 pode resultar em erros HTTP 502 devido a timeouts de consulta. + +Instâncias do DefectDojo Open Source também podem apresentar timeouts com tamanhos de página muito grandes, dependendo do tamanho do conjunto de dados e dos recursos do servidor. + +Para conjuntos de resultados grandes, use paginação com um tamanho de página de 50 a 250 e adicione pequenos atrasos entre as requisições paginadas para evitar sobrecarregar o pool de workers. + +## Boas práticas para importação em grande escala + +Ao importar resultados de scan em grande escala (por exemplo, pipelines de SBOM com milhares de componentes), considere o seguinte: + +- **Use `background_import=true`** para payloads grandes. Importações síncronas ocupam um worker uwsgi durante toda a importação, o que pode degradar o desempenho para todos os usuários. +- **Direcione tamanhos de payload abaixo de 1 MB por importação**, sempre que possível. Divida SBOMs grandes em arquivos menores por produto ou grupo de componentes. +- **Adicione atrasos entre chamadas de API consecutivas** para evitar o esgotamento do pool de workers, o que causa erros HTTP 502. +- **Use a Reimportação** (`/api/v2/reimport-scan/`) para scans recorrentes, a fim de atualizar achados existentes em vez de criar duplicatas. + +## Respostas de importação em segundo plano (API: `background_import`) + +Uma importação em segundo plano retorna assim que o relatório enviado é analisado (parsed), antes que qualquer achado tenha sido gravado. Sua resposta, portanto, descreve um trabalho *agendado*, e tem um formato diferente do de uma importação síncrona. Isso se aplica a `/api/v2/import-scan/` e `/api/v2/reimport-scan/` sempre que `background_import` é `true`, ou sempre que a configuração de sistema `api_async_import` ativa esse comportamento para todas as importações. + +Uma resposta em segundo plano contém: + +- `background_import` — `true`. Este é o campo em que se deve basear a lógica condicional. +- `status` — o status de ciclo de vida do teste no momento em que a resposta foi produzida: + `Processing`, `Post Processing - Deduplication`, + `Post Processing - False Positive History`, `Processed` ou `Failed`. +- `findings_parsed` — quantos achados foram lidos a partir do relatório. Esta é uma contagem de análise (parse), não uma contagem de criação: a deduplicação e as opções de importação fornecidas por você determinam quantos achados são de fato gravados. +- `test_id` (e `engagement_id`, `product_id`, `product_type_id`) — os identificadores para consulta. +- `message` — a mesma informação de `status` e `findings_parsed`, em forma de texto. Prefira os campos estruturados. + +Ela **não** contém `statistics`, nem contém `deduplication_complete`. Essas chaves ficam ausentes em vez de zeradas, pois, nesse momento, nenhum achado foi criado, e informar zeros descreveria a importação de forma incorreta. Um cliente que lê `response["statistics"]` incondicionalmente falhará em uma importação em segundo plano — leia `background_import` primeiro, ou use `statistics` apenas no caminho síncrono. + +Para acompanhar uma importação em segundo plano até sua conclusão, consulte o teste: + +``` +POST /api/v2/import-scan/ (background_import=true) -> test_id, status, findings_parsed +GET /api/v2/tests/{test_id}/ -> status, processing +``` + +Repita o `GET` até que `status` seja `Processed` (a importação terminou, e as contagens de achados do teste agora são significativas) ou `Failed` (a importação não foi concluída). Enquanto a importação está em execução, `processing` é `true` e `status` informa em qual fase ela se encontra. Use alguns segundos entre as consultas; um relatório grande pode levar minutos no pós-processamento. + +Uma importação síncrona (`background_import` omitido ou `false`) permanece inalterada: ela retorna assim que os achados foram gravados, inclui `statistics` e não inclui `status` nem `findings_parsed`. + +## Usando o campo de data de conclusão do scan (API: `scan_date`) + +O DefectDojo oferece uma infinidade de relatórios de scanner suportados, mas nem todos contêm a informação mais importante para o usuário. O campo `scan_date` é um recurso inteligente e flexível que permite ao usuário definir a data de conclusão de um determinado relatório de scan, propagando-a para todos os achados importados. Este campo **não** é obrigatório, mas o valor padrão para esse campo é a data da importação (quando a requisição é processada e uma resposta de sucesso é retornada). + +Seguem os casos de uso para esse campo: + +1. O relatório **não** define a data, e `scan_date` **não** é definido na importação + - A data do achado será o valor padrão de `scan_date` +2. O relatório **define** a data, e `scan_date` **não** é definido na importação + - A data do achado será o que quer que o relatório definir +3. O relatório **não** define a data, e `scan_date` **é definido** na importação + - A data do achado será o que quer que o usuário tenha definido para `scan_date` +4. O relatório **define** a data, e `scan_date` **é definido** na importação + - A data do achado será o que quer que o usuário tenha definido para `scan_date` diff --git a/docs/content/automation/api/languages.pt-br.md b/docs/content/automation/api/languages.pt-br.md new file mode 100644 index 0000000000..33f5ea4afa --- /dev/null +++ b/docs/content/automation/api/languages.pt-br.md @@ -0,0 +1,39 @@ +--- +title: Idiomas e linhas de código +description: Importe dados de composição de linguagens para um Produto usando a ferramenta + cloc +weight: 3 +audience: opensource +aliases: +- /pt-br/en/open_source/languages +--- + +O DefectDojo pode exibir uma análise das linguagens de programação e das linhas de código de um Produto, preenchida a partir da importação de um relatório da ferramenta [cloc](https://github.com/AlDanial/cloc) (Count Lines of Code) via API. + +## Gerando o relatório do cloc + +Execute o `cloc` sobre sua base de código usando a flag `--json` para produzir um arquivo JSON no formato correto: + +```bash +cloc --json /path/to/your/project > cloc-report.json +``` + +## Importando via API + +Envie o relatório JSON para o DefectDojo via API. Ao importar, todos os dados de linguagem existentes para o Produto são substituídos pelo conteúdo do novo arquivo. + +O endpoint de importação está documentado em [DefectDojo API v2 docs](../api-v2-docs/). + +## Visualizando os resultados + +Após a importação, a análise das linguagens é exibida no lado esquerdo da página de detalhes do Produto, mostrando cada linguagem e sua contagem de linhas. As cores de cada linguagem são definidas por entradas na tabela `Language_Type`, pré-preenchida com dados do GitHub. + +## Atualizando as cores das linguagens + +O GitHub atualiza periodicamente as cores das linguagens conforme surgem novas linguagens. Para obter os dados de cor mais recentes, execute o seguinte comando de gerenciamento: + +```bash +./manage.py import_github_languages +``` + +Isso lê os dados de [ozh/github-colors](https://github.com/ozh/github-colors) e adiciona novas linguagens ou atualiza cores existentes. diff --git a/docs/content/automation/api/notification_webhooks.pt-br.md b/docs/content/automation/api/notification_webhooks.pt-br.md new file mode 100644 index 0000000000..405c8dff5e --- /dev/null +++ b/docs/content/automation/api/notification_webhooks.pt-br.md @@ -0,0 +1,347 @@ +--- +title: Webhooks de notificação +description: Envie notificações de webhook HTTP para um servidor externo em eventos + do DefectDojo +weight: 8 +audience: opensource +aliases: +- /pt-br/en/open_source/notification_webhooks/how_to +--- + +**Este é um recurso experimental do Open Source — o comportamento pode mudar em versões futuras.** + +Webhooks são requisições HTTP de saída enviadas da sua instância do DefectDojo para um servidor definido pelo usuário sempre que ocorrem eventos específicos. + +## Configuração + +Os endpoints de webhook são configurados por administradores. Quando um webhook é criado, o DefectDojo envia um evento [`ping`](#ping) para verificar se o endpoint está acessível e retornando o código de status esperado. + +## Transições de estado do endpoint + +O DefectDojo monitora o sucesso das entregas e desabilitará um endpoint temporária ou permanentemente com base em respostas HTTP ou falhas de rede. A reativação manual por um administrador também é possível. + +- **Estados em formato de estádio**: Ativo — webhooks podem ser enviados +- **Estados em formato de retângulo**: Inativo — a entrega do webhook falhará e não será repetida +- **Transições motivadas por**: respostas HTTP do servidor de destino, automação do celery, ou ação manual de um administrador + +## Cabeçalhos da requisição + +Toda requisição de webhook inclui os seguintes cabeçalhos: + +```yaml +User-Agent: DefectDojo- +X-DefectDojo-Event: +X-DefectDojo-Instance: +``` + +## Eventos + +### product_type_added + +Disparado quando um novo Tipo de Produto é criado. + +**Cabeçalho:** +```yaml +X-DefectDojo-Event: product_type_added +``` + +**Corpo:** +```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 + +Disparado quando um novo Produto é criado. + +**Cabeçalho:** +```yaml +X-DefectDojo-Event: product_added +``` + +**Corpo:** +```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 + +Disparado quando um novo Engajamento é criado. + +**Cabeçalho:** +```yaml +X-DefectDojo-Event: engagement_added +``` + +**Corpo:** +```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 + +Disparado quando um novo Teste é criado. + +**Cabeçalho:** +```yaml +X-DefectDojo-Event: test_added +``` + +**Corpo:** +```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 + +Disparado quando um scan é importado ou reimportado. `scan_added_empty` é disparado quando uma reimportação não resulta em nenhuma alteração (nenhum achado criado ou fechado). + +**Cabeçalhos:** +```yaml +X-DefectDojo-Event: scan_added +``` +```yaml +X-DefectDojo-Event: scan_added_empty +``` + +**Corpo:** +```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 + +Enviado durante a configuração do webhook para verificar se o endpoint está acessível. + +**Cabeçalho:** +```yaml +X-DefectDojo-Event: ping +``` + +**Corpo:** +```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" + } +} +``` + +## Roteiro + +Melhorias planejadas conhecidas: + +- Eventos relacionados a SLA (ainda não suportado) +- Webhooks definidos pelo usuário (atualmente restrito a administradores) +- UI aprimorada com filtragem e paginação para endpoints de webhook diff --git a/docs/content/automation/api/rate_limiting.pt-br.md b/docs/content/automation/api/rate_limiting.pt-br.md new file mode 100644 index 0000000000..46371053f6 --- /dev/null +++ b/docs/content/automation/api/rate_limiting.pt-br.md @@ -0,0 +1,45 @@ +--- +title: Limitação de taxa +description: Configure a limitação de taxa na página de login para mitigar ataques + de força bruta +weight: 4 +audience: opensource +aliases: +- /pt-br/en/open_source/rate_limiting +--- + +O DefectDojo inclui limitação de taxa (rate limiting) na página de login para proteger contra ataques de força bruta, com tecnologia do [Django Ratelimit](https://django-ratelimit.readthedocs.io/en/stable/index.html). + +## Configuração + +A limitação de taxa é configurada por meio das seguintes definições (veja [Configuration](/get_started/open_source/configuration/) para saber como aplicá-las): + +```python +DD_RATE_LIMITER_ENABLED=(bool, True), +DD_RATE_LIMITER_RATE=(str, '5/m'), +DD_RATE_LIMITER_BLOCK=(bool, True), +DD_RATE_LIMITER_ACCOUNT_LOCKOUT=(bool, True), +``` + +### Rate Limit (`DD_RATE_LIMITER_RATE`) + +Define a frequência com que as requisições serão limitadas. Unidades suportadas: + +- Segundos: `1s` +- Minutos: `5m` +- Horas: `100h` +- Dias: `2400d` + +Consulte a [documentação de taxas do Django Ratelimit](https://django-ratelimit.readthedocs.io/en/stable/rates.html) para opções de configuração estendidas. + +### Block Requests (`DD_RATE_LIMITER_BLOCK`) + +Por padrão, a limitação de taxa registra as ocorrências, mas não bloqueia as requisições. Definir `DD_RATE_LIMITER_BLOCK` como `True` bloqueará ativamente todas as requisições recebidas assim que a taxa configurada for excedida. + +### Account Lockout (`DD_RATE_LIMITER_ACCOUNT_LOCKOUT`) + +Quando habilitado, um usuário cujas tentativas de login acionarem o limite de taxa precisará redefinir sua senha antes de conseguir fazer login novamente. Isso reduz o risco de comprometimento de credenciais durante um ataque de força bruta. + +## Comportamento com múltiplos processos + +Ao executar com múltiplos processos `uwsgi`, o pacote de limitação de taxa usa um cache baseado em memória, local a cada processo. Os contadores de limite de taxa não são compartilhados entre processos nessa configuração padrão. diff --git a/docs/content/automation/rules_engine/_index.pt-br.md b/docs/content/automation/rules_engine/_index.pt-br.md new file mode 100644 index 0000000000..14d1a6ce7b --- /dev/null +++ b/docs/content/automation/rules_engine/_index.pt-br.md @@ -0,0 +1,17 @@ +--- +title: Rules Engine +description: '' +summary: '' +date: 2023-09-07 16:06:50+02:00 +lastmod: 2023-09-07 16:06:50+02:00 +draft: false +weight: 98 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine/about.pt-br.md b/docs/content/automation/rules_engine/about.pt-br.md new file mode 100644 index 0000000000..fb7f2fc8d2 --- /dev/null +++ b/docs/content/automation/rules_engine/about.pt-br.md @@ -0,0 +1,126 @@ +--- +title: Automação do Rules Engine +description: Trabalhando com a automação do Rules Engine +weight: 1 +audience: pro +aliases: +- /pt-br/en/customize_dojo/rules_engine +--- + +Observação: o Rules Engine é um recurso exclusivo do DefectDojo Pro. + +O Rules Engine do DefectDojo permite construir workflows personalizados e ações em massa para tratar Findings e outros objetos. O Rules Engine permite construir ações automatizadas que são disparadas quando um objeto corresponde a uma Regra. + +O Rules Engine só pode ser acessado através da [Pro UI](/get_started/about/ui_pro_vs_os/). + +**Procurando o editor de grafos?** O [Rules Engine 2.0](/automation/rules_engine_2/about/) constrói automações como grafos visuais de nós, e adiciona ramificações, ações de saída como tickets e mensagens, rastros por execução e um livro-razão de entregas. Os dois mecanismos funcionam lado a lado, e regras existentes podem ser [convertidas](/automation/rules_engine_2/converting_from_rules_engine/). + +## Habilitando o Rules Engine + +O Rules Engine está em Beta e vem desativado por padrão. Um superusuário pode ativá-lo em **Settings > Feature Flags**, tanto em instâncias Cloud quanto On-Premise. Veja [Feature Flags](/admin/feature_flags/pro__feature_flags/). + +Atualmente, Regras só podem ser criadas para Findings, mas mais tipos de objeto serão suportados no futuro. + +As Regras podem ser disparadas manualmente na página **All Rules**, ou agendadas para rodar automaticamente em um cronograma recorrente. Quando uma regra é disparada, ela será aplicada a todos os Findings existentes que correspondam às condições de filtro definidas. + +## Ações de Regra possíveis +Cada Regra pode aplicar uma ou mais destas alterações a um Finding quando é disparada com sucesso (ou seja, corresponde às condições de Filtro definidas). + +### Modificações de campo +* **Definir um campo** em um Finding, incluindo Title, Description, Severity, CVSSv3 Vector, Active, Verified, Risk Accepted, False Positive, Mitigated +* **Anexar ou prefixar texto** ao Title ou Description de um Finding +* **Set Priority** — sobrescreve o valor de Priority calculado em um Finding (sobrepõe o cálculo automático de prioridade) +* **Set Risk** — sobrescreve o nível de Risk calculado em um Finding (sobrepõe o cálculo automático de risco) +* **Somar, Subtrair, Multiplicar ou Dividir** o valor de Priority em um Finding por um número informado + +### Atribuições e propriedade +* **Definir um usuário para revisar** um Finding +* **Atribuir um Grupo como Owners** de um Finding +* **Definir uma Mitigation Policy** em um Finding — atribui uma Mitigation Policy pré-configurada ao Finding +* **Adicionar a Risk Acceptance** — adiciona um Finding a um registro de Risk Acceptance existente (define risk_accepted=True, active=False, e trata a integração com Jira e os status de endpoint) + +### Tags, Notas e Alertas +* **Adicionar Tags** a um Finding +* **Adicionar uma Nota** a um Finding +* **Criar um Alerta** no DefectDojo com texto personalizado + +### Condições de filtro +As Regras são disparadas automaticamente quando um Finding atende a condições de Filtro específicas. Para mais informações sobre os Filtros que podem ser usados para criar Ações de Regra, veja a página [Filter Index](/navigation/pro__filter_index). + +## Criando uma nova Regra +Inicie este processo pela página New Rule. Na [Pro UI](/get_started/about/ui_pro_vs_os/), em **Manage Category**, expanda o menu suspenso **Rules Engine** e clique em **+ New Rule**. + +![image](images/rules_engine_1.png) + +### Etapa 1: Nomeie sua Regra +Digite um Label como identificador da nova regra e clique em Next. + +![image](images/rules_engine_2.png) + +### Etapa 2: Defina as condições de disparo com um Filtro +Você verá uma tabela All Findings. Usando essa tabela, defina as condições de Filtro para filtrar o conjunto de Findings ao qual sua regra deve se aplicar. Para mais informações sobre como aplicar Filtros a uma tabela, veja [nosso guia da Pro UI](/get_started/about/ui_pro_vs_os/#navigational-changes). + +A tabela mostrará uma prévia da lista de Findings existentes que você filtrou. + +Por exemplo, nesta captura de tela estamos filtrando todos os Findings que estão em 'Product One'. Depois de aplicarmos este filtro (clicando fora do menu de Filtros), ele será adicionado à nossa lista de Filtros aplicáveis. + +![image](images/rules_engine_3.png) + +Na captura de tela acima, todos os Findings que estão no Produto 'Product One' terão ações aplicadas a eles. + +Depois de ter o conjunto de Filtros que deseja aplicar, clique no botão Next. + +### Etapa 3: Defina as Ações da Regra +No menu suspenso **Action**, selecione a Ação que deseja aplicar a um Finding que corresponda a todos os filtros da Etapa 2. Várias Ações podem ser aplicadas. + +Você pode definir Valores Condicionais adicionais, que permitem executar ações extras caso certos critérios sejam atendidos. + +![image](images/rules_engine_4.png) + + +Por exemplo, na captura de tela acima temos 4 Ações de Regra definidas. Duas dessas ações são Condicionais. + +Todos os Findings que correspondem às condições de filtro disparam estas Ações Não Condicionais: + +* O Finding será atribuído ao grupo de usuários 'Group 1' +* O Finding será marcado com a tag `all_group_1` + +Quaisquer Findings que correspondam às condições de filtro, mais estas condições **adicionais**, disparam estas Ações Condicionais, além das duas Ações Não Condicionais listadas acima: + +* **se o Finding tiver Severidade Crítica**, ele será marcado com a tag `critical_group_1`. +* **se o Finding tiver Severidade Alta**, ele será marcado com a tag `high_group_1`. + +### Etapa 4 - Visualize a prévia da sua Regra + +O Rule Preview exibe todos os Findings que serão alterados por esta regra quando ela for executada, junto com uma prévia das Ações realizadas. Confirme que está satisfeito com as alterações propostas e clique em Submit para salvar sua regra. + +Se você acredita que esta regra não foi aplicada corretamente, pode clicar no botão Back e voltar a qualquer uma das etapas anteriores. + +![image](images/rules_engine_5.png) + +Por exemplo, na captura de tela acima temos uma lista de Findings que serão afetados pela Regra quando ela for executada. Podemos ver que novas Tags e Owners serão aplicados a cada um desses Findings, nas colunas à direita da lista de Findings. + +Você será solicitado novamente a confirmar que deseja criar sua Regra. Observe que a **Regra não será aplicada imediatamente**, e deve ser disparada manualmente. + +## Executando uma Regra +Na página All Rules, você pode selecionar a Regra que deseja executar. Clique no título da regra para vê-la em mais detalhes. + +![image](images/rules_engine_6.png) + +Nesta página, você pode ver informações detalhadas sobre esta regra em **Metadata**, incluindo informações sobre quando a regra foi disparada pela última vez. Você também pode ver uma prévia de quaisquer Findings que serão afetados por uma nova execução desta Regra, logo abaixo de **Rule Preview**. + +Para executar a Regra, clique no botão verde Run Rule. Depois de confirmar que deseja executar a regra, aparecerá uma mensagem informando que a regra foi enfileirada para execução em segundo plano. + +Assim que a Regra terminar de ser executada com sucesso, o número de Items Changed será atualizado na seção Rule Metadata da descrição da Regra. + +## Referência de Rule Metadata +* **Rule For**: os objetos governados pela Regra. +* **Rule Name**: o nome da Regra. +* **Filters**: o número de Filtros aplicados por esta Regra. +* **Actions**: o número de Ações realizadas por esta Regra. +* **Owner**: o Usuário que criou esta Regra. +* **Status**: o relatório de Status da última vez que esta Regra foi executada. + 'E' = 'Error', 'R' = 'Running', 'S' = 'Success'. +* **Last Run**: o timestamp da última vez que esta Regra foi executada. +* **Items Changed:** contagem de objetos que foram alterados na última execução da regra. +* **Items Skipped:** contagem de objetos que foram ignorados na última execução da regra. Se um objeto filtrado já corresponde ao 'resultado' de uma Ação de Regra aplicada a ele (por exemplo, se ele já tem as Tags que seriam aplicadas por uma Ação de Regra), o objeto simplesmente será ignorado. diff --git a/docs/content/automation/rules_engine/scheduling.pt-br.md b/docs/content/automation/rules_engine/scheduling.pt-br.md new file mode 100644 index 0000000000..02a3d6064e --- /dev/null +++ b/docs/content/automation/rules_engine/scheduling.pt-br.md @@ -0,0 +1,55 @@ +--- +title: Agendamento de regras +description: Execute regras do Rules Engine automaticamente em um agendamento recorrente + ou único +weight: 2 +audience: pro +--- + +Observação: o Agendamento do Rules Engine é um recurso exclusivo do DefectDojo Pro. + +As Regras podem ser agendadas para rodar automaticamente, em vez de serem disparadas manualmente todas as vezes. Uma regra agendada será executada contra todos os Findings que correspondam às suas condições de filtro no horário configurado. + +O agendamento vem desativado por padrão e é habilitado por instância pelo DefectDojo, em vez de pela página Feature Flags. Entre em contato com o [Suporte DefectDojo](mailto:support@defectdojo.com) para que o **Scheduling Service** seja ativado; a opção **Schedule Rule** aparece assim que ele estiver ativo. Veja [Feature Flags](/admin/feature_flags/pro__feature_flags/) para saber como são exibidos os recursos que o DefectDojo gerencia de forma centralizada. + +O usuário que configurar o agendamento precisa ter a permissão de configuração **Change Scheduling Service Schedule**. + +## Tipos de agendamento + +### Single Run + +Um agendamento Single Run executa a regra uma única vez, em uma data e hora específicas. Depois que a execução é concluída, o agendamento não se repete. + +### Repeated Run + +Um agendamento Repeated Run permite disparar uma regra de forma recorrente — por exemplo, todo dia às 9:00, ou toda segunda-feira às 15:00. + +**Observação:** os agendamentos do Rules Engine são limitados a marcas de quinze em quinze minutos. O campo de minuto de um agendamento cron deve ser um dos seguintes: **0, 15, 30 ou 45**. Outros valores de minuto não são permitidos. + +Exemplos de agendamentos válidos: +- Toda hora, na hora cheia: `0 * * * *` +- Todo dia às 9:15: `15 9 * * *` +- Toda segunda-feira às 15:00: `0 15 * * 1` +- A cada 15 minutos: `0,15,30,45 * * * *` + +## Criando um agendamento para uma Regra + +1. Navegue até a página **All Rules** pelo menu **Rules Engine** na barra lateral. +2. Encontre a regra que deseja agendar e abra seu menu de ações (**⋮**). +3. Clique em **Schedule Rule**. Esta opção só fica visível se o Scheduling Service estiver habilitado e você tiver a permissão necessária. +4. No modal **Schedule Rule**, preencha os seguintes campos: + +| Campo | Descrição | +|---|---| +| **Name** | Um nome único para este agendamento (obrigatório, máximo de 100 caracteres). | +| **Description** | Descrição opcional da finalidade do agendamento. | +| **Trigger Type** | Escolha **Single Run** para uma execução única, ou **Repeated Run** para um agendamento cron recorrente. | +| **Frequency** | Para Repeated Run: use o construtor de cron para selecionar o período (por hora, diário, semanal etc.) e os valores específicos de minuto, hora e dia. Para Single Run: selecione uma data e hora usando o seletor de data. | +| **Enable Schedule** | Alterna para habilitar ou desabilitar o agendamento. Um agendamento desabilitado não será executado até ser reabilitado. | + +5. Clique em **Submit** para salvar o agendamento. A regra será executada automaticamente no próximo horário agendado. + + +## Permissões + +O acesso ao agendamento dentro do Rules Engine requer permissões de Superusuário ou a Permissão de Configuração apropriada. Veja [User Permission Chart](/admin/user_management/user_permission_chart) para mais detalhes. diff --git a/docs/content/automation/rules_engine_2/_index.pt-br.md b/docs/content/automation/rules_engine_2/_index.pt-br.md new file mode 100644 index 0000000000..56ad6d1ca7 --- /dev/null +++ b/docs/content/automation/rules_engine_2/_index.pt-br.md @@ -0,0 +1,18 @@ +--- +title: Motor de Regras 2.0 +description: Construa automações como grafos visuais de nós, com rastreamento por + execução e um registro de entregas +summary: '' +date: 2026-08-02 09:00:00+00:00 +lastmod: 2026-08-02 09:00:00+00:00 +draft: false +weight: 99 +chapter: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +exclude_search: true +audience: pro +--- diff --git a/docs/content/automation/rules_engine_2/about.pt-br.md b/docs/content/automation/rules_engine_2/about.pt-br.md new file mode 100644 index 0000000000..a249e0d62d --- /dev/null +++ b/docs/content/automation/rules_engine_2/about.pt-br.md @@ -0,0 +1,118 @@ +--- +title: Sobre o Rules Engine 2.0 +description: O que é o Rules Engine 2.0, como ativá-lo e os conceitos em que se baseia +weight: 1 +audience: pro +aliases: +- /pt-br/automation/rules_engine_v2/about/ +--- + +Nota: O Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro. + +Rules Engine 2.0 é um construtor visual de automação. Em vez de um filtro mais uma lista simples de ações, uma regra é um **grafo**: um nó de gatilho que decide quando a regra é ativada, e qualquer número de nós de lógica, de Achado e de saída (egress) conectados entre si para dizer o que acontece a seguir. + +O Rules Engine 2.0 só pode ser acessado pela [Pro UI](/get_started/about/ui_pro_vs_os/). + +## O que ele adiciona em relação ao Rules Engine + +O [Rules Engine](/automation/rules_engine/about/) original aplica uma lista ordenada de ações a cada Achado que corresponde a um filtro. O Rules Engine 2.0 mantém essa capacidade e adiciona quatro coisas: + +* **Ramificação (branching).** Um nó **If / Filter** encaminha os itens por um ramo verdadeiro e um ramo falso, de modo que uma única regra possa tratar Achados Críticos de forma diferente do restante sem precisar ser dividida em duas regras. +* **Saída (egress).** Uma regra pode sair do DefectDojo: abrir um chamado no JIRA ou em um sistema de tickets externo, publicar no Slack ou no Microsoft Teams, enviar um e-mail, chamar um webhook, disparar um alerta no aplicativo ou gerar um relatório. +* **Rastreabilidade.** Cada execução é registrada nó a nó como uma [Execução](../runs/), e cada envio de saída é registrado como uma [Entrega](../deliveries/) que informa exatamente o que foi enviado, para onde foi e como terminou. +* **Um modo de simulação.** Uma regra pode registrar exatamente o que enviaria sem enviar nada de fato, o que permite testá-la com segurança antes de deixá-la tocar o mundo externo. + +Os dois mecanismos funcionam lado a lado. Ativar o Rules Engine 2.0 não desativa nem converte suas regras existentes, e há um [conversor](../converting_from_rules_engine/) para quando você quiser migrá-las. + +## Ativando o Rules Engine 2.0 + +O Rules Engine 2.0 está em Beta e vem desativado por padrão. Um superusuário o ativa em **Settings > Feature Flags**, tanto em instâncias Cloud quanto On-Premise. Veja [Feature Flags](/admin/feature_flags/pro__feature_flags/). + +Assim que a flag é ativada, uma seção **Rules Engine 2.0** aparece na barra lateral com três páginas: + +| Página | Para que serve | +|------|----------------| +| **All Rules** | A lista de regras. Crie, edite, ative, execute e exclua regras a partir daqui. | +| **Runs** | Cada execução, com seu rastreamento por nó. | +| **Deliveries** | O registro de tudo o que as regras enviaram para fora. | + +### Permissões + +O acesso é regido por duas permissões globais de função, compartilhadas com o Rules Engine original: + +* **Rule View** é necessária para ver a seção na barra lateral e tudo o que está nela. +* **Rule Edit** é necessária para criar, alterar, executar, excluir, converter, assumir a propriedade e reproduzir. + +Rule Edit está próxima de ser uma permissão administrativa. Um autor de regra pode alcançar qualquer Achado que o proprietário da regra consiga ver, e pode direcionar a saída para sistemas externos, portanto conceda-a com cautela. + +## Os conceitos + +### Regras e grafos + +Uma regra é um nome, uma descrição, um proprietário, um modo, uma chave de ativação e um grafo. O grafo é um conjunto de **nós** e as **arestas** entre eles. Ele deve conter exatamente um nó de gatilho e não pode conter um ciclo. Tudo o mais fica a seu critério, inclusive deixar um nó desconectado, o que simplesmente significa que ele é executado sem nada para processar. + +Novas regras são sempre criadas **desativadas**, portanto ativar uma é um ato deliberado. + +### Itens + +O que trafega pelas arestas de um grafo é um **item**: um snapshot em JSON de um Achado mais o contexto ao seu redor. + +```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" } +} +``` + +As condições e os modelos de mensagem são escritos com base nos caminhos dessa estrutura, por exemplo `finding.severity` ou `product.name`. A lista completa de campos está em [Building Rules](../building_rules/). + +### Proprietário + +Toda regra é executada **como o seu proprietário**. Ela vê exatamente os Achados que esse usuário consegue ver, através da mesma autorização usada em todo o restante do produto. Duas consequências valem a pena conhecer: + +* Restringir o acesso do proprietário de uma regra restringe a regra. +* Uma regra cujo proprietário teve a conta excluída fica sem proprietário, portanto não corresponde a nada e não faz nada. Atribua um novo proprietário, ou use **Take Ownership** na lista de regras, para trazê-la de volta. + +### Modo: Simulate ou Live + +O modo é definido por regra, não por nó. + +* **Simulate** (o padrão) executa o grafo inteiro de verdade, incluindo toda edição de Achado, mas os nós de saída registram o que *teriam* enviado e param por aí. Nada sai do DefectDojo. +* **Live** realiza os envios de fato. + +Os envios simulados ainda aparecem no registro de Deliveries, marcados como `simulated`, com sua carga (payload) completa. Essa é a forma pretendida de revisar uma regra antes de liberá-la. + +O modo se aplica deliberadamente à regra inteira. Um grafo em que alguns envios são reais e outros não é mais difícil de entender do que duas regras separadas. + +### Execuções (Runs) + +Uma execução de uma regra é uma [Execução](../runs/). Uma execução registra o evento que a disparou, seu status, seu rastreamento por nó e qualquer erro. Uma regra só pode ter uma execução em andamento por vez, portanto uma regra ocupada entra em fila em vez de competir consigo mesma. + +### Entregas (Deliveries) + +Todo efeito colateral de saída é uma linha no registro de [Entregas](../deliveries/), gravada **antes** de qualquer chamada de rede acontecer. A linha contém a carga (payload), o destino resolvido, o status, o número de tentativas e o que quer que o destino tenha respondido. As omissões (skips) também são registradas, de modo que "a regra não fez nada" e "a regra não fez nada porque o Achado já tinha um chamado aberto" são situações distinguíveis. + +### Proveniência + +Toda alteração que uma regra faz em um Achado é atribuída de volta à regra, à execução e ao nó que a realizou. Essa linha do tempo fica visível no próprio Achado, de modo que você pode responder "por que esse Achado mudou?" sem precisar ler as definições das regras. + +### Escala + +Uma regra processa tudo o que seu escopo corresponde. Não há limite para quantos Achados uma execução processa: ela os percorre em blocos (chunks) para que o consumo de memória permaneça limitado, e não a cobertura. Somente o Preview impõe limites, e ele avisa quando o faz. + +### Retenção + +Execuções e entregas são mantidas por 180 dias por padrão, e depois são removidas. O produto mostra a janela e a data em que um determinado registro será excluído, em vez de deixar isso implícito, e ambas as janelas são configuráveis. Veja [Configuration](../configuration/#retention). + +## Para onde ir a seguir + +* [Building Rules](../building_rules/) aborda o editor, gatilhos, escopo, condições e modelos. +* [Node Reference](../node_reference/) documenta todos os 25 nós. +* [Runs](../runs/) aborda execução, rastreamentos, encadeamento (cascading) e limites. +* [Deliveries](../deliveries/) aborda canais, status, novas tentativas e reprodução (replay). +* [Converting from Rules Engine](../converting_from_rules_engine/) aborda a migração de regras existentes. +* [Configuration](../configuration/) aborda as configurações em nível de implantação. diff --git a/docs/content/automation/rules_engine_2/building_rules.pt-br.md b/docs/content/automation/rules_engine_2/building_rules.pt-br.md new file mode 100644 index 0000000000..5277501325 --- /dev/null +++ b/docs/content/automation/rules_engine_2/building_rules.pt-br.md @@ -0,0 +1,197 @@ +--- +title: Construindo Regras +description: O editor de grafos, gatilhos, escopo, condições e modelos de mensagem +weight: 2 +audience: pro +aliases: +- /pt-br/automation/rules_engine_v2/building_rules/ +--- + +Nota: O Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro. + +Uma regra é construída em uma tela (canvas). Você arrasta nós de uma paleta, os conecta entre si e configura cada um em um painel lateral. Esta página aborda as partes desse processo que são iguais independentemente dos nós usados. Os próprios nós estão descritos em [Node Reference](../node_reference/). + +## O editor + +Abra **Rules Engine 2.0 > All Rules** e escolha **New Rule**, ou abra uma regra existente para editá-la. + +A paleta é agrupada em quatro categorias, que também é a ordem em que os itens fluem por um grafo típico: + +| Categoria | O que os nós fazem | +|----------|-------------------| +| **Triggers** | Decidem quando a regra é ativada e quais Achados entram nela. Exatamente um por grafo. | +| **Logic** | Roteiam, limitam e removem duplicidades dos itens que fluem por ela. | +| **Findings** | Alteram os Achados. | +| **Egress** | Enviam algo para fora: um chamado, uma mensagem, um relatório. | + +A paleta é gerada a partir do próprio mecanismo, portanto o que você vê no editor é sempre exatamente o que o mecanismo consegue executar. + +### Regras do grafo + +Um grafo é verificado quando você o salva, e novamente antes de cada execução. Ele deve satisfazer todas as condições a seguir: + +* Tem pelo menos um nó. +* Tem **exatamente um** nó de gatilho. +* Cada nó tem um id único e não vazio de até 100 caracteres. +* Cada nó é de um tipo conhecido pelo mecanismo. +* Cada aresta conecta dois nós que existem. +* Não contém ciclos. + +Um nó sem nada conectado a ele é válido. Ele é executado com uma lista de entrada vazia, o que geralmente significa que não faz nada. + +Um nó com várias arestas de entrada recebe todas as saídas delas concatenadas. + +### Pré-visualizando antes de salvar + +O **Preview** executa a seco (dry-run) o grafo que você tem atualmente na tela e mostra o rastreamento por nó que ele produziria: quantos itens entraram em cada nó, quantos saíram por cada saída, e o que cada nó teria alterado. + +O Preview executa o mecanismo real, não uma simulação dele, e depois desfaz tudo. Nada é gravado, nenhuma execução é registrada, e a saída (egress) é forçada a simular o que quer que o modo da regra determine. É a forma mais rápida de verificar se suas condições correspondem ao que você esperava. + +O Preview é a única execução que limita quantos Achados ele examina, para permanecer rápido. Quando trunca, ele informa isso no rastreamento. Uma execução real não tem esse limite. + +## Gatilhos e escopo + +Todo grafo começa com um dos três gatilhos. + +* **On Finding Event** ativa a regra quando Achados são criados, atualizados, fechados ou reabertos. Escolha qual desses eventos na configuração **Event** do nó, ou `any` para os quatro. +* **On a Schedule** varre os Achados em uma programação recorrente. +* **Manual Run** varre os Achados quando você pressiona **Run** na regra. + +### Escopo + +Os três gatilhos aceitam um **Scope**, e o escopo é a forma de restringir o que a regra considera. É o mesmo vocabulário de filtros usado pelo Rules Engine original, cerca de sessenta filtros que abrangem os Achados e os objetos ao seu redor, portanto um filtro que você já sabe escrever lá significa a mesma coisa aqui. + +Duas coisas sobre o escopo valem a pena entender: + +* **O escopo é aplicado por cima da autorização, nunca no lugar dela.** A regra é executada como seu proprietário, portanto o escopo restringe um conjunto de Achados já autorizado. Deixar o escopo vazio não significa "todo Achado na instância", significa "todo Achado que o proprietário da regra consegue ver". +* **Um escopo inválido faz a execução falhar, em vez de ampliá-la.** Se uma chave de filtro não existir, ou um valor for algo que o filtro descartaria silenciosamente, a execução termina com erro. Uma regra que não faz nada é recuperável. Uma regra que silenciosamente edita todo Achado na instância não é. + +Para um gatilho de evento, o escopo funciona como um segundo portão: os Achados indicados no evento são comparados a ele, e somente os que passam entram no grafo. + +### Agendamento + +Uma regra cujo gatilho é **On a Schedule** é agendada a partir da própria regra. Definir a programação exige Rule Edit, a mesma permissão usada para editar a regra, porque uma regra disparada por agendamento não faz absolutamente nada até ter uma programação definida. + +As programações se limitam a marcas de quinze em quinze minutos. O campo de minutos de uma expressão cron deve ser `0`, `15`, `30` ou `45`. + +Exemplos válidos: + +``` +0 * * * * every hour, on the hour +15 9 * * * every day at 09:15 +0 15 * * 1 every Monday at 15:00 +30 2 * * * every day at 02:30 +``` + +## Referindo-se aos dados do Achado + +Dois lugares em uma regra leem valores do item que passa por ela: **condições** e **modelos**. Ambos usam os mesmos caminhos com pontos (dot paths). + +``` +finding.severity +finding.title +finding.vulnerability_ids.0 +product.name +product_type.name +test.scan_type +ctx.rule_name +``` + +Um caminho que não resolve produz nenhum valor, em vez de um erro. + +### Campos disponíveis + +Cada item carrega um conjunto fixo de campos do Achado. Esta lista é um contrato, portanto só muda de forma deliberada. + +| Grupo | Campos | +|-------|--------| +| Identidade | `id`, `title`, `hash_code`, `unique_id_from_tool` | +| Severidade e pontuação | `severity`, `numerical_severity`, `cvssv3`, `cvssv3_score`, `epss_score`, `epss_percentile`, `priority`, `risk`, `risk_score` | +| Texto | `description`, `mitigation`, `impact` | +| Status | `active`, `verified`, `false_p`, `duplicate`, `is_mitigated`, `out_of_scope`, `risk_accepted`, `under_review` | +| Datas | `date`, `mitigated`, `last_status_update`, `sla_expiration_date` | +| Localização | `file_path`, `line`, `component_name`, `component_version`, `service` | +| Classificação | `cwe`, `vulnerability_ids`, `tags` | + +Além de `finding`, cada item carrega `test` (`id`, `title`, `scan_type`), `engagement` (`id`, `name`), `product` (`id`, `name`), `product_type` (`id`, `name`), e `ctx`. + +As datas são strings ISO-8601. Isso é proposital: significa que `gt` e `lt` as ordenam corretamente como texto, portanto `2026-07-28` é corretamente maior que `2026-01-01`. + +`priority`, `risk` e `risk_score` vêm da priorização do Pro. Um Achado que ainda não foi pontuado não carrega valor para eles. + +### Condições + +Um nó **If / Filter** contém uma lista de linhas de condição. Cada linha é um caminho, um operador e um valor. **Match** decide se todas as linhas precisam ser verdadeiras (`all`) ou apenas uma delas (`any`). + +| Operador | Significado | +|----------|---------| +| `eq` | igual a | +| `neq` | diferente de | +| `contains` | contém | +| `not_contains` | não contém | +| `in` | é um de | +| `not_in` | não é um de | +| `gt` | é maior que | +| `gte` | é maior ou igual a | +| `lt` | é menor que | +| `lte` | é menor ou igual a | +| `startswith` | começa com | +| `endswith` | termina com | +| `exists` | está definido | +| `not_exists` | não está definido | + +As comparações são **flexíveis (loose)**. Primeiro tenta-se um número, e se isso falhar os valores são comparados como texto, sem espaços nas bordas e sem diferenciar maiúsculas de minúsculas. Assim, uma condição escrita como `finding.severity eq high` corresponde a um Achado cuja severidade é `High`, que é quase sempre o que o autor pretendia. + +#### Transformações + +Uma linha de condição pode pós-processar o valor lido antes de compará-lo. + +| Transformação | Efeito | +|-----------|--------| +| `int` | número inteiro | +| `float` | número decimal | +| `str` | texto | +| `first` | primeiro item de uma lista | +| `list` | como lista | +| `join` | unido com vírgulas | +| `upper` | MAIÚSCULAS | +| `lower` | minúsculas | +| `strip` | sem espaços nas bordas | +| `cwe_int` | número do CWE | +| `severity` | severidade normalizada, de modo que valores como `critical`, `error` e `warning` vindos de diferentes scanners são mapeados para os cinco níveis do DefectDojo | +| `numerical_severity` | código de severidade ordenável, para comparações de ordenação | + +### Modelos (Templates) + +Qualquer configuração identificada como mensagem, nota, título ou valor aceita placeholders `{{ path }}`, resolvidos por item: + +``` +{{finding.severity}}: {{finding.title}} ({{product.name}}) +``` + +Um caminho sem valor é renderizado como uma string vazia. Uma lista é renderizada unida por vírgulas. + +Os modelos também enxergam um bloco `ctx` que carrega detalhes sobre a própria execução. As chaves disponíveis dependem do nó, mas as mais comuns são: + +| Placeholder | Significado | +|-------------|---------| +| `{{ctx.rule_name}}` | O nome da regra | +| `{{ctx.count}}` | Quantos Achados a mensagem cobre | +| `{{ctx.trigger}}` | O evento que iniciou a execução | +| `{{ctx.findings_html}}` | A lista de Achados renderizada, no nó de e-mail | +| `{{ctx.report_url}}` | O link de download, no nó de relatório | +| `{{ctx.template_name}}` | O nome do modelo de relatório, no nó de relatório | + +Os modelos fazem substituição simples. Não há avaliação de expressões, execução de código, nem acesso a atributos de objetos em nenhum lugar da configuração de uma regra. + +## Testando uma regra com segurança + +A ordem recomendada para uma regra que envia algo: + +1. Construa o grafo e use o **Preview** até que a contagem de itens pareça correta. +2. Salve-a. Novas regras são criadas desativadas. +3. Deixe o modo em **Simulate** e ative a regra. +4. Deixe-a executar, depois leia **Deliveries** e verifique se as cargas (payloads) registradas são as que você pretendia. +5. Mude o modo para **Live**. + +Simulate não é uma execução parcial. Toda edição de Achado no grafo acontece de verdade no modo de simulação. Somente os envios de saída são retidos. diff --git a/docs/content/automation/rules_engine_2/configuration.pt-br.md b/docs/content/automation/rules_engine_2/configuration.pt-br.md new file mode 100644 index 0000000000..a7347f07c8 --- /dev/null +++ b/docs/content/automation/rules_engine_2/configuration.pt-br.md @@ -0,0 +1,141 @@ +--- +title: Configuração +description: Configurações em nível de implantação para o Rules Engine 2.0 +weight: 7 +audience: pro +aliases: +- /pt-br/automation/rules_engine_v2/configuration/ +--- + +Nota: O Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro. + +O Rules Engine 2.0 funciona pronto para uso. As configurações desta página são para implantações que precisam ajustar throughput, retenção ou a política de rede de saída. Todas elas são aplicadas da mesma forma que qualquer outra configuração do DefectDojo (veja [Configuration](/get_started/open_source/configuration/)). + +O Rules Engine 2.0 é configurado separadamente do Rules Engine original. Os dois mecanismos não compartilham nenhum ajuste, portanto uma configuração `DD_RULES_ENGINE_*` não afeta o Rules Engine 2.0, e uma configuração `DD_RULES_V2_*` não afeta o mecanismo original. + +```python +DD_RULES_V2_EVENT_BATCH=(int, 500), +DD_RULES_V2_CHUNK_SIZE=(int, 1000), +DD_RULES_V2_STALLED_AFTER_MINUTES=(int, 30), +DD_RULES_V2_RUN_TIME_LIMIT_MINUTES=(int, 360), +DD_RULES_V2_ALLOW_PRIVATE_EGRESS=(bool, False), +DD_RULES_V2_DELIVERY_RETENTION_DAYS=(int, 180), +DD_RULES_V2_RUN_RETENTION_DAYS=(int, 180), +DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS=(int, 8000), +DD_RULES_V2_MAX_PER_ITEM_SENDS=(int, 1000), +``` + +## Throughput + +### Achados por evento (`DD_RULES_V2_EVENT_BATCH`) + +**Padrão: 500.** + +Quantos ids de Achado um único evento carrega. Os eventos atravessam uma fronteira assíncrona, portanto são mantidos pequenos o suficiente para continuar sendo uma mensagem barata. Uma gravação maior se espalha em vários eventos, cada um dos quais se torna sua própria execução. + +Aumentar esse valor produz execuções mais raras e maiores. Diminuí-lo produz execuções mais frequentes e menores. + +### Achados por bloco (`DD_RULES_V2_CHUNK_SIZE`) + +**Padrão: 1000.** + +Quantos Achados uma execução mantém na memória de uma vez. Uma execução é processada em blocos (chunks), portanto isso é um ajuste de memória e **não** um limite para o que uma regra processa: uma regra sempre processa tudo o que seu escopo corresponde. + +Um envelope tem aproximadamente 2,7 KB por Achado, portanto o padrão ocupa alguns megabytes de cada vez. Aumentá-lo troca memória por menos idas e voltas. Diminuí-lo faz o oposto. + +### Limite de texto do envelope (`DD_RULES_V2_ENVELOPE_TEXT_MAX_CHARS`) + +**Padrão: 8000. Defina como 0 para desativar.** + +Quantos caracteres de `description`, `mitigation` e `impact` um item carrega. + +Esses três campos correspondem à maior parte do tamanho de um envelope. O limite existe para o caso incomum de um Achado com uma descrição muito grande, em que um bloco cheio deles seria muito maior do que o tamanho do bloco sugere. Ele é generoso o suficiente para que uma instância comum nunca perceba isso. + +Observe que isso afeta o que condições e modelos conseguem ver. Uma condição que compara com o final de uma descrição muito longa não verá texto além do limite. + +## Ciclo de vida da execução + +### Janela de estagnação (`DD_RULES_V2_STALLED_AFTER_MINUTES`) + +**Padrão: 30.** + +Por quanto tempo uma execução pode ficar sem uma pulsação (heartbeat) antes de ser tratada como abandonada, marcada como com erro, e ter seu bloqueio por regra liberado. + +Uma execução registra uma pulsação após cada bloco, portanto isso é medido a partir da última pulsação, e não do início. Uma varredura longa que ainda está progredindo nunca é confundida com um worker travado, o que é o que permite manter a janela curta. + +### Limite de tempo de execução (`DD_RULES_V2_RUN_TIME_LIMIT_MINUTES`) + +**Padrão: 360, que são seis horas.** + +O tempo máximo que uma única execução pode levar antes de o worker encerrá-la. + +Isso é uma proteção contra uma regra que nunca terminaria enquanto ocupa um slot de worker e o bloqueio de execução da sua regra. É deliberadamente generoso, porque uma varredura em blocos sobre um escopo muito grande é exatamente o tipo de carga de trabalho para o qual este mecanismo foi construído. + +## Retenção + +Duas tarefas limitam as três tabelas que este recurso faz crescer. Ambas usam **180 dias** por padrão, e ambas aceitam `0` para desativar completamente a limpeza (pruning). + +A retenção é exposta no produto, em vez de ficar implícita: a API fornece tanto a janela quanto a data em que um determinado registro será excluído, e as páginas que mostram uma execução ou uma entrega informam isso em uma frase. A data é calculada no momento da leitura, portanto alterar a janela tem efeito imediato, em vez de se aplicar apenas a novos registros. + +### `DD_RULES_V2_DELIVERY_RETENTION_DAYS` + +**Padrão: 180.** + +Por quantos dias uma entrega concluída é mantida. + +Esta é a tabela que mais cresce no recurso. Um nó de saída por Achado grava até o equivalente a um bloco de linhas por execução, inclusive no modo Simulate. Aumente-a se precisar de uma trilha de auditoria de saída mais longa, e diminua-a se o volume for um problema. + +### `DD_RULES_V2_RUN_RETENTION_DAYS` + +**Padrão: 180.** + +Por quantos dias uma execução concluída é mantida, junto com suas linhas por nó e sua proveniência de Achados. + +O lado das execuções cresce mais rápido do que o das entregas, porque a proveniência é uma linha por Achado por nó de mutação por execução. Uma regra que roda de hora em hora sobre um escopo grande gera muito disso. + +Uma execução que ainda contém entregas é mantida até que essas sejam removidas, portanto definir uma janela de execução mais curta do que a janela de entrega não deixa nada órfão. + +## Validação de destino de saída + +Duas configurações de nó recebem um destino como texto livre, em vez de a partir de um objeto configurado: a **URL** em Call a Webhook, e o **To** em Send an Email. Ambas são validadas quando a regra é salva. + +Para URLs de webhook: + +* Somente `http` e `https` são aceitos. Outros esquemas são rejeitados de imediato. +* A URL precisa ter um host. +* Por padrão, um host que resolve para um endereço loopback, link-local, privado, reservado ou multicast é rejeitado. + +Para endereços de e-mail, um endereço vazio é rejeitado, assim como um que contenha uma quebra de linha, o que caracteriza injeção de cabeçalho. + +O motivo dessa verificação de rede é que o worker que envia a requisição geralmente fica dentro do seu cluster e consegue alcançar uma parte muito maior da rede interna do que a pessoa que escreve a regra consegue. Sem essa verificação, uma URL em texto livre é um primitivo de falsificação de requisição: aponte-a para um serviço de metadados ou uma porta administrativa interna, e a resposta volta através do registro de entregas. + +Isso é defesa em profundidade, e não o único controle. Rule Edit já está próxima de ser uma permissão administrativa de qualquer forma. Vale a pena tê-la para que o raio de alcance de uma função concedida em excesso não seja "ler qualquer endpoint HTTP interno", e para que um erro de digitação falhe no momento de salvar, com uma mensagem clara, em vez de no momento do envio, com um erro de conexão. + +### Permitindo endereços privados (`DD_RULES_V2_ALLOW_PRIVATE_EGRESS`) + +**Padrão: desativado.** + +Desativa a verificação de endereço de rede, de modo que os webhooks possam enviar para endereços loopback, link-local e privados. A validação de esquema e formato continua se aplicando. + +Ative isso se você realmente usa webhook para algo em um endereço privado, o que geralmente é o caso de um chat ou receptor de webhook auto-hospedado. + +## Limite de envios por Achado + +### `DD_RULES_V2_MAX_PER_ITEM_SENDS` + +**Padrão: 1000. Defina como 0 para remover o limite.** + +O número máximo de envios por Achado que um único nó de saída registrará em uma execução. + +Um nó com **One Message per Finding** ativado produz uma linha de entrega e uma tarefa enfileirada por Achado. Como uma execução não tem limite de itens, uma regra com um escopo muito amplo e envio por Achado ativado significaria, de outra forma, um número ilimitado de ambos. + +Após esse limite, o nó registra uma **omissão visível (visible skip)** informando quantos Achados não tiveram envio realizado. Isso não faz a execução falhar, nem para silenciosamente. + +## Configurações relacionadas + +Alguns nós do Rules Engine 2.0 usam a configuração de integração de todo o sistema, em vez da própria: + +* **Send a Slack Message** usa o token do Slack do sistema, e recorre ao canal do Slack do sistema quando o nó não indica nenhum. +* **Send a Microsoft Teams Message** usa o webhook do Microsoft Teams das configurações do sistema. +* **Create a JIRA Issue** usa a configuração do JIRA do produto para o resumo, a descrição e a prioridade. +* **Raise an In-App Alert** respeita a própria configuração de notificação **Rules Engine Match** de cada destinatário. diff --git a/docs/content/automation/rules_engine_2/converting_from_rules_engine.pt-br.md b/docs/content/automation/rules_engine_2/converting_from_rules_engine.pt-br.md new file mode 100644 index 0000000000..60ecb42c85 --- /dev/null +++ b/docs/content/automation/rules_engine_2/converting_from_rules_engine.pt-br.md @@ -0,0 +1,89 @@ +--- +title: Migrando do Rules Engine +description: Migre regras existentes do Rules Engine para grafos do Rules Engine 2.0 +weight: 6 +audience: pro +aliases: +- /pt-br/automation/rules_engine_v2/converting_from_rules_engine/ +--- + +Nota: O Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro. + +Os dois mecanismos funcionam lado a lado. Ativar o Rules Engine 2.0 não muda nada em suas regras existentes do [Rules Engine](/automation/rules_engine/about/), e não há um prazo até o qual você precise migrá-las. + +Quando você quiser migrá-las, existe um conversor. Ele traduz uma regra do Rules Engine (um filtro mais uma lista ordenada de ações) em um grafo equivalente do Rules Engine 2.0. + +## O que o conversor garante + +**Uma regra é convertida por completo ou não é convertida de forma alguma.** Toda conversão relata dois tipos de resultado: + +* **Problems** significam que a regra não foi escrita. Nada parcial é salvo. +* **Warnings** significam que a regra foi convertida, mas algo nela mudou e você deveria dar uma olhada. + +Nada é aproximado silenciosamente. Todo o valor do conversor está em você poder confiar em uma regra que converteu sem ressalvas, e verificar manualmente uma que não converteu. + +**Regras convertidas são sempre criadas desativadas.** Os dois mecanismos estão em execução, e duas regras fazendo a mesma coisa com os mesmos Achados é o único resultado que um conversor nunca deve produzir por conta própria. Revise cada regra convertida e ative-a deliberadamente. + +**Uma regra converte uma única vez.** Cada regra convertida lembra de qual regra ela veio, portanto executar o conversor duas vezes ignora o que já foi feito, em vez de criar duplicatas. Use a opção de sobrescrever para substituir deliberadamente um grafo convertido anteriormente. + +## Executando o conversor + +### Pela interface (UI) + +A lista de regras oferece uma ação de conversão, que informa, por regra, o que foi convertido, o que foi ignorado e o que falhou. + +### Pela linha de comando + +```bash +python manage.py convert_rules_to_v2 +``` + +| Opção | Efeito | +|--------|--------| +| `--dry-run` | Imprime o grafo que cada regra produziria e não grava nada. | +| `--rule-ids 1,2,3` | Converte somente essas regras. Converte todas as regras quando omitido. | +| `--overwrite` | Substitui o grafo de uma regra já convertida e incrementa sua versão, em vez de ignorá-la. | +| `--activate-schedules` | Também copia cada programação para a sua regra convertida. Desativado por padrão. | +| `--drop-invalid-filters` | Descarta os filtros de escopo que o conjunto de filtros não reconhece mais e emite um aviso, em vez de falhar a regra. | +| `--json` | Imprime o relatório em JSON em vez de texto. | + +O comando termina com código diferente de zero somente quando uma regra falha ao converter. Itens ignorados são relatados, mas não são falhas. + +Comece com `--dry-run` no conjunto completo para ver no que você está se metendo, depois converta de verdade. + +## O que a conversão produz + +| Conceito do Rules Engine | Torna-se | +|----------------------|---------| +| O filtro da regra | O **Scope** no nó de gatilho. | +| Uma regra com uma programação | Um gatilho **On a Schedule**. | +| Uma regra sem programação | Um gatilho **Manual Run**. | +| Cada ação, em ordem | Um nó, encadeado na mesma ordem. | +| Uma ação protegida por uma condição | Um nó **If / Filter** na frente desse nó. | + +O vocabulário de filtros é compartilhado entre os dois mecanismos, portanto um escopo é convertido sem tradução. Isso é proposital: é o mesmo conjunto de filtros, com uma única implementação. + +Os grafos convertidos são validados da mesma forma que um grafo construído manualmente, incluindo a configuração por nó e os valores permitidos de cada menu suspenso. Uma regra que contém um valor de severidade ou de risco que o produto já deixou de usar é detectada na conversão, e não em tempo de execução. + +## O que não é migrado + +Quatro coisas para planejar. O conversor relata essas informações como notas em cada execução. + +* **O histórico de execuções permanece onde está.** O histórico de execuções existente, junto com seus registros afetados e ignorados, permanece na interface do Rules Engine. Eles não são copiados. +* **As programações não são ativadas por padrão.** Uma regra disparada por agendamento é convertida, mas sua programação não é copiada a menos que você passe `--activate-schedules`. Isso mantém a propriedade exclusiva das programações ativas com o mecanismo original enquanto os dois estão em execução, de modo que uma regra convertida não pode começar a disparar sem você perceber. Quando você copia uma programação, a cópia recebe um nome distinto para não colidir com a original. +* **O modelo de concorrência é diferente.** O Rules Engine tem um único bloqueio de execução para toda a instância. O Rules Engine 2.0 serializa por regra, portanto regras distintas são executadas simultaneamente. Um conjunto de regras que costumava se revezar agora vai se sobrepor. +* **Uma ação não tem equivalente.** Uma ação de "definir falso positivo como falso" não pode ser expressa como um nó do Rules Engine 2.0 e precisa ser convertida manualmente. + +Uma regra cujo proprietário não está definido é convertida, com um aviso. Lembre-se de que uma regra sem proprietário não vê nenhum Achado, portanto atribua um antes de ativá-la. + +## Uma ordem sugerida + +1. Ative o Rules Engine 2.0 e deixe suas regras existentes em execução. +2. Execute o conversor com `--dry-run` e leia o relatório. +3. Converta. Tudo é criado desativado. +4. Abra cada regra convertida, verifique o grafo e deixe o modo em **Simulate**. +5. Ative a regra convertida e deixe-a rodar ao lado da original por um tempo. Simulate significa que ela altera Achados, mas não envia nada, portanto compare suas execuções com o que a original fez. +6. Quando estiver satisfeito, desative a regra original e mude a convertida para **Live**. +7. Copie a programação por último, quando nada mais estiver executando a regra antiga. + +O passo 5 é o que mais vale a pena não pular. Os dois mecanismos editando os mesmos Achados é algo tranquilo de observar, mas você quer ser quem decide quando os envios começam. diff --git a/docs/content/automation/rules_engine_2/deliveries.pt-br.md b/docs/content/automation/rules_engine_2/deliveries.pt-br.md new file mode 100644 index 0000000000..11f004f1b6 --- /dev/null +++ b/docs/content/automation/rules_engine_2/deliveries.pt-br.md @@ -0,0 +1,120 @@ +--- +title: Entregas +description: O registro de tudo que as regras enviam para fora, e como funcionam as + tentativas e a reprodução +weight: 5 +audience: pro +aliases: +- /pt-br/automation/rules_engine_v2/deliveries/ +--- + +Nota: o Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro. + +Cada efeito colateral de saída produzido por uma regra é uma linha no registro de entregas. **Rules Engine 2.0 > Entregas** as lista. + +A linha é gravada **antes** de qualquer chamada de rede acontecer, e contém exatamente o que seria, ou foi, enviado. É isso que torna a saída auditável, em vez de uma linha de log que você espera que alguém tenha guardado, e é por isso que **Simulate** não é um caminho de código separado: um envio simulado é a mesma linha com a etapa de despacho pulada. + +## O que uma entrega registra + +| Field | Meaning | +|-------|---------| +| **Run** e **Node** | Qual execução e qual nó de saída a produziu. | +| **Finding** | O Achado a que ela se refere, em um envio por Achado. Envios em lote registram o grupo em vez disso. | +| **Channel** | Que tipo de envio é. | +| **Target** | O destino resolvido: uma chave de projeto do JIRA, um canal, uma URL, um endereço. | +| **Title** | Uma descrição de uma linha do envio. | +| **Payload** | Exatamente o que seria, ou foi, enviado. | +| **Mode** | `simulate` ou `live`. | +| **Status** | Até onde a entrega chegou. | +| **Attempts** | Quantos envios já foram tentados, em relação ao máximo permitido. | +| **Last error** | Por que a última tentativa falhou, ou por que a entrega foi ignorada. | +| **Response** | O que o destino respondeu. | +| **External reference** e **URL** | A chave do chamado, o id da mensagem ou o caminho do arquivo que o destino retornou, e um link para ele quando existir. | + +## Canais + +| Canal | Produzido por | +|---------|-------------| +| **JIRA** | Criar uma Issue do JIRA | +| **Downstream connector** | Criar um Ticket Downstream | +| **Slack** | Enviar uma Mensagem no Slack, e anúncios de relatórios enviados ao Slack | +| **Microsoft Teams** | Enviar uma Mensagem no Microsoft Teams | +| **Email** | Enviar um E-mail, e anúncios de relatórios enviados por e-mail | +| **Webhook** | Chamar um Webhook | +| **Report** | Gerar um Relatório | +| **In-app alert** | Emitir um Alerta no Aplicativo | + +## Status + +| Status | Significado | +|--------|---------| +| `simulated` | A regra estava no modo Simulate. Nada foi enviado, e nada nunca será. | +| `skipped` | Algo já cobriu esse envio, ou o controle o recusou. O motivo está no campo de último erro. | +| `pending` | Registrada no modo Live, aguardando sua tarefa de entrega. | +| `dispatched` | Repassada ao serviço de integração, aguardando confirmação. | +| `sent` | Entrega confirmada. | +| `failed` | Rejeitada permanentemente, por exemplo um 4xx ou um erro do fornecedor. Pode ser reproduzida. | +| `dead` | Tentativas esgotadas, ou nenhuma confirmação jamais chegou. Pode ser reproduzida. | + +Vale a pena examinar melhor o `skipped`. Entradas ignoradas são registradas em vez de silenciosas, porque "a regra não fez nada" e "a regra não fez nada porque este Achado já tinha um chamado" são respostas diferentes, e apenas uma delas é um problema. + +Há três motivos comuns para uma entrada ser ignorada, e o campo de último erro sempre diz qual: + +* **Idempotência.** Algo já cobriu esse envio. +* **O canal está desligado.** Uma regra com um nó do Slack em uma instância onde o Slack está desabilitado registra uma entrada ignorada explicando isso, em vez de falhar. Uma regra salva enquanto um canal estava ativo não deveria passar a apresentar erros quando alguém o desativa. Veja [disponibilidade do nó](../node_reference/#when-a-channel-is-unavailable). +* **O limite de envio por Achado foi atingido.** Um nó que envia uma mensagem por Achado para por padrão após 1.000 em uma única execução, e registra quantos Achados ficaram de fora do envio. + +### Fidelidade do payload + +O registro é honesto sobre o quão próximo o payload registrado está do corpo real transmitido, porque isso varia conforme o canal. + +| Fidelity | Significado | +|----------|---------| +| `exact` | Equivalente byte a byte ao que foi enviado. | +| `rendered` | Renderizado pelos helpers reais, mas o controle no momento do envio ainda pode reduzi-lo. | +| `dojo request` | A requisição exata entregue ao serviço de integração. O payload específico do fornecedor é composto downstream. | +| `summary` | Uma descrição do envio em vez de uma reprodução dele. Um relatório gerado é o exemplo: o arquivo é construído a partir de dados ao vivo no momento do envio, então uma cópia armazenada dele estaria errada no instante em que qualquer coisa mudasse. | + +## A proteção contra envio duplicado + +Apenas uma entrega **ativa** pode existir por chave de idempotência, imposto no banco de dados em vez de por convenção. Ativa significa `pending`, `dispatched` ou `sent`. + +Um segundo envio que colidiria com um ativo se torna uma linha `skipped` com seu motivo registrado. Nunca é um no-op silencioso, e nunca é um chamado duplicado. + +Como as linhas `simulated`, `skipped`, `failed` e `dead` não mantêm nenhuma reserva, uma entrega com falha pode ser reproduzida no lugar sem que uma segunda linha dispute a mesma chave. + +## Tentativas + +Uma entrega ao vivo é repetida automaticamente. Cada linha carrega sua própria contagem de tentativas e seu próprio limite, seis tentativas por padrão, de modo que um destino com falha não consegue arrastar seus vizinhos junto. As repetições aguardam um intervalo crescente entre as tentativas. + +Quando a última tentativa é consumida, a linha é marcada como `dead` em vez de ficar parada em `pending`. O esgotamento é visível, não silencioso. + +Se um worker for encerrado no meio de um envio, a mensagem é reentregue. A linha é bloqueada e seu status é reverificado antes que qualquer coisa seja enviada novamente, de modo que uma reentrega não pode se tornar um envio duplicado. + +Entregas repassadas ao serviço de integração passam para `dispatched` e aguardam um callback de confirmação. Se nenhum callback chegar em até seis horas, a linha é marcada como `dead` para que possa ser reproduzida. Essa janela é deliberadamente generosa: uma fila downstream congestionada por uma hora é normal, e marcar uma linha como morta cedo demais transformaria uma reprodução em um chamado duplicado. + +## Reproduzindo uma entrega + +Uma entrega `failed` ou `dead` pode ser reenviada a partir da página Entregas. O registro anota quando ela foi reproduzida e por quem. + +Reproduzir exige **Rule Edit**. + +Reproduzir reenvia o payload registrado. Para um relatório, isso regenera o relatório a partir dos dados atuais, porque o payload é uma descrição do que gerar, e não o arquivo em si. + +## Simulate + +No modo Simulate, cada nó de saída grava sua linha de entrega com status `simulated`, payload completo e destino resolvido, e então para. Nenhum despacho é registrado, então nada pode ser enviado depois, não importa como a execução termine. O Preview se comporta da mesma forma, e nem sequer insere as linhas. + +Essa é a forma indicada de revisar uma regra antes de colocá-la em produção: ative-a em Simulate, deixe-a rodar contra Achados reais, e depois leia os payloads que ela registrou. + +Lembre-se de que o Simulate contém **apenas** os envios de saída. Nós de Achados continuam alterando Achados. + +## Retenção + +As entregas são mantidas por **180 dias** por padrão, após os quais um job de retenção as remove. + +Esta é a tabela que mais cresce no recurso, porque um nó que envia uma mensagem por Achado grava uma linha por Achado, tanto no modo Simulate quanto no Live. O padrão é uma janela real em vez de "guardar tudo", então o crescimento não vira seu problema silenciosamente. + +Você é avisado sobre isso em vez de ser deixado para descobrir sozinho. O detalhe de uma entrega mostra a janela de retenção e a data em que aquela linha será excluída, e a data é recalculada a cada leitura, de modo que alterar a janela tem efeito imediato. + +Defina a janela mais longa se precisar de uma trilha de auditoria de saída mais longa, ou `0` para manter tudo. Veja [Configuração](../configuration/#retention). diff --git a/docs/content/automation/rules_engine_2/node_reference.pt-br.md b/docs/content/automation/rules_engine_2/node_reference.pt-br.md new file mode 100644 index 0000000000..071178df60 --- /dev/null +++ b/docs/content/automation/rules_engine_2/node_reference.pt-br.md @@ -0,0 +1,347 @@ +--- +title: Referência de Nós +description: Todos os nós com que o Rules Engine 2.0 vem, e o que cada um faz +weight: 3 +audience: pro +aliases: +- /pt-br/automation/rules_engine_v2/node_reference/ +--- + +Nota: o Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro. + +O Rules Engine 2.0 vem com 25 nós em quatro categorias. Esta página documenta todos eles. + +Salvo indicação contrária, um nó recebe uma entrada, produz uma saída chamada `out`, e repassa a essa saída cada item que recebeu. Isso importa quando você encadeia nós: um nó de Achados altera o Achado e então repassa o item adiante, de modo que vários deles em sequência são todos aplicados. + +## Gatilhos + +Todo grafo tem exatamente um gatilho, e apenas um gatilho pode iniciar uma execução. Os três produzem itens de Achado, e os três recebem um **Scope** que restringe quais Achados eles produzem. Veja [Construindo Regras](../building_rules/) para saber como o escopo funciona. + +### Em Evento de Achado + +`trigger.finding` + +É executado quando Achados são criados, atualizados, fechados ou reabertos. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Event** | `created` | Qual mudança do Achado ativa esta regra: `created`, `updated`, `closed`, `reopened`, ou `any` para as quatro. | +| **Scope** | vazio | Quais Achados esta regra considera. Vazio significa todo Achado que o proprietário da regra pode ver. | + +Os Achados indicados pelo evento são comparados ao escopo antes de entrarem no grafo, de modo que o evento decide *quando* e o escopo decide *quais*. + +### Em uma Programação + +`trigger.schedule` + +Varre todos os Achados no escopo em uma programação. A programação é configurada na regra e é limitada a marcas de quinze em quinze minutos. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Scope** | vazio | Quais Achados esta regra considera. | + +### Execução Manual + +`trigger.manual` + +Varre todos os Achados no escopo quando você clica em **Run** na regra. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Scope** | vazio | Quais Achados esta regra considera. | + +## Lógica + +### Se / Filtro + +`filter.if` + +Direciona cada item para o ramo **true** ou **false**, de acordo com condições. Este é o único nó com duas saídas, e é assim que um grafo se ramifica. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Conditions** | vazio | Cada linha é um caminho, um operador e um valor. Veja [Condições](../building_rules/#conditions). | +| **Match** | `all` | Se toda condição precisa ser verdadeira (`all`), ou apenas uma delas (`any`). | + +Uma lista de condições vazia passa tudo para o ramo true. Os dois ramos são opcionais: deixar o ramo false sem conexão simplesmente descarta os itens que falharam. + +### Limite + +`flow.limit` + +Passa os primeiros N itens e descarta o restante. Útil como válvula de segurança enquanto você está testando uma regra, e para limitar quantos tickets ou mensagens uma única execução pode produzir. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Keep First** | `100` | Quantos itens repassar. | + +### Deduplicar Dentro da Execução + +`flow.dedupe_batch` + +Mantém o primeiro item por chave e descarta os posteriores que carregam a mesma chave. Restrito à execução, então ele deduplica dentro de uma única execução, e não entre execuções. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Key Path** | `finding.hash_code` | O caminho do item cujo valor identifica uma duplicata. | + +Um uso comum é `finding.component_name`, para notificar uma vez por componente afetado em vez de uma vez por Achado. + +## Achados + +Esses nós alteram Achados. Toda alteração é atribuída de volta à regra, à execução e ao nó que a fez, e aparece na linha do tempo de proveniência do Achado. + +### Definir Severidade + +`finding.set_severity` + +Define a severidade, e recalcula a data de SLA e a prioridade com base nela. + +| Setting | Options | +|---------|---------| +| **Severity** | `Critical`, `High`, `Medium`, `Low`, `Info` | + +### Definir um Campo + +`finding.set_field` + +Define, anexa ao final de, ou insere no início de um campo de texto. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Field** | nenhum | Um de `component_name`, `component_version`, `cvssv3`, `cwe`, `description`, `file_path`, `impact`, `mitigation`, `service`, `title`. | +| **Mode** | `set` | `set`, `append` ou `prepend`. Um vetor CVSSv3 só pode ser substituído. | +| **Value** | nenhum | O texto a escrever. Suporta placeholders no estilo `{{finding.title}}`. | + +### Definir Status + +`finding.set_status` + +Move o Achado para um status. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Status** | nenhum | `active`, `inactive`, `verified`, `unverified`, `false_positive`, `mitigated`, `reopen`. | +| **Note** | vazio | Uma nota opcional registrada junto com a mudança de status. | + +### Adicionar Tags + +`finding.add_tags` + +Adiciona tags ao Achado. As tags existentes são mantidas. + +| Setting | Notes | +|---------|-------| +| **Tags** | Separadas por vírgula. Suporta placeholders no estilo `{{product.name}}`, para que você possa marcar com dados do Achado. | + +### Adicionar uma Nota + +`finding.add_note` + +Adiciona uma nota ao Achado. + +| Setting | Notes | +|---------|-------| +| **Note** | O texto da nota. Suporta placeholders. | + +### Definir Responsáveis + +`finding.set_owners` + +Torna um grupo responsável pelo Achado. + +| Setting | Notes | +|---------|-------| +| **Group** | O grupo dono desses Achados. | + +### Definir Revisores + +`finding.set_reviewers` + +Coloca o Achado em revisão pelos usuários selecionados. + +| Setting | Notes | +|---------|-------| +| **Reviewers** | Um ou mais usuários que devem revisar esses Achados. | + +### Aceitar Risco + +`finding.risk_accept` + +Aceita simplesmente o risco do Achado, ou o adiciona a um registro de aceitação de risco. + +| Setting | Default | Notes | +|---------|---------|-------| +| **How** | `simple` | `simple` define aceitação de risco simples no Achado. `acceptance` o adiciona a um registro de aceitação de risco. | +| **Accepted** | ativado | Exibido para `simple`. Desative para desfazer a aceitação do risco. | +| **Risk Acceptance** | nenhum | Exibido para `acceptance`. A qual aceitação de risco adicionar esses Achados. | + +### Definir Política de Mitigação + +`finding.set_mitigation_policy` + +Define a política de mitigação sob a qual o Achado é corrigido. + +| Setting | Notes | +|---------|-------| +| **Mitigation Policy** | A política a aplicar. | + +### Alterar Prioridade + +`finding.set_priority` + +Define a prioridade, ou a ajusta aritmeticamente. Isso substitui a prioridade calculada. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Operation** | `set` | `set`, `add`, `subtract`, `multiply`, `divide`. | +| **Value** | nenhum | A prioridade a definir, ou a quantidade a ajustar. | + +### Definir Risco + +`finding.set_risk` + +Define o risco, substituindo o calculado. + +| Setting | Options | +|---------|---------| +| **Risk** | `Low`, `Medium`, `Needs Action`, `Urgent` | + +## Saída + +Nós de saída são os nós que saem do DefectDojo. Cada um deles registra uma [Entrega](../deliveries/) antes de qualquer coisa ser enviada, e cada um deles respeita o modo **Simulate** ou **Live** da regra. + +Vários deles oferecem a mesma opção **One Message per Finding**. Desativada, o nó envia uma mensagem descrevendo o lote inteiro, com uma divisão por severidade e uma lista limitada de Achados. Ativada, ele envia uma mensagem por Achado. + +Um nó que envia uma mensagem por Achado para por padrão após 1.000 envios em uma única execução, e registra uma entrada ignorada visível dizendo sobre quantos Achados ele não enviou. Veja [Configuração](../configuration/#per-finding-send-ceiling). + +### Quando um canal está indisponível + +Um nó de saída depende de algo externo à regra: um token do Slack, um webhook do Microsoft Teams, uma configuração do JIRA, um conector licenciado. Quando isso está ausente ou desligado, o nó não consegue funcionar, e o Rules Engine 2.0 avisa disso em três momentos diferentes, em vez de falhar silenciosamente: + +* **Na paleta**, um nó indisponível é marcado como tal, com o motivo, antes de você arrastá-lo para a tela. +* **Ao salvar**, um grafo contendo um nó indisponível é recusado. Esse é o momento em que alguém está presente para escolher outro. +* **Em tempo de execução**, a entrega é **ignorada** com o motivo anexado, não falha. Uma regra salva enquanto o Slack estava ativo não deveria começar a apresentar erros no dia em que alguém desativa o Slack. O registro honesto é uma entrega ignorada dizendo que o Slack está desligado. + +### Criar uma Issue do JIRA + +`ticket.jira` + +Cria ou atualiza a issue do JIRA do Achado. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Skip Findings That Already Have an Issue** | ativado | Deixa intactos os Achados que já têm uma issue do JIRA. | +| **Update an Existing Issue** | desativado | Exibido quando a opção acima está desativada. Envia os Achados que já têm uma issue, para que o JIRA seja atualizado. | + +O resumo, a descrição e a prioridade vêm da configuração do JIRA do produto, não deste nó. Um ticket criado por uma regra é, portanto, idêntico a um criado por push all issues. + +### Criar um Ticket Downstream + +`ticket.downstream` + +Cria ou atualiza um ticket através de um [Downstream Connector](/connectors/downstream/about/). + +| Setting | Default | Notes | +|---------|---------|-------| +| **Issue Trackers** | `auto` | `auto` usa os rastreadores de issues atribuídos ao engajamento ou ao produto. `mapping` direciona para um mapeamento específico. | +| **Issue Tracker Mapping** | nenhum | Exibido para `mapping`. Para qual mapeamento enviar. | +| **Operation** | `create` | `create` um ticket, ou `update` o que já existe. Uma atualização sem ticket existente o cria. | +| **Skip Findings That Already Have a Ticket** | ativado | Deixa intactos os Achados que já têm um ticket no mapeamento de destino. | + +A regra substitui as configurações automáticas de push da atribuição: os filtros de severidade e apenas-ativos não são aplicados uma segunda vez aqui. Um Achado cujo ticket já existe é ignorado, não importa como aquele ticket tenha sido criado. + +### Enviar uma Mensagem no Slack + +`notify.slack` + +Publica em um canal do Slack através de um Conector de Mensagens. A conexão carrega o token do bot; as configurações do Slack de toda a instância em **System Settings** não são usadas e não servem como alternativa. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Connection** | nenhuma | Um [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) desse tipo. Obrigatório. | +| **Destination** | vazio | Exibido assim que uma conexão é escolhida. Os campos dependem do fornecedor da conexão. | +| **One Message per Finding** | desativado | Desativado envia uma mensagem sobre o lote. | +| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Renderizado por Achado. | +| **Findings Listed in the Digest** | `10` | Exibido para mensagens em lote. Quantos Achados a mensagem lista antes de dizer quantos mais existiam. | + +### Enviar uma Mensagem no Microsoft Teams + +`notify.msteams` + +Publica um cartão através de um Conector de Mensagens. A conexão carrega a URL do fluxo de trabalho do Power Automate; o webhook do Teams de toda a instância em **System Settings** não é usado e não serve como alternativa. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Connection** | nenhuma | Um [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) desse tipo. Obrigatório. | +| **Destination** | vazio | Exibido assim que uma conexão é escolhida. Os campos dependem do fornecedor da conexão. | +| **One Message per Finding** | desativado | Desativado envia um cartão sobre o lote. | +| **Message** | `{{finding.severity}}: {{finding.title}} ({{product.name}})` | Renderizado por Achado. | +| **Findings Listed in the Digest** | `10` | Exibido para mensagens em lote. | + +### Enviar um E-mail + +`notify.email` + +Envia e-mail para uma lista fixa de endereços através de um Conector de Mensagens. Os destinatários são o destino da conexão. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Connection** | nenhuma | Um [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) desse tipo. Obrigatório. | +| **Destination** | vazio | Exibido assim que uma conexão é escolhida. Os campos dependem do fornecedor da conexão. | + +| **Subject** | `[DefectDojo] {{ctx.count}} finding(s) from rule {{ctx.rule_name}}` | Renderizado uma vez por mensagem. | +| **Body** | um corpo HTML contendo `{{ctx.findings_html}}` | HTML. `{{ctx.findings_html}}` renderiza a lista de Achados. | +| **One Message per Finding** | desativado | Desativado envia um e-mail sobre o lote. | +| **Findings Listed in the Body** | `25` | Quantos Achados `{{ctx.findings_html}}` lista antes de dizer quantos mais existiam. | + +### Chamar um Webhook + +`notify.webhook` + +Envia um POST com JSON para um endpoint de webhook. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Webhook Endpoint** | nenhum | Um [notification webhook](/automation/api/notification_webhooks/) configurado. Seu cabeçalho personalizado é enviado com a requisição. | +| **URL** | vazio | Exibido quando nenhum endpoint é selecionado. Para onde fazer o POST. | +| | | Um dos dois acima é obrigatório. | +| **Signing Secret** | vazio | Assina o corpo como `X-DefectDojo-Signature: sha256=HMAC`. | +| **One Message per Finding** | desativado | Desativado publica o lote inteiro em uma única requisição. | + +Duas coisas a saber. Um signing secret digitado aqui é armazenado junto com a regra, então, para qualquer coisa sensível, prefira um endpoint configurado e seu próprio cabeçalho. E um webhook chamado por uma regra nunca altera o status de saúde daquele endpoint, então uma regra não pode desativar seus webhooks de notificação ao falhar. + +URLs em texto livre são validadas quando você salva. Veja [Configuration](../configuration/#outbound-destination-validation) para saber o que é rejeitado e como permitir endereços privados. + +### Emitir um Alerta no Aplicativo + +`notify.alert` + +Cria um alerta no aplicativo sobre o lote. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Title** | `Rules Engine 2.0: {{ctx.rule_name}}` | Renderizado uma vez para o lote inteiro. | +| **Description** | `{{ctx.count}} finding(s) matched the rule {{ctx.rule_name}}.` | Renderizado uma vez para o lote inteiro. | +| **Recipients** | vazio | Nomes de usuário, separados por vírgula. Vazio alerta os administradores. | + +Os destinatários ainda controlam isso por meio de sua própria configuração de notificação **Rules Engine Match**, de modo que um alerta não pode contornar as preferências de notificação de um usuário. + +### Gerar um Relatório + +`report.generate` + +Gera um relatório a partir de um modelo, restrito aos Achados que chegaram a este nó, e pode anunciar o link de download. + +| Setting | Default | Notes | +|---------|---------|-------| +| **Report Template** | nenhum | A partir de qual modelo gerar. Obrigatório. | +| **Format** | `pdf` | `pdf` ou `html`. | +| **Findings Included** | `batch_findings` | `batch_findings` limita o relatório aos Achados que chegaram a este nó. `template_default` permite que o modelo use seus próprios filtros. | +| **Announce Over** | nenhum | Um [Messaging Connector](/issue_tracking/pro_integration/messaging_connectors/) pelo qual publicar o link de download assim que o relatório for gerado. Deixe vazio para não anunciar. | +| **Announce To** | vazio | Exibido assim que uma conexão é escolhida. Para onde essa conexão envia: um ID de canal do Slack, endereços de e-mail, e assim por diante. | +| **Announcement** | `Report ready: {{ctx.report_url}}` | Exibido ao anunciar. `{{ctx.report_url}}` é o link de download. | + +`batch_findings` é o que uma regra consegue fazer e um relatório agendado não: reportar exatamente os Achados que acabaram de corresponder. + +O anúncio é registrado como sua própria entrega, separada da geração do relatório, de modo que você pode ver o relatório ter sucesso e o anúncio falhar de forma independente. diff --git a/docs/content/automation/rules_engine_2/runs.pt-br.md b/docs/content/automation/rules_engine_2/runs.pt-br.md new file mode 100644 index 0000000000..7c7bc4e5c7 --- /dev/null +++ b/docs/content/automation/rules_engine_2/runs.pt-br.md @@ -0,0 +1,133 @@ +--- +title: Execuções +description: Como uma regra é executada, o que uma execução registra e como o encadeamento + é limitado +weight: 4 +audience: pro +aliases: +- /pt-br/automation/rules_engine_v2/runs/ +--- + +Observação: o Rules Engine 2.0 é um recurso exclusivo do DefectDojo Pro. + +Um **run** (execução) é a execução de uma regra. Toda execução é registrada, tenha sido bem-sucedida ou não, e cada nó dentro dela deixa um rastro. **Rules Engine 2.0 > Runs** lista essas execuções. + +## O que uma execução registra + +| Campo | Significado | +|-------|---------| +| **Rule** | A regra que foi executada. | +| **Trigger** | O evento que iniciou a execução, por exemplo `finding.created`, `schedule` ou `manual`. | +| **Triggered by** | A pessoa que a disparou, quando uma pessoa esteve envolvida: quem clicou em Run, ou quem salvou o Finding que a disparou. Fica vazio para um agendamento, e para uma alteração em que ninguém esteve presente, como uma importação ou uma chamada de API sem usuário. Isso é diferente do proprietário da regra, que é quem a execução realmente executa **como**. | +| **Status** | `Running`, `Success` ou `Error`. | +| **Started** e **Finished** | Quando foi executada. Finished fica vazio apenas enquanto ela ainda está em execução. | +| **Error** | O erro que a encerrou, caso tenha falhado. | +| **Stats** | Totais por nó, eventos em cascata e trabalho adiado. | +| **Depth** | Quantos saltos de cascata esta execução está distante do evento que a originou. | +| **Source run** | A execução cujo evento emitido disparou esta, no caso de uma execução em cascata. | + +### O rastro dos nós + +Dentro de uma execução, cada nó registra sua própria linha: + +| Campo | Significado | +|-------|---------| +| **Order** | Onde o nó se posicionou na ordem de execução. | +| **Node** | Seu id, seu tipo e seu rótulo, se você tiver definido um. | +| **Status** | Se o nó foi concluído ou gerou um erro. | +| **Items in** | Quantos itens entraram. | +| **Items out** | Quantos saíram, detalhados por handle de saída, de modo que um nó If / Filter mostra suas contagens de verdadeiro e falso separadamente. | +| **Summary** | Quaisquer contadores que o nó tenha reportado, por exemplo quantos Findings ele alterou. | +| **Error** | O erro gerado, caso tenha falhado. | + +O rastro é o que você lê quando uma regra não fez o que você esperava. Um nó If / Filter reportando 400 itens de entrada e 0 no ramo verdadeiro informa que as condições estão erradas, sem que você precise adivinhar. + +## Modelo de execução + +Os nós são executados em ordem topológica: um nó é executado assim que tudo que o alimenta já foi executado. Um nó com várias arestas de entrada recebe todas as saídas delas concatenadas. Um nó sem nada o alimentando ainda é executado, com uma lista de entrada vazia. + +### Uma execução com falha não altera nada + +Uma execução é atômica. Se qualquer nó gerar um erro, toda alteração de Finding feita pela execução é revertida. + +O rastro não é revertido junto. As linhas dos nós e o status `Error` são gravados depois, de modo que uma execução com falha mostra exatamente qual nó quebrou, sem deixar nenhuma edição parcialmente aplicada para trás. Esta é a garantia mais importante a se ter em mente ao ler a página Runs: uma execução com erro é uma execução que não fez nada. + +A saída (egress) segue a mesma regra. As entregas são registradas dentro da transação da execução e só são despachadas depois que ela é confirmada (commit), de modo que uma execução revertida não envia nada. + +### Uma execução por regra por vez + +Uma regra só pode ter uma execução em andamento. Um segundo disparo para a mesma regra enquanto ela ainda está em execução não entra em disputa com ela. Ele aguarda e tenta novamente. + +Regras diferentes são executadas totalmente em paralelo, de modo que uma regra lenta nunca atrasa suas irmãs. + +Se uma execução for de alguma forma abandonada, por exemplo porque o worker que a executava foi encerrado, seu lock é liberado após uma janela de inatividade (30 minutos por padrão), de modo que a regra não fique travada para sempre. Uma execução próxima dessa janela se interrompe primeiro, revertendo tudo de forma limpa, de modo que uma execução apenas lenta nunca acaba sendo executada junto com sua própria substituta. + +## Encadeamento (cascata) + +Uma regra que altera um Finding produz exatamente o tipo de evento que outra regra pode usar como gatilho. O Rules Engine 2.0 permite isso, de modo que cadeias `A -> B -> C` funcionam, e as limita de duas formas independentes: + +* **Depth (profundidade).** Um evento pode percorrer no máximo **3** saltos de cascata a partir da alteração que o originou. +* **Pertencimento à cadeia.** Todo evento carrega a lista de regras já percorridas em sua cadeia, e uma regra nunca é executada duas vezes na mesma cadeia. Assim, uma regra não pode disparar a si mesma novamente, e duas regras não podem ficar em ping-pong. + +Os campos **Depth** e **Source run** de uma execução permitem rastrear uma cadeia até a alteração que a iniciou. **Triggered by** é propagado por toda a cadeia, de modo que uma cascata disparada por uma pessoa permanece atribuída a ela em cada salto. + +Alterações feitas *por* uma regra em execução são atribuídas à própria cascata dessa regra, em vez de parecerem nova atividade do usuário, de modo que uma regra que delega trabalho internamente não infla a cadeia. + +## Escala e limites + +**Uma execução não tem limite superior de itens.** Uma regra processa tudo o que seu escopo corresponde, por maior que seja. Uma regra que parasse silenciosamente nos primeiros N Findings seria uma regra na qual você não poderia confiar. + +Em vez disso, uma execução é processada em **blocos (chunks)**, 1.000 Findings por vez por padrão. Apenas o bloco fica em memória, de modo que uma varredura sobre um escopo muito grande é limitada em memória, não em cobertura. A única exceção é o **Preview**, que tem um limite, e informa isso em seu rastro quando trunca. + +Outros dois números moldam como o trabalho é dividido: + +* **Findings per event**, 500 por padrão. Uma alteração em massa é dividida em vários eventos, cada um se tornando sua própria execução. O efeito prático para uma importação grande é um número administrável de execuções, em vez de uma execução por Finding. +* **Per-Finding send ceiling**, 1.000 por padrão. Um nó de saída configurado para enviar uma mensagem por Finding para de enviar ao atingir esse número em uma única execução, e registra uma omissão visível informando sobre quantos não enviou. Isso limita as linhas de entrega e as tarefas enfileiradas, algo que uma execução em blocos não limita mais por si só. + +Todos os três são configurações de implantação, documentadas em [Configuração](../configuration/). + +### Quanto tempo uma execução pode levar + +Uma execução registra um **heartbeat (pulsação)** após cada bloco. A detecção de travamento lê essa pulsação em vez do horário de início, de modo que uma varredura longa que ainda está progredindo nunca é confundida com um worker travado. + +Duas janelas se aplicam, ambas configuráveis: + +* Uma execução que fica 30 minutos sem pulsação é tratada como abandonada, marcada como erro, e seu lock é liberado. +* Uma execução é encerrada à força após seis horas, como proteção contra uma execução que nunca terminaria. + +## Retenção + +As execuções são mantidas por **180 dias** por padrão, junto com suas linhas por nó e sua proveniência de Finding. As entregas são mantidas por 180 dias separadamente. + +O produto informa isso em vez de deixar implícito: o detalhe de uma execução mostra a janela de retenção e a data em que aquela execução será excluída. Uma execução que ainda contém entregas é mantida até que essas sejam removidas. + +Ambas as janelas são configuráveis, e qualquer uma delas pode ser definida para manter os registros indefinidamente. Veja [Configuração](../configuration/#retention). + +## Executando uma regra manualmente + +Uma regra cujo gatilho é **Manual Run** é executada com a ação **Run** na lista de regras. Regras com outros gatilhos são executadas quando seu gatilho dispara. + +**Preview**, no editor, é a outra forma de executar um grafo. Ele executa o mecanismo real e depois reverte tudo, não registra nenhuma execução, e força a saída (egress) a simular. Use o preview enquanto constrói, e as execuções para ver o que realmente aconteceu. + +## Proveniência em um Achado + +As execuções respondem "o que esta regra fez?". A proveniência responde à pergunta oposta: "por que este Finding mudou?". + +Toda alteração feita por uma regra é registrada no Finding junto com a regra, a execução e o nó responsáveis, e aparece como uma linha do tempo no próprio Finding. As ações registradas são: + +| Ação | Significado | +|--------|---------| +| `created`, `updated`, `closed`, `reopened` | O ciclo de vida do Finding mudou. | +| `duplicate`, `status_change` | Seus sinalizadores de duplicidade ou status mudaram. | +| `notified` | Uma notificação foi enviada sobre ele. | +| `delivered` | Uma entrega de saída o cobriu. | + +Edições de campo registram o que mudou, incluindo o valor anterior e o valor posterior de cada campo. Valores muito longos são truncados no registro, de modo que a linha do tempo permanece um registro da alteração, e não uma segunda cópia do Finding. + +Notificações e entregas também são registradas aqui. Isso é proposital: uma regra que enviou uma mensagem, mas não alterou nenhum campo, de outra forma não deixaria nenhum rastro no Finding. + +A proveniência sobrevive à regra. Excluir uma regra ou uma execução mantém as entradas da linha do tempo e simplesmente as desvincula, de modo que o histórico não desaparece quando alguém faz uma limpeza. + +## Excluindo regras com histórico + +Uma regra que produziu entregas não pode ser excluída enquanto elas existirem. Exclua as entregas primeiro, ou mantenha a regra e a desative. Isso é intencional: as entregas guardam o registro do que foi realmente enviado para sistemas externos, e uma exclusão em cascata levaria consigo envios em andamento. diff --git a/docs/content/connectors/_index.pt-br.md b/docs/content/connectors/_index.pt-br.md new file mode 100644 index 0000000000..0926f17324 --- /dev/null +++ b/docs/content/connectors/_index.pt-br.md @@ -0,0 +1,17 @@ +--- +title: Conectores +description: Conecte o DefectDojo aos seus scanners e rastreadores de issues +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.pt-br.md b/docs/content/connectors/about.pt-br.md new file mode 100644 index 0000000000..280d895495 --- /dev/null +++ b/docs/content/connectors/about.pt-br.md @@ -0,0 +1,66 @@ +--- +title: Sobre os Conectores +description: O local unificado para Conectores Upstream e Downstream na interface + do Pro +summary: '' +date: 2026-07-14 00:00:00+00:00 +lastmod: 2026-07-14 00:00:00+00:00 +draft: false +weight: 1 +chapter: true +sidebar: + collapsed: true +seo: + title: '' + description: '' + canonical: '' + robots: '' +pro-feature: true +--- + +Observação: Conectores são um recurso exclusivo do DefectDojo Pro. + +**Conectores** é o local único na interface do DefectDojo Pro para todas as ferramentas com as quais o DefectDojo se comunica, em ambas as direções. Ele reúne dois recursos que antes eram configurados em locais separados: + +* **Conectores Upstream** (antigos **Conectores de API**) trazem achados e inventário de ativos *para dentro*, a partir dos seus scanners e ferramentas de segurança. +* **Conectores Downstream** (antigas **Integrações**) enviam achados *para fora*, para os seus sistemas de rastreamento de problemas e emissão de tickets. + +Se você pensar no DefectDojo como o hub dos seus dados de segurança, os Conectores Upstream são a forma como os dados chegam, e os Conectores Downstream são a forma como o trabalho de remediação sai. + +## Onde encontrar os Conectores + +Na barra lateral da interface do Pro, abra o grupo **Connectors** no cabeçalho **Import**: + +* **Connectors > Upstream Connectors** — substitui a antiga entrada **API Connectors** (anteriormente em Import). +* **Connectors > Downstream Connectors** — substitui a antiga entrada **Integrations** (anteriormente em Settings). Esta direção está atualmente em **Beta**. + +Os favoritos e links diretos antigos continuam funcionando: as URLs legadas de **API Connectors** e **Integrations** redirecionam automaticamente para as novas páginas **Upstream Connectors** e **Downstream Connectors**. + +## Quem pode ver o quê + +* **Upstream Connectors** fica visível para usuários com Função Global de Reader ou superior. +* **Downstream Connectors** fica visível apenas para superusuários, e atualmente está em **Beta** para instâncias do DefectDojo Pro hospedadas na Cloud. + +O grupo **Connectors** aparece na barra lateral se pelo menos uma das duas páginas estiver visível para você. + +## As páginas de Connectors + +As duas direções compartilham o mesmo layout renovado: + +* Cada ferramenta é exibida como um **quadro** (tile) em largura total — logotipo à esquerda, o nome da ferramenta e uma breve descrição no centro, e um botão de ação à direita. +* Cada seção tem uma **caixa de busca** que filtra os quadros por nome da ferramenta enquanto você digita. + +Na página **Upstream Connectors**: + +* **Configured Connectors** lista os conectores que você já configurou. Cada quadro mostra um resumo de integridade operacional (status de integridade, última operação e contagens totais/mapeadas de registros) e um menu **Manage Configuration** com as ações **Manage Records & Operations**, **Edit Configuration** e **Delete Configuration**. +* **Available Connectors** lista as ferramentas suportadas que você ainda não configurou, cada uma com um botão **Add Configuration**. +* Um filtro no cabeçalho da página restringe ambas as seções por tipo de conector: **All**, **Asset** (ou **Product**, dependendo do vocabulário da sua instância) para conectores que importam inventário de ativos, e **Finding** para conectores que importam dados de vulnerabilidade. + +Na página **Downstream Connectors**: + +* **Available Integrations** lista todos os sistemas de rastreamento de problemas suportados. Os quadros das integrações já configuradas mostram uma contagem das Integration Instances existentes. + +## Próximos passos + +* Leia [Sobre os Conectores Upstream](/connectors/upstream/about/) e [adicione seu primeiro Conector Upstream](/connectors/upstream/add_edit/) para começar a importar achados automaticamente. +* Leia o [guia de Conectores Downstream](/connectors/downstream/about/) para enviar achados aos seus sistemas de rastreamento de problemas. diff --git a/docs/content/connectors/downstream/PRO__jira_guide.pt-br.md b/docs/content/connectors/downstream/PRO__jira_guide.pt-br.md new file mode 100644 index 0000000000..a35a6efe13 --- /dev/null +++ b/docs/content/connectors/downstream/PRO__jira_guide.pt-br.md @@ -0,0 +1,786 @@ +--- +title: Jira (Legado) +description: Trabalhe com a integração do Jira +weight: 1 +audience: pro +aliases: +- /pt-br/issue_tracking/jira/pro__jira_guide/ +- /pt-br/en/share_your_findings/jira_guide +--- + +> **Esta página documenta a integração legada do Jira.** A integração do Jira por produto descrita aqui foi substituída pelo **[Conector Downstream do Jira](/connectors/downstream/about/)**, que está disponível de forma geral em todas as instâncias do DefectDojo Pro e é a forma recomendada de enviar Achados para o Jira. Na barra lateral do Pro, **Connect > Jira** traz um selo `LEGACY` por esse motivo — veja [Menu Badges](/navigation/pro__menu_badges/). +> +> **Se você está configurando o Jira pela primeira vez, comece pelo [Conector Downstream](/connectors/downstream/about/) em vez deste guia.** +> +> **Já usa a integração legada?** O DefectDojo Pro inclui uma migração integrada que move sua configuração clássica existente do Jira para os Conectores Downstream, incluindo os tickets que você já enviou — veja [Migrando para o Conector Downstream do Jira](#migrating-to-the-jira-downstream-connector) abaixo. +> +> A integração legada continua funcionando, e este guia permanece válido para ela. + +A integração do Jira do DefectDojo pode ser usada para enviar dados de Achados para um ou mais Espaços do Jira. Ao fazer isso, você pode integrar o DefectDojo ao seu fluxo de trabalho de desenvolvimento padrão. Aqui estão alguns exemplos de como isso pode funcionar: + +* A equipe de AppSec pode enviar seletivamente Achados para um Espaço do Jira usado pelos desenvolvedores, para que a correção de problemas possa ser adequadamente priorizada junto com o desenvolvimento normal. Os desenvolvedores nesse quadro não precisam acessar o DefectDojo - eles podem manter todo o trabalho deles em um só lugar. +* O DefectDojo pode enviar TODOS os Achados para um Espaço do Jira bidirecional que a equipe de AppSec usa, o que permite que eles dividam a validação de problemas. Esse quadro se mantém sincronizado com o DefectDojo e permite fluxos de correção complexos. +* O DefectDojo pode enviar seletivamente Achados de Produtos e/ou Engajamentos separados para Espaços do Jira separados, para manter as coisas em seu contexto adequado. + +## Migrando para o Conector Downstream do Jira + +O DefectDojo Pro pode converter uma configuração clássica existente do Jira em uma configuração de Conector Downstream para você, em vez de exigir que você a reconstrua manualmente. + +**Onde encontrar:** acesse **Connect \> Downstream** para abrir a página **Downstream Connectors**, e use o cartão **Classic Jira Migration**. Clique em **Migrate from classic Jira** e depois confirme. + +O cartão só aparece se houver configuração clássica do Jira para migrar, ou uma execução anterior a reportar — então uma instância que nunca usou o Jira clássico não vai vê-lo. Depois que tudo tiver sido migrado, o cartão permanece, mas o botão fica desabilitado, porque não há mais nada a fazer. + +Executar a migração exige **permissões globais de nível Maintainer** (especificamente, permissão para editar integrações), e ela precisa ser executada a partir de uma sessão de navegador autenticada — não pode ser feita com um token de API. + +### O que acontece com os tickets que você já enviou + +**Seus tickets existentes do Jira são mantidos e vinculados novamente — eles não ficam órfãos, e o conector não abre duplicatas.** Cada Achado que o Jira clássico já havia enviado mantém seu ticket, e o conector passa a atualizar esse mesmo ticket a partir de então. Os links em Grupos de Achados são transferidos da mesma forma. + +A única exceção são os **epics de Engajamento**. O Conector Downstream não tem o conceito de epics, então os problemas do tipo epic são reportados nos avisos da migração e deixados intocados. + +### O que é migrado + +* Sua conexão de **instância** do Jira — URL e credenciais — se torna uma instância de integração de Conector Downstream, mantendo seu nome. +* Os **mapeamentos de severidade** e os **mapeamentos de status** (suas chaves de transição de abertura e fechamento) são transferidos. +* Cada configuração de **Projeto do Jira** se torna um mapeamento de rastreador de problemas, mantendo sua chave de projeto e tipo de issue, e permanece atribuída ao mesmo Produto ou Engajamento. +* **Push All Issues** é preservado: projetos que tinham essa opção habilitada continuam enviando automaticamente. +* **Campos personalizados**, **campos de transição de fechamento/reabertura**, **componente**, **responsável padrão** e **labels** são convertidos em mapeamentos de campo. Onde você usava *Add Vulnerability Id as a Jira label*, isso também se torna um mapeamento de label. +* Um diretório de **modelo de issue personalizado** se torna um modelo de ticket. Os modelos padrão não são copiados, porque o conector já traz equivalentes. + +### O que não é transferido + +Esses itens são reportados como avisos na execução da migração — eles não a interrompem. Procure pela lista *"things the connector cannot carry over"* nos resultados. + +* **Sincronização reversa do Jira → DefectDojo.** Esse é o ponto importante. O Conector Downstream não sincroniza alterações *de volta* a partir do Jira, então os mapeamentos de resolução que aplicam Risco aceito ou Falso positivo a partir de uma resolução do Jira não são migrados. **Se você depende da sincronização reversa, mantenha a instância clássica do Jira configurada** — a migração não a remove. +* **Engagement Epic Mapping** — o conector não tem o conceito de epic. +* **Push Notes**, **comentários de notificação de SLA** e **comentários de expiração de aceitação de risco** — o conector não publica esses itens no Jira. +* Campos personalizados chamados `summary`, `description`, `project`, `issuetype` ou `status` — esses são reservados pelo conector, e um mapeamento de campo que use um deles é ignorado. +* Valores de campo personalizado com mais de 512 caracteres — são ignorados em vez de truncados. +* Um Projeto do Jira que não está vinculado a nenhum Produto nem Engajamento não gera nenhuma atribuição. + +### O que acontece com a integração clássica depois + +**Nada é enviado duas vezes.** Para cada projeto que migra, a migração desativa o projeto clássico do Jira, de modo que somente o conector envia a partir desse ponto. Você não precisa desabilitar nada manualmente. + +Sua configuração clássica é **mantida, não excluída** — a instância, o projeto e os registros de issue permanecem todos, apenas com as configurações de envio desativadas. Isso é proposital: é o que torna a mudança reversível, e é o que mantém a sincronização reversa funcionando caso você dependa dela. + +**Para reverter**, reative as configurações do projeto clássico do Jira e remova a configuração do conector criada pela migração. Não existe um desfazer com um clique. + +**Executar novamente é seguro.** A migração registra o que já foi convertido e ignora isso em uma segunda execução, então nada é duplicado. Se um projeto ou instância falhar, o restante ainda é migrado — um projeto com falha é deixado em execução na integração clássica em vez de ser desativado, para que continue funcionando enquanto você investiga. + +### Enquanto ela é executada + +A migração é executada em segundo plano e reporta o progresso conforme avança. Quando termina, você recebe um resumo — quantos conectores, mapeamentos, atribuições, modelos e vínculos de ticket foram criados, quantos projetos clássicos foram desativados, e o que foi ignorado — junto com os avisos descritos acima. Apenas uma migração é executada por vez. + +# Configurando o Jira + +Configurar o Jira exige as seguintes etapas: +1. Habilite a integração do Jira em System Settings. Até que você faça isso, o restante das configurações do Jira fica oculto em todo o DefectDojo. +2. Conecte uma Instância do Jira, seja com um nome de usuário / senha ou com um token de API. Múltiplas instâncias podem ser vinculadas. +3. Adicione essa Instância do Jira a um ou mais Produtos ou Engajamentos dentro do DefectDojo. +4. Se desejar usar sincronização bidirecional, crie um Webhook do Jira que enviará atualizações ao DefectDojo. + +## Etapa 1: Habilitar a integração do Jira em System Settings + +A integração do Jira fica desativada por padrão, e enquanto estiver desativada o DefectDojo oculta todos os demais controles do Jira na interface. Isso é a primeira coisa a configurar: nenhuma das etapas abaixo fica disponível até que ela seja habilitada. + +Enquanto a integração está desabilitada, não há uma entrada **Jira Instances** na barra lateral, então não há onde adicionar uma Instância do Jira: + +![image](images/jira-menu-hidden-pro.png) + +### Habilitar a integração + +1. Navegue até **Settings \> System \> System Settings** a partir da barra lateral do DefectDojo. Em instâncias que ainda usam o layout de menu anterior, isso fica em um grupo nomeado de acordo com seu pacote de licença — **Pro Settings** ou **Enterprise Settings**. Veja [The Settings Menu](/navigation/pro__settings_menu/). +​ +2. Na seção **Jira Integration Settings**, marque **Enable Jira Integration**. +​ +3. Clique em **Submit**. **Jira Instances** aparece na barra lateral imediatamente, sem recarregar a página: + +![image](images/jira-enable-system-settings-pro.png) + +### O que a configuração controla + +Habilitar **Enable Jira Integration** é o que faz o restante da interface do Jira aparecer. Com ela ativada, você obtém: + +* o menu **Jira Instances**, onde as Instâncias do Jira são adicionadas e editadas +* a página **Jira Project Settings** no menu ⚙️ do Ativo, e as configurações do Jira nos Engajamentos +* as ações **Push to Jira** em Achados e Grupos de Achados, os campos do Jira nos formulários de Achado e edição em massa, e as colunas do Jira nas listas de Ativo, Engajamento, Achado e Grupo de Achados (incluindo exportações CSV) + +A configuração também controla a integração fora da interface: enquanto estiver desativada, o DefectDojo não enviará Achados para o Jira (incluindo requisições `push_to_jira` enviadas pela API), e os webhooks recebidos do Jira são ignorados. + +Os demais campos do Jira em **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**) permanecem visíveis independentemente de a integração estar ativada ou desativada, mas não têm efeito até que ela seja habilitada. + +## Etapa 2: Conectar uma Instância do Jira + +Com a integração habilitada, conectar uma Instância do Jira é a próxima etapa na configuração da integração do Jira no DefectDojo. Observe que o Jira Service Management não é suportado atualmente. + +#### Informações necessárias do Jira + +A Atlassian usa formas diferentes de autenticação entre o Jira Cloud e o Jira Data Center. + +para **Jira Cloud**, você precisará de: +* uma URL do Jira, ex.: https://yourcompany.atlassian.net/ +* uma conta com permissões para criar e atualizar issues na sua instância do Jira. Isso pode ser: + * Uma combinação padrão de **usuário / senha** + * Uma combinação de **usuário / Token de API** + +para **Jira Data Center (ou Server)**, você precisará de: +* uma URL do Jira, ex.: https://jira.yourcompany.com +* uma conta com permissões para criar e atualizar issues na sua instância do Jira. Isso pode ser: + * Uma combinação padrão de **usuário / senha** + * Uma combinação de **endereço de e-mail / Personal Access Token** + +Opcionalmente, você pode mapear: +* Transições do Jira para acionar a Reabertura e o Fechamento de Achados +* Resoluções do Jira que podem aplicar os status de Risco aceito e Falso positivo aos Achados (opcional) + +Múltiplos Espaços do Jira podem ser tratados por uma única conexão de Instância do Jira, desde que a conta / token do Jira usado pelo DefectDojo tenha permissão para criar Issues no Espaço do Jira associado. + +### Adicionar uma Instância do Jira + +1. Certifique-se de que **Enable Jira Integration** esteja marcado em System Settings, conforme descrito na [Etapa 1](#step-1-enable-the-jira-integration-in-system-settings). O menu **Jira Instances** não aparece na barra lateral até que isso ocorra. + +2. Navegue até a página **Enterprise Settings \> Jira Instances \> + New Jira Instance** a partir da barra lateral do DefectDojo. + +![image](images/jira-instance-beta.png) + +3. Selecione um **Configuration Name** para essa Instância do Jira usar no DefectDojo. Esse nome é simplesmente um rótulo para a conexão da Instância no DefectDojo, e não precisa estar relacionado a nenhum dado do Jira. + +4. Selecione a URL da instância do Jira da sua empresa \- provavelmente semelhante a `https://**yourcompany**.atlassian.net` se você estiver usando uma instalação do Jira Cloud. + +5. Informe um método de autenticação apropriado nos campos Username / Password do Jira: + * Para a **autenticação padrão de usuário / senha do Jira**, informe um Nome de Usuário do Jira e a Senha correspondente nesses campos. + * Para autenticação com um **token de API do usuário (Jira Cloud)**, informe o Nome de Usuário com o **token de API** correspondente no campo de senha. + * Para autenticação com um **Personal Access Token** do Jira (também conhecido como PAT, usado apenas no Jira Data Center e no Jira Server), informe o PAT no campo de senha. O Nome de Usuário não é usado para autenticação com um PAT do Jira, mas o campo ainda é obrigatório neste formulário, então você pode usar um valor de referência aqui para identificar seu PAT. + +Observe que o usuário associado a essa conexão precisa ter permissão para criar Issues e acessar dados na sua instância do Jira. + +6. Você precisará fornecer valores para um Epic Name ID, Re-open Transition ID e Close Transition ID. Esses valores podem ser alterados depois. Estando conectado ao Jira, você pode acessar esses valores a partir das seguintes URLs: +- **Epic Name ID**: visite `https:///rest/api/2/field` e procure por Epic Name. Copie o número em `number` e cole aqui. Se você não tiver um Epic Name ID associado ao seu Espaço no Jira (por usar um Espaço Gerenciado por Equipe, por exemplo), informe 0 nesse campo. +- **Re-open Transition ID**: visite `https:///rest/api/latest/issue//transitions?expand-transitions.fields` para encontrar o ID da sua instância do Jira. Cole no campo Reopen Transition ID. +- **Close Transition ID**: Visite `https:///rest/api/latest/issue//transitions?expand-transitions.fields` para encontrar o ID da sua instância do Jira. Cole no campo Close Transition ID. + +7. Selecione o tipo de issue padrão que você deseja usar ao criar Issues no Jira. As opções são **Bug, Task, Story** e **Epic** (que são tipos de issue padrão do Jira), além de **Spike** e **Security**, que são tipos de issue personalizados. Se você tiver um Tipo de Issue diferente que deseja usar, entre em contato com [support@defectdojo.com](mailto:support@defectdojo.com) para obter assistência. + +8. Selecione seu Modelo de Issue, que determinará a Descrição da Issue quando as Issues forem criadas no Jira. + +Os dois tipos são: +- **Jira\_full**, que incluirá todas as informações do Achado nas Issues do Jira +- **Jira\_limited**, que incluirá uma quantidade menor de informações e metadados do Achado. + +Se você deixar esse campo em branco, o padrão será **Jira\_full.** Se precisar de um tipo diferente de modelo, entre em contato com [support@defectdojo.com](mailto:support@defectdojo.com). + +9. Se desejar, informe o nome de uma Resolução do Jira que alterará o status de um Achado para Aceito ou para Falso positivo (quando a Resolução for acionada na Issue). + +O formulário pode ser enviado a partir daqui. Se desejar, você pode personalizar ainda mais sua integração do Jira em Optional Fields. Clicar nesse botão permitirá aplicar texto genérico às Issues do Jira ou alterar o mapeamento de Jira Severity Mappings. + +## Etapa 3: Conectar um Produto ou Engajamento ao Jira + +Cada Produto ou Engajamento no DefectDojo tem suas próprias configurações que determinam como os Achados são convertidos em Issues do JIRA. A partir daqui, você pode decidir o Espaço do Jira associado e definir o comportamento padrão para criação de Issues, Epics, Labels e outros metadados do JIRA. + +### Adicionar o Jira a um Produto + +Você pode encontrar essa página clicando no menu de Engrenagem em um Produto ⚙️ e abrindo a página **Jira Project Settings**. + +![image](images/jira-project-settings.png) + +#### Instância do Jira + +Se você tiver múltiplas instâncias do Jira configuradas, para produtos ou equipes separados dentro da sua organização, você pode indicar em qual Espaço do Jira deseja que o DefectDojo crie Issues. Selecione um Espaço no menu suspenso. + +Se esse menu não listar nenhuma instância do Jira, confirme que esses Espaços estão conectados na sua Configuração Global do Jira para o DefectDojo \- yourcompany.defectdojo.com/jira. + +#### Chave do projeto + +Essa é a chave do Espaço que você deseja usar com o DefectDojo. A Chave do Espaço para um determinado Espaço pode ser encontrada na URL. (Isso antes era chamado de **Jira Project Key**, mas a partir de setembro de 2025, isso agora é chamado no Jira de **Space Key**). + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_3.png) + +#### Nome do tipo de issue Epic + +O nome do tipo de issue Epic no Jira. O padrão é "Epic", mas pode ser alterado se sua instância do Jira usar um nome diferente. + +#### Modelo de issue + +Aqui você pode determinar quantos metadados do DefectDojo deseja enviar ao Jira. Selecione uma das duas opções: + +* **jira\_full**: as Issues rastrearão todos os parâmetros do DefectDojo \- uma Descrição completa, CVE, Severidade, etc. Útil se você precisar de contexto completo do Achado no Jira (por exemplo, se alguém está trabalhando nessa Issue e não tem acesso ao DefectDojo). + +Aqui está um exemplo de uma Issue **jira\_full**: +​ +![image](images/Add_a_Connected_Jira_Project_to_a_Product_4.png) + +* **Jira\_limited:** as Issues rastrearão apenas o link do DefectDojo, os links de Produto/Engajamento/Teste, os campos Reporter e Environment. Todos os outros campos são rastreados apenas no DefectDojo. Útil se você não precisar de contexto completo do Achado no Jira (por exemplo, se alguém está trabalhando nessa Issue e trabalha principalmente no DefectDojo, sem precisar do quadro completo também no JIRA). + +​Aqui está um exemplo de uma Issue **jira\_limited**: + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_5.png) + +#### Componente + +Se você gerencia seu Espaço do Jira usando Componentes, pode atribuir aqui o Componente apropriado para o DefectDojo. Para atribuir mais de um Componente, informe uma lista separada por vírgulas (por exemplo, `Security, DevSecOps`); cada valor é enviado ao Jira como um componente separado. + +#### Campos personalizados + +Se você não precisar usar Campos Personalizados com issues do DefectDojo, pode deixar esse campo como 'null'. + +No entanto, se as Configurações do seu Espaço do Jira **exigirem** que você use Campos Personalizados em novas Issues, você precisará codificar esses mapeamentos. + +Observe que o DefectDojo não consegue enviar metadados específicos de uma Issue como Campos Personalizados, apenas um valor padrão. Essa seção só deve ser configurada se o seu Espaço do Jira **exigir que esses Campos Personalizados existam** em todas as Issues do seu Espaço. + +Siga **[este guia](#custom-fields-in-jira)** para começar a trabalhar com Campos Personalizados. + +#### Campos de transição de fechamento / reabertura + +Alguns fluxos de trabalho do Jira **exigem** que determinados campos sejam definidos como parte de uma transição — por exemplo, um fluxo de trabalho que se recusa a fechar uma Issue a menos que um campo de Resolução e um campo de Justificativa sejam fornecidos na tela de fechamento. A configuração de Campos personalizados acima só se aplica quando uma Issue é *criada*, então ela não consegue atender a esses fluxos de trabalho. + +Sem essas configurações, o DefectDojo envia transições de fechamento / reabertura sem nenhum campo. Um fluxo de trabalho que exige campos rejeitará essa transição, e o Achado e a Issue do Jira ficam dessincronizados: o Achado aparece como Mitigado no DefectDojo enquanto a Issue permanece aberta no Jira. + +As configurações **Close Transition fields** e **Reopen Transition fields** aceitam um objeto JSON que é enviado como o payload `fields` da chamada de transição de fechamento / reabertura. Por exemplo, para fechar Issues com uma Resolução de *Won't Fix* mais um valor de justificativa: + +```json +{ + "resolution": {"name": "Won't Fix"}, + "customfield_10200": "Risk accepted by security team #report-false-positive" +} +``` + +Deixe essas configurações como 'null' se o seu fluxo de trabalho do Jira não exigir campos nas transições. + +**Quais campos você precisa?** + +* Pergunte ao seu administrador do Jira quais campos estão nas **telas de transição** de fechamento / reabertura, e quais deles são exigidos por um validador. O JSON configurado precisa atender **todos** os campos obrigatórios: se algum campo obrigatório estiver ausente do payload, o Jira rejeita toda a transição e não define nada — fornecer apenas alguns dos campos obrigatórios não ajuda. +* Por outro lado, os campos precisam estar presentes **na tela de transição** para serem enviados: o Jira rejeita transições que tentam definir campos que não estão na tela dessa transição. +* Em fluxos de trabalho construídos com o editor de fluxo de trabalho atual do Jira Cloud, o Jira preenche automaticamente a Resolução padrão do site quando uma Issue passa para um status da categoria concluído. Assim, uma Resolução obrigatória sozinha não bloqueará uma transição simples nesse caso, e o uso prático de `"resolution"` neste payload é escolher um valor *significativo* (por exemplo, *False Positive*) em vez do padrão do site. Fluxos de trabalho construídos com o editor clássico, ou com aplicativos validadores do marketplace, ainda podem exigir a Resolução de forma obrigatória. +* As transições de reabertura tipicamente limpam a Resolução através do próprio fluxo de trabalho, então **Reopen Transition fields** geralmente só precisa dos campos personalizados que seu fluxo de trabalho exige. + +**Observações:** + +* O mesmo JSON é enviado para *toda* transição de fechamento (ou reabertura) do Produto ou Engajamento — os valores são estáticos e não variam por Achado. Se você precisar de campos diferentes por disposição (por exemplo, uma Resolução diferente para achados Falso positivo do que para achados corrigidos), use o DefectDojo Pro Jira Integrator, que suporta mapeamentos de campo de transição por status. +* Os valores usam o mesmo formato da API REST do Jira: strings para campos de texto, `{"name": ...}` para resoluções, `[{"name": ...}]` para campos de múltipla seleção, e assim por diante. +* Se as transições foram rejeitadas enquanto essas configurações estavam ausentes ou incompletas, corrigir as configurações repara a divergência: o próximo envio de status para o Achado tenta novamente a transição com os campos configurados. +* Ambas as configurações também estão disponíveis no endpoint REST `/api/v2/jira_projects/` (`close_transition_fields` / `reopen_transition_fields`), então podem ser gerenciadas via API. +* Esses campos também são aplicados quando o DefectDojo fecha uma Issue porque seu Achado foi **excluído** — os valores são capturados no momento em que o fechamento é enfileirado. + +#### Labels do Jira + +Selecione os labels relevantes com os quais você deseja que a Issue seja criada no Jira, ex.: **DefectDojo**, **YourProductName..** + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_6.png) + +#### Responsável padrão + +O nome do responsável padrão no Jira. Se deixado em branco, o DefectDojo seguirá o comportamento padrão do seu Espaço do Jira ao criar Issues. + +### Jira Project Settings + +#### Habilitado + +Esse alternador controla se o DefectDojo envia Achados para o Jira nesse Produto. Desabilitar isso não excluirá nem alterará nenhum ticket do Jira existente criado pelo DefectDojo, mas impedirá quaisquer atualizações adicionais ou a criação de novas Issues. + +As integrações do Jira só podem ser removidas da sua instância se nenhuma Issue relacionada tiver sido criada. Se Issues já foram criadas, não há como remover completamente uma Instância do Jira do DefectDojo. + +#### Adicionar o Vulnerability Id como um label do Jira + +Isso permite adicionar automaticamente os dados de Vulnerability ID como um Label do Jira. Os IDs de Vulnerabilidade são adicionados aos Achados por ferramentas de segurança individuais \- podem ser IDs de Common Vulnerabilities and Exposures (CVE) ou um formato diferente, específico da ferramenta que reporta o Achado. + +#### Push All Issues + +Se marcado, o DefectDojo enviará automaticamente todos os Achados Ativos e Verificados ao Jira como Issues. Se deixado desmarcado, todos os Achados precisarão ser enviados ao Jira manualmente (individualmente ou por envio em massa). + +Quando essa configuração está habilitada, as Issues do Jira continuarão sincronizadas com o DefectDojo mesmo se o status do Achado mudar. + +#### Habilitar Engagement Epic Mapping + +No DefectDojo, os Engajamentos representam uma coleção de trabalho. Cada Engajamento contém um ou mais testes, que contêm um ou mais Achados que precisam ser mitigados. Os Epics no Jira funcionam de forma semelhante, e essa caixa de seleção permite enviar Engajamentos ao Jira como Epics. + +* Um Engajamento no DefectDojo \- observe os três achados listados na parte inferior. +​ +![image](images/Add_a_Connected_Jira_Project_to_a_Product_8.png) +* Como o mesmo Engajamento se torna um Epic quando enviado ao JIRA \- os Achados do Engajamento também são enviados, e residem dentro do Epic como Issues filhas. + +![image](images/Add_a_Connected_Jira_Project_to_a_Product_9.png) + +#### Push Notes + +Se habilitado, os comentários do Jira serão exibidos no Achado associado no DefectDojo, em Notas, e vice-versa; Notas em Achados serão adicionadas à Issue do Jira associada como Comentários. + +#### Enviar Notificações de SLA Como Comentários + +Se habilitado, qualquer Issue que viole as regras de Acordo de Nível de Serviço do DefectDojo terá comentários adicionados na issue do Jira indicando isso. Esses comentários serão publicados diariamente até que a Issue seja resolvida. + +Os Acordos de Nível de Serviço podem ser configurados em **Configuration \> SLA Configuration** no DefectDojo e atribuídos a cada Produto. + +#### Enviar Notificações de Expiração de Aceitação de Risco Como Comentário + +Se habilitado, qualquer Issue cuja Aceitação de Risco associada no DefectDojo expire terá um comentário adicionado na issue do Jira indicando isso. Esses comentários serão publicados diariamente até que a Issue seja resolvida. + +### Configurações de Jira em Nível de Engajamento + +Por padrão, os Engajamentos **herdam as configurações do Jira do seu Produto**. No entanto, você pode sobrepor as configurações do Jira para Engajamentos individuais. + +Para acessar as configurações de Jira em nível de Engajamento, clique no menu de Engrenagem ⚙️ em um Engajamento e abra a página **Jira Project Settings**. + +A partir daqui, você pode desmarcar **Inherit from Product** e fornecer valores específicos do Engajamento para: **Project Key**, **Issue Template, Custom Fields, Jira Labels, Default Assignee**, e outras configurações. + +Observe que, uma vez que um Engajamento tenha seu próprio projeto do Jira atribuído, ele não pode mais herdar do Produto. + +![image](images/Creating_Issues_in_Jira_5.png) + +## Etapa 4: Configurar Sincronização Bidirecional: Webhook do Jira + +A integração com o Jira permite sincronização bidirecional via webhook. O DefectDojo recebe notificações do Jira em um endereço exclusivo, o que permite que comentários do Jira sejam recebidos nos Achados, ou que Achados sejam resolvidos via Jira, dependendo da sua configuração. + +### Localizando a URL do seu Webhook do Jira + +Seu Webhook do Jira está localizado no formulário de Configurações do Sistema, em **Configurações de Integração do Jira**: **Configurações Corporativas \> Configurações do Sistema** na barra lateral. + +Você também precisa marcar **Habilitar Webhook do Jira** na mesma página antes que o DefectDojo processe as notificações recebidas do Jira. Os webhooks recebidos são ignorados se essa caixa ou **Habilitar Integração com o Jira** (veja a [Etapa 1](#step-1-enable-the-jira-integration-in-system-settings)) estiver desmarcada. + +![image](images/Configuring_the_Jira_DefectDojo_Webhook.png) + +### Criando o Webhook do Jira + +1. Acesse `**https:// \ /plugins/servlet/webhooks**` +2. Clique em 'Create a Webhook'. +3. No campo chamado 'URL', insira: `https:// \<**YOUR DOJO DOMAIN**\> /jira/webhook/ \<**YOUR GENERATED WEBHOOK SECRET**\>`. O Web Hook Secret está listado em Configurações de Integração do Jira, conforme mencionado acima. +4. Em 'Comments', habilite 'Created'. Em 'Issue', habilite 'Updated'. +5. Certifique-se de que sua instância do JIRA confia no certificado SSL usado pela sua instância do DefectDojo. Para o JIRA Cloud, o DefectDojo deve usar [um certificado SSL/TLS válido, assinado por uma autoridade certificadora globalmente confiável](https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-registering-webhooks-with-non-secure-urls/) + +Observe que você não precisa criar um Secret dentro do Jira para usar esse webhook. O Secret já está embutido na URL do DefectDojo, portanto basta adicionar a URL completa ao formulário de Webhook do Jira. + +As requisições de webhook recebidas são autenticadas pelo secret contido nessa URL, portanto trate a URL completa como uma credencial e mantenha-a privada. + +#### Testando o Webhook + +Depois de ter uma ou mais Issues criadas a partir de Achados do DefectDojo, você pode testar o Webhook adicionando um Comentário a um desses Achados. O Comentário deve ser recebido pelo webhook do Jira como uma nota. + +Se isso não funcionar corretamente, pode ser devido a um problema de firewall na sua instância do Jira bloqueando o Webhook. + +* As Regras de Firewall do DefectDojo incluem uma caixa de seleção para o **Jira Cloud,** que precisa ser habilitada antes que o DefectDojo possa receber mensagens de Webhook do Jira. + +### Alternativa: Usando o Jira Automation (Send web request) + +Algumas instâncias do Jira não permitem webhooks de sistema em `/plugins/servlet/webhooks` — por exemplo, quando essa área de administração é restrita e somente regras do **Jira Automation** são permitidas. Nesse caso, você pode obter a mesma sincronização bidirecional usando a ação **Send web request** do Automation, que envia os dados para o mesmo endpoint de webhook do DefectDojo. + +O endpoint de webhook do DefectDojo aceita qualquer `POST` HTTP com `Content-Type: application/json` e um secret válido no caminho da URL. Ele **não** exige que a requisição venha do mecanismo de webhook de sistema do Jira, portanto a ação "Send web request" do Automation funciona como uma alternativa direta. + +#### Pré-requisitos + +Aplicam-se os mesmos pré-requisitos do webhook de sistema: + +* **Enable JIRA integration** e **Enable JIRA web hook** estão ambas marcadas na página ⚙️ **Configuration \> System Settings**. +* Um **Jira webhook secret** não vazio está definido nessa página. O secret pode conter apenas os caracteres `A-Z`, `a-z`, `0-9`, `_` e `-`. +* O Achado (ou Grupo de Achados) já está vinculado à issue do Jira. Se a issue não estiver vinculada a um Achado do DefectDojo, a requisição ainda é aceita (HTTP `200`), mas nenhuma ação é executada. + +#### Como o DefectDojo processa a requisição + +* O DefectDojo direciona o processamento com base em um campo `webhookEvent` de nível superior. Somente `"jira:issue_updated"` e `"comment_created"` são processados; qualquer outro valor é aceito e ignorado. O Automation **não** adiciona esse campo automaticamente, portanto você precisa incluí-lo você mesmo no corpo da requisição. +* Por isso, defina o **Body** da requisição como **Custom data** e forneça o JSON abaixo. As opções de body **Empty** e **Jira issue data** não incluem o campo `webhookEvent` obrigatório, portanto o DefectDojo as ignorará. +* O endpoint sempre retorna HTTP `200`, independentemente de uma atualização ter sido aplicada ou não. O sucesso ou a falha só ficam visíveis no corpo da resposta e nos logs do DefectDojo — um `200` no log de auditoria do Automation **não** confirma, por si só, que a atualização chegou a um Achado. + +#### Rule 1 — Issue atualizada + +Crie uma regra do Automation com: + +* **Trigger:** *Issue transitioned* (ou outro trigger que seja disparado quando os campos que você sincroniza mudarem, por exemplo *Field value changed* em Status). +* **Action:** *Send web request* + * **Web request URL:** `https:///jira/webhook/` + * **HTTP method:** `POST` + * **Web request body:** *Custom data* + * **Headers:** `Content-Type: application/json` + * **Custom data:** + +```json +{ + "webhookEvent": "jira:issue_updated", + "issue": { + "id": "{{issue.id}}", + "fields": { + "updated": "{{issue.updated}}", + "resolution": null, + "status": { "statusCategory": { "key": "{{issue.status.statusCategory.key}}" } }, + "assignee": { "name": "{{issue.assignee.accountId}}", "displayName": "{{issue.assignee.displayName}}" } + } + } +} +``` + +Restrições para atualizações de issue: + +* `issue.id` deve ser o **ID numérico interno da issue no Jira** (`{{issue.id}}`), não a chave da issue (por exemplo, `PROJ-123`). O DefectDojo associa a atualização a um Achado por meio desse ID numérico. +* Os campos `resolution` e `updated` devem sempre estar presentes. `resolution` pode ser `null`, mas se qualquer um dos dois campos estiver ausente, a requisição é aceita (`200`) e silenciosamente não processada. +* A sincronização de status e a auto-mitigação são controladas por `status.statusCategory.key`, cujos valores no Jira são `new` (To Do), `indeterminate` (In Progress) e `done` (Done). Um Achado só é mitigado quando a issue é realmente fechada, e não apenas porque um valor de resolution está presente. + +#### Rule 2 — Issue comentada + +Crie uma segunda regra do Automation com: + +* **Trigger:** *Issue commented* +* **Action:** *Send web request* — mesma URL, método, header e opção de body *Custom data* que na Rule 1, com este 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}}" } + } +} +``` + +Restrições para comentários: + +* Tanto `body` quanto `updateAuthor` devem estar presentes. +* O DefectDojo deriva a issue de destino a partir da URL `comment.self` — especificamente o `` no segmento `.../issue//comment/...` — portanto `{{issue.id}}` (o ID numérico) precisa aparecer ali. +* **Prevenção de loop:** se o autor do comentário corresponder à conta do Jira que o DefectDojo usa para postar seus próprios comentários, o DefectDojo ignora o comentário para evitar um loop de eco. Se você quiser que *todos* os comentários sejam ingeridos, execute a regra do Automation como um usuário do Jira **diferente** daquele configurado na instância do Jira do DefectDojo. + +#### Uma observação sobre smart values + +Os smart values mostrados acima (`{{issue.id}}`, `{{issue.status.statusCategory.key}}`, `{{comment.author.accountId}}`, e assim por diante) são os nomes padrão do Jira Cloud, mas podem variar entre instâncias. Antes de colocar em produção, use o payload preview do Automation para confirmar que cada smart value resolve para o valor esperado. + +## Testando a integração com o Jira + +#### Teste 1: os Achados são enviados corretamente para o Jira? + +Para testar se a integração com o Jira está funcionando corretamente, você pode adicionar um novo Achado em branco ao Produto associado ao Jira no DefectDojo. **Product \> Findings \> Add New Finding.** + +Adicione o título, a severidade e a descrição que desejar, e clique em "Finished". O Achado deve aparecer como uma Issue no Jira com todos os metadados relevantes. + +Se as Issues do Jira não estiverem sendo criadas corretamente, verifique suas Notificações para códigos de erro. + +* Confirme que o Usuário do Jira associado à Configuração do Jira do DefectDojo tem permissão para criar e atualizar issues naquele Jira Space específico. + +#### Teste 2: os Webhooks do Jira enviam dados para o DefectDojo + +Para testar os webhooks do Jira, adicione uma Nota a um Achado que também exista no JIRA como uma Issue (por exemplo, a issue de teste da seção acima). + +Se os webhooks estiverem configurados corretamente, você deverá ver a Nota no Jira como um Comentário na issue. + +Se isso não funcionar corretamente, pode ser devido a um problema de firewall na sua instância do Jira bloqueando o Webhook. + +* As Regras de Firewall do DefectDojo incluem uma caixa de seleção para o **Jira Cloud,** que precisa ser habilitada antes que o DefectDojo possa receber mensagens de Webhook do Jira. + +## Desconectando do Jira + +As integrações com o Jira só podem ser removidas da sua instância se nenhuma Issue relacionada tiver sido criada. Se Issues já tiverem sido criadas, não há como remover completamente uma instância do Jira do DefectDojo. + +No entanto, você pode desabilitar sua integração com o Jira desabilitando-a no nível do Produto. Na página **Jira Project Settings** (acessível pelo menu ⚙️ Engrenagem em um Produto), desmarque a opção **Enabled**. Isso não excluirá nem alterará nenhum ticket do Jira já criado pelo DefectDojo, mas desabilitará futuras atualizações. + +# Enviando Achados para o Jira + +Um Produto com um mapeamento do JIRA pode enviar Achados para o Jira como Issues usando vários métodos. Você pode enviar Achados individualmente, em massa, como Grupos de Achados, ou automaticamente. + +## Enviar um Único Achado + +1. Abra o Achado que deseja enviar. +2. Clique no **☰ Finding Menu** e selecione **Push to Jira**. +3. Confirme o envio quando solicitado. O DefectDojo criará uma Issue no Jira e a vinculará ao Achado. + +Depois que a Issue for criada, o DefectDojo exibirá um link para a Issue do Jira na página do Achado. + +![image](images/Creating_Issues_in_Jira_2.png) + +Você também pode marcar a caixa de seleção **Push to Jira** ao editar um Achado pelo formulário **Edit Finding**. Quando o Achado for salvo, ele será enviado para o Jira. + +### Atualizando uma Issue do Jira Vinculada + +Se um Achado já tiver uma Issue do Jira vinculada, selecionar **Push to Jira** novamente atualizará a Issue existente no Jira com quaisquer alterações feitas no DefectDojo. Se **Push All Issues** estiver habilitado no Produto, essa sincronização acontece automaticamente. + +### Desvinculando um Achado do Jira + +Para remover a associação entre um Achado e sua Issue do Jira, clique no **☰ Finding Menu** e selecione **Unlink From Jira**. Isso remove o vínculo no DefectDojo, mas não exclui a Issue do Jira em si. + +## Enviar Achados em Massa + +Você pode enviar vários Achados para o Jira de uma vez usando o formulário **Bulk Update**: + +1. Em uma lista de Achados, selecione os Achados que deseja enviar usando as caixas de seleção. +2. Abra o formulário **Bulk Update**. +3. Em **Jira Settings**, marque a caixa de seleção **Push to Jira**. +4. Clique em **Submit**. + +Os Achados selecionados serão colocados na fila para envio ao Jira. O DefectDojo exibirá uma mensagem de confirmação indicando quantos Achados foram enfileirados. + +## Enviar Engajamentos como Epics + +Se **Enable Engagement Epic Mapping** estiver ativado nas **Jira Project Settings**, você pode enviar um Engajamento para o Jira como um Epic. Os Achados do Engajamento serão enviados como Issues filhas dentro desse Epic. + +Para enviar um Engajamento como um Epic: + +1. Abra o Engajamento que deseja enviar. +2. Clique no **☰ Engagement Menu** e selecione **Push to Jira**. +3. Opcionalmente, forneça um **Epic Name** (o padrão é o nome do Engajamento, se deixado em branco) e uma **Epic Priority**. +4. Marque **Push to Jira (Create Epic)** e envie o formulário. + +## Enviar Grupos de Achados como Issues do Jira + +Se você tiver Finding Groups habilitados, pode enviar um Grupo de Achados para o Jira como uma única Issue, em vez de Issues separadas para cada Achado. + +Para enviar um Grupo de Achados: + +1. Abra o Finding Group. +2. Clique no **☰ Finding Group Menu** e selecione **Push to Jira**, ou marque a caixa de seleção **Push to Jira** ao editar o Finding Group. + +A Issue do Jira associada a um Grupo de Achados deve ser excluída diretamente na instância do Jira, caso a remoção seja necessária. + +### Criar e Enviar Grupos de Achados Automaticamente + +Com **Push All Issues** habilitado no Produto, e uma opção de **Group By** selecionada na importação: + +Desde que os Finding Groups sejam criados com sucesso, é o Grupo de Achados que será enviado automaticamente para o Jira como uma Issue, e não os Achados individuais. + +![image](images/Creating_Issues_in_Jira_4.png) + +## Comportamento de Envio Automático + +O DefectDojo pode enviar Achados e atualizações automaticamente para o Jira em vários cenários: + +### Push All Issues + +Quando a configuração **Push All Issues** está habilitada nas Jira Project Settings de um Produto, o DefectDojo criará automaticamente Issues no Jira para todos os Achados Ativos e Verificados. Isso inclui Achados criados por importação de scan. Depois que uma Issue do Jira é criada, ela continuará sincronizada com o DefectDojo mesmo que o status do Achado mude. + +### Auto-Sincronização em Mudanças de Status + +Quando **Push All Issues** ou a configuração de nível de sistema **Finding Jira Sync** está habilitada, o DefectDojo atualizará automaticamente as Issues do Jira vinculadas quando determinadas ações forem realizadas nos Achados: + +* **Request Review** \- Um comentário é adicionado à Issue do Jira vinculada (ou à Issue do Jira do Finding Group, se o Achado pertencer a um grupo). +* **Clear Review** \- Um comentário é adicionado à Issue do Jira vinculada. +* **Close Finding** \- A Issue do Jira vinculada é atualizada para refletir o fechamento. Se **Push Notes** estiver habilitado, um comentário também é adicionado. + +## Comentários e Notas do Jira + +Quando **Push Notes** está habilitado nas Jira Project Settings: + +* Se um comentário for adicionado a uma Issue do Jira, o mesmo comentário será adicionado ao Achado, na seção **Notes**. +* Da mesma forma, se uma Nota for adicionada a um Achado, a Nota será adicionada à issue do Jira como um comentário. + +## Mudanças de Status no Jira + +A configuração da Jira Instance tem entradas para duas Jira Transitions que acionarão uma mudança de status em um Achado. + +* Quando a **'Close' Transition** é executada no Jira, o Achado associado também será fechado, e ficará marcado como **Inactive** e **Mitigated** no DefectDojo. O DefectDojo registrará essa mudança na página do Achado, no campo **Mitigated By**. +​ +![image](images/Creating_Issues_in_Jira_3.png) + +* Quando a **'Reopen' Transition** é executada na Issue do Jira, o Achado associado será definido como **Active** no DefectDojo, e perderá seu status de **Mitigated**. + +## Mapeando Resoluções do Jira para Aceitação de Risco / Falso Positivo + +A configuração da Jira Instance inclui dois campos opcionais que permitem mapear uma **Resolution** do Jira para um status de Achado no DefectDojo: + +* **Risk Accepted Finding Mapping Resolution** — quando uma issue do Jira é fechada com essa Resolution, o Achado vinculado se torna Risco Aceito no DefectDojo. +* **False Positive Finding Mapping Resolution** — quando uma issue do Jira é fechada com essa Resolution, o Achado vinculado se torna Falso Positivo no DefectDojo. + +### Status vs Resolution: um Ponto Comum de Confusão + +Esses campos mapeiam a **Resolution** do Jira, não o **Status** do Jira. Status e Resolution são dois conceitos independentes no Jira: Status descreve em que ponto do fluxo de trabalho a issue está (Open, In Progress, Done), enquanto Resolution descreve como ela foi resolvida (Fixed, Won't Do, Duplicate, False Positive, etc.). + +### Pré-requisito: uma pós-função "Set issue resolution" na transição do fluxo de trabalho do Jira + +O motor de fluxo de trabalho do Jira não preenche o campo Resolution automaticamente. Cada transição que deve fechar uma issue com uma Resolution específica precisa de uma pós-função **Set issue resolution** configurada na própria transição. Sem essa pós-função, a issue passa para o novo Status, mas a Resolution permanece em branco, e o mapeamento do DefectDojo não tem com o que fazer a correspondência. + +Um administrador do Jira pode adicionar essa pós-função em **Project Settings → Workflows → (edit workflow) → (selecione a transição de fechamento) → Post Functions → Add post function → Set issue resolution**. + +# Custom Fields no Jira + +Atualmente, o DefectDojo não oferece suporte para passar informações específicas de uma Issue para esses Custom Fields \- esses campos precisarão ser atualizados manualmente no Jira depois que a issue for criada. Cada Custom Field só será criado a partir do DefectDojo com um valor padrão. + + O Jira Cloud agora permite criar um valor padrão de Custom Field diretamente no aplicativo. [Consulte a documentação da Atlassian sobre Custom Fields](https://support.atlassian.com/jira-cloud-administration/docs/configure-a-custom-field/) para mais informações sobre como configurar isso. + +Os Jira Issue Types integrados ao DefectDojo (**Bug, Task, Story** e **Epic)** são configurados para funcionar 'prontos para uso'. Os campos de dados no DefectDojo serão mapeados automaticamente para os campos correspondentes no Jira. Por padrão, o DefectDojo atribuirá Priority, Labels e um Reporter a qualquer nova Issue que criar. + +Algumas configurações do Jira exigem que campos personalizados adicionais sejam levados em conta antes que uma issue possa ser criada. Este processo permitirá que você contemple esses custom fields na sua integração DefectDojo \-\> Jira, garantindo que as issues sejam criadas com sucesso. Esses custom fields serão adicionados a todas as chamadas de API enviadas do DefectDojo para uma instância do Jira vinculada. + +Se você ainda não usa Custom Fields no Jira, não há necessidade de seguir este processo. + +1. Registrar os nomes dos seus Custom Fields no Jira (**Jira UI**) +2. Determinar os valores de Key para os novos Custom Fields (Jira Field Spec Endpoint) +3. Localizar os dados aceitáveis para cada Custom Field, usando os valores de Key como referência (Jira Issue Endpoint) +4. Criar um bloco JSON de referência de campos para rastrear todas as Keys dos Custom Fields e os dados aceitáveis (Jira Issue Endpoint) +5. Armazenar o bloco JSON no Product do DefectDojo associado, para permitir que os Custom Fields sejam criados a partir do Jira (DefectDojo UI) +6. Testar seu trabalho e garantir que todos os dados obrigatórios estejam fluindo corretamente a partir do Jira + +#### Etapa 1: Registre os nomes dos seus Custom Fields no Jira + +O Jira oferece suporte a uma variedade de Context Fields diferentes, incluindo Date Pickers, Custom Labels, Radio Buttons. Cada um desses Context Fields terá um valor de Key diferente, que pode ser encontrado na API do Jira. + +Anote os nomes de cada Custom Field necessário, pois você precisará pesquisar na API do Jira para encontrá-los na próxima etapa. + +**Exemplo de uma lista de Custom Fields (os nomes dos seus Custom Fields serão diferentes):** + +* DefectDojo Custom URL Field +* Outro exemplo de Custom Field +* ... + +#### Etapa 2: Encontrando os Valores de Key dos seus Jira Custom Fields + +Comece este processo navegando até a URL de Field Spec da sua instância inteira do Jira. + +Aqui está um exemplo de uma URL de Field Spec: + +`https://yourcompany-example.atlassian.net/rest/api/2/field` + +A API retornará uma longa string de JSON, que deve ser formatada em texto legível (usando um editor de código, uma extensão de navegador ou ). + +O JSON retornado por essa URL conterá todos os seus custom fields do Jira, a maioria dos quais é irrelevante para o DefectDojo e tem valores `"Null"`. Cada objeto nessa resposta da API corresponde a um campo diferente no Jira. Você precisará procurar os objetos cujos atributos `"name"` correspondam aos nomes de cada Custom Field que você criou na Jira UI, e então anotar o valor do atributo "key" deles. + +![image](images/Using_Custom_Fields.png) + +Depois de encontrar o objeto correspondente na saída JSON, você pode determinar o valor de "key" \- neste caso, é `customfield_10050`. + +O Jira gera valores de key diferentes para cada Custom Field, mas esses valores de key não mudam depois de criados. Se você criar outro Custom Field no futuro, ele terá um novo valor de key. + +**Expandindo nossa lista de Custom Fields:** + +* "DefectDojo Custom URL Field" \= customfield\_10050 +* "Outro exemplo de Custom Field" \= customfield\_12345 +* ... + +#### Etapa 3 \- Encontrando os Custom Fields em uma Jira Issue + +Localize uma Issue no Jira que contenha os Custom Fields que você registrou na Etapa 2\. Copie a Issue Key do título (deve se parecer com "`EXAMPLE-123`") e navegue até a seguinte URL: + +`https://yourcompany-example.atlassian.net/rest/api/2/issue/EXAMPLE-123` + +Isso retornará outra string de JSON. + +Como antes, a saída da API conterá muitos parâmetros de objeto `customfield_##` com valores `null` \- esses são custom fields que o Jira adiciona por padrão, que não são relevantes para essa issue. Ela também conterá valores `customfield_##` que correspondem aos valores de Key dos Custom Fields que você encontrou na etapa anterior. Diferente da saída do Field Spec, você não verá nomes identificando nenhum desses custom fields, e é por isso que você precisou registrar os valores de key na Etapa 2\. + +![image](images/Using_Custom_Fields_2.png) + +**Exemplo:** +Sabemos que `customfield_10050` representa o DefectDojo Custom URL Field porque o registramos na Etapa 2\. Agora podemos ver que `customfield_10050` contém o valor `"https://google.com"` na issue `EXAMPLE-123`. + +#### Etapa 4 \- Criando uma Referência de Campos JSON a partir de cada Jira Custom Field Key + +Agora você precisará pegar o valor de cada um dos Custom Fields da sua lista e armazená-los em um objeto JSON (para usar como referência). Você pode ignorar quaisquer Custom Fields que não correspondam à sua lista. + +Esse objeto JSON conterá todos os valores padrão para novas Issues do Jira. Recomendamos usar nomes que sejam fáceis para sua equipe reconhecer como valores 'padrão' que precisam ser alterados: '`change-me.com`', '`Change this paragraph.`' etc. + +**Exemplo:** + +Da etapa 3, agora sabemos que o Jira espera uma string de URL para "`customfield_10050`". Podemos usar isso para construir nosso objeto JSON de exemplo. + +Digamos que também tivéssemos localizado um campo de texto curto relacionado ao DefectDojo, que identificamos como "`customfield_67890`". Nós observaríamos esse campo na nossa segunda saída de API, veríamos o valor associado, e referenciaríamos o valor armazenado no nosso objeto JSON de exemplo também. +​ +Seu objeto JSON começará a ficar assim, à medida que você adiciona mais Custom Fields a ele. + +``` +{ + "customfield_10050": "https://change-me.com", + "customfield_67890": "This is the short text custom field." +} +``` + +Repita esse processo até que todos os custom fields relevantes do DefectDojo no Jira tenham sido adicionados à sua Referência de Campos JSON. + +#### Tipos de Dados e Sintaxe do Jira + +Alguns campos, como campos de Date, podem estar relacionados a múltiplos custom fields no Jira. Se for esse o caso, você precisará adicionar ambos os campos à sua Referência de Campos JSON. + +``` + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", +``` + +Outros campos, como o campo Label, podem ser rastreados como uma lista de strings \- certifique-se de que sua Referência de Campos JSON use um formato que corresponda à saída da API do Jira. + +``` +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], +``` + +Outros custom fields podem conter informações contextuais adicionais que devem ser removidas da Referência de Campos. Por exemplo, o Custom Multichoice Field contém um bloco extra na saída da API, que você precisará remover, pois esse bloco armazena o valor atual do campo. + +* você deve remover o objeto extra deste campo: + +``` +"customfield_10047": [ + { + "value": "A" + }, + { + "self": "example.url...", + "value": "C", + "id": "example ID" + } +] +``` +* em vez disso, você pode reduzir isso para o seguinte e desconsiderar a segunda parte: + +``` +"customfield_10047": [ + { + "value": "A" + } +] +``` + +#### Exemplo de Referência de Campos Completa + +Aqui está uma Referência de Campos JSON completa, com comentários inline explicando a que cada custom field se refere. Isso serve como um exemplo abrangente. Seu JSON conterá valores de key e dados diferentes, dependendo dos Custom Values que você deseja usar durante a criação da issue. + +``` +{ + "customfield_10050": "https://change-me.com", + + "customfield_10049": "This is a short text custom field", + +// two different fields, but both correspond to the same custom date attribute + "customfield_10040": "1970-01-01", + "customfield_10041": "1970-01-01T03:30:00.000+0200", + +// a list of custom labels on a Jira object + "customfield_10042": [ + "custom-label-one", + "this-is-default", + "change-me-please" + ], + +// custom number field + "customfield_10043": 0, + +// custom paragraph field + "customfield_10044": "This is a very long winded way to say CHANGE ME PLEASE", + +// custom radio button field + "customfield_10045": { + "value": "radio button option" + }, + +// custom multichoice field + "customfield_10047": [ + { + "value": "A" + } + ], + +// custom checkbox field + "customfield_10039": [ + { + "value": "A" + } + ], + +// custom select list (singlechoice) field + "customfield_10048": { + "value": "1" + } +} +``` + +#### Etapa 5 \- Adicionando os Custom Fields a um Product do DefectDojo + +Agora você pode adicionar esses custom fields ao Product associado no DefectDojo, na página Jira Project Settings (acessível pelo menu ⚙️ Engrenagem no Product). Cole a Referência de Campos JSON como texto simples na caixa **Custom Fields** e salve. + +#### Etapa 6 \- Testando seus Jira Custom Fields a partir de um novo Achado: + +Agora, quando você criar um novo Achado no Product associado ao Jira, o Jira criará automaticamente todos esses Custom Fields de acordo com o bloco JSON contido nele. Esses Custom Fields serão criados com os valores padrão ("change\-me\-please", etc.). + +Dentro do Product no DefectDojo, navegue até a página Findings \> Add New Finding. Certifique-se de que o Achado esteja Active e Verified para garantir que ele seja enviado ao Jira, e então confirme, no lado do Jira, que os Custom Fields foram criados com sucesso, sem inconsistências. diff --git a/docs/content/connectors/downstream/_index.pt-br.md b/docs/content/connectors/downstream/_index.pt-br.md new file mode 100644 index 0000000000..0a27d08391 --- /dev/null +++ b/docs/content/connectors/downstream/_index.pt-br.md @@ -0,0 +1,19 @@ +--- +title: Conectores Downstream +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: +- /pt-br/issue_tracking/pro_integration/ +--- diff --git a/docs/content/connectors/downstream/about.pt-br.md b/docs/content/connectors/downstream/about.pt-br.md new file mode 100644 index 0000000000..fc003a9e19 --- /dev/null +++ b/docs/content/connectors/downstream/about.pt-br.md @@ -0,0 +1,135 @@ +--- +title: Conectores Downstream +weight: 1 +audience: pro +aliases: +- /pt-br/en/share_your_findings/integrations +- /pt-br/issue_tracking/pro_integration/integrations/ +--- + +**Disponibilidade:** os Conectores Downstream estão disponíveis de forma geral e ativados em todas as instâncias do DefectDojo Pro, tanto Cloud quanto On-Premise. Não há nada para habilitar, e eles não estão mais listados na página de Feature Flags. + +Os Conectores Downstream permitem enviar seus Achados e Grupos de Achados para sistemas de rastreamento de tickets, integrando facilmente a remediação de segurança ao fluxo de trabalho de desenvolvimento já existente da sua equipe. + +Conectores Downstream suportados: +- Azure Devops +- Bitbucket +- Freshservice +- GitHub +- GitLab Boards +- Jira +- Linear +- Opsgenie +- PagerDuty +- ServiceDesk Plus +- ServiceNow +- ServiceNow SecOps / Vulnerability Response +- Shortcut +- Zendesk + +## Abrindo a página de Conectores Downstream + +A página de Conectores Downstream pode ser encontrada em **Import > Connectors > Downstream Connectors** na barra lateral. + +![image](images/integrators_3.png) + +## Configurando um Conector Downstream + +Um Conector Downstream é configurado com três componentes principais: + +- **Instância de Integração**: este é o método de conexão principal que o DefectDojo usará com um sistema de terceiros. A Instância incluirá detalhes como um rótulo, localização e credenciais de conexão, além de qualquer outra informação que possa ser exigida pelo fornecedor. +- **Mapeamento do Issue Tracker**: é aqui que as informações de mapeamento são armazenadas, definindo os detalhes necessários para se conectar a um determinado "projeto" no fornecedor. Esses detalhes incluem o nome ou ID do "projeto", e os mapeamentos entre a severidade e o status dos Achados do DefectDojo e o campo correspondente no "ticket" do fornecedor. Você pode ter vários mapeamentos configurados se estiver tentando enviar Achados para vários locais de "projeto". +- **Atribuição do Issue Tracker**: é aqui que Produtos e Engajamentos do DefectDojo são atribuídos a um determinado Mapeamento do Issue Tracker, com opções por Produto/Engajamento para definir como um Achado será enviado a um determinado sistema do fornecedor. + +Esses componentes são hierárquicos: cada **Instância** tem um ou mais **Mapeamentos**, que por sua vez têm uma ou mais **Atribuições de Tracker**. + +![image](images/integrators_2.png) + +## Enviando Achados e Grupos de Achados + +Depois que esses componentes estiverem configurados, Achados e Grupos de Achados podem ser enviados a um determinado Issue Tracker de duas formas: manualmente ou automaticamente. + +- **Manualmente**: Achados e Grupos de Achados contidos em um Produto/Engajamento com um **Mapeamento do Issue Tracker** atribuído terão a opção "Enviar para o Integrador". Isso criará um Issue no Issue Tracker com as informações correspondentes do Achado/Grupo de Achados. "Enviar para o Integrador" também pode ser usado para atualizar um Issue existente. + +### Envio automático de Achados + +Achados também podem ser enviados automaticamente, com a **Atribuição do Issue Tracker** determinando como esses objetos serão enviados. Estas são as quatro opções: + +- **Publicar Alterações no Destino Apenas Explicitamente**: esta opção desativa qualquer comportamento automático no Produto ou Engajamento atribuído. A única forma de enviar um Achado ou Grupo de Achados será explicitamente, conforme mencionado acima. +- **Vincular Automaticamente Novo Achado ao Destino**: quando novos Achados ou Grupos de Achados são **criados** no Produto ou Engajamento atribuído, o DefectDojo enviará automaticamente o objeto para o Issue Tracker. Uma vez criados, esses Achados ou Grupos de Achados não serão atualizados sem uma ação manual de Enviar para o Integrador. +- **Atualizar Automaticamente Vínculo Existente ao Editar o Achado**: quando Achados ou Grupos de Achados são **atualizados** no Produto ou Engajamento atribuído, o objeto é enviado automaticamente para o Issue Tracker caso um vínculo existente já tenha sido criado manualmente. +- **Vincular Novo e Atualizar Vínculo Existente Automaticamente ao Editar o Achado**: quando Achados ou Grupos de Achados são criados **ou** atualizados no Produto ou Engajamento atribuído, o objeto é enviado automaticamente para o Issue Tracker. + +#### Filtros de Envio + +Cada Atribuição do Issue Tracker pode, opcionalmente, restringir quais Achados são enviados **automaticamente**: + +- **Severidade Mínima**: cria tickets automaticamente apenas para Achados com severidade igual ou superior à selecionada. Deixe em branco para incluir todas as severidades. +- **Apenas Achados Ativos**: cria tickets automaticamente apenas para Achados ativos, ignorando aqueles que já estão Mitigado, Falso positivo ou Risco aceito no momento em que a atribuição os identifica pela primeira vez. + +Esses filtros se aplicam apenas à **criação** automática. Atualizações em um Achado que já possui um ticket vinculado são sempre enviadas, portanto mudanças de status (incluindo fechamentos) continuam sendo propagadas. Um "Enviar para o Integrador" manual sempre ignora os filtros. Deixar ambos com os valores padrão preserva o comportamento original de enviar todos os Achados. + +#### Atribuindo vários Produtos + +Uma Atribuição do Issue Tracker tem como alvo um único Produto ou Engajamento. Para cobrir vários ativos, crie uma Atribuição por Produto (ou Engajamento). Se você também precisar que os campos do fornecedor sejam diferentes por ativo — por exemplo, um **Assignment group** ou **Assigned to** distinto no ServiceNow, ou um projeto diferente no Jira — crie um Mapeamento do Issue Tracker separado (com seus próprios Mapeamentos de Campos Personalizados) para cada ativo e aponte cada Atribuição para o Mapeamento correspondente. + +## Representação do Ticket no Issue Tracker + +Os Tickets do Issue Tracker são representados por uma série de ícones na coluna "Integrator Tickets" ao visualizar e listar +Achados e Grupos de Achados + +Ícones da esquerda para a direita: + +- **Tipo de Integração**: o tipo de Issue Tracker ao qual o Ticket está associado +- **ID do Ticket**: o ID do Ticket, conforme definido pelo Issue Tracker +- **Link do Ticket**: o link direto para o Ticket, conforme definido pelo Issue Tracker +- **Changelog**: especifica quando o Ticket do Issue Tracker foi associado a um Achado ou Grupo de Achados, além da última vez que o DefectDojo fez uma alteração no ticket + +![image](images/integrators_1.png) + +## Requisitos Específicos do Fornecedor + +Cada fornecedor terá requisitos variados quanto à forma como o DefectDojo precisará interagir com ele. Isso pode ser na forma de um mecanismo de autenticação, campos adicionais por "projeto", ou mapeamentos de severidade/status. + +Para a lista completa de requisitos, abra as páginas específicas de cada fornecedor abaixo: + +- [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) + +## Tratamento de Erros e Depuração + +Conectores Downstream podem produzir erros por diversos motivos, como conectividade, autenticação, permissões etc. Para ajudar na depuração desses erros, cada Mapeamento do Issue Tracker possui uma tabela de erros que lista quando o erro ocorreu, o motivo pelo qual ocorreu, e o Achado ou Grupo de Achados que falhou ao ser enviado. + +Esses erros podem ser encontrados na página All Issue Tracker Mappings & Assignments, na coluna ⚠️ Total Errors. + +![image](images/integrators_4.png) + +Clicar na entrada Total Errors leva você a uma página com descrições mais detalhadas dos erros associados a este Conector Downstream. + +### Ver todas as falhas em um só lugar + +A tabela de erros por mapeamento cobre um único Conector Downstream. O [Diagnósticos](/admin/diagnostics/pro__diagnostics/) cobre todos eles, além de todas as outras tentativas de integração na instância — conectores upstream, importações, Jira, SSO e o motor de regras — com os mesmos recursos de filtragem e ordenação sobre tudo isso. + +Use-o quando a pergunta for mais ampla do que um único mapeamento: + +* uma tentativa que **nunca foi concluída** em vez de falhar, o que nenhuma tabela de erros reporta, porque nada gerou erro +* se uma falha é específica de uma integração ou está ocorrendo em várias ao mesmo tempo +* quem ou o que disparou uma tentativa, e contra qual configuração + +Credenciais citadas em um erro são removidas antes que a linha seja armazenada, e o detalhe técnico completo é restrito a superusuários. + +## Layout da página de Conectores Downstream + +Os Conectores Downstream são listados em duas seções, **Configured Connectors** e **Available Connectors**, cada uma ordenada alfabeticamente com uma contagem do que é exibido ao lado do seu título. Uma ferramenta pode ter várias configurações; cada uma é seu próprio bloco, intitulado ` -