Microsoft 365에서 전자 메일 인증

아티클
04/26/2024
적용 대상:

✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

팁

Microsoft Defender XDR Office 365 플랜 2의 기능을 무료로 사용해 볼 수 있다는 사실을 알고 계셨나요? Microsoft Defender 포털 평가판 허브에서 90일 Office 365용 Defender 평가판을 사용합니다. Office 365용 Microsoft Defender 시도에서 누가 등록하고 평가판을 사용할 수 있는지에 대해 알아봅니다.

Exchange Online 사서함이 있는 Microsoft 365 organization 또는 Exchange Online 사서함이 없는 독립 실행형 Exchange Online Protection(EOP) organization 사용자의 보낸 사람으로부터 전자 메일 메시지의 무결성을 보호합니다. 도메인은 중요합니다. 받는 사람은 도메인의 보낸 사람이 보낸 메시지가 실제로 도메인의 보낸 사람으로부터 온 것이라고 확신해야 합니다.

Email 인증(전자 메일 유효성 검사라고도 함)은 위조된 보낸 사람(스푸핑이라고도 함)의 전자 메일 메시지 배달을 식별하고 방지하기 위한 표준 그룹입니다. 스푸핑된 보낸 사람이 BEC(비즈니스 메일 손상), 피싱 및 기타 이메일 공격에 일반적으로 사용됩니다. 이러한 표준은 다음과 같습니다.

SPF(보낸 사람 정책 프레임워크) : 도메인에 대한 메일을 보낼 권한이 있는 원본 전자 메일 서버를 지정합니다.
DomainKeys DKIM(식별 메일): 도메인을 사용하여 메시지의 중요한 요소에 디지털 서명하여 메시지가 전송 중에 변경되지 않았는지 확인합니다.
도메인 기반 메시지 인증, 보고 및 준수(DMARC): SPF 또는 DKIM이 도메인에서 보낸 사람 확인을 실패하는 메시지에 대한 작업을 지정하고 DMARC 결과(보고)를 보낼 위치를 지정합니다.
ARC(인증된 수신 체인) : 전송 중인 메시지를 수정하는 알려진 서비스에 의한 원래 전자 메일 인증 정보를 유지합니다. 대상 전자 메일 서버는 이 정보를 사용하여 DMARC에 실패하는 메시지를 인증할 수 있습니다.

이러한 표준은 스푸핑 및 피싱 공격 방지를 위한 최상의 전자 메일 보호를 제공하기 위해 함께 작동하는상호 종속된 구성 요소임을 인식하는 것이 중요합니다. 모든 전자 메일 인증 방법보다 작은 것은 비표준 보호를 초래합니다.

Exchange Online 사서함이 없는 Exchange Online 또는 EOP(독립 실행형 Exchange Online Protection) 조직에 사서함이 있는 Microsoft 365 조직에서 보낸 메일에 대한 전자 메일 인증을 구성하려면 다음 문서를 참조하세요.

Microsoft 365 organization 전송된 인바운드 메일을 수정하는 서비스로 인한 전자 메일 인증 실패를 방지하려면 신뢰할 수 있는 ARC 실러 구성을 참조하세요.

이 문서의 나머지 부분에는 다음이 설명됩니다.

인터넷 전자 메일에 인증이 필요한 이유
SPF, DKIM 및 DMARC가 함께 작동하여 전자 메일 메시지 보낸 사람 인증 방법
Microsoft에서 전자 메일 인증을 사용하여 Microsoft 365로 전송된 인바운드 메일을 검사 방법
Microsoft 365로 메일을 보낼 때 전자 메일 인증 실패를 방지하는 방법

팁

이 문서의 동반자로서 모범 사례를 검토하고 이메일, 링크 및 공동 작업 위협으로부터 보호하기 위한 Office 365용 Microsoft Defender 설정 가이드를 참조하세요. 기능에는 안전한 링크, 안전한 첨부 파일 등이 포함됩니다. 사용자 환경에 기반한 사용자 지정 환경의 경우 Microsoft 365 관리 센터 Office 365용 Microsoft Defender 자동화된 설정 가이드에 액세스할 수 있습니다.

인터넷 전자 메일에 인증이 필요한 이유

기본적으로 인터넷의 SMTP(Simple Mail Transfer Protocol) 전자 메일은 메시지 보낸 사람이 자신이 주장하는 사람인지 확인하기 위해 노력하지 않습니다.

