실험실

개요

다른 로그프레소 소나 인스턴스의 티켓을 이 인스턴스로 복제하는 기능입니다. 지사·고객사·망분리 구간에 흩어진 소나의 티켓을 본사 인스턴스 한 곳에서 모아 보는 용도로 사용합니다.

복제 대상은 티켓만이 아닙니다. 티켓이 근거로 삼은 탐지 이벤트와 원본 로그까지 함께 가져오므로, 복제된 티켓을 열어 "무엇을 보고 이 티켓이 생겼는지"를 그대로 확인할 수 있습니다.

시작하기 전에

양쪽 인스턴스에 실험실 앱을 설치하는 것을 권장합니다. 수집하는 쪽에만 설치해도 동작하지만, 원격에도 설치되어 있으면 변경된 티켓만 골라내는 전용 조회 명령어를 쓸 수 있어 원격 부하가 크게 줄어듭니다. 원격에 앱이 없으면 자동으로 호환 모드로 내려가며, 그때는 메모가 제한적으로만 복제됩니다(아래 "조회 방식" 참고).

원격 인스턴스에 연동 전용 계정을 하나 만들고 다음을 확인하세요.

• 다단계 인증(MFA)이 비활성이어야 합니다. 로그인 과정에 추가 단계가 있으면 접속하지 못합니다.
• 클러스터 관리자여야 합니다. 전용 조회 명령어가 클러스터 관리자 권한을 요구합니다. 일반 관리자 권한으로는 부족하며, 권한이 모자라면 진단 화면에 REMOTE_PERMISSION으로 표시됩니다.
• 탐지 시나리오 조회 권한(실시간 탐지 시나리오 조회 / 배치 탐지 시나리오 조회)이 있으면 좋습니다. 근거 이벤트를 제대로 표시하는 데 사용되고, 복제 티켓에 MITRE ATT&CK 정보를 표시하는 데에도 쓰입니다(아래 "복제 전용 탐지 시나리오" 참고).

1단계 — 접속 프로파일 만들기

설정 > 접속 프로파일에서 유형이 로그프레소 소나인 프로파일을 만듭니다.

저장 전에 연결 테스트로 접속과 로그인이 되는지 확인하세요.

2단계 — 매핑 만들기

실험실 > 티켓 동기화에서 추가를 누르면 오른쪽에 설정 패널이 열립니다. 위에서부터 차례로 고르면 되고, 앞 단계를 정해야 다음 단계가 채워집니다.

1. 로그프레소 소나 접속 프로파일 — 1단계에서 만든 프로파일을 고릅니다.
2. 원격 티켓 분류 — 원격 인스턴스의 티켓 분류 목록이 표시됩니다. 고르면 그 분류의 최근 티켓 20건이 미리보기로 나옵니다. 저장하기 전에 의도한 분류가 맞는지 여기서 확인하세요.
3. 로컬 티켓 분류 — 복제된 티켓이 쌓일 이 인스턴스의 분류입니다.
4. 수집 주기 — 기본 5초입니다.
5. 수집 대기 — 기본 0초. 아래 참고.
6. 동기화 대상 — 분류 안에서 어떤 티켓만 가져올지 좁힙니다. 비워 두면 전부 가져옵니다. 아래 참고.
7. 동기화 항목 — 항목별로 무엇을 어디까지 따라갈지 정합니다. 아래 참고.
8. 동기화 활성화 — 켠 상태로 저장하면 바로 수집이 시작됩니다.

기존 매핑을 수정할 때 접속 프로파일과 원격 티켓 분류는 바꿀 수 없습니다. 이미 수집 중인 동기화를 말없이 다른 대상으로 돌리지 않기 위해서입니다. 대상을 바꾸려면 매핑을 지우고 새로 만드세요. 동기화 대상 조건은 언제든 바꿀 수 있습니다.

수집 대기

마지막 변경 후 이만큼 지난 티켓만 가져옵니다. 기본값은 0초이고, 설정 화면은 60초를 권장값으로 안내합니다.

사람이 티켓 하나를 정리하는 동안 보통 여러 번 저장이 일어납니다. 대기가 없으면 폴링이 그 중간에 내려앉아 미완성 상태를 복제했다가 다음 회차에 다시 고칩니다. 원격이 근거 이벤트를 저장소에 올리기 전에 티켓만 먼저 가져가는 것도 막아 줍니다.

