DMARC 암호화는 다양한 이메일 위험을 해결합니다. DMARC 수신 시스템이 정렬되고 인증된 경로를 통해 도메인이 사용되고 있는지 여부를 평가하는 데 도움이 됩니다. 암호화는 전송 홉 전체에서 또는 메시지 끝점 간에 다른 설계로 메시지 데이터를 보호합니다. 어느 컨트롤도 다른 컨트롤을 자동으로 공급하지 않습니다.
동일한 메시지가 잘 인증되어 의도한 전송 보증 없이 계속 이동할 수 있기 때문에 이러한 구별이 중요합니다. 정렬된 인증이 없는 보낸 사람 도메인을 요청하는 동안 메시지는 암호화된 연결을 통해 이동할 수도 있습니다.
보호 질문부터 시작하세요
컨트롤을 선택하기 전에 무엇을 보호해야 하는지 물어보세요.
- 보호 질문: 전달된 인증 도메인이 보낸 사람의 도메인과 일치합니까? 관련 메커니즘: DMARC SPF 또는 DKIM; 확립되지 않은 것: 기밀성, 보낸 사람의 의도 또는 안전한 콘텐츠
- 보호 질문: d= 도메인에 대한 DKIM 개인 키 소유자가 메시지에 서명했습니까? 관련 메커니즘: DKIM ; 확립되지 않은 것: 인간의 신원, 비밀 또는 받은 편지함 배치
- 보호 질문: 허용되는 TLS 사용하려면 이 SMTP 배달 홉이 필요했습니까? 관련 메커니즘: MTA-STS 또는 다른 운송 정책; 확립되지 않은 것: 종단간 기밀성 또는 발신 도메인 조정
- 보호 질문: 수신자가 해당 수신자를 위해 의도된 콘텐츠를 해독할 수 있습니까? 관련 메커니즘: 메시지 수준 암호화; 설정하지 않는 것: 별도로 구성하지 않는 한 DMARC 정렬
이 매트릭스는 제품 순위가 아닌 제어 경계를 설명합니다. 위협은 상호 교환이 불가능하므로 완전한 아키텍처는 두 개 이상의 메커니즘을 사용할 수 있습니다.
하나의 합성 메시지 경로를 따르십시오.
직접 SMTP 전달을 통해 billing@shop.example.com 에서 accounts@buyer.example.org 로 전송된 가상 송장을 생각해 보세요. 발신 서비스는 bounce.mailer.example.net 의 봉투 도메인을 사용하고 d=shop.example.com. 적용 가능한 DMARC 정책을 가정하고 신원 확인을 완료합니다. 이 합성 시나리오에서는 전송이 MTA https://mta-sts.buyer.example.org/.well-known/mta-sts.txt에서 수신 도메인 buyer.example.org 에 대한 유효한 시행 모드 MTA-STS 정책을 검색하고 검색합니다 https://mta-sts.buyer.example.org/.well-known/mta-sts.txt. 선택한 대상인 mx1.buyer.example.org 가 정책과 일치하는지 확인한 다음 TLS 에 연결하고 협상하여 메시지를 전송하기 전에 MX 인증서를 검증합니다.
아래에 RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 그리고 RFC 8461 §5, 가상 컨트롤은 다음 설명을 지원합니다.
- 이 예에서는 서명이 확인되고 해당 d= 도메인이 보낸 사람 도메인과 일치하므로 DKIM 정렬된 전달 경로를 제공할 수 있습니다.
- DMARC 정렬된 DKIM 경로를 통해 메시지 수준에서 전달할 수 있습니다.
- 수신 SMTP 홉은 수신자 도메인의 게시된 전송 정책에 따라 TLS 사용했으며, 정책이 유효하고 최신이며 올바르게 적용되었다고 가정했습니다.
- 이러한 사실 중 어느 것도 송장이 진짜인지, 보낸 사람의 계정이 손상되지 않았는지, 메시지의 모든 이전 및 이후 사본이 암호화된 상태로 유지되는지를 증명하지 못합니다.
이제 서명 도메인만 d=mailer.example.net. DKIM 통과할 수 있지만 관련 없는 도메인은 shop.example.com 과 일치하지 않습니다. TLS로 보호되는 배달 홉은 해당 정렬 오류를 복구하지 않습니다.
DKIM 서명과 암호화를 별도로 유지
아래에 RFC 6376 §3.7, DKIM 선택한 메시지 데이터에 암호화 서명을 적용합니다. 검증자는 공개 키를 사용합니다. 선택자 d= 도메인. 서명은 서명된 콘텐츠와 서명 도메인에 대한 증거를 제공합니다. 메시지를 숨기지 않습니다.
암호화에는 다른 목적이 있습니다. 아래에 RFC 3207 §6, SMTP TLS 전체 종단 간 메시지 경로가 아닌 시스템 간 협상된 연결에서 데이터를 보호합니다. MTA-STS 사용하면 수신 도메인이 MX 호스트에 대한 TLS 전달을 확인할 때 규정을 준수하는 발신자가 사용할 수 있는 정책을 게시할 수 있습니다. TLS 보고는 전송 실패에 대한 집계된 피드백을 제공할 수 있습니다. RFC 8460 §4.1, RFC 8460 §4.2 그리고 RFC 8460 §4.3. 이러한 제어는 SMTP 메일을 종단 간 암호화된 개체로 변환하지 않습니다.
메시지 수준 암호화는 S/MIME 으로 설명되는 또 다른 계층입니다. RFC 8551 §1 그리고 RFC 8551 §3.3. 적합한 키를 가진 의도된 엔드포인트만 읽을 수 있도록 콘텐츠를 보호할 수 있지만 키 배포 및 인증서 처리는 다음과 같습니다. RFC 8551 §4 문제. 수신자 기능, 복구 및 아카이브 액세스에도 명시적인 운영 설계가 필요합니다. DMARC 표시되는 보낸 사람 도메인과 정렬된 인증에 대한 별도의 평가로 유지됩니다.
각 신뢰 결정 정의
유용한 설계 기록에는 모든 컨트롤에 대한 네 가지 사항이 명시되어 있습니다.
- 제어: DMARC ; 신원 또는 자산: 보낸 사람의 도메인; 신뢰 앵커: DNS 정책과 정렬된 SPF 또는 DKIM 결과; 보유할 증거: 신뢰할 수 있는 수신자 결과 및 적용 가능한 정책
- 제어: DKIM ; 신원 또는 자산: 서명 도메인 및 선택기 신뢰 앵커: DNS 공개 키; 보존할 증거 : 서명, 확인결과, 주요기록
- 제어: MTA-STS ; ID 또는 자산: 도메인 및 MX 전송 수신 트러스트 앵커: DNS 검색과 HTTPS 정책; 보관할 증거 : 정책 ID, 가져온 정책 및 전달 결과
- 제어: 메시지 암호화; ID 또는 자산: 수신자 또는 엔드포인트 키 신뢰 앵커: 선택된 키 및 인증서 신뢰 모델. 보관할 증거: 암호화 상태, 수신자 매핑 및 키 수명 주기
이를 하나의 녹색 배지로 번역하지 마십시오. 각 답변은 더 좁은 의미와 다른 실패 모드를 갖습니다.
위협에 대한 매핑 제어
DMARC 사용하면 보호된 From 도메인의 무단 사용을 참여 수신자가 더 쉽게 식별하고 처리할 수 있습니다. 합법적인 계정의 오용을 방지하지 않으며, 결제 요청이 사실인지 검사하거나, 저장된 메일을 암호화하지 않습니다.
TLS 보호된 홉에 대한 수동적 가로채기에 대한 노출을 줄일 수 있습니다. 보낸 사람 도메인을 인증하지 않습니다. 잘못되었거나 신뢰할 수 없는 대상과 TLS 협상하는 시스템은 정책이 적용되고 검증된 연결과 동일한 보증을 달성하지 못했습니다.
메시지 암호화는 설계에 따라 전송 세션 이후의 콘텐츠를 보호할 수 있습니다. 그 자체로는 DMARC 정렬을 생성하거나 비즈니스 트랜잭션을 승인하거나 엔드포인트 손상을 제거하지 않습니다.
과장하지 않고 증거를 구축하세요
ID의 경우 대표 수신 메시지를 캡처하고 보낸 사람, 봉투 ID, 각 DKIM d= 도메인, 원시 인증 결과, 정렬 및 DMARC 처리를 기록합니다. 전송을 위해 MTA-STS 정책, MX 범위 및 TLS 보고 증거를 보관합니다. 메시지 암호화의 경우 키 보유자, 수신자 등록 방법, 키 분실 시 발생하는 상황, 일반 텍스트에 액세스할 수 있는 시스템을 문서화합니다.
실험실 테스트는 테스트로 표시되어야 합니다. 모든 생산 경로가 동일하게 작동한다는 것을 증명하는 것은 아닙니다. 제어 목표에 영향을 미치는 저용량 서비스, 경로 전달, 백업 MX 호스트, 모바일 또는 아카이브 액세스를 검증합니다.
별도의 소유자 및 복구 경로 할당
메일 작업은 인증 및 SMTP 전송을 자체적으로 수행하는 경우가 많습니다. 보안 아키텍처는 정책, 위협 범위 및 암호화 표준을 소유할 수 있습니다. 애플리케이션 팀은 비즈니스 메일을 생성하는 전송 경로를 소유합니다. 법률 및 기록 팀은 콘텐츠 보존 및 키 복구 요구 사항에 영향을 미칠 수 있습니다.
각 컨트롤에 에스컬레이션 트리거를 제공합니다. 정렬 회귀는 보낸 사람 소유권 및 메일 작업으로 이동합니다. TLS 정책 실패는 전송 및 DNS 소유자에게 전달됩니다. 분실된 메시지 암호화 키는 키 관리 복구 프로세스로 이동됩니다. 일반적인 "이메일 보안" 대기열 중 하나는 내려야 할 결정을 숨깁니다.
구매 결정을 명확하게 하세요.
프로젝트를 승인하기 전에 필요한 결과에 대해 한 문장을 작성하세요. "발신 도메인의 무단 사용 줄이기"는 DMARC 및 정렬 인증을 가리킵니다. "도메인으로의 전달을 위해 허용 가능한 TLS 요구합니다"는 전송 정책을 가리킵니다. "승인된 엔드포인트 외부에서 메시지 콘텐츠를 읽을 수 없도록 유지"하려면 메시지 암호화 설계가 필요합니다.
이러한 결과는 공존할 수 있습니다. 중요한 결정은 친숙한 이메일 보안 약어가 신원, 기밀성 및 비즈니스 합법성을 동시에 다룬다고 가정하기보다는 누락된 보호에 자금을 지원하는 것입니다.
증거 내에서 결론을 유지하라
송장 고정의 경우 다양한 증거 필드에서 성공적인 DKIM 정렬 및 검증된 SMTP 홉을 유지합니다. SPF 정렬되지 않은 상태에서 d=만 관련되지 않은 공급자 도메인으로 변경되는 경우 TLS 여전히 정렬된 ID를 생성하지 않습니다. 여기에 설명된 정책 가져오기, TLS 협상 및 서명 확인은 수행된 네트워크 또는 메시지 테스트가 아니라 입력을 가르치는 것으로 가정됩니다.