표준 SMTP 전자 메일 메시지는 메시지 봉투 및 메시지 콘텐츠로 구성됩니다.

메시지 봉투에는 SMTP 서버 간에 메시지를 전송하고 수신하기 위한 정보가 포함되어 있습니다. 메시지 봉투는 RFC 5321에 설명되어 있습니다. 받는 사람은 메시지 전송 프로세스 중에 생성되므로 메시지 봉투를 볼 수 없습니다.
메시지 콘텐츠에는 메시지 헤더 필드(전체적으로 메시지 헤더라고 함) 및 메시지 본문이 포함됩니다. 메시지 헤더는 RFC 5322에 설명되어 있습니다.

이 디자인으로 인해 메시지에는 여러 보낸 사람 값이 있습니다.

MAIL FROM 주소(주소, P1 보낸 사람 또는 봉투 보낸 사람라고 5321.MailFrom 도 함)는 SMTP 전자 메일 서버 간에 메시지를 전송하는 데 사용되는 이메일 주소입니다. 이 주소는 일반적으로 메시지 헤더의 Return-Path 헤더 필드에 기록됩니다(원본 전자 메일 서버는 다른 Return-Path 전자 메일 주소를 지정할 수 있지만). 이 이메일 주소는 배달되지 않는 보고서(NDR 또는 반송 메시지라고도 함)에서 사용됩니다.
보낸 사람 주소(주소 또는 P2 발신자라고도 함 5322.From )는 보낸 사람 헤더 필드의 전자 메일 주소이며 전자 메일 클라이언트에 표시되는 보낸 사람의 전자 메일 주소입니다.

다음 예제에서는 두 SMTP 전자 메일 서버 간에 유효한 메시지 전송의 간소화된 기록을 보여줍니다.

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

이 예제의 특징은 다음과 같습니다.

원본 전자 메일 서버는 HELO 명령의 대상 전자 메일 서버 tailspintoys.com woodgrovebank.com 자신을 식별합니다.
메시지 수신자는 입니다 astobes@tailspintoys.com.
메시지 봉투의 MAIL FROM 주소(SMTP 전자 메일 서버 간에 메시지를 전송하는 데 사용됨)는 입니다 dubious@proseware.com.
받는 사람의 이메일 클라이언트에 표시되는 보낸 사람 주소는 입니다 security@woodgrovebank.com.

이 메시지는 SMTP에 따라 유효하지만 MAIL FROM 주소(proseware.com)의 도메인이 보낸 편지(woodgrovebank.com)의 도메인과 일치하지 않습니다. 이 메시지는 스푸핑의 전형적인 예입니다. 여기서 의도는 피싱 공격에 사용할 메시지의 실제 원본을 마스킹하여 받는 사람을 속일 가능성이 높습니다.

분명히 SMTP 전자 메일은 메시지 보낸 사람이 자신이 누구라고 주장하는지 확인하는 데 도움이 필요합니다.

SPF, DKIM 및 DMARC가 함께 작동하여 전자 메일 메시지 보낸 사람 인증 방법

이 섹션에서는 인터넷의 도메인에 대해 SPF, DKIM 및 DMARC가 필요한 이유를 설명합니다.

SPF: Microsoft 365 도메인에 대한 유효한 전자 메일 원본을 식별하도록 SPF 설정에서 설명한 대로 SPF는 DNS의 TXT 레코드를 사용하여 MAIL FROM 도메인에서 유효한 메일 원본을 식별하고 대상 전자 메일 서버가 정의되지 않은 원본에서 메일을 수신하는 경우 수행할 작업('하드 실패'하여 메시지를 거부합니다. 메시지를 수락하고 표시하려면 '소프트 실패'입니다.)

SPF 문제:
- SPF는 MAIL FROM 도메인에서 보낸 사람만 원본의 유효성을 검사합니다. SPF는 보낸 편지 주소 또는 MAIL FROM 및 From 도메인 간의 맞춤에서 도메인을 고려하지 않습니다.
  - 공격자는 다음 단계에 따라 SPF 인증(거짓 부정)을 전달하는 이메일을 보낼 수 있습니다.
    - 도메인(예: proseware.com)을 등록하고 도메인에 대한 SPF를 구성합니다.
    - 다른 도메인의 보낸 전자 메일 주소(예: woodgrovebank.com)를 사용하여 등록된 도메인의 유효한 원본에서 전자 메일을 보냅니다.
  - 다른 도메인을 대신하여 메일을 보내는 합법적인 전자 메일 서비스가 MAIL FROM 주소를 제어할 수 있습니다. 다른 도메인과 MAIL FROM 도메인이 일치하지 않으므로 메시지가 SPF 인증을 통과할 수 없습니다(가양성).