반영까지 걸리는 시간은 수집 주기 + 수집 대기가 됩니다. 호환 모드(msgbus)에서는 적용되지 않습니다.

동기화 대상

원격 분류 전체가 필요한 경우는 많지 않습니다. 실제로 보고 싶은 것은 "저쪽에서 누가 태그를 단 것만", "아직 안 닫힌 것만", "오탐으로 판정되지 않은 것만" 쪽입니다. 다섯 가지 조건으로 좁힐 수 있습니다.

비워 둔 조건은 제한하지 않습니다. 서로 다른 조건은 모두 만족해야 하고(AND), 한 조건 안에서 체크한 값끼리는 하나만 맞으면 됩니다(OR). 예를 들어 공격 여부에 정탐·미분류를 체크하고 종료 여부에 미종료를 체크하면 "오탐으로 판정되지 않았고 아직 열려 있는 티켓"이 됩니다.

미분류는 아무도 아직 판단하지 않은 상태입니다. 갓 올라온 티켓이 여기에 해당하므로, 이것만 체크하면 "아직 아무도 손대지 않은 것만 가져오기"가 됩니다.

알아 둘 것

• 태그는 대상을 고르는 데만 씁니다. 복제된 티켓에는 태그가 붙지 않습니다. 태그는 티켓 분류에 매이지 않은 회사 전역 객체라, 복제하면 이 동기화와 무관한 화면까지 원격 태그로 채워집니다.
• 조건을 벗어난 티켓은 지우지 않습니다. 이미 복제된 티켓이 원격에서 조건 밖으로 바뀌면 갱신만 멈추고 로컬 사본은 그대로 남습니다.
• 판정은 이 인스턴스에서 합니다. 조건을 원격 쿼리에 실어 보내지 않으므로 원격 버전과 무관하게 동작하고, 원격에 실험실 앱이 없어도 다섯 조건이 모두 적용됩니다.
• 거른 티켓도 수집 기준점은 지나갑니다. 조건에 맞는 티켓이 한동안 없어도 조회 구간이 계속 넓어지지 않습니다. 거른 건수는 수집 로그의 회차 요약에 filtered로 남습니다.
• 원격에서 태그를 뒤늦게 붙이면 바로 반영되지 않을 수 있습니다. 태그만 추가하는 것은 티켓의 변경 시각을 움직이지 않아 증분 조회에 걸리지 않습니다. 초기화로 수집 시점을 그 티켓의 변경 시각 이전으로 되돌리면 들어옵니다.
• 호환 모드(msgbus)에서 태그 조건을 쓰면 티켓마다 상세 조회가 한 번씩 더 붙습니다. 목록 응답에 태그가 없을 수 있어 확인이 필요하기 때문입니다. 태그 외의 조건만 쓰면 추가 비용은 없습니다.

동기화 항목

원격을 그대로 따라가는 것이 늘 옳지는 않습니다. 복제된 티켓을 여기서 분석가가 재분류하거나 종료했다면, 다음 회차에 원격 값이 되돌아오면 곤란합니다. 그래서 항목마다 세 가지 중에서 고릅니다.

제목과 본문·중요도·종료 여부·건수와 이벤트 시각은 최초 복제에서 뺄 수 없습니다. 티켓을 만드는 데 반드시 필요한 값이라 가져오지 않음이 제시되지 않습니다.

"원본 이벤트"는 "근거 이벤트"에 의존합니다. 근거 이벤트를 끄면 원본도 복제되지 않습니다. 원본만 켜는 조합은 의미가 없습니다. 저장소 부담을 줄이려면 원본 이벤트만 끄세요.

현재 근거 이벤트·원본 이벤트·메모에서는 최초 1회만과 계속 동기화가 같게 동작합니다. 구분이 필요하면 가져오지 않음만 의미가 있습니다.

목록 화면 읽기

마지막 두 열은 서로 다른 질문에 답합니다. 앞은 "언제 돌았나", 뒤는 "어디까지 가져왔나"입니다. 원격이 조용하면 앞은 계속 갱신되지만 뒤는 멈춰 있습니다. 둘 다 과거에 멈춰 있으면 수집 자체가 동작하지 않는 것이니 상태 인디케이터를 확인하세요.

