다음을 통해 공유

Office 365용 Microsoft Defender 마이그레이션 - 3단계: 온보딩


1단계: 준비.
1 단계: 준비		 2단계: 설정.
2 단계: 설정		 3단계: 온보딩.
3 단계: 온보딩
당신은 여기 있습니다!

3단계: Office 365용 Microsoft Defender 마이그레이션온보딩을 시작합니다. 이 마이그레이션 단계에는 다음 단계가 포함됩니다.

  1. 보안 팀 온보딩 시작
  2. (선택 사항) 기존 보호 서비스에 의한 필터링에서 파일럿 사용자 제외
  3. 스푸핑 인텔리전스 조정
  4. 가장 보호 및 사서함 인텔리전스 조정
  5. 사용자가 보고한 메시지의 데이터를 사용하여 측정 및 조정
  6. (선택 사항) 파일럿에 더 많은 사용자 추가 및 반복
  7. 모든 사용자에게 Microsoft 365 보호를 확장하고 SCL=-1 메일 흐름 규칙을 끕니다.
  8. MX 레코드 전환

1단계: 보안 팀 온보딩 시작

organization 보안 대응 팀이 있는 경우 이제 티켓팅 시스템을 비롯한 응답 프로세스에 Office 365용 Microsoft Defender 통합하기 시작할 때입니다. 이 프로세스는 전체 토픽이지만 때로는 간과되기도 합니다. 보안 대응 팀을 조기에 참여시키는 것은 MX 레코드를 전환할 때 organization 위협에 대처할 준비가 되도록 합니다. 다음 작업을 처리하려면 인시던트 대응을 잘 갖추어야 합니다.

organization 플랜 2를 Office 365용 Microsoft Defender 구매한 경우 위협 Explorer, 고급 헌팅 및 인시던트와 같은 기능을 숙지하고 사용하기 시작해야 합니다. 관련 교육은 를 참조하세요 https://aka.ms/mdoninja.

보안 응답 팀이 필터링되지 않은 메시지를 수집하고 분석하는 경우 필터링되지 않은 메시지를 받도록 SecOps 사서함을 구성할 수 있습니다. 자세한 내용은 고급 배달 정책에서 SecOps 사서함 구성을 참조하세요.

SIEM/SOAR

SIEM/SOAR과 통합하는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.

organization 보안 대응 팀 또는 기존 프로세스 흐름이 없는 경우 이 시간을 사용하여 Office 365용 Defender 기본 헌팅 및 응답 기능을 숙지할 수 있습니다. 자세한 내용은 위협 조사 및 대응을 참조하세요.

RBAC 역할

Office 365용 Defender 권한은 RBAC(역할 기반 액세스 제어)를 기반으로 하며 Microsoft Defender 포털의 권한에 설명되어 있습니다. 유의해야 할 중요한 사항은 다음과 같습니다.

  • Microsoft Entra 역할은 Microsoft 365의 모든 워크로드에 권한을 부여합니다. 예를 들어 Azure Portal 보안 관리자에 사용자를 추가하는 경우 모든 위치에 보안 관리자 권한이 있습니다.
  • Microsoft Defender 포털의 Email & 협업 역할은 Microsoft Defender 포털 및 Microsoft Purview 규정 준수 포털 대한 권한을 부여합니다. 예를 들어 Microsoft Defender 포털에서 보안 관리자에 사용자를 추가하는 경우 Microsoft Defender 포털 및 Microsoft Purview 규정 준수 포털 보안 관리자 액세스 권한만 있습니다.
  • Microsoft Defender 포털의 많은 기능은 Exchange Online PowerShell cmdlet을 기반으로 하므로 해당 Exchange Online PowerShell에 액세스하려면 Exchange Online 해당 역할(기술적으로 역할 그룹)의 역할 그룹 멤버 자격이 필요합니다. cmdlet).
  • Microsoft Defender 포털에는 Microsoft Entra 역할과 동일하지 않고 보안 작업(예: 미리 보기 역할 및 Search 및 제거 역할)에 중요한 Email & 협업 역할이 있습니다.

일반적으로 보안 담당자의 하위 집합만 사용자 사서함에서 직접 메시지를 다운로드할 수 있는 추가 권한이 필요합니다. 이 경우 보안 읽기 권한자가 기본적으로 갖지 않은 추가 권한이 필요합니다.

2단계: (선택 사항) 기존 보호 서비스에 의한 필터링에서 파일럿 사용자 제외

이 단계는 필요하지 않지만 기존 보호 서비스에 의한 필터링을 무시하도록 파일럿 사용자를 구성하는 것이 좋습니다. 이 작업을 통해 Office 365용 Defender 파일럿 사용자에 대한 모든 필터링 및 보호 업무를 처리할 수 있습니다. 파일럿 사용자를 기존 보호 서비스에서 제외하지 않으면 Office 365용 Defender 다른 서비스에서 누락된 경우에만 효과적으로 작동합니다(이미 필터링된 메시지 필터링).