- 메시지를 리디렉션하거나 릴레이 하는 서버 기반 전자 메일 전달이 메시지가 발생한 후 SPF가 중단됩니다.
  - 서버 기반 전자 메일 전달은 메시지 원본을 원래 서버에서 전달 서버로 변경합니다.
  - 전달 서버는 원래 MAIL FROM 도메인에서 메일을 보낼 권한이 없으므로 메시지가 SPF 인증(가양성)을 전달할 수 없습니다.
- 각 도메인 및 하위 도메인에는 고유한 개별 SPF 레코드가 필요합니다. 하위 도메인은 부모 도메인의 SPF 레코드를 상속하지 않습니다. 이 동작은 정의되고 사용된 하위 도메인의 전자 메일을 허용하지만 정의되지 않은 하위 도메인 및 사용되지 않는 하위 도메인에서 전자 메일을 방지하려는 경우 문제가 됩니다.
DKIM: Microsoft 365 도메인에서 메일에 서명하도록 DKIM 설정에 설명된 대로 DKIM은 도메인을 사용하여 메시지의 중요한 요소(보낸 사람의 주소 포함)에 디지털 서명하고 메시지 헤더에 서명을 저장합니다. 대상 서버는 메시지의 서명된 요소가 변경되지 않았는지 확인합니다.

DKIM이 SPF에 도움이 되는 방법: DKIM은 SPF에 실패한 메시지의 유효성을 검사할 수 있습니다. 예:
- 다른 도메인의 메일에 동일한 MAIL FROM 주소가 사용되는 메일 호스팅 서비스의 메시지입니다.
- 서버 기반 전자 메일 전달이 발생하는 메시지입니다.
이러한 시나리오에서는 메시지 헤더의 DKIM 서명이 영향을 받거나 변경되지 않으므로 이러한 메시지는 DKIM을 전달할 수 있습니다.

DKIM 문제: DKIM이 메시지에 서명하는 데 사용하는 도메인은 전자 메일 클라이언트에 표시된 보낸 사람 주소의 도메인과 일치할 필요가 없습니다.

SPF와 마찬가지로 공격자는 다음 단계에 따라 DKIM 인증(거짓 부정)을 전달하는 이메일을 보낼 수 있습니다.
- 도메인(예: proseware.com)을 등록하고 도메인에 대한 DKIM을 구성합니다.
- 다른 도메인의 보낸 사람 전자 메일 주소(예: woodgrovebank.com)를 사용하여 전자 메일을 보냅니다.
DMARC: Microsoft 365에서 보낸 사람의 보낸 사람 주소 도메인의 유효성을 검사하기 위해 DMARC 설정에서 설명한 대로 DMARC는 SPF 및 DKIM을 사용하여 MAIL FROM 및 보낸 사람 주소의 도메인 간 맞춤을 위해 검사. 또한 DMARC는 대상 전자 메일 시스템이 DMARC에 실패한 메시지에 대해 수행해야 하는 작업을 지정하고 DMARC 결과를 보낼 위치(통과 및 실패 모두)를 식별합니다.

DMARC가 SPF 및 DKIM에 도움이 되는 방법: 앞서 설명한 대로 SPF는 MAIL FROM 도메인 및 From 주소에서 도메인을 일치시키려고 시도하지 않습니다. DKIM은 메시지에 서명한 도메인이 보낸 사람의 주소에 있는 도메인과 일치하는지 상관하지 않습니다.

DMARC는 SPF 및 DKIM을 사용하여 MAIL FROM 및 From 주소의 도메인이 일치하는지 확인하여 이러한 결함을 해결합니다.

DMARC 문제: 배달 중단 SPF, DKIM 및 DMARC 검사 전에 전송 중인 메시지를 수정하는 합법적인 서비스입니다.
ARC: 신뢰할 수 있는 ARC 실러 구성에 설명된 대로 전송 중인 메시지를 수정하는 합법적인 서비스는 ARC를 사용하여 수정된 메시지의 원래 전자 메일 인증 정보를 보존할 수 있습니다.