분류 이름에 마우스를 올리면 GUID가 툴팁으로 보이고, 옆의 복사 버튼으로 클립보드에 담을 수 있습니다.

행 동작

각 행 오른쪽에 세 가지 동작이 있습니다.

재동기화와 삭제는 확인 창을 띄웁니다. 확인 창에는 대상 매핑의 접속 프로파일·원격 티켓 분류·로컬 티켓 분류가 함께 표시되므로, 비슷한 매핑이 여러 개일 때 잘못 누르는 것을 막을 수 있습니다.

상태 인디케이터

수집기 목록과 같은 규칙입니다.

오류일 때만 클릭할 수 있습니다. 진단 대화상자에는 오류 분류·상세 메시지·발생 시각·마지막 성공 시각·동기화 기준점·조회 방식·마지막 시나리오 재동기화 결과가 표시되고, 분류별 권장 조치가 함께 나옵니다. 여기서 지금 동기화로 즉시 재시도하거나 초기화로 수집 시점을 바꿀 수 있습니다.

수집 시점 초기화

과거 티켓을 가져오는 유일한 방법이고, 수집이 멈춰 있을 때 되살리는 방법이기도 합니다. 목록의 초기화 버튼 또는 진단 대화상자에서 엽니다.

달력에서 시작할 시점을 고르면 다음 회차부터 그 시점을 기준으로 수집하고, 오류와 마지막 동기화 기록, 조회 방식을 지웁니다. 미래 시각은 지정할 수 없습니다.

• 진행 중이던 회차는 중단됩니다. 그대로 두면 옛 기준으로 끝나면서 방금 지정한 시점을 덮어쓰기 때문입니다.

• 시점을 멀리 잡을수록 그 다음 회차가 길어집니다. 몇 달 전으로 되돌리면 첫 회차에 시간이 걸리고, 그동안 해당 매핑의 다음 회차는 시작되지 않습니다.

동기화 대상 조건을 넓힌 뒤에는 초기화가 효과가 있습니다. 그동안 걸러지던 티켓은 로컬에 복제된 적이 없으므로, 수집 시점을 되돌리면 새 티켓으로 들어옵니다.

탐지 시나리오 재동기화

자리표시자 탐지 시나리오는 처음 만들어질 때 원격 정보를 한 번 읽고 그대로 고정됩니다. 원격에서 시나리오 이름을 바꾸거나 중요도를 조정해도 이쪽에는 최초 문구가 남습니다. 이것을 맞추는 유일한 방법이 목록의 시나리오 재동기화 버튼입니다.

프로파일 단위로 동작합니다. 자리표시자는 접속 프로파일을 공유하므로, 한 매핑에서 실행하면 같은 프로파일의 자리표시자가 모두 갱신됩니다.

갱신되는 것

• 시나리오 이름, 설명, 메시지, 중요도
• 원본 탐지 쿼리(실시간은 비고란, 배치는 쿼리 주석)
• MITRE ATT&CK 테크닉과 전술

갱신되지 않는 것

• 활성 여부 — 자리표시자는 계속 비활성입니다
• 동작 쿼리·스키마·티켓 분류 — 자리표시자가 탐지를 수행하게 되거나, 근거 권한이 정해진 분류에서 움직이면 안 됩니다
• 이미 복제된 티켓의 시나리오 참조 — 시나리오 번호가 그대로이므로 바꿀 이유가 없습니다
• 삭제된 탐지 시나리오 — 재동기화는 지워진 시나리오를 되살리지 않습니다

결과는 진단 대화상자의 "시나리오 재동기화" 항목에서 확인합니다. 갱신된 건수와 함께, 원격에서 읽지 못한 건수(원격에서 이미 삭제되었거나 권한이 없는 경우)와 이쪽에서 삭제된 건수가 구분되어 표시됩니다.

무엇이 복제되는가

복제되는 것