참고

현재 보호 서비스에서 링크 래핑을 제공하지만 안전한 링크 기능을 파일럿하려는 경우 이 단계가 명시적으로 필요합니다. 링크의 이중 래핑은 지원되지 않습니다.

3단계: 스푸핑 인텔리전스 조정

스푸핑 인텔리전스 인사이트를 확인하여 스푸핑으로 허용되거나 차단되는 항목을 확인하고 스푸핑에 대한 시스템 평결을 재정의해야 하는지 확인합니다. 중요 비즈니스용 전자 메일의 일부 원본은 DNS(SPF, DKIM 및 DMARC)에서 전자 메일 인증 레코드를 잘못 구성했을 수 있으며 기존 보호 서비스에서 재정의를 사용하여 도메인 문제를 마스킹할 수 있습니다.

스푸핑 인텔리전스는 DNS에서 적절한 전자 메일 인증 레코드가 없는 도메인에서 전자 메일을 구출할 수 있지만, 이 기능에는 좋은 스푸핑과 잘못된 스푸핑을 구별하는 데 도움이 필요한 경우가 있습니다. 다음 유형의 메시지 원본에 집중합니다.

  • 커넥터에 대한 향상된 필터링에 정의된 IP 주소 범위를 벗어난 메시지 원본입니다.
  • 메시지 수가 가장 많은 메시지 원본입니다.
  • organization 가장 큰 영향을 주는 메시지 원본입니다.

스푸핑 인텔리전스는 사용자가 보고한 설정을 구성한 후 결국 자체적으로 조정되므로 완벽할 필요가 없습니다.

4단계: 가장 보호 및 사서함 인텔리전스 조정

동작 모드를 적용하지 않음 에서 가장 보호 결과를 관찰할 충분한 시간이 있으면 피싱 방지 정책에서 각 가장 보호 작업을 개별적으로 켤 수 있습니다.

  • 사용자 가장 보호: 표준 및 엄격 모두에 대한 메시지를 격리 합니다.
  • 도메인 가장 보호: 표준 및 엄격 모두에 대한 메시지를 격리 합니다.
  • 사서함 인텔리전스 보호: 메시지를 수신자의 표준용 정크 Email 폴더로 이동합니다. Strict에 대한 메시지를 격리합니다.

메시지에 대해 작업하지 않고 가장 보호 결과를 더 오래 모니터링할수록 더 많은 데이터를 식별해야 할수록 필요할 수 있는 허용 또는 블록이 늘어나게 됩니다. 관찰 및 조정을 허용할 만큼 중요한 각 보호 켜기 사이의 지연을 사용하는 것이 좋습니다.

참고

이러한 보호를 자주 지속적으로 모니터링하고 조정하는 것이 중요합니다. 가양성이 의심되는 경우 원인을 조사하고 필요한 경우에만 재정의를 사용하고 필요한 검색 기능에만 재정의를 사용합니다.

사서함 인텔리전스 조정

사서함 인텔리전스는 가장 시도로 확인된 메시지에 대해 아무런 조치도 취하지 못하도록 구성되었지만, 파일럿 사용자의 전자 메일 보내기 및 수신 패턴을 켜고 학습합니다. 외부 사용자가 파일럿 사용자 중 한 명과 접촉하는 경우 해당 외부 사용자의 메시지는 사서함 인텔리전스에 의한 가장 시도로 식별되지 않으므로 가양성을 줄입니다.

준비가 되면 다음 단계를 수행하여 사서함 인텔리전스가 가장 시도로 감지된 메시지에 대해 작동하도록 허용합니다.

  • 표준 보호 설정이 있는 피싱 방지 정책에서 사서함 인텔리전스가 가장한 사용자를 검색하는 경우의 값을 받는 사람의 정크 Email 폴더로 메시지 이동으로 변경합니다.

  • 엄격한 보호 설정이 있는 피싱 방지 정책에서 사서함 인텔리전스에서 사용자를 검색하고 가장한 경우 의 값을 메시지 격리로 변경합니다.

정책을 수정하려면 Office 365용 Defender 피싱 방지 정책 구성을 참조하세요.

결과를 관찰하고 조정한 후 다음 섹션으로 이동하여 사용자 가장에 의해 검색된 메시지를 격리합니다.

사용자 가장 보호 조정

표준 및 엄격한 설정을 기반으로 하는 피싱 방지 정책 모두에서 메시지를 사용자 가장으로 감지한 경우 값을 변경하여 메시지를 격리합니다.

가장 인사이트를 확인하여 사용자 가장 시도 시 차단되는 항목을 확인합니다.

