이 시리즈의 첫 번째 기사에서는 OWA 사용자가 자동 전달 주소를 만드는 기능을 제거하는 방법에 대해 논의했습니다. 이는 조직 외부로의 이메일 전달을 막는 데 큰 역할을 하지만, OWA는 문제의 일부에 불과합니다. 우리는 또한 메시지가 외부 주소로 자동 전달되는 다른 방법에 대처해야 합니다.
예를 들어, Outlook 규칙은 메시지를 전달할 수 있습니다. PowerShell을 사용하여 전달 규칙을 검색할 수는 있지만, 그렇게 하면 계속해서 해야 할 많은 처리가 필요할 수 있습니다. 외부 자동 전달을 차단하는 더 견고한 방법을 고려해 봅시다.
도메인으로 차단하기
도메인으로 차단하는 것은 자동 전달된 메시지를 중지시키는 효과적인 방법입니다. 차단은 Set-RemoteDomain cmdlet(또는 메일 흐름 아래에서 원격 도메인 설정을 편집함으로써 EAC에서)을 사용하여 구현됩니다. 이 명령은 명시적 설정이 외부 도메인으로 전달을 허용하는 경우에만 도메인으로의 이메일 자동 전달을 중지합니다.
Set-RemoteDomain -Identity Default -AutoForwardEnabled $False
어떤 도메인이 자동 전달을 허용하는지 확인하려면 이 명령을 실행하세요:
Get-RemoteDomain |?{$_.AutoForwardEnabled -eq $True}| Format-Table DomainName, AutoReplyEnabled
DomainName AutoReplyEnabled
---------- ----------------
Contoso.com True
버려진 메시지 찾기
관리자는 PowerShell을 사용하거나 규정 준수 센터의 메시지 추적 GUI를 사용하여 메시지 추적을 실행하여 메시지가 차단되었는지 확인할 수 있습니다(그림 1).
테넌트를 통과하는 메시지 수가 많은 경우 PowerShell을 사용하여 드롭 이벤트를 찾는 것이 쉽습니다. Get-MessageTrace 명령은 많은 데이터를 처리할 수 있으므로, 메시지 이벤트를 가져오는 데 사용하는 시간 범위를 가능한 한 제한하는 것이 현명합니다. 이 코드는 두 시간 동안의 드롭된 메시지를 찾습니다.
Get-MessageTrace -StartDate "11-Feb-2020 17:36" -EndDate "11-Feb-2020 19:37" | Get-MessageTraceDetail | ?{$_.Event -eq "Drop" -and $_.Data -Match "BlockAFToExternalUser"} | Select MessageID, Date, Event, Detail, Data
메일 흐름 규칙 사용
원격 도메인으로의 자동 전달 차단의 간단함과 직접성이 매력적이지만, 이는 날카로운 도구입니다. 또 다른 접근 방법은 외부 수신자에게 보내지는 “자동 전달” 유형의 메시지를 가로채어 해당 메시지를 거부하고, 발신자에게 적절한 이유와 함께 배달 알림을 반환하는 메일 흐름 규칙을 만드는 것입니다. 예를 들어, “귀하의 메시지는 조직의 지적 재산의 기밀 유지를 위해 차단되었습니다.”
대신, 원하는 수신처에 자동 전달된 메시지를 전달할 수 있지만, 수신자가 메시지를 읽을 권리가 없도록 메시지에 제한적 민감도 레이블을 적용한 후에 전달해야 합니다. 여기서의 의도는 수신자에게 우리 조직의 콘텐츠를 보려고 하지 말아야 한다는 점을 강조하는 것입니다. 희망적으로 수신자가 자신의 짜증을 발신자에게 신고할 것이고, 그러면 발신자가 조직에서 금기시하는 행동을 하고 있다는 것을 깨닫게 될 수 있습니다.
Power Automate 주의
조직 외부로 콘텐츠를 전달하는 사용자들을 막기 위해 모든 장벽을 세운 후에 우리는 Power Automate가 우려 없이 메일 흐름 규칙, 도메인 차단 또는 메일함에서 자동 전달 주소를 제거하는 것과 같은 제한사항을 무시한다는 문제에 직면합니다. 이 문제는 Vasil Michev가 이전에 문서화했으나, 마이크로소프트는 이 문제를 개선하기 위해 아무것도 하지 않았습니다.
업데이트 (2020년 9월): Power Automate는 이제 메시지에 x-헤더를 삽입하여 이 트래픽을 전송 규칙을 사용하여 차단할 수 있습니다.
예를 들어, 마이크로소프트가 제공하는 템플릿을 사용하여 새 항목이 폴더에 도착할 때 메시지를 전달하는 새 흐름을 생성할 수 있습니다. 나는 표준 템플릿을 가져와 메일함에 연결한 다음 보관 폴더를 모니터링하도록 수정하고 외부 주소에 복사본을 보내도록 선택했습니다(그림 2).
결과적으로 Power Automate가 흐름을 실행할 때마다 보관 폴더에 새 메시지가 배치되면 외부 주소로 전달되었습니다. 메시지는 메시지 추적 로그에 나타나지만 정상적인 메시지처럼 보입니다.
Power Automate가 캡처한 감사 이벤트 세트 그리고 Office 365 감사 로그에 수집된 것은 꽤 부족하며 거기서 도움을 얻는 것은 별로 없습니다. 감사 로그에 표시되는 유일한 것은 OpenApiConnection 커넥터를 사용하여 흐름을 생성한 사용자입니다.
민감도 레이블이 해결책일 수 있습니다.
공통된 주제는 자동으로 전달된 메시지를 수신자가 읽을 수 있다는 것입니다. 이를 막으려면 수신자가 메시지 내용을 열고 액세스할 수 없도록 해야 하며 이를 위해서는 보호된 메시지를 사용해야 합니다.
S/MIME is one approach, but sensitivity labels are a better long-term solution because Microsoft is investing heavily to increase the usefulness of these labels across Office 365. The simple fact is that only those authorized to open protected messages can access their content, so when the messages are forwarded by rules, autoforwarding addresses, or Power Automate, the external recipient won’t be able to read them.
조직 통화
사용자가 이메일을 자동으로 전달할 수 있는지 여부를 결정하는 것은 조직의 데이터 거버넌스 전략의 일부로 이루어져야 합니다. 이메일이 테넌트 내에 남아 있어야 한다고 결정하는 경우 자동 전달 방지를 쉽게 설정할 수 있지만 이 정책을 사용자에게 전달하도록 기억하십시오.