• 티켓 본문 — 제목, 내용, 형식, 중요도, 상태, 공격 여부, 사고 여부, 건수, 발생·이벤트 시각, 출처 정보, 생성·변경 시각
• 상태 전이 — 원격에서 종료하면 로컬도 종료되고, 재오픈하면 로컬도 재오픈됩니다
• 근거 이벤트와 원본 로그 — 건수 제한이 없습니다
• 탐지 시나리오 참조 — 복제 티켓이 어느 탐지 시나리오에서 생겼는지 화면에 표시됩니다. 티켓을 처음 복제하는 순간에만 기록합니다(아래 "복제 전용 탐지 시나리오" 참고)
• MITRE ATT&CK 정보 — 복제 티켓에 어떤 테크닉에 해당하는지 표시됩니다. 티켓이 아니라 자리표시자 탐지 시나리오에 복제됩니다(아래 참고)
• 메모 — 아래 "메모 복제" 참고
• GUID — 원격과 같은 GUID로 복제됩니다. 두 인스턴스가 같은 티켓을 같은 식별자로 가리킵니다

복제되지 않는 것

메모 복제

메모는 티켓과 별개의 기준점으로 수집합니다. 메모를 달아도 티켓의 변경 시각은 움직이지 않기 때문에, 티켓 기준으로만 보면 영원히 잡히지 않습니다.

• 작성자는 옮길 수 없습니다. 복제된 메모의 작성자는 연동 계정이고, 원본 작성자는 본문 앞에 [이름] 형태로 표기됩니다.
• 원격에서 메모를 수정하면 복제본도 따라 수정됩니다. 삭제는 따라가지 않습니다.
• 복제된 티켓의 메모만 들어옵니다. 아직 복제되지 않은 티켓에 달린 메모는 붙일 곳이 없어 건너뜁니다. 그 메모까지 필요하면 티켓이 복제될 만큼 수집 시점을 과거로 되돌리세요. 동기화 대상 조건에서 걸러진 티켓의 메모도 같은 이유로 들어오지 않습니다.
• 호환 모드(msgbus)에서는 티켓이 다른 이유로 변경될 때 딸려오는 메모만 들어옵니다.

복제 전용 탐지 시나리오

동기화를 시작하면 탐지 시나리오 목록에 비활성 탐지 시나리오가 자동으로 생성됩니다. 이름은 원본 시나리오 이름 (접속 프로파일 이름) 형태입니다. 실시간 탐지 시나리오와 배치 탐지 시나리오 모두 만들어집니다.

이것은 복제된 근거 이벤트를 화면에 보이게 하기 위한 자리표시자입니다. 소나는 이벤트를 조회할 때 "그 이벤트를 만든 탐지 시나리오를 볼 권한이 있는가"를 함께 검사하는데, 복제된 이벤트가 달고 온 원격 시나리오 번호는 이 인스턴스에 존재하지 않아 그대로 두면 아무에게도 보이지 않습니다.

복제된 티켓도 이 탐지 시나리오를 가리킵니다. 티켓 화면에서 "무엇이 탐지했는지"를 확인할 수 있고, 거기서 자리표시자 시나리오로 이동하면 원본 탐지 쿼리를 읽을 수 있습니다.

• 항상 비활성입니다. 탐지를 수행하지 않고, 쿼리도 동작하지 않습니다.
• 매핑의 로컬 티켓 분류에 묶입니다. 그 분류를 볼 수 있는 사람만 근거 이벤트를 볼 수 있다는 뜻이고, 티켓 권한과 근거 권한이 어긋나지 않습니다.
• 원본 탐지 쿼리는 주석 형태로 보존됩니다. 복제된 티켓을 조사할 때 원격에서 어떤 로직이 탐지했는지 읽을 수 있습니다. 실시간 탐지 시나리오는 원본이 비고란에, 배치 탐지 시나리오는 쿼리 주석에 들어갑니다.
• 같은 시나리오에서 올라온 티켓이 여러 개여도 자리표시자는 하나만 만들어집니다.
• 여기에 담긴 정보는 생성 시점에 고정되며, "시나리오 재동기화" 로만 갱신됩니다.

MITRE ATT&CK 정보

복제 티켓이 어떤 공격 기법에 해당하는지는 티켓이 아니라 탐지 시나리오에 붙습니다. 소나는 티켓 화면에서 테크닉을 보여줄 때 그 티켓이 가리키는 시나리오의 매핑을 읽기 때문입니다. 그래서 자리표시자 시나리오에 원격 시나리오의 테크닉과 전술을 함께 복제합니다.