정책을 수정하려면 Office 365용 Defender 피싱 방지 정책 구성을 참조하세요.

결과를 관찰하고 조정한 후 다음 섹션으로 진행하여 도메인 가장에 의해 검색된 메시지를 격리합니다.

도메인 가장 보호 조정

표준 및 엄격한 설정을 기반으로 하는 피싱 방지 정책 모두에서 메시지가 도메인 가장으로 검색되면메시지를 격리하도록 값을 변경합니다.

가장 인사이트를 확인하여 도메인 가장 시도로 차단되는 항목을 확인합니다.

정책을 수정하려면 Office 365용 Defender 피싱 방지 정책 구성을 참조하세요.

결과를 관찰하고 필요에 따라 조정합니다.

5단계: 사용자가 보고한 메시지의 데이터를 사용하여 측정 및 조정

파일럿 사용자가 가양성 및 거짓 부정을 보고하면 메시지는 Microsoft Defender 포털의 제출 페이지의사용자 보고 탭에 표시됩니다. 분석을 위해 잘못 알려진 메시지를 Microsoft에 보고하고 정보를 사용하여 필요에 따라 파일럿 정책의 설정 및 예외를 조정할 수 있습니다.

다음 기능을 사용하여 Office 365용 Defender 보호 설정을 모니터링하고 반복합니다.

organization 사용자가 보고한 메시지에 타사 서비스를 사용하는 경우 해당 데이터를 피드백 루프에 통합할 수 있습니다.

6단계: (선택 사항) 파일럿에 더 많은 사용자 추가 및 반복

문제를 찾고 해결하면 파일럿 그룹에 더 많은 사용자를 추가할 수 있습니다(이에 따라 기존 보호 서비스에서 검사에서 새 파일럿 사용자를 적절하게 제외). 지금 더 많은 테스트를 수행할수록 나중에 처리해야 하는 사용자 문제가 줄어듭니다. 이 "폭포" 접근 방식을 사용하면 organization 많은 부분을 튜닝할 수 있으며 보안 팀이 새 도구 및 프로세스에 적응할 수 있는 시간을 제공합니다.

  • Microsoft 365는 조직 정책에서 높은 신뢰도의 피싱 메시지를 허용하는 경우 경고를 생성합니다. 이러한 메시지를 식별하려면 다음 옵션이 있습니다.

    • 위협 방지 상태 보고서에서 재정의합니다.
    • 위협 Explorer 필터링하여 메시지를 식별합니다.
    • 고급 헌팅에서 필터링하여 메시지를 식별합니다.

    관리자 제출을 통해 가능한 한 빨리 Microsoft에 가양성 보고하고 테넌트 허용/차단 목록 기능을 사용하여 이러한 가양성에 대한 안전한 재정의를 구성합니다.

  • 또한 불필요한 재정의를 검토하는 것이 좋습니다. 즉, Microsoft 365가 메시지에 제공한 판결을 살펴봅니다. Microsoft 365가 올바른 평결을 렌더링한 경우 재정의의 필요성이 크게 감소하거나 제거됩니다.

7단계: 모든 사용자에게 Microsoft 365 보호 확장 및 SCL=-1 메일 흐름 규칙 해제

MX 레코드를 Microsoft 365를 가리키도록 전환할 준비가 되면 이 섹션의 단계를 수행합니다.

  1. 파일럿 정책을 전체 organization 확장합니다. 기본적으로 정책을 확장하는 방법에는 여러 가지가 있습니다.

    • 미리 설정된 보안 정책을 사용하고 표준 보호 프로필과 엄격한 보호 프로필 간에 사용자를 나눕니다(모든 사용자가 적용되는지 확인). 미리 설정된 보안 정책은 사용자가 만든 사용자 지정 정책 또는 기본 정책 앞에 적용됩니다. 개별 파일럿 정책을 삭제하지 않고 해제할 수 있습니다.

      미리 설정된 보안 정책의 단점은 보안 정책을 만든 후에는 많은 중요한 설정을 변경할 수 없다는 것입니다.

    • 모든 사용자(예: 모든 도메인의 모든 수신자)를 포함하도록 파일럿 중에 만들고 조정한 정책의 scope 변경합니다. 동일한 유형의 여러 정책(예: 피싱 방지 정책)이 동일한 사용자(개별적으로 그룹 멤버 자격 또는 이메일 도메인별)에 적용되는 경우 우선 순위가 가장 높은 정책 설정(우선 순위가 가장 낮은 수)만 적용되고 해당 정책 유형에 대한 처리가 중지됩니다.

  2. SCL=-1 메일 흐름 규칙을 끕니다(삭제하지 않고 해제할 수 있습니다).

  3. 이전 변경 내용이 적용되었으며 이제 모든 사용자에 대해 Office 365용 Defender 올바르게 사용하도록 설정되어 있는지 확인합니다. 이 시점에서 Office 365용 Defender 모든 보호 기능은 이제 모든 받는 사람의 메일에 대해 작동할 수 있지만 기존 보호 서비스에서 해당 메일을 이미 검사했습니다.