ARC가 DMARC에 도움이 되는 방법: 대상 전자 메일 시스템은 서비스를 신뢰할 수 있는 ARC 실러로 식별할 수 있습니다. 그런 다음 ARC는 보존된 전자 메일 인증 정보를 사용하여 메시지의 유효성을 검사할 수 있습니다.

Microsoft 365로 전송된 메일에 대한 인바운드 전자 메일 인증

피싱 문제가 있고 인터넷에서 전자 메일 보낸 사람이 강력한 전자 메일 인증 정책을 완전히 채택하지 못하기 때문에 Microsoft 365는 암시적 전자 메일 인증을 사용하여 인바운드 전자 메일을 검사. 암시적 전자 메일 인증은 다른 원본의 신호를 사용하여 인바운드 이메일을 평가하여 일반 SPF, DKIM 및 DMARC 검사를 확장합니다. 이러한 원본은 다음과 같습니다.

보낸 사람 평판.
보낸 사람 기록입니다.
받는 사람 기록입니다.
동작 분석.
기타 고급 기술.

암시적 인증에 대한 Microsoft의 원래 발표를 보려면 A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365를 참조하세요.

이러한 다른 신호를 사용하면 기존 전자 메일 인증 검사에 실패하는 메시지는 암시적 인증을 전달하고 Microsoft 365로 허용될 수 있습니다.

복합 인증

Microsoft 365의 암시적 인증 검사 결과는 복합 인증이라는 단일 값 또는 compauth 짧은 값으로 결합되고 저장됩니다. compauth 값은 메시지 헤더의 인증-결과 헤더에 스탬프로 표시됩니다. Authentication-Results 헤더는 다음 구문을 사용합니다.

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

이러한 값은 Authentication-results 메시지 헤더에서 설명됩니다.

관리자와 사용자는 메시지 헤더를 검사하여 Microsoft 365가 보낸 사용자를 의심스러운 스푸핑된 보낸 사람 또는 합법적인 사람으로 식별하는 방법을 검색할 수 있습니다.

팁

복합 인증 실패로 인해 메시지가 직접 차단되지는 않는다는 점을 이해하는 것이 중요합니다. 복합 인증 결과와 함께 메시지의 전반적인 의심스러운 특성을 고려하는 전체적인 평가 전략을 사용하는 시스템입니다. 이 방법은 전자 메일 인증 프로토콜을 엄격하게 준수하지 않을 수 있는 도메인에서 합법적인 전자 메일을 잘못 차단할 위험을 완화하도록 설계되었습니다. 이 균형 잡힌 접근 방식을 사용하면 표준 전자 메일 인증 사례를 준수하지 않는 메시지 보낸 사람으로부터 진정으로 악의적인 전자 메일을 구별할 수 있습니다.

다음 예제에서는 전자 메일 인증의 결과( compauth 값 및 이유)에만 초점을 맞춥니다. 다른 Microsoft 365 보호 기술은 전자 메일 인증을 스푸핑된 것으로 전달하는 메시지를 식별하거나 전자 메일 인증에 실패한 메시지를 합법적인 것으로 식별할 수 있습니다.

시나리오: SPF 레코드 또는 DKIM 서명의 도메인이 보낸 사람의 주소에 있는 도메인과 일치하지 않습니다.

결과: 메시지가 복합 인증에 실패할 수 있습니다. 복합 인증 실패에도 불구하고 다른 평가가 의심스러운 특성을 나타내지 않으면 메시지가 계속 허용될 수 있습니다.

Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

시나리오: fabrikam.com 도메인에는 SPF, DKIM 또는 DMARC 레코드가 없습니다.

결과: fabrikam.com 도메인의 보낸 사람이 보낸 메시지는 복합 인증에 실패할 수 있습니다.

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

시나리오: fabrikam.com 도메인에는 SPF 레코드가 있고 DKIM 레코드는 없습니다. MAIL FROM 및 From 주소의 도메인이 일치합니다.

결과: SPF를 통과한 도메인이 보낸 사람의 도메인과 일치하므로 메시지는 복합 인증을 전달할 수 있습니다.

Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

시나리오: fabrikam.com 도메인에는 SPF 레코드가 없는 DKIM 레코드가 있습니다. DKIM이 메시지에 서명한 도메인이 보낸 사용자 주소의 도메인과 일치합니다.