• 시나리오 하나에 매핑이 들어가면 그 시나리오의 복제 티켓 전부에 한꺼번에 표시됩니다. 티켓마다 따로 처리하지 않습니다.
• 양쪽 인스턴스의 ATT&CK 데이터 버전이 달라 이쪽에 없는 테크닉이 섞여 있으면, 그 항목만 빠지고 나머지는 정상적으로 표시됩니다. 빠진 항목은 수집 로그에 남습니다.
• 이 기능이 들어오기 전에 만들어진 자리표시자에는 매핑이 없습니다. 시나리오 재동기화를 한 번 실행하면 채워집니다.
• 원격에서 시나리오를 읽을 수 없으면(삭제되었거나 연동 계정에 시나리오 조회 권한이 없는 경우) 매핑도 가져올 수 없습니다.

자리표시자를 지웠을 때

자리표시자 탐지 시나리오를 삭제해도 동기화는 멈추지 않고, 이미 복제된 근거 이벤트도 계속 보입니다. 소나의 시나리오 삭제는 표시만 지우는 방식이고, 근거 조회의 허용 목록에는 삭제된 시나리오도 포함되기 때문입니다.

이후 같은 원격 시나리오의 티켓이 들어오면 새 자리표시자를 만들지 않고 지워진 것을 그대로 재사용합니다. 새로 만들면 같은 원격 시나리오의 복제분이 두 시나리오로 갈라지는데, 이미 적재된 이벤트는 나중에 고칠 수 없어 되돌릴 방법이 없기 때문입니다.

티켓의 시나리오 참조에 대해 알아 둘 것

• 티켓을 처음 복제하는 순간에만 기록합니다. 이미 복제된 티켓이 원격에서 갱신되어도 탐지 시나리오 참조는 다시 쓰지 않습니다. 여기서 사람이 바꾼 내용을 폴링이 매번 덮어쓰지 않기 위해서입니다.
• 이 기능이 들어오기 전에 복제된 티켓은 탐지 시나리오 참조가 비어 있고, 초기화로도 채워지지 않습니다. 그 티켓들의 근거는 그대로 보입니다 — 근거가 보이는지는 이벤트 쪽 탐지 시나리오 번호가 결정하는 것이지 티켓의 시나리오 참조와는 무관합니다.
• 탐지 시나리오 교환으로 같은 탐지 시나리오가 양쪽에 배포되어 있으면, 복제 티켓이 자리표시자가 아니라 이 인스턴스에서 실제로 운영 중인 그 시나리오에 붙습니다. 그 탐지 시나리오의 티켓 집계와 MITRE 표시에 복제분이 섞이게 되며, 로그에 경고로 남습니다. 근거 이벤트가 이미 그 탐지 시나리오 번호로 적재되어 있기 때문에 연결을 끊으면 근거가 보이지 않게 되므로, 그대로 두는 것이 맞습니다. 이 경우 재동기화도 그 시나리오를 건드리지 않습니다 — 운영 중인 시나리오의 이름과 매핑을 복제본이 덮어쓰면 안 됩니다.
• 원격에서 탐지 시나리오를 읽을 수 없어도(삭제되었거나 연동 계정에 시나리오 조회 권한이 없는 경우) 티켓이 들고 온 탐지 시나리오 이름으로 자리표시자를 만듭니다. 이름이 부실해지는 대신 근거는 보입니다.

자동 생성되는 인덱스

앱을 설치하면 기동할 때 코어 테이블 두 곳에 인덱스를 만듭니다. 매핑이 하나도 없어도 생성됩니다.

코어 티켓 테이블에는 updated_at 인덱스가 없어, 이 인덱스가 없으면 증분 조회 비용이 변경 건수가 아니라 해당 분류의 전체 티켓 수에 비례합니다. 5초 주기로 치르기에는 큰 비용입니다.

이 인덱스가 필요한 쪽은 티켓을 읽히는 인스턴스(원격)인데, 그쪽에는 매핑이 없습니다. 그래서 매핑 유무를 보지 않고 생성합니다.

동작은 이렇습니다.

