VPN 사용자 이름은 로그 파이프라인의 어디에서 사라지는가?

세션이 대시보드에 표시되는데 사용자 이름 열은 비어 있고, 첫 번째 반응은 파서를 탓하는 것입니다. 그 반응은 값이 사라졌을 수 있는 세 가지 이전 단계를 건너뜁니다. 게이트웨이는 정책에 따라 식별자를 마스킹할 수 있고, 수집 규칙은 색인 전에 그것을 삭제할 수 있으며, 검색 시점의 추출은 단순히 이름을 붙이지 못할 수 있습니다. 수정은 어느 경계가 책임이 있다고 증명할 수 있는지에 달려 있으므로 유용한 작업은 구성이 아니라 비교입니다.

대시보드가 아니라 하나의 이벤트에서 시작하십시오

인증 이벤트 하나를 골라 그것을 식별하는 항목, 즉 게이트웨이 모델과 릴리스, 인증 방식, 이벤트 식별자, 타임스탬프, 출발지 주소를 적으십시오. 대소문자를 구분하는 조회가 실제로 존재하는 필드를 숨길 수 있으므로 사용자 이름은 본인이 입력한 그대로 대소문자까지 포함해 추가하십시오. 그 이벤트를 이후 모든 비교의 기준으로 삼으십시오.

이벤트 유형은 같은 스키마를 공유하지 않습니다. 실패한 시도, 클라이언트 없는 성공적인 로그인, 터널 재연결은 각각 다른 필드를 만들 수 있고, 일부 게이트웨이는 시도가 사용자 인증에 도달하지 않았을 때 식별자를 생략합니다. 따라서 한 이벤트 유형에서 열이 비어 있다는 것은 파이프라인 문제의 약한 증거입니다.

실제 직원 계정 대신 승인된 테스트 식별자로 작업하고, 비교는 로그 데이터에 이미 적용되는 접근 규칙 안에서 유지하십시오. 표본을 얻기 위해 상세 인증 로깅을 광범위하게 켜면 측정하려는 시스템 자체가 바뀝니다.

네 경계를 순서대로 비교하십시오

값은 네 지점 중 하나에서 사라질 수 있습니다. 지점마다 담당자도 수정 방법도 다릅니다.

값이 사라지는 첫 번째 경계에서 멈추십시오. 장치 보기와 원본 사본의 불일치는 전송이나 수집기 구성을 가리키고, 그곳이 일치하는데 색인된 이벤트에 값이 없으면 변환을 가리키며, 색인된 이벤트에 값이 있는데 대시보드에 없으면 추출이나 쿼리를 가리킵니다.

이 순서가 중요한 이유는 이후 단계는 정보를 잃을 수만 있고 결코 복원할 수 없기 때문입니다. 정규식은 이전 단계가 자리 표시자로 바꾼 문자열을 되살릴 수 없고, 개인정보 설정은 전송되지 않은 값을 설명할 수 없습니다.

원본에서의 마스킹은 정책이지 파서 버그가 아닙니다

Cisco의 ASA 로깅 문서는 사용자 이름 숨기기를 구성 가능한 동작으로 설명하며, 유효하지 않거나 알 수 없는 사용자 이름이 어떻게 표현되는지도 포함합니다. 따라서 원본 이벤트의 마스킹된 식별자는 개인정보 정책이 요구하는 바로 그 결과일 수 있으며, 이를 구문 분석 실패로 취급하면 제어를 약화시키는 요청으로 이어집니다.

정확한 표현은 릴리스와 메시지 유형에 따라 다릅니다. 어떤 이벤트는 자리 표시자를 담고, 다른 이벤트는 필드를 완전히 생략하며, 인증 실패에는 이름이 전혀 없을 수도 있습니다. 과거 버그 보고서를 모든 누락된 식별자에 적용하지 말고 해당 이벤트에 문서화된 동작을 확인하십시오.

마스킹이 의도된 것이라면 질문은 필드를 어떻게 복원할지에서 감사 요구를 다른 방식으로 충족할 수 있는지로 바뀝니다. 세션 식별자, 더 작은 그룹이 보유한 통제된 식별자 매핑, 더 좁은 범위의 승인된 이벤트 피드는 시도된 모든 사용자 이름을 모든 로그 판독자 앞에 두지 않고도 요구를 충족하는 경우가 많습니다.

색인 전 익명화는 되돌릴 수 없습니다

Splunk의 이벤트 처리 문서는 색인 전에 데이터를 다시 쓰거나 제거하는 sed 식과 변환을 통한 익명화를 설명합니다. 바로 그 위치가 핵심이며, 원본 이벤트는 들어오는 과정에서 변경되므로 검색 시점의 추출에는 찾을 것이 남지 않습니다.

색인 시점의 삭제와 검색 시점의 필드 추출은 서로 다른 문제를 해결합니다. 삭제는 누가 값을 볼 수 있는지를 제한하고, 추출은 쿼리가 어떤 이름을 쓰는지만 결정합니다. 해싱은 상관관계를 보존하는 중간 선택이지만, 작은 사용자 이름 공간에 대한 안정적인 해시는 누군가 후보 이름을 대조할 수 있을 때 여전히 식별 가능합니다.

저장된 이벤트에 아직 식별자가 있다면 문제는 하류, 즉 소스 유형, 줄 바꿈, 구분자 처리, 필드 별칭, 또는 쿼리 자체에 있습니다. 이것들은 일반적인 구문 분석 수정이며 개인정보 경계를 건드리지 않습니다.

경계에 맞는 수정을 선택하십시오

세 가지 조건이 대응을 결정합니다. 첫째, 개인정보 정책이 식별자를 제외하려는 것입니까? 둘째, 감사나 조사 절차에 식별자, 가명, 아니면 세션만 필요한 것입니까? 셋째, 값이 수집, 저장, 표시 중 어느 경계에서 필요한 것입니까?

정책이 제외를 의도한다면 제어가 아니라 요구 사항이나 표시 방식을 바꾸십시오. 정책이 식별자를 허용하는데 수집이 그것을 떨어뜨린다면 수집기를 고치고 원본 이벤트를 확인하십시오. 저장이 온전하다면 추출을 고치고 처음에 확보한 승인된 이벤트에 대해 검증하십시오.

변경 기록에 원본에서 마스킹되었는지, 수집 중에 제거되었는지, 추출에서 누락되었는지를 명시하여 조사를 마무리하십시오. 그 한 문장이 다음 엔지니어에게 어디를 먼저 볼지 알려 주고, 대시보드 불만이 조용히 비활성화된 개인정보 기능으로 바뀌는 것을 막습니다.