더 큰 규모의 데이터 기록 및 튜닝을 위해 이 단계에서 일시 중지할 수 있습니다.

8단계: MX 레코드 전환

참고

  • 도메인에 대한 MX 레코드를 전환하면 변경 내용이 인터넷 전체에 전파되는 데 최대 48시간이 걸릴 수 있습니다.
  • DNS 레코드의 TTL 값을 낮추어 더 빠른 응답 및 가능한 롤백(필요한 경우)을 사용하도록 설정하는 것이 좋습니다. 전환이 완료되고 확인된 후 원래 TTL 값으로 되돌리기 수 있습니다.
  • 자주 사용되지 않는 도메인 변경부터 시작해야 합니다. 더 큰 도메인으로 이동하기 전에 일시 중지하고 모니터링할 수 있습니다. 그러나 이렇게 하더라도 보조 SMTP 도메인이 정책 애플리케이션 이전의 기본 도메인으로 확인되기 때문에 모든 사용자와 도메인에 정책이 적용되는지 확인해야 합니다.
  • 이 문서의 모든 지침을 따른 경우 단일 도메인에 대한 여러 MX 레코드가 기술적으로 작동하므로 분할 라우팅을 수행할 수 있습니다. 특히 설정 3단계: SCL=-1 메일 흐름 규칙 유지 관리 또는 만들기에 설명된 대로 SCL=-1 메일 흐름 규칙이 기존 보호 서비스를 통과하는 메일에만 적용되는 정책이 모든 사용자에게 적용되는지 확인해야 합니다. 그러나 이 구성은 문제 해결을 훨씬 더 어렵게 만드는 동작을 도입하므로, 특히 장기간 권장하지는 않습니다.
  • MX 레코드를 전환하기 전에 보호 서비스에서 Microsoft 365로 인바운드 커넥터에서 다음 설정이 사용하도록 설정되지 않은지 확인합니다. 일반적으로 커넥터에는 다음 설정 중 하나 이상이 구성됩니다.
    • 파트너가 Office 365 인증하는 데 사용하는 인증서의 주체 이름이 이 도메인 이름(RestrictDomainsToCertificate)과 일치하도록 요구합니다.
    • 이 IP 주소 범위 (RestrictDomainsToIPAddresses) 커넥터 유형이 파트너 이고 이러한 설정 중 하나가 켜져 있으면 MX 레코드를 전환한 후 도메인에 대한 모든 메일 배달이 실패합니다. 계속하기 전에 이러한 설정을 사용하지 않도록 설정해야 합니다. 커넥터가 하이브리드에 사용되는 온-프레미스 커넥터인 경우 온-프레미스 커넥터를 수정할 필요가 없습니다. 하지만 여전히 파트너 커넥터가 있는지 검사 수 있습니다.
  • 현재 메일 게이트웨이에서 받는 사람 유효성 검사도 제공하는 경우 도메인이 Microsoft 365에서 신뢰할 수 있는 도메인으로 구성되었는지 검사 수 있습니다. 이렇게 하면 불필요한 반송 메시지를 방지할 수 있습니다.

준비가 되면 도메인에 대한 MX 레코드를 전환합니다. 모든 도메인을 한 번에 마이그레이션할 수 있습니다. 또는 덜 자주 사용하는 도메인을 먼저 마이그레이션한 다음 나중에 마이그레이션할 수 있습니다.

언제든지 여기서 일시 중지하고 평가할 수 있습니다. 하지만 SCL=-1 메일 흐름 규칙을 해제하면 사용자는 가양성 확인을 위한 두 가지 환경이 서로 다를 수 있습니다. 일관된 단일 환경을 더 빨리 제공할수록 사용자와 지원 센터 팀이 누락된 메시지를 해결해야 할 때 더 행복해질 수 있습니다.

다음 단계

축하합니다! Office 365용 Microsoft Defender 마이그레이션을 완료했습니다. 이 마이그레이션 가이드의 단계를 수행했기 때문에 메일이 Microsoft 365로 직접 배달되는 처음 며칠은 훨씬 더 원활해야 합니다.

이제 Office 365용 Defender 정상 작동 및 유지 관리를 시작합니다. 파일럿 중에 경험한 것과 비슷하지만 더 큰 규모로 발생한 문제를 모니터링하고 watch. 스푸핑 인텔리전스 인사이트 및 가장 인사이트가 가장 유용하지만 다음 활동을 정기적으로 수행하는 것이 좋습니다.