• 같은 역할의 인덱스가 이미 있으면 건너뜁니다. 이름이 아니라 repo_id가 첫 번째, updated_at이 두 번째인 인덱스가 있는지를 봅니다. 코어가 나중에 같은 인덱스를 다른 이름으로 추가해도 중복이 생기지 않습니다.
• 전용 백그라운드 스레드에서 만듭니다. 티켓이 수백만 건이면 수 분이 걸릴 수 있지만 동기화가 그 뒤에 줄 서지 않고, InnoDB가 온라인으로 추가하므로 그동안에도 인스턴스는 정상 동작합니다.
• 실패해도 동기화는 그대로 돕니다. 계정에 DDL 권한이 없으면 경고 한 줄만 남습니다. 속도만 잃고 정확성은 잃지 않습니다.

생성 여부는 로그에서 확인할 수 있습니다.

experimental: creating index IX_sonar_tickets_repo_id_updated on sonar_tickets, this may take a while on a large ticket table
experimental: created index IX_sonar_tickets_repo_id_updated in 1234 ms
experimental: cannot create index IX_sonar_tickets_repo_id_updated on sonar_tickets, incremental ticket queries will scan the repository: ...

직접 확인하려면:

SHOW INDEX FROM sonar_tickets        WHERE Key_name = 'IX_sonar_tickets_repo_id_updated';
SHOW INDEX FROM sonar_ticket_comments WHERE Key_name = 'IX_sonar_ticket_comments_repo_id_updated';

조회 방식

진단 대화상자의 "조회 방식" 항목에 둘 중 하나가 표시됩니다.

호환 모드에서는 세 가지가 제한됩니다. 수집 대기가 적용되지 않고, 메모가 티켓 변경에 딸려올 때만 들어오며, 태그 조건을 쓰면 티켓마다 상세 조회가 한 번씩 더 붙습니다. 동기화 대상 조건 자체는 양쪽 모드에서 똑같이 동작합니다.

원격에 앱을 설치하면 다음 회차부터 자동으로 query로 올라갑니다. 즉시 바꾸려면 초기화하세요.

문제 해결

진단 대화상자의 오류 분류를 먼저 보세요.

시나리오 재동기화의 실패는 여기에 표시되지 않습니다. 수집 회차가 실패한 것이 아니기 때문에 동기화 상태를 오류로 바꾸지 않고, 결과는 진단 대화상자의 "시나리오 재동기화" 항목에만 남습니다.

티켓은 들어오는데 근거자료가 비어 있을 때

가장 흔한 원인은 복제 전용 탐지 시나리오가 만들어지지 않은 것입니다. 이 경우 이벤트는 저장소에 정상적으로 적재되어 있는데 조회에서만 걸러지므로, 오류도 로그도 남지 않습니다.

순서대로 확인하세요.

1. 진단 대화상자에 오류가 있는지 먼저 봅니다. 근거 적재 자체가 실패하면 그 회차 전체가 실패로 기록됩니다.
2. 탐지 시나리오 목록에 원본 이름 (프로파일 이름) 형태의 비활성 탐지 시나리오가 있는지 확인합니다. 하나도 없으면 그 매핑의 근거는 전부 보이지 않는 상태입니다.
3. 연동 계정에 탐지 시나리오 조회 권한이 있는지 확인합니다. 권한이 없으면 자리표시자를 제대로 만들지 못합니다.
4. 동기화 항목에서 "건수와 이벤트 시각"이 최초 1회만으로 되어 있지 않은지 확인합니다 (위 경고 참고).
5. 원격에서 해당 이벤트가 아직 보존 기간 안에 있는지 확인합니다. 이미 삭제된 이벤트는 가져올 수 없습니다.

복제 티켓에 MITRE 정보가 보이지 않을 때

1. 이 기능이 들어오기 전에 만들어진 자리표시자이면 매핑이 비어 있습니다. 시나리오 재동기화를 한 번 실행하세요.
2. 원격 탐지 시나리오에 애초에 MITRE 매핑이 없으면 가져올 것이 없습니다. 원격에서 먼저 확인하세요.
3. 연동 계정에 탐지 시나리오 조회 권한이 있는지 확인합니다. 시나리오를 읽지 못하면 매핑도 가져오지 못합니다.
4. 일부 테크닉만 보인다면 양쪽 ATT&CK 데이터 버전이 다른 경우입니다. 이쪽에 없는 테크닉은 표시되지 않습니다.
5. 코어가 4.0.2404.0 미만이면 이 기능이 동작하지 않습니다.

