인증된 메시지에도 여전히 사기성 요청이 포함될 수 있습니다. 그 진술은 그렇지 않습니다 SPF, DKIM 또는 DMARC 중요하지 않습니다. 그것은 그들의 경계를 정의합니다.
이메일 인증은 도메인 ID 및 메시지 처리에 대한 증거를 제공합니다. 비즈니스 승인은 다른 질문에 답합니다. 이 사람 또는 시스템이 이 요청을 할 자격이 있었고 조직은 이에 따라 조치를 취해야 합니까? 안전한 프로세스에는 두 가지 모두가 필요합니다.
패스가 실제로 무엇을 증명하는지 물어보세요
아래에 RFC 9989 §5.3.5 그리고 RFC 9989 §5.4, 메시지 수준 DMARC 패스는 수신자가 인증된 도메인이 보낸 사람의 도메인과 일치하는 통과 SPF 또는 DKIM 경로를 하나 이상 찾았음을 의미합니다. 다음 사항을 증명하지 않습니다.
- 계정을 관리하는 개인은 누구입니까?
- 계정이 손상되지 않았는지 확인합니다.
- 송장이나 은행 변경이 합법적이라는 것,
- 링크나 첨부 파일은 무해합니다.
- 도메인은 수신자가 염두에 둔 브랜드입니다.
정확한 설명이 유용합니다. 메시지는 보낸 사람 도메인을 표시하고 해당 도메인과 관련된 적격 인증 증거를 생성했습니다. 보낸 사람이나 메시지가 안전하다는 광범위한 주장으로 변환하지 마세요.
대응을 선택하기 전에 신원 도용을 분류하세요.
받은 편지함에서는 다양한 공격이 유사해 보일 수 있지만 인증 경계의 서로 다른 측면에 있을 수 있습니다.
- 패턴: 정확한 도메인 위조; 인증이 표시할 수 있는 내용: 정렬된 통과 경로가 없으며 수신자 증거 및 처리에 따라 달라질 수 있습니다. 제어 및 대응 초점: DMARC 정책, 발신자 범위, 수신자 제어 및 조사
- 무늬: 유사 도메인; 인증이 표시할 수 있는 내용: 유사 도메인은 자신의 도메인을 성공적으로 인증할 수 있습니다. 제어 및 대응 초점: 도메인 모니터링, 사용자 신호, 필터링, 보고 및 비례적인 남용 조치
- 패턴: 표시 이름 속임수; 인증이 표시할 수 있는 내용: 관련 없는 도메인은 친숙한 이름을 제시하면서 인증할 수 있습니다. 제어 및 대응 초점: 표시 이름 분석, 컨텍스트, 사용자 보고 및 독립적 검증
- 패턴: 손상된 승인된 계정; 인증이 표시할 수 있는 내용: 실제 도메인은 인증을 통과할 수 있습니다. 통제 및 대응 초점: 계정 보안, 세션 및 로그인 조사, 봉쇄 및 비즈니스 검증
- 패턴: 손상된 공급업체; 인증 내용: 공급자의 실제 도메인이 통과할 수 있습니다. 통제 및 대응 초점: 공급업체 사고 조정, 거래 통제 및 대체 채널 확인
DMARC 해당 도메인 ID의 무단 사용에 대해 가장 강력합니다. 시각적으로 유사한 도메인의 소유권을 생성하거나 표시 이름의 진실성을 확인하거나 실제 계정이 적절한 권한으로 사용되었는지 여부를 결정하지 않습니다.
가상의 결제 변경 사건을 따라가세요
다음 시나리오는 합성입니다. 고객 사건을 암시하지 않고 증거 체인을 보여주도록 설계되었습니다.
재무 직원이 다음으로부터 요청을 받습니다. accounts@supplier.example 은행 정보 변경을 요청합니다. 적용 가능한 정책을 가정하면 신뢰할 수 있는 수신자 결과에 다음에 대해 정렬된 DKIM 패스가 표시됩니다. supplier.example이므로 메시지는 DMARC 통과합니다. 스레드 이력과 글쓰기 스타일도 친숙해 보입니다.
직원은 이러한 신호를 기반으로 변경 사항을 승인하지 않습니다. 그들은 이전에 확인된 공급업체 번호로 전화를 걸어 사서함이 손상되었음을 알게 됩니다. 조직은 요청된 변경 사항을 동결하고 원본 메시지를 보존하며 공급업체에 타임스탬프와 관련 헤더를 제공합니다.
인증은 설계된 대로 작동했습니다. 즉, 메시지가 공급자의 인증된 도메인을 사용했음을 보여주었습니다. 독립적인 검증 제어는 도메인 인증이 판단할 수 없는 무단 거래를 중지했습니다.
프로토콜 증거 및 비즈니스 증거 보존
결과적인 사고의 경우 수정된 사본을 만들기 전에 접근이 통제된 원본 메시지를 보관하세요. RFC 8601 §7.1 신뢰할 수 있는 결과 경계를 정의합니다. 서명된 자료를 편집하면 재인증에 영향을 미칠 수 있습니다. RFC 6376 §3.7. 유용한 기술적 증거에는 신뢰할 수 있는 기술이 포함될 수 있습니다. Authentication-Results, 관련 수신 필드, 보낸 사람, 회신, Return-Path, DKIM 서명, 메시지 식별자, 타임스탬프 및 수신 로그.
유용한 비즈니스 증거에는 요청, 의도된 조치, 설정된 승인 규칙, 확인에 사용된 연락 방법 및 결과가 포함됩니다. 사실과 추론을 분리하세요. 원시 패스는 손상의 증거가 아니며 DMARC 실패는 피해가 발생했다는 증거가 아닙니다.
아래에 RFC 9990 §3.1, 집계된 DMARC 보고서는 도메인 소유자가 관찰된 인증 및 처리 패턴을 이해하는 데 도움이 될 수 있습니다. 이는 개별 메시지의 완전한 기록이 아니며 일반적으로 특정 요청이 승인되었는지 여부를 결정하는 데 필요한 콘텐츠를 제공하지 않습니다. 아래에 RFC 9989 §5.3.9, 실패 보고서, 생성된 경우 신중한 개인 정보 보호 및 액세스 처리가 필요하며 보편적으로 사용할 수 없습니다.
민감한 워크플로에 독립적인 검증 구축
큰 영향을 미치는 작업은 수신 메시지에만 의존하지 않는 컨트롤을 사용해야 합니다. 예는 다음과 같습니다:
- 이전에 승인된 채널을 통해 은행 세부정보 변경 사항을 확인합니다.
- 정의된 한도를 초과하는 지급에 대해 이중 승인을 요구합니다.
- 이메일 스레드가 요청과 확인 연락처를 모두 제공하는 것을 방지합니다.
- 민감한 데이터 교환을 위해 인증된 포털을 사용합니다.
- 긴급한 비밀, 비정상적인 시기 또는 통제 우회를 위험 신호로 간주합니다.
이는 인증을 대체하는 것이 아닌 비즈니스 제어입니다. 인증은 도메인 사용에 대한 모호성을 줄이는 반면, 트랜잭션 제어는 인증되었지만 승인되지 않은 요청의 결과를 줄여줍니다.
프로그램을 약화시키지 않고 경계를 전달
DMARC 매번 멈추지 않는다고 말하면서 피싱 기술이 정확해요. 그러므로 효과가 없다고 말하는 것은 아닙니다. 시행된 정책은 보호된 도메인의 무단 사용 성공을 줄이고, 수신자 증거를 향상시키며, 합법적인 전송 경로의 소유권을 명시적으로 만들 수 있습니다.
올바른 메시지는 계층화되어 있습니다. 도메인을 보호하고, 계정을 보호하고, 유사 항목과 사기성 표현을 탐지하고, 민감한 작업을 독립적으로 확인합니다. 사용 DMARC 신원 가이드 도메인 수준 결과와 발송인 인벤토리 승인된 서비스 소유권을 위해.
증거 내에서 결론을 유지하라
가상의 결제 변경 사례는 두 가지 독립적인 결과를 유지합니다. 도메인 인증 통과; 제안된 거래는 별도 검증 후 승인되지 않았습니다. 패스만으로 손상을 보고하지 마세요. 승인된 사고 공개만 유지하고 수신 요청 외부에 신뢰할 수 있는 확인 연락처를 유지하세요. 공급업체에 연락하지 않았으며 거래나 사고 대응도 수행되지 않았습니다.