인바운드 메시지는 도메인 인증을 통과하면서도 수신자에게 위험한 작업을 수행하도록 요청할 수 있습니다. 합법적인 경로가 끊어져 인증에 실패할 수도 있습니다. 인증을 메시지의 측정된 속성 중 하나로 간주한 다음 수신 시스템의 다른 제어 및 조직의 비즈니스 확인 프로세스를 적용합니다. 이러한 단계를 축소하면 잘못된 확신과 불필요한 중단이 발생합니다.
세 가지 결정을 확인하세요.
첫 번째 결정은 기술적입니다. 인증된 식별자가 해당 항목의 작성자 도메인과 일치합니까? DMARC 규칙? 두 번째는 운영입니다. 이 수신 환경은 정책 및 기타 신호를 고려하여 메시지를 어떻게 처리해야 합니까? 세 번째는 특정 비즈니스에 관한 것입니다. 요청된 조치가 합법적이고 승인되었습니까? RFC 9989 도메인 기반 인증 및 정책을 정의합니다. 지나가는 메시지를 송장 지불 승인으로 바꾸지는 않습니다. DMARC 사양.
이러한 결정을 별도의 필드에 기록하십시오. 송장 변경 요청의 경우 인증 필드가 통과되고 처리 필드 격리가 검토 보류 중이며 비즈니스 필드가 확인되지 않을 수 있습니다. 해당 값은 호환됩니다. 수신자는 DMARC 외부 신호를 사용할 수 있으며 직원은 메일이 인증된 경우에도 독립적인 승인 워크플로를 따라야 합니다.
신뢰할 수 있는 경계의 결과 사용
안 Authentication-Results 헤더 출처를 이해할 때만 유용합니다. 공격자는 메시지에 헤더 텍스트를 삽입할 수 있습니다. 수신 조직은 신뢰할 수 있는 인증 서비스에서 생성된 결과를 신뢰할 수 없는 주장과 구별해야 합니다. RFC 8601 해당 신뢰 경계를 설명합니다. 인증 결과.
원시 메시지와 신뢰할 수 있는 수신 시스템의 로그를 보존합니다. 표시되는 보낸 사람 도메인과 확인된 각 도메인을 비교하세요. DKIM 서명 도메인 및 SPF 실제로 아이덴티티가 평가되었습니다. 표시 이름, 회신 필드 또는 전달된 스크린샷을 인증된 작성자 도메인으로 취급하지 마세요. 메시지가 전달된 경우 어떤 증거가 적용되는지 결정하기 전에 원래 평가 지점과 후속 변환을 기록하세요.
세 가지 합성 요청 비교
세 가지 가상의 결제 변경 메시지를 생각해 보세요. 첫 번째는 Brand.test를 요구하지만 통과 evil.test 서명만 있고 SPF 통과는 없습니다. 가정된 유일한 인증 식별자가 엄격하게 실패했습니다. 조정. 두 번째는 From 및 전달하는 DKIM ID 모두에서brand-pay.test를 사용하므로 유사성 문제에도 불구하고 모델링된 인증이 통과됩니다. 세 번째는 Brand.test를 일관되게 사용하고 통과하므로 계정 남용이나 무단 요청이 가능합니다.
각 사례에 대해 제안된 비즈니스 조치는 변경 사항을 유지하고 독립적으로 확인하는 것입니다. 이는 암호화 또는 수신자 결과가 아닌 발명된 인증 입력입니다. 서면 사례에서는 명시된 ID가 유일하게 사용 가능한 인증 식별자라고 가정하고 엄격한 정확한 도메인 일치를 격리하며 전체 DMARC 검색을 구현하지 않습니다. 메시지, 서명 또는 수신자 테스트가 실행되지 않았습니다. 인증 부울만으로는 비즈니스 조치를 계산할 수 없는 이유를 보여줍니다.
검토를 우회하지 않고 설계 처리
각 제어 경로에 대해 승인된 테스트 메시지를 선택하고 시스템이 해당 메시지를 거부, 격리, 전달 또는 나중에 교정할지 여부를 기록합니다. 공급업체의 기능 라벨은 구성된 동작의 증거가 아닙니다. 효과적인 결과를 변경할 수 있으므로 테스트에 예외를 포함하고 규칙을 허용합니다. 단순히 손상된 합법적인 경로를 통과시키기 위해 광범위한 허용 목록을 작성하지 마세요.
재정적 요청의 경우 이전에 설정된 연락 채널을 사용하십시오. FBI는 지불 요청 및 계좌 세부정보 변경 사항을 독립적으로 확인할 것을 권장합니다. 의심스러운 메시지에 소개된 연락처 정보를 독립적인 채널로 사용하지 마세요. FBI 비즈니스 이메일 침해 지침.
세 가지 결정, 각각의 증거 및 해결되지 않은 문제에 대한 검토를 마무리합니다. 이를 통해 재무 팀이 지불 보류를 유지하는 동안 메일 팀이 인증을 복구하거나, 보안 팀이 DMARC 결함이 있다고 주장하지 않고 통과했지만 의심스러운 메시지를 조사할 수 있습니다.
소스 및 실행 경계
RFC 9989 섹션 4.4, 5.3.5 및 5.4 인증, 정렬 및 처리를 구별합니다. 패스는 메시지 내용을 보증하지 않습니다. 여기서 운영 결정은 고객, 공급자 또는 과거 설비에 대한 새로운 테스트가 아닌 범위가 지정된 권장 사항과 명시적인 가상의 예입니다. 실제 변경에는 자체 승인된 범위, 보유된 증거 및 책임 있는 결정이 필요합니다.