원격에서 시나리오 이름을 바꿨는데 반영되지 않을 때

자리표시자는 생성 시점 정보로 고정되어 있습니다. 시나리오 재동기화 를 실행하세요. 초기화로는 갱신되지 않습니다.

근거자료가 회차마다 일부만 들어올 때

원격이 이중화되어 있고 접속 프로파일이 VIP를 가리키는 경우입니다. 티켓은 두 노드가 공유하는 데이터베이스에서 오지만 근거 이벤트는 각 노드의 로그 저장소에서 오기 때문에, 회차마다 응답하는 노드가 달라지면 그 노드가 가진 만큼만 복제됩니다.

프로파일 주소를 노드 하나로 고정하세요. 양쪽 노드의 근거가 모두 필요하면 노드마다 접속 프로파일을 따로 만들어 매핑을 두고 같은 로컬 분류로 모으면 됩니다.

특정 티켓이 들어오지 않을 때

1. 동기화 대상 조건을 먼저 확인하세요. 조건에 하나라도 걸리지 않으면 가져오지 않습니다. 수집 로그의 회차 요약에 filtered 건수가 보이면 조건이 걸러내고 있다는 뜻입니다.
2. 수집 기준은 티켓의 변경 시각입니다. 생성 시각이 아닙니다. 원격에서 오래전에 만들어졌지만 최근에 갱신된 티켓은 들어오고, 반대로 "마지막 티켓 시각"보다 변경 시각이 이른 티켓은 들어오지 않습니다. 필요하면 초기화로 기준점을 그 티켓의 변경 시각 이전으로 되돌리세요.
3. 원격에서 태그만 추가한 티켓은 변경 시각이 움직이지 않아 증분 조회에 걸리지 않습니다. 초기화가 필요합니다.

티켓이 들어왔는데 시나리오 참조가 비어 있을 때

• 이 기능이 들어오기 전에 복제된 티켓이면 비어 있는 것이 정상이고, 초기화로도 채워지지 않습니다. 근거 이벤트는 영향을 받지 않습니다.
• 원격 티켓이 애초에 탐지 시나리오를 지목하지 않는 경우(수동으로 만든 티켓 등)에도 비어 있습니다.
• 그 외에는 "티켓은 들어오는데 근거자료가 비어 있을 때"와 같은 순서로 확인하세요. 자리표시자를 만들지 못하면 시나리오 참조도 비게 됩니다.

제약사항

• 연동 계정은 다단계 인증을 사용할 수 없고, 원격의 클러스터 관리자여야 합니다.
• HTTP 프록시를 경유한 접속은 지원하지 않습니다. 수집 측에서 원격 인스턴스로 직접 연결할 수 있어야 합니다.
• 티켓 삭제와 메모 삭제는 동기화되지 않습니다.
• 담당자·결재자·첨부파일·태그는 복제되지 않습니다.
• 탐지 시나리오 참조는 티켓을 처음 복제할 때만 기록되며, 기존 복제 티켓에는 소급되지 않습니다.
• 탐지 시나리오 정보(이름·중요도·원본 쿼리·MITRE 매핑)는 자동으로 갱신되지 않습니다. 시나리오 재동기화로만 맞춥니다.
• 재동기화는 이쪽에서 삭제한 자리표시자를 되살리지 않습니다.
• MITRE ATT&CK 정보 복제는 코어 4.0.2404.0 이상에서 동작합니다.
• 매핑을 삭제해도 이미 복제된 티켓과 이벤트는 남습니다.
• 같은 접속 프로파일로 같은 원격 분류를 두 번 등록할 수 없습니다. 두 수집기가 같은 티켓을 쓰게 되기 때문입니다. 프로파일이 다르거나 원격 분류가 다르면 추가할 수 있고, 여러 매핑이 한 로컬 분류로 모이는 것도 허용됩니다.
• 동기화 대상 조건은 수집 단계에서만 적용됩니다. 조건을 좁혀도 이미 복제된 티켓은 지워지지 않습니다.
• 앱을 설치하면 티켓 테이블과 메모 테이블에 조회용 인덱스가 자동으로 생성됩니다 (위 "자동 생성되는 인덱스").