VPN 로그로 인터넷 기록을 보여줄 수 있을까? 증거가 증명하는 것
세션 로그, 리졸버 질의, 흐름 레코드는 각기 다른 것을 증명합니다. 질문을 고르고 신원과 시간을 연결한 뒤, 입증된 것만 말하십시오.
감사의 두 질문은 비슷하게 들리지만 필요한 증거의 종류가 다릅니다. 어느 세션이 이 주소에 접속했는지는 연결 및 흐름 레코드로 답할 수 있습니다. 어느 사람이 이 페이지를 열었는지는 보통 답할 수 없습니다. 적어도 그 레코드로는 아닙니다. 질문을 고르기 전에 수집기를 고르면 네트워크 팀은 호스트 이름을 인터넷 기록으로 제시하게 됩니다.
감사가 확립해야 할 사건부터 시작하십시오
질문을 주어, 동사, 시간이 있는 문장으로 쓰십시오. 그 규율만으로도 세션 레코드와 페이지 조회 사이의 간극 이 드러납니다. 세션 로그는 어떤 신원이 일정 구간 동안 기록된 정책에 따라 할당된 주소와 함께 수용되었음을 확립하지만, 요청을 한 번도 보지 못했으므로 누가 어느 페이지를 읽었는지는 확립할 수 없습니다.
수집을 설계하기 전에 관측에 이름을 붙이십시오. 방문한 사이트의 이름을 따르지만 실제로는 해석된 이름을 저장하는 필드는 편의가 아니라 미래의 오류입니다. 필드 이름은 그것을 고른 사람보다 오래 살아남으므로 결론이 아니라 증거를 서술하는 이름을 고르십시오.
각 레코드가 뒷받침할 수 있는 것과 없는 것
거의 모든 감사 설계에 네 가지 레코드 유형이 나타나며 각각 다른 질문에 답합니다. 보고서에서도 파이프라인에서도 이들을 분리하십시오. 그것들을 섞는 것이 바로 방어 가능한 발견을 난처하게 만드는 길입니다.
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
마지막 열을 가운데 열만큼 주의 깊게 읽으십시오. 흐름 레코드는 주소와 포트를 서술하고, 주소의 역방향 조회는 브라우저가 사용한 이름을 재구성하지 않습니다. 하나의 주소가 여러 무관한 사이트를 호스팅할 수 있기 때문입니다. 리졸버 질의는 질문이 있었다는 것을 증명할 뿐 페이지가 표시되었다는 것을 증명하지 않습니다. TLS 협상 중에 보이는 호스트 이름도 암호화된 요청 경로가 아닙니다.
이들 각각은 실제 관측이며, 어느 것도 사람들이 가정하는 관측이 아닙니다. 자체 암호화 리졸버를 고집하는 브라우저는 감시 범위 밖에 있고, 기록이 본 적 없는 것을 분석으로 되살릴 수 없습니다. 그 간극은 각주가 아니라 명시된 한계로 보고서에 속합니다.
선행 조회와 캐시된 응답
브라우저는 이름을 미리 해석하며, 때로는 아무것도 불러오지 않고 처리합니다. 또한 감시 중인 리졸버에 새 질의를 보내지 않고 캐시에서 응답하므로, 질의가 없다는 것이 방문이 없다는 뜻은 아닙니다. 두 행동 모두 DNS 로그와 인터넷 기록 사이의 순진한 등식을 깨뜨립니다.
HTTPS상의 DNS는 두 번째 경계를 더합니다. 자체 리졸버를 가진 브라우저나 게스트 앱은 조직의 기록 장치에 아무것도 묻지 않습니다. 정확한 트랜잭션은 앱 자체의 이벤트나 기록을 명시적으로 지원하는 프록시에서만 나옵니다. 평범한 HTTPS CONNECT 터널은 프록시에 내부의 페이지 경로를 전혀 보여주지 않습니다. 네트워크를 소유한다고 해서 앱의 신뢰 모델을 조용히 바꿀 권한이 생기지는 않습니다.
주소는 세션의 것이지 사람의 것이 아닙니다
터널 범위의 주소를 담은 흐름 레코드는 답이 아니라 출발점입니다. 그 주소와 시각을 그 순간 활성이던 세션 할당에 연결하십시오. 그 주소는 한 시간 뒤 다른 세션에 재할당될 수 있기 때문입니다. 정적 주소 지정은 그 연관을 유지하는 한 방법이며 유일한 방법은 아닙니다.
번역 단계가 센서 상류에서 여러 장치를 하나의 원본 주소로 압축할 때, 결합은 공유 게이트웨이 세션만 지목할 수 있습니다. 공유 계정이나 여러 사람이 쓰는 인증서는 네트워크 데이터가 아무리 완전해 보여도 귀속을 제한합니다. 둘 다 나중을 위한 단서가 아니라 한계로 보고서에 속합니다.
시간대, 시계 원천, 관측 지점, 그리고 그 사이의 모든 번역 경계를 기록하십시오. 부재는 존재만큼 배려를 받을 자격이 있습니다. 기록이 없다는 것은 흐름 항목이 만료되었거나, 센서가 패킷을 한 번도 보지 못했거나, 앱 로그가 꺼져 있었음을 뜻할 수 있습니다.
선언된 목적에 맞게 설계하고, 그다음 파이프라인을 입증하십시오
질문이 고정되면 어떤 필드가 필요한지, 누가 읽을 수 있는지, 얼마나 보관하는지를 정하십시오. 저장이 싸다고 더 모으는 것은 조사보다 오래 사는 책임을 만듭니다. RFC 6973 의 프라이버시 모델은 상관, 오귀속, 불필요한 수집을 사후 고려가 아니라 설계 문제로 규정합니다.
매핑과 레코드를 하나의 대상으로 보호하십시오. 각각은 단독으로 있을 때 쌍보다 훨씬 덜 민감합니다. 그다음 생성이 허용되고 이미 이해하는 활동에 대해, 보고서가 의존할 가장 작은 질의로 설계를 검증하십시오. 알려진 사건을 재현하지 못하는 파이프라인은 알려지지 않은 사건도 재현하지 못합니다. 증거가 뒷받침하는 사건을 증거가 허락하는 말로 보고하고, 더 큰 결론에 이르는 일은 읽는 이에게 맡기십시오.
발견 옆에 한계를 쓰십시오. 무엇을 결합했고, 무엇을 번역했고, 어느 로그가 침묵했는지. 자기 경계를 밝히는 발견은 자신감 있는 요약이 견디지 못하는 검토를 견딥니다. 그것이 증거와 증거에 관한 이야기의 차이입니다.