결과: DKIM 서명의 도메인이 보낸 사용자 주소의 도메인과 일치하므로 메시지가 복합 인증을 전달할 수 있습니다.

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

시나리오: SPF 레코드 또는 DKIM 서명의 도메인이 보낸 사람의 주소에 있는 도메인과 일치하지 않습니다.

결과: 메시지가 복합 인증에 실패할 수 있습니다.

Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Microsoft 365로 메일을 보낼 때 전자 메일 인증 실패를 방지하는 방법

팁

Microsoft 365 고객은 다음 방법을 사용하여 스푸핑 또는 인증 실패로 식별되는 보낸 사람의 메시지를 허용할 수 있습니다.

도메인에 대한 SPF, DKIM 및 DMARC 레코드 구성: 도메인 등록 기관 또는 DNS 호스팅 서비스에서 제공하는 구성 정보를 사용합니다. 전자 메일 인증 레코드를 설정하는 데 전념하는 타사 회사도 있습니다.

많은 회사에서 도메인의 메시지에 대한 전자 메일 원본을 모두 모르기 때문에 SPF 레코드를 게시하지 않습니다.
1. 먼저 알고 있는 모든 전자 메일 원본(특히 회사 트래픽이 있는 위치)이 포함된 SPF 레코드를 게시하고 적용 규칙 값 "일시 실패"(~all)를 사용합니다. 예:
```
fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"
```
  이 SPF 레코드를 만드는 경우 Microsoft 365는 회사 인프라의 인바운드 전자 메일을 인증된 것으로 처리하지만, 복합 인증에 실패할 경우 확인되지 않은 원본의 전자 메일은 여전히 스푸핑으로 표시될 수 있습니다. 그러나 이 동작은 여전히 Microsoft 365에서 스푸핑으로 표시된 도메인의 보낸 사람의 모든 전자 메일에서 개선된 것입니다. 일반적으로 대상 전자 메일 시스템은 SPF가 소프트 장애 적용 규칙으로 구성된 경우 확인되지 않은 원본의 도메인에 있는 보낸 사람의 메시지를 수락합니다.
2. 메시지에 대한 더 많은 전자 메일 원본을 검색하고 포함합니다. 예:
  - 온-프레미스 전자 메일 서버
  - SaaS (서비스로서의 소프트웨어) 공급자에서 보낸 전자 메일입니다.
  - 클라우드 호스팅 서비스(Microsoft Azure, GoDaddy, Rackspace, Amazon 웹 서비스 등)에서 보낸 전자 메일입니다.
  도메인에 대한 모든 전자 메일 원본을 식별한 후 적용 규칙 값 "하드 실패"(-all)를 사용하도록 SPF 레코드를 업데이트할 수 있습니다.
3. 메시지에 디지털 서명하도록 DKIM을 설정합니다.
4. DMARC를 설정하여 MAIL FROM 및 From 주소의 도메인이 일치하는지 확인하고, DMARC 검사에 실패한 메시지(거부 또는 격리)로 수행할 작업을 지정하고, DMARC 결과를 모니터링하는 보고 서비스를 식별하도록 설정합니다.
5. 대량 보낸 사람이 사용자를 대신하여 전자 메일을 보내는 경우 보낸 사람 주소의 도메인이 SPF 또는 DMARC를 통과하는 도메인과 일치하는지 확인합니다.
도메인의 이메일을 호스트하거나 이메일을 보낼 수 있는 호스팅 인프라를 제공합니다.
- 고객에게 해당 도메인에 대해 SPF를 구성하는 방법을 설명하는 설명서가 있는지 확인합니다.
- 고객이 도메인에서 DKIM을 명시적으로 설정하지 않은 경우에도 DKIM이 DKIM 아웃바운드 메일에 서명하는 것을 고려합니다(기본 도메인으로 서명). DKIM 서명을 사용하여 이메일을 두 번 서명할 수도 있습니다(사용 가능한 경우 회사 도메인 및 고객의 도메인 사용 가능).
플랫폼에서 보낸 전자 메일을 인증하더라도 Microsoft로의 배달은 보장되지 않습니다. 그러나 전자 메일 인증은 Microsoft가 인증되지 않았기 때문에 고객 도메인의 전자 메일을 자동으로 정크하지 않도록 합니다.

다음을 통해 공유