보안 탐지 결과와 증거¶
보안 탐지 결과은 민감한 호출에 국한된 모델링된 소스의 데이터 흐름 관찰 또는 후보 코드 위험을 기록하며 취약성, 악의적인 의도 또는 성공적인 악용을 확인하지 않습니다. 다음 동작은 게시된 Java, Node.js 및 Python 버전을 기반으로 하며 PHP 또는 .NET에 동일한 분석 기능이 있다는 의미는 아닙니다. 게시된 .NET 범위는 .NET Security를 참조하세요.
게시된 버전 및 이벤트 형식¶
| 언어 | 최초로 요청별 로깅 및 공격 증거 지원 | 스키마 v2를 처음 사용하는 경우 | 이 가이드에 사용된 버전 |
|---|---|---|---|
| Java | 1.3.0 | 1.3.3 | 1.3.4 |
| Node.js | 1.3.0 | 2.0.0 | 2.0.1 |
| Python | 1.2.0 | 1.2.3 | 1.2.4 |
레코드를 해석하기 전에 schema_version를 읽으십시오. 이벤트 이름은 여전히 beacon.security.finding이고 지문 버전은 여전히 1입니다. 스키마를 공유한다고 해서 런타임 적용 범위가 동일하다는 의미는 아닙니다. 이전 프로덕션 엔드포인트에는 선택적 요청 레코드, 샘플링 또는 공격 증거 필드가 누락될 수 있습니다. 누락된 필드가 no_evidence와 같지 않습니다.
코드 위험, 증거 요청 및 악용 결과¶
스키마 v1에서 assessment=observation 또는 candidate_risk는 코드 위험을 설명하고, validation=unvalidated는 유효성이 검사되지 않았음을 의미하며, 선택 사항인 attack_evidence는 현재 요청을 설명합니다. 이 세 가지 차원은 별도로 해석되어야 합니다.
attack_evidence.status |
의미 |
|---|---|
unknown |
분석이 불가능하거나, 지원되지 않거나, 부정확하거나, 예산이 초과되거나, 필요한 경계 정책이 부족합니다. |
no_evidence |
지원되는 분석에서 공격 증거를 찾지 못했습니다. 안전함을 뜻하지 않으며 코드 위험도 해소하지 않습니다. |
suspected |
지원되는 분석은 가능한 악용의 증거를 찾아내지만 악의적인 의도나 성공적인 악용을 입증하지는 않습니다. |
attack_evidence.reason는 프로그램에서 읽을 수 있는 길이 제한 이유이며 원래 요청 값을 포함하지 않습니다. attack_evidence.outcome=not_assessed의 v1. Schema v2에서는 고정된 평가 및 검증 자리 표시자 필드와 고정된 결과 필드가 생략되었습니다. 생략이 사용이 확인되었음을 의미하지는 않습니다. 단순히 호출, 정상적인 반환 또는 특정 HTTP 상태를 관찰하는 것만으로는 공격 성공을 증명할 수 없습니다.
오염 범위가 정확하고 지원되는 ANSI SQL 분석이 활성화된 경우 다음 상황은 다른 의미를 갖습니다. 키워드별 공격 일치 규칙이 아닌 민감한 호출의 컨텍스트를 설명하는 예:
| 용도 | 해석 |
|---|---|
| 일반 입력은 동적 SQL의 따옴표로 묶인 값으로 연결됩니다. | 지원되는 분석이 no_evidence를 반환하는 경우에도 후보 코드 위험이 여전히 존재할 수 있습니다. |
| 개별적으로 바인딩된 매개변수 값이 있는 고정 SQL 템플릿 | 일반 바인딩 값에서는 SQL 템플릿 삽입 검색이 발생하지 않습니다. 명령문을 준비하기 전에 신뢰할 수 없는 템플릿을 작성하는 것은 또 다른 경우입니다. |
| 신뢰할 수 없는 입력 컨트롤은 SQL 구조 연산자 또는 주석 구분 기호를 지원합니다. | suspected가 반환될 수 있지만 데이터베이스가 악용을 실행했음을 증명하지는 않습니다. |
| 방언이 구성되지 않음, 구문이 지원되지 않음, 부정확한 오염 또는 분석 예산이 소진됨 | unknown를 유지하세요. 이에 따른 안전 주장은 없습니다. |
ANSI 스위치 및 분석 경계는 개별 언어 페이지에 제공됩니다. 위 버전은 네트워크 허용 목록이나 파일 시스템 루트 디렉터리 정책을 구현하지 않으며 이러한 경계 정책에 의존하는 공격 판단은 여전히 unknown입니다. 단순한 경로 정규화로는 경로를 안전하게 만들 수 없습니다.
하나의 발견, 많은 요청¶
finding_id는 안정적인 코드 위험 지문을 나타내고, occurrence_id는 발견 감지 요청을 식별합니다. Java 1.3.0 스키마 v1에서 이는 요청의 evidence_id와 동일합니다. 동일한 요청 내에서 동일한 지문을 반복적으로 감지하면 한 번만 계산됩니다. 더 강력한 증거는 동일한 ID로 요청 기록을 업데이트할 수 있습니다.
다음 Java 1.3.0 예에서는 집계가 가능하고 세 가지 요청이 동일한 전체 증거 샘플링 간격 내에 있다고 가정합니다. 테이블의 ID는 문자 그대로의 이벤트 페이로드가 아닌 도식 라벨입니다. 각 요청에는 현재 요청에 대한 자체 Trace/Span 컨텍스트가 있습니다.
| 묻다 | finding_id |
evidence_id = occurrence_id |
Trace / Span | 자세한 증거를 보관하세요 | occurrences_total |
|---|---|---|---|---|---|
| A | F | A1 | trace-A / span-A | 예, 첫 번째 샘플링 | 1 |
| B | F | B1 | trace-B / span-B | 아니요, 간격 샘플링 | 2 |
| C | F | C1 | trace-C / span-C | 아니요, 간격 샘플링 | 3 |
자세한 증거 샘플링은 요청 레코드 내보내기 및 OpenTelemetry Trace 샘플링과 별개입니다. B에 대한 자세한 증거는 샘플링되지 않았으나 B가 검출되지 않았다는 의미는 아니다. 추적 누락 또는 샘플링되지 않은 추적은 보안 탐지 결과을 방해하지 않습니다. 검색 시 추적 ID는 해당 링크가 백엔드에 도달했거나 여전히 보존된다는 것을 보장하지 않습니다.
동일한 요청 내의 증거 우선순위는 suspected > unknown > no_evidence입니다. 증거 에스컬레이션은 요청의 상태 수를 이동하지만 발생 횟수를 늘리지 않으며 일반적인 증거 샘플링 간격을 우회할 수 있습니다. 다양한 요청은 독립적으로 분류됩니다. 보통 → 의심됨 → 보통으로 분류되며 마지막 요청은 의심스러운 것으로 바뀌지 않습니다. 보유된 가장 강력한 대표적인 증거는 아마도 중간 요청에서 나온 것이고, last_trace_id는 최신 요청에서 나온 것입니다. v2는 로컬 진단 출력이 명시적으로 활성화된 경우에만 전체 대표 증거와 누적 로컬 개수를 유지합니다.
v1의 attack_evidence_counts는 집계 요청 수를 세 가지 상태로 나눕니다. 이는 확인된 공격 횟수가 아니라 증거 상태 횟수입니다. v2 온라인 로드에는 누적 발생 횟수가 없습니다. 소비자는 instance_id + occurrence_id별로 중복을 제거하고 finding_id별로 그룹화하며 동일한 발생의 업그레이드를 병합하며 각 업데이트는 새 요청으로 계산될 수 없습니다.
샘플링 및 마이그레이션¶
| 프로젝트 | Java 1.3.0–1.3.2 schema v1 | 위의 스키마 v2 버전 |
|---|---|---|
| 요청 레코드 식별자 | evidence_id 및 별칭 occurrence_id |
occurrence_id; evidence_id 제거 |
| 자세한 증거는 샘플링되지 않았습니다. | evidence_sampled=false, 필수 sources, propagation, ranges, stack 배열이 비어 있습니다. |
evidence_sampled=false; 빈 증거 배열이 생략되었습니다. |
| 샘플링 이유 | evidence_sample_reason, 세부사항 생략 시 truncated=true, truncation_reason=evidence_sampled_out 추가 |
evidence_sample_reason; 샘플링만 한다고 해서 잘림이 의미되는 것은 아닙니다. |
| 수집 한도 | 잘린 필드 설명 증거가 불완전합니다. | collection_complete는 관찰의 품질을 설명합니다. truncated=true는 실제 획득 또는 코드 잘림을 나타냅니다. |
| 중합 | aggregation_status=tracked일 때 프로세스 로컬 occurrences_total가 있습니다. capacity_exceeded인 경우 총 개수가 생략되고 제한된 요청 레코드 내보내기가 계속됩니다. |
온라인 합계 및 독립 요약, 상태, 손실 및 잘림 기록 이벤트를 제거합니다. 수신된 요청 기록의 백엔드 집계 |
비어 있거나 생략된 증거 배열은 오염이 없음을 증명하지 않습니다. v1 프로세스 로컬 개수는 클러스터 수준이나 영구 합계가 아닙니다. v2 레코드는 v1 이벤트 스키마에 대해 확인할 수 없습니다. 게시된 Java v1 참조 및 Java v2 참조를 참조하세요.
수출 정책 및 배송 제한¶
Java 1.3.4, Node.js 2.0.1 및 Python 1.2.4는 기본적으로 no_evidence 결과를 OpenTelemetry 로그 및 증거 JSONL로 내보내지 않습니다. 내보내기를 재개하려면 BEACON_SECURITY_EXPORT_NO_EVIDENCE_ENABLED=true를 설정하세요. unknown 및 suspected는 계속 내보낼 수 있으며 SBOM은 영향을 받지 않습니다. 필터링은 대기열에 참여하기 전에 발생하며 대기열이나 전송 할당량을 차지하지 않으며 내보내기 손실로 계산되지 않습니다. 내부 감지, 중복 제거 및 동일 요청 증거 업그레이드는 계속 수행됩니다. 이 스위치는 아직 Java 1.3.3에서는 사용할 수 없지만 1.3.4부터 사용할 수 있습니다. 위의 A/B/C v1 예는 이 수출 정책보다 우선합니다.
상세한 증거 샘플링을 수행하더라도 중복 결과로 인해 로그 볼륨이 계속 증가할 수 있습니다. 대기열, 메모리, 항목당 바이트 및 속도 예산에 제한이 있습니다. v1은 관찰 가능한 손실 횟수를 제공합니다. 일반 레코드가 맞지 않는 경우 최소 절단 봉투만 전송될 수 있으며, 이는 발생 또는 추적 필드를 반드시 보존하지 않습니다. v2에서는 이러한 독립적인 진단 이벤트를 제거하고 손실된 기록을 보상하기 위해 재생 이벤트를 생성하지 않습니다. 누락된 레코드는 정책 필터링, 수집 제한, 대기열 손실, 전송 실패 또는 보존 정책으로 인해 발생할 수 있습니다. 수신된 기록을 기반으로 한 수는 수신된 관찰만을 나타내며 완전한 인구 조사는 아닙니다. 요청 로깅이나 OpenTelemetry API 호출 모두 지속적인 전달이나 백엔드 승인을 보장하지 않습니다.