기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 조직 작업
Amazon WorkMail에서 조직은 회사의 사용자를 나타냅니다. Amazon WorkMail 콘솔에는 사용 가능한 조직 목록이 표시됩니다. Amazon WorkMail을 사용하기 위해서는 사용 가능한 조직이 없는 경우 조직을 하나 생성해야 합니다.
**Topics**
+ [조직 생성](add_new_organization.md)
+ [조직 삭제](delete_organization.md)
+ [이메일 주소 찾기](find-emails.md)
+ [조직 설정 작업](org-settings.md)
+ [조직 태깅](org-tag.md)
+ [액세스 제어 규칙 작업](access-rules.md)
+ [사서함 보존 정책 설정](mailbox-retention-policy.md)
# 조직 생성
Amazon WorkMail을 사용하려면 먼저 조직을 생성해야 합니다. 하나의 AWS 계정에 여러 Amazon WorkMail 조직이 있을 수 있습니다. 조직을 생성할 때는 조직의 도메인을 선택하고 사용자 디렉터리 및 암호화 설정도 지정합니다.
Amazon WorkMail 조직과 함께 사용할 새 Amazon WorkMail 디렉터리를 생성하거나 Amazon WorkMail을 기존 디렉터리와 통합할 수 있습니다. Amazon WorkMail을 다음과 같은 유형의 기존 디렉터리와 함께 사용할 수 있습니다.
+ 온프레미스 Microsoft Active Directory
+ AWS Managed Active Directory([AWS Directory Service에서 관리하는 Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html))
+ Simple AD
온프레미스 디렉터리와 통합하여 Amazon WorkMail의 기존 사용자 및 그룹을 사용할 수 있고 사용자는 기존 보안 인증을 사용하여 로그인할 수 있습니다. 온프레미스 디렉터리를 사용하는 경우 먼저 AWS Directory Service에서 AD Connector를 설정해야 합니다. AD 커넥터는 사용자 및 그룹을 Amazon WorkMail 주소록과 동기화하고 사용자 인증 요청을 수행합니다. 자세한 내용은 *Directory Service 관리 안내서*의 [Active Directory Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html)를 참조하세요.
또한 Amazon WorkMail AWS KMS key 이 사서함 콘텐츠를 암호화하는 데 사용하는를 선택할 수 있습니다. Amazon WorkMail의 기본 AWS 관리형 마스터 키를 선택하거나 AWS Key Management Service ()에서 기존 KMS 키를 사용할 수 있습니다AWS KMS. 새 KMS 키 생성에 대한 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [키 생성](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)을 참조하세요. AWS Identity and Access Management (IAM) 사용자로 로그인한 경우 자신을 KMS 키의 키 관리자로 설정합니다. 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [키 활성화 및 비활성화](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html)를 참조하세요.
**고려 사항**
Amazon WorkMail 조직을 생성할 때는 다음 사항에 유의하세요.
+ Amazon WorkMail은 현재 여러 계정과 공유되는 관리형 Microsoft Active Directory 서비스를 지원하지 않습니다.
+ Microsoft Exchange와 AD Connector를 사용하는 온프레미스 Active Directory를 사용하는 경우 조직의 상호 운용성 설정을 구성하는 것이 좋습니다. 그러면 사서함을 Amazon WorkMail로 마이그레이션하거나 회사 사서함의 하위 세트에 Amazon WorkMail을 사용할 때 사용자가 경험하는 중단을 최소화합니다. 자세한 내용은 [Amazon WorkMail과 Microsoft Exchange 간의 상호 운용성](interoperability.md) 단원을 참조하십시오.
+ **무료 테스트 도메인** 옵션을 선택하면 제공된 테스트 도메인에서 Amazon WorkMail 조직을 사용할 수 있습니다. 테스트 도메인 형식은 *example*.awsapps.com입니다. Amazon WorkMail 조직에서 활성화된 사용자를 유지하는 한 Amazon WorkMail 및 기타 지원되는 AWS 서비스와 함께 테스트 메일 도메인을 사용할 수 있습니다. 하지만 테스트 도메인을 다른 용도로는 사용할 수 없습니다. Amazon WorkMail 조직에서 활성화된 사용자를 한 명 이상 유지하지 않는 경우 다른 고객이 테스트 도메인을 등록하고 사용하도록 제공될 수 있습니다.
+ Amazon WorkMail은 다중 리전 디렉터리를 지원하지 않습니다.
+ Amazon WorkMail은 4시간마다 디렉터리 데이터를 AWS 관리형 Active Directory, Simple AD 및 AD Connector와 동기화합니다.
## AWS 관리형 Active Directory 사용에 대한 중요 변경 사항
Amazon WorkMail은 AWS 관리형 Active Directory(관리형 AD)를 사용하는 조직에 대한 권한 부여 모델을 업데이트하고 있습니다. 이 변경 사항은 Amazon WorkMail이 디렉터리 데이터와 상호 작용하는 방식에 영향을 미치며, 기능이 계속 정상적으로 작동하려면 사용자가 특정 조치를 취해야 합니다.
이전에는 Amazon WorkMail 조직이 AWS 관리형 Active Directory로 생성되었을 때 Amazon WorkMail은 서비스 수준 권한을 사용하여 관리형 AD와 상호 작용했습니다. 고객이 디렉터리 관리 및 사서함 관리 역할을 분리할 수 있는 추가적인 유연성을 제공하기 위해 WorkMail의 API 및 콘솔은 이제 AWS Directory Service Data(DS-Data) API를 사용하여 AWS Managed Active Directory에서 사용자 및 그룹을 생성하거나 업데이트합니다. 또한 WorkMail 콘솔 또는 API를 통해 이러한 작업을 실행하는 IAM 위탁자는 WorkMail 조직과 연결된 Managed AD에 대해 동등한 DS-Data 작업을 사용할 수 있는 권한이 필요하므로 더 세분화된 제어와 IAM 정책과의 더 나은 통합을 제공합니다.
Managed AD를 사용하여 새 조직을 생성하든 Managed AD를 사용하는 기존 조직이 있든, WorkMail 콘솔 또는 API를 통해 사용자 및 그룹을 계속 생성, 업데이트 또는 삭제할 수 있으려면 업데이트된 권한 부여 모델에 맞게 정상적으로 작동하도록 추가적인 구성 단계를 완료해야 합니다. 이는 [AWS Managed Active Directory 통합 구성](#configure-managed-ad-integration) 섹션에 설명되어 있습니다.
**Topics**
+ [AWS 관리형 Active Directory 사용에 대한 중요 변경 사항](#important-changes)
+ [조직 생성](#create-organization)
+ [AWS Managed Active Directory 통합 구성](#configure-managed-ad-integration)
+ [조직 세부 정보 보기](#view-org-details)
+ [WorkSpaces 디렉터리 통합](#compatible)
+ [조직 상태 및 설명](#org-states)
## 조직 생성
Amazon WorkMail 콘솔에서 새 조직을 생성합니다.
**조직을 생성하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html)를 참조하세요.
1. 탐색 모음에서 **조직**을 선택합니다.
**조직** 페이지가 나타나고 조직(있는 경우)이 표시됩니다.
1. **조직 생성**을 선택합니다.
1. **이메일 도메인**에서 조직의 이메일 주소로 사용할 도메인을 선택합니다.
+ ****기존 Route 53 도메인**** - Amazon Route 53(Route 53) 호스팅 영역으로 관리하는 기존 도메인을 선택합니다.
+ ****새 Route 53 도메인**** - Amazon WorkMail과 함께 사용할 새 Route 53 도메인 이름을 등록합니다.
+ ****외부 도메인**** - 외부 도메인 이름 시스템(DNS) 공급자를 통해 관리하는 기존 도메인을 입력합니다.
+ ****무료 테스트 도메인**** - Amazon WorkMail에서 제공하는 무료 테스트 도메인을 사용합니다. 테스트 도메인을 사용하여 Amazon WorkMail을 탐색한 다음 나중에 조직에 도메인을 추가할 수 있습니다.
1. (선택 사항) Amazon Route 53을 통해 도메인을 관리하는 경우 **Route 53 호스팅 영역**에 대해 Route 53 도메인을 선택합니다.
1. **별칭**에 조직의 고유한 별칭을 입력합니다.
1. **고급 설정**을 선택하고 **사용자 디렉터리**에 대해 다음 옵션 중 하나를 선택합니다.
+ **새 Amazon WorkMail 디렉터리 생성** - 사용자를 추가하고 관리하기 위한 새 디렉터리를 생성합니다.
+ **기존 디렉터리 사용** - 온프레미스 Microsoft Active Directory, AWS Managed Active Directory 또는 Simple AD와 같은 기존 디렉터리를 사용하여 사용자를 관리합니다.
1. **암호화**에 대해 다음 옵션 중 하나를 선택합니다.
+ **Amazon WorkMail 관리 키 사용** - 계정에 새 암호화 키를 생성합니다.
+ **기존 KMS 키 사용** - AWS KMS에서 이미 생성한 기존 KMS 키를 사용합니다.
1. **조직 생성**을 선택합니다.
외부 도메인을 사용하는 경우 DNS 서비스에 적절한 텍스트(TXT) 및 메일 교환기(MX) 레코드를 추가하여 외부 도메인을 확인합니다. TXT 레코드를 사용하면 DNS 서비스에 대한 메모를 입력할 수 있습니다. MX 레코드는 수신 메일 서버를 지정합니다.
도메인을 조직의 기본 도메인으로 설정해야 합니다. 자세한 내용은 [도메인 확인](domain_verification.md) 및 [기본 도메인 선택](default_domain.md) 섹션을 참조하세요.
조직이 **활성 상태**이면 사용자를 추가하고 이메일 클라이언트를 설정할 수 있습니다. 자세한 내용은 [사용자 추가](add_user.md) 및 [Amazon WorkMail용 이메일 클라이언트 설정](https://docs.aws.amazon.com/workmail/latest/userguide/clients.html)을 참조하세요.
## AWS Managed Active Directory 통합 구성
Amazon WorkMail 조직에서 AWS Managed Active Directory를 사용하는 경우 업데이트된 권한 부여 모델에 맞춰 정상적으로 작동하도록 추가적인 구성 단계를 수행해야 합니다.
**새 조직에 대해 Managed AD 통합을 구성하는 방법**
1. Directory Service 콘솔에서 관리형 AD(Microsoft AD)로 이동하거나 Amazon WorkMail 콘솔에서 왼쪽 탐색 패널에서 **사용자** 또는 **그룹을** 선택한 다음 페이지 상단의 메모 상자에 있는 디렉터리 링크를 클릭합니다.
1. **사용자 및 그룹 관리**에 대해 **활성화**를 선택합니다. 이 설정은 기본적으로 비활성화되어 있으며, 사용자 및 그룹에서 쓰기 작업을 수행하려면 활성화해야 합니다.
1. IAM 위탁자가 필요한 권한을 갖도록 다음 작업이 포함된 정책을 연결합니다.
```
ds:AccessDSData
ds:ResetUserPassword
ds-data:CreateGroup
ds-data:DeleteGroup
ds-data:AddGroupMember
ds-data:RemoveGroupMember
ds-data:CreateUser
ds-data:DeleteUser
ds-data:UpdateUser
```
**기존 Managed AD 조직을 마이그레이션하는 방법**
1. Amazon WorkMail 콘솔의 사용자 또는 그룹 페이지에서 마이그레이션 알림을 모니터링합니다.
1. 알림이 나타나면 **업데이트된 디렉터리 작업 활성화**를 켜서 새 디렉터리 서비스 API로 마이그레이션합니다.
1. 마지막으로 Directory Service 콘솔에서 **사용자 및 그룹 관리를** 활성화하고 이전 섹션에 설명된 대로 필요한 DS-Data 권한으로 IAM 정책을 업데이트했는지 확인합니다.
사용자를 생성, 업데이트 및 삭제하기 위해 AWS 디렉터리 서비스 데이터(DS-Data) APIs를 사용하면 이전에 활성화되지 않은 관리형 AD를 사용하는 나머지 Amazon WorkMail 조직에 대해 활성화됩니다.
## 조직 세부 정보 보기
각 Amazon WorkMail 조직은 조직 세부 정보 페이지를 표시할 수 있습니다. 이 페이지에는 AWS Command Line Interface에서 사용할 수 있는 ID를 포함하여 해당 조직에 대한 정보가 표시됩니다. 페이지의 메시지에는 확인되지 않은 도메인이나 사용자 부족과 같이 설정 및 구성을 완료하는 데 필요한 모든 단계가 표시될 수도 있습니다. 메시지에서는 해당 이메일 클라이언트를 설정하기 위해 따라야 하는 첫 번째 단계도 제공합니다.
**조직 세부 정보를 확인하려면**
1. 탐색 모음에서 **조직**을 선택합니다.
**조직** 페이지가 나타나고 조직이 표시됩니다.
1. 표시할 조직을 선택합니다.
## WorkSpaces 디렉터리 통합
Amazon WorkMail을 WorkSpaces와 함께 사용하려면 다음 단계를 사용하여 호환 디렉터리를 생성합니다.
**호환되는 WorkSpaces 디렉터리를 추가하려면**
1. WorkSpaces를 사용하여 호환되는 디렉터리를 만듭니다. WorkSpaces 지침은 *Amazon WorkSpaces 관리 안내서*의 [Amazon WorkSpaces 빠른 설정 시작하기](https://docs.aws.amazon.com/workspaces/latest/adminguide/getting-started.html)를 참조하세요.
1. Amazon WorkMail 콘솔에서 Amazon WorkMail 조직을 생성하고 기존 디렉터리를 사용하도록 선택합니다. 자세한 내용은 [조직 생성](#create-organization) 단원을 참조하십시오.
## 조직 상태 및 설명
조직을 생성하면 조직은 다음 상태 중 하나일 수 있습니다.
****
| **상태** | 설명 |
| --- | --- |
| **활성** | 조직이 정상적인 상태로 사용할 준비가 되어 있습니다. |
| **생성 중** | 조직을 생성하는 워크플로우가 실행 중입니다. |
| **실패** | 조직을 생성할 수 없습니다. |
| [**Impaired**] | 조직이 제대로 작동하지 않거나 문제가 감지되었습니다. |
| **비활성** | 조직이 비활성 상태입니다. |
| [**Requested**] | 조직 생성 요청이 대기열에 있어 생성 대기 중입니다. |
| **검증** | 조직에 대한 모든 설정의 상태를 확인 중입니다. |
# 조직 삭제
조직의 이메일에 Amazon WorkMail을 더 이상 사용하지 않으려는 경우 Amazon WorkMail에서 조직을 삭제할 수 있습니다.
**참고**
이 작업은 실행 취소할 수 없습니다. 조직 삭제 후에는 사서함 데이터를 복구할 수 없습니다.
**조직을 삭제하는 방법**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html)를 참조하세요.
1. **조직** 화면의 조직 목록에서 제거할 조직을 선택하고 **삭제**를 선택합니다.
1. **조직 삭제**에서 조직의 이름을 입력한 후 기존 사용자 디렉터리를 유지할지 삭제할지 선택합니다.
1. 그런 다음 **조직 삭제**를 선택합니다.
**참고**
Amazon WorkMail용 디렉터리를 제공하지 않으셨다면 새로 만들어 드리겠습니다. 조직을 삭제할 때 이 기존 디렉터리를 유지할 경우 이 디렉터리가 Amazon WorkMail, WorkDocs 또는 WorkSpaces에서 사용되지 않는 한 요금이 부과됩니다. 요금에 대한 자세한 내용은 [기타 디렉터리 유형 요금](https://aws.amazon.com/directoryservice/other-directories-pricing/)을 참조하십시오.
디렉터리를 삭제하기 위해 다른 AWS 애플리케이션을 활성화할 수 없습니다. 자세한 내용은 *AWS Directory Service 관리 안내서*의 [Simple AD 디렉터리 삭제](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/simple_ad_delete.html) 또는 [AD Connector 디렉터리 삭제](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_delete.html)를 참조하세요.
조직을 삭제하려고 하면 잘못된 Amazon Simple Email Service(Amazon SES) 규칙 세트 오류 메시지가 표시될 수 있습니다. 이 오류가 발생하면 Amazon SES 콘솔에서 Amazon SES 규칙을 편집하고 잘못된 규칙 세트를 제거하세요. 편집하는 규칙의 규칙 이름에는 사용자의 Amazon WorkMail 조직 ID가 포함되어 있어야 합니다. Amazon SES 규칙 편집에 대한 자세한 내용은 *Amazon Simple Email Service 개발자 안내서*의 [수신 규칙 생성](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-receipt-rules-console-walkthrough.html)을 참조하세요.
잘못된 규칙 세트를 찾아야 하는 경우 먼저 규칙을 저장합니다. 규칙 세트에 대해 오류 메시지가 표시됩니다.
# 이메일 주소 찾기
해당 이메일 주소가 조직 내에서 사용자, 리소스 또는 그룹에 의해 사용되고 있는지 확인할 수 있습니다.
**이메일 주소를 찾는 방법**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. **조직** 페이지에서 **이메일 주소 찾기**를 선택합니다.
1. **검색**을 선택합니다.
# 조직 설정 작업
다음 섹션에서는 Amazon WorkMail 조직에 사용할 수 있는 설정을 사용하는 방법을 설명합니다. 선택한 설정은 전체 조직에 적용됩니다.
**Topics**
+ [사서함 마이그레이션 활성화](migration-settings.md)
+ [저널링 활성화](journaling.md)
+ [상호 운용성 활성화](enable-interop.md)
+ [SMTP 게이트웨이 활성화](smtp-gateway.md)
+ [이메일 흐름 관리](email-flows.md)
+ [수신 이메일에 DMARC 정책 적용](inbound-dmarc.md)
# 사서함 마이그레이션 활성화
Microsoft Exchange 또는 G Suite Basic과 같은 소스에서 Amazon WorkMail로 사서함을 전송하려는 경우 사서함 마이그레이션을 활성화합니다. 대규모 마이그레이션 프로세스의 일환으로 마이그레이션을 활성화합니다. 방법 안내 단계를 포함한 자세한 내용은 이 설명서의 *시작하기* 섹션에서 [Amazon WorkMail로 마이그레이션](migration_overview.md)을 참조하세요.
# 저널링 활성화
이메일 통신을 기록하도록 저널링을 활성화할 수 있습니다. 저널링을 사용할 때는 일반적으로 통합된 타사 보관 및 eDiscovery 도구를 사용합니다. 저널링은 데이터 스토리지, 개인 정보 보호, 정보 보호를 위한 준수 규정을 충족하도록 보장하는 데 도움이 됩니다.
방법 안내 단계를 포함한 자세한 내용은 이 설명서의 *시작하기* 섹션에서 [Amazon WorkMail을 통해 이메일 저널링 사용](journaling_overview.md)을 참조하세요.
# 상호 운용성 활성화
상호 운용성을 통해 Microsoft Exchange에서 마이그레이션하고 Amazon WorkMail을 회사 사서함의 하위 집합으로 사용할 수 있습니다. 방법 안내 단계를 포함한 자세한 내용은 이 설명서의 *시작하기* 섹션에서 [Amazon WorkMail에서 가용성 설정 구성](enable_interop_wm.md)을 참조하세요.
# SMTP 게이트웨이 활성화
아웃바운드 이메일 흐름 규칙에서 Simple Mail Transfer Protocol(SMTP) 게이트웨이를 사용하도록 설정합니다. 아웃바운드 이메일 흐름 규칙을 사용하면 SMTP 게이트웨이를 통해 Amazon WorkMail 조직에서 발송한 이메일 메시지를 라우팅할 수 있습니다. 자세한 내용은 [아웃바운드 이메일 규칙 작업](email-flows.md#email-flows-rule-outbound) 단원을 참조하십시오.
**참고**
아웃바운드 이메일 흐름 규칙에 구성한 SMTP 게이트웨이는 주요 인증 기관의 인증서를 사용하여 전송 계층 보안(TLS) v1.2를 지원해야 합니다. 기본 인증만 지원됩니다.
**SMTP 게이트웨이를 구성하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. 탐색 창에서 **조직 설정**을 선택합니다.
**조직 설정** 페이지가 나타나고 탭 세트가 표시됩니다.
1. **SMTP 게이트웨이** 탭을 선택한 다음 **게이트웨이 생성**을 선택합니다.
1. 다음을 입력합니다.
+ **게이트웨이 이름** - 고유한 이름을 입력합니다.
+ **게이트웨이 주소** - 게이트웨이의 호스트 이름 또는 IP 주소를 입력합니다.
+ **포트 번호** - 게이트웨이의 포트 번호를 입력합니다.
+ **사용자 이름** - 사용자 이름을 입력합니다.
+ **암호** - 강력한 암호를 입력합니다.
1. **생성(Create)**을 선택합니다.
SMTP 게이트웨이는 아웃바운드 이메일 흐름 규칙에 사용할 수 있습니다.
아웃바운드 이메일 흐름 규칙과 함께 사용하도록 SMTP 게이트웨이를 구성하면 아웃바운드 메시지가 규칙을 SMTP 게이트웨이와 일치시키려고 시도합니다. 규칙과 일치하는 메시지는 해당 SMTP 게이트웨이로 라우팅되며, 해당 SMTP 게이트웨이는 나머지 이메일 전송을 처리합니다.
Amazon WorkMail이 SMTP 게이트웨이에 도달할 수 없는 경우 시스템은 이메일 메시지를 발신자에게 반송합니다. 이 경우 이전 단계에 따라 게이트웨이 설정을 수정하세요.
# 이메일 흐름 관리
이메일 관리에 도움이 되도록 *이메일 흐름 규칙*을 설정할 수 있습니다. 이메일 흐름 규칙은 주소 또는 도메인을 기반으로 이메일 메시지에 대해 하나 이상의 작업을 수행할 수 있습니다. 발신자 및 수신자 모두의 이메일 주소 또는 도메인에서 이메일 흐름 규칙을 사용할 수 있습니다.
이메일 흐름 규칙을 만들 때는 지정된 규칙 [*패턴*](#email-flows-patterns)이 일치할 때 이메일에 적용되는 [*규칙 작업*](#email-flows-rule-actions)을 지정합니다.
**Topics**
+ [인바운드 이메일 규칙 작업](#email-flows-rule-actions)
+ [아웃바운드 이메일 규칙 작업](#email-flows-rule-outbound)
+ [발신자 및 수신자 패턴](#email-flows-patterns)
+ [이메일 흐름 규칙 생성](create-email-rules.md)
+ [이메일 흐름 규칙 편집](edit-rules.md)
+ [Amazon WorkMail AWS Lambda 용 구성](lambda.md)
+ [Amazon WorkMail Message Flow API에 대한 액세스 관리](lambda-content-access.md)
+ [이메일 흐름 규칙 테스트](test-email-flow-rule.md)
+ [이메일 흐름 규칙 제거](remove-email-flow-rule.md)
## 인바운드 이메일 규칙 작업
인바운드 이메일 흐름 규칙은 원치 않는 이메일이 사용자의 사서함에 도착하지 않도록 하는 데 도움이 됩니다. 규칙 작업이라고도 하는 인바운드 이메일 흐름 규칙은 Amazon WorkMail 조직 내의 사용자에게 보낸 모든 이메일 메시지에 자동으로 적용됩니다. 이는 개별 사서함에 대한 이메일 규칙과 다릅니다.
**참고**
선택적으로 AWS Lambda 함수와 함께 규칙을 사용하여 수신 이메일이 사용자의 사서함으로 전송되기 전에 처리할 수 있습니다. Amazon WorkMail에서 Lambda 사용에 대한 자세한 내용은 [Amazon WorkMail AWS Lambda 용 구성](lambda.md) 단원을 참조하세요. Lambda에 대한 자세한 내용은 [https://docs.aws.amazon.com/lambda/latest/dg/welcome.html](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)를 참조하세요.
규칙 작업이라고도 하는 인바운드 이메일 흐름 규칙은 Amazon WorkMail 조직 내의 사용자에게 보낸 모든 이메일 메시지에 자동으로 적용됩니다. 이는 개별 사서함에 대한 이메일 규칙과 다릅니다.
다음 규칙 작업은 인바운드 이메일이 처리되는 방식을 정의합니다. 각 규칙에 대해 다음 작업 중 하나와 함께 [발신자 및 수신자 패턴](#email-flows-patterns)을 지정합니다.
****
| 작업 | 설명 |
| --- | --- |
| 이메일 삭제 | 이메일 메시지는 무시됩니다. 이메일이 전달되지 않고, 발신자에게 전달되지 않음을 알리지 않습니다. |
| 반송 메일 응답 보내기 | 이메일 메시지가 전달되지 않고, 반송 메일 메시지를 통해 발신자에게 전달되지 않음을 알립니다. |
| 정크 폴더로 전달 | Amazon WorkMail 스팸 감지 시스템에서 스팸으로 원래 식별하지 않은 경우에도 이메일 메시지가 사용자의 스팸 또는 정크 폴더로 전달됩니다. |
| 기본값 | Amazon WorkMail 스팸 감지 시스템에서 확인된 후 이메일 메시지가 전달됩니다. 스팸 이메일은 정크 폴더로 전달됩니다. 기타 모든 이메일 메시지는 받은 편지함으로 전달됩니다. 덜 구체적인 발신자 패턴을 사용하는 기타 이메일 흐름 규칙은 무시됩니다. 도메인 기반 이메일 흐름 규칙에 예외를 추가하려면 더 구체적인 발신자 패턴을 사용하여 기본 작업을 구성합니다. 자세한 내용은 [발신자 및 수신자 패턴](#email-flows-patterns) 단원을 참조하십시오. |
| 정크 폴더로 전달 안 함 | Amazon WorkMail 스팸 감지 시스템에서 스팸으로 식별된 경우에도 이메일 메시지가 항상 사용자의 받은 편지함으로 전달됩니다. 기본 스팸 감지 시스템을 우회하면 지정된 주소의 위험성이 높은 콘텐츠에 사용자가 노출될 수 있습니다. |
| 실행 AWS Lambda | 이메일 메시지를 사용자의 받은 편지함으로 전송하기 전에 또는 전송 중에 처리를 위해 Lambda 함수에 전달합니다. |
**참고**
인바운드 이메일은 먼저 Amazon SES에 전달된 후 Amazon WorkMail에 전달됩니다. Amazon SES가 수신 이메일을 차단하면 규칙 작업은 적용되지 않습니다. 예를 들어, Amazon SES는 알려진 바이러스가 감지될 때 또는 명시적인 IP 필터링 규칙 때문에 이메일 메시지를 차단합니다. **Default(기본)**, **Deliver to junk folder(정크 폴더로 전달)** 또는 **Never deliver to junk folder(정크 폴더로 전달 안 함)**와 같은 규칙 작업을 지정하면 아무 영향도 미치지 않습니다.
## 아웃바운드 이메일 규칙 작업
아웃바운드 이메일 흐름 규칙을 사용하여 SMTP 게이트웨이를 통해 이메일 메시지를 보내거나, 발신자가 지정된 수신자에게 이메일 메시지를 전송하는 것을 차단합니다. SMTP 게이트웨이에 대한 자세한 내용은 [SMTP 게이트웨이 활성화](smtp-gateway.md) 부분을 참조하세요.
또한 아웃바운드 이메일 흐름 규칙을 사용하여 이메일 메시지가 전송된 후 처리를 위해 AWS Lambda 함수에 이메일을 전달할 수 있습니다. Lambda에 대한 자세한 내용은 [https://docs.aws.amazon.com/lambda/latest/dg/welcome.html](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)를 참조하세요.
다음 규칙 작업은 아웃바운드 이메일이 처리되는 방식을 정의합니다. 각 규칙에 대해 다음 작업 중 하나와 함께 [발신자 및 수신자 패턴](#email-flows-patterns)을 지정합니다.
****
| 작업 | 설명 |
| --- | --- |
| 기본값 | 이메일 메시지가 정상 흐름을 통해 전송됩니다. |
| 이메일 삭제 | 이메일 메시지가 삭제됩니다. 이메일이 전송되지 않고, 발신자에게 알리지 않습니다. |
| 반송 메일 응답 보내기 | 이메일 메시지가 전송되지 않고, 관리자가 이메일 메시지를 차단했다는 메시지를 발신자에게 보냅니다. |
| SMTP 게이트웨이로 라우팅 | 구성된 SMTP 게이트웨이를 통해 이메일 메시지가 전송됩니다. |
| Lambda 실행 | 이메일 메시지가 전송되기 전이나 전송 중에 처리를 위해 이메일 메시지를 Lambda 함수에 전달합니다. |
## 발신자 및 수신자 패턴
이메일 흐름 규칙은 특정 이메일 주소나 특정 도메인 또는 도메인 세트의 모든 이메일 주소에 적용할 수 있습니다. 패턴을 정의하여 규칙을 적용할 이메일 주소를 결정합니다.
발신자 및 수신자 패턴은 다음 형식 중 하나입니다.
+ *이메일 주소*는 단일 이메일 주소와 일치합니다. 예를 들어 다음과 같습니다.
```
mailbox@example.com
```
+ *도메인 이름*은 도메인의 모든 이메일 주소와 일치합니다. 예를 들어 다음과 같습니다.
```
example.com
```
+ *와일드카드 도메인*은 해당 도메인과 모든 하위 도메인의 모든 이메일 주소와 일치합니다. 와일드카드는 도메인 앞에만 나타납니다. 예를 들면 다음과 같습니다.
```
*.example.com
```
+ *별표*는 모든 도메인의 모든 이메일 주소와 일치합니다.
```
*
```
**참고**
\$1 기호는 발신자 또는 수신자 패턴 내에서 유효하지 않습니다.
규칙 하나에 대해 여러 패턴을 지정할 수 있습니다. 자세한 내용은 [인바운드 이메일 규칙 작업](#email-flows-rule-actions) 및 [아웃바운드 이메일 규칙 작업](#email-flows-rule-outbound) 섹션을 참조하세요.
인바운드 이메일 메시지의 `Sender` 또는 `From` 헤더가 특정 패턴과 일치하는 경우 인바운드 이메일 흐름 규칙이 적용됩니다. 있는 경우 `Sender` 주소가 먼저 일치됩니다. `Sender` 헤더가 없거나 `Sender` 헤더가 어떠한 규칙과도 일치하지 않는 경우에는 그 다음으로 `From` 주소가 일치됩니다. 다양한 규칙과 일치하는 이메일 메시지에 대해 여러 수신자가 있는 경우 일치된 수신자에 대해 각 규칙이 적용됩니다.
아웃바운드 이메일 메시지의 수신자 및 `Sender` 또는 `From` 헤더가 특정 패턴과 일치하는 경우 아웃바운드 이메일 흐름 규칙이 적용됩니다. 다양한 규칙과 일치하는 이메일 메시지에 대해 여러 수신자가 있는 경우 일치된 수신자에 대해 각 규칙이 적용됩니다.
여러 개의 규칙이 일치하는 경우 가장 구체적인 규칙의 작업이 적용됩니다. 예를 들면 특정 이메일 주소에 대한 규칙이 전체 도메인에 대한 규칙보다 우선합니다. 여러 규칙에 동일한 구체성이 있는 경우 가장 제한적인 작업이 적용됩니다. 예를 들면 **Drop(삭제)** 작업이 **Bounce(반송)** 작업보다 우선합니다. 작업에 대한 우선순위 순서는 [인바운드 이메일 규칙 작업](#email-flows-rule-actions) 및 [아웃바운드 이메일 규칙 작업](#email-flows-rule-outbound)에 나열된 순서와 동일합니다.
**참고**
**삭제** 또는 **반송 메일** 작업을 사용해 발신자 패턴이 중첩된 규칙을 생성하는 경우 주의해야 합니다. 예기치 않은 우선순위 순서 지정으로 인해 많은 수의 인바운드 이메일 메시지가 전달되지 않을 수 있습니다.
# 이메일 흐름 규칙 생성
이메일 흐름 규칙은 수신 및 발신 이메일 메시지에 [규칙 작업](email-flows.md#email-flows-rule-actions)을 적용합니다. 메시지가 지정된 [패턴](email-flows.md#email-flows-patterns)과 일치하는 경우 작업이 적용됩니다. 새 이메일 흐름 규칙은 즉시 적용됩니다.
**이메일 흐름 규칙을 생성하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. 탐색 창에서 **조직 설정**을 선택합니다.
**조직 설정** 페이지가 나타나고 탭 세트가 표시됩니다. 이 페이지에서 인바운드 또는 아웃바운드 규칙을 만들 수 있습니다. 다음 단계에서는 두 유형을 모두 생성하는 방법에 대해 설명합니다.
**인바운드 규칙을 만들려면**
1. **인바운드 규칙** 탭을 선택한 후 **생성**을 선택합니다.
1. **규칙 이름** 상자에 고유한 이름을 입력합니다.
1. **작업**에서 목록을 열고 작업을 선택합니다. 목록의 각 항목에는 설명이 포함되며 일부는 **자세히 알아보기** 링크를 제공합니다.
**참고**
**Run Lambda** 작업을 선택하면 추가 컨트롤이 나타납니다. 이러한 컨트롤 사용에 대한 자세한 내용은 다음 섹션인 [Amazon WorkMail AWS Lambda 용 구성](lambda.md)을 참조하세요.
1. **발신자 도메인 또는 주소**에 규칙을 적용할 발신자 도메인 또는 주소를 입력합니다.
1. **대상 도메인 또는 주소**에서 대상 도메인과 이메일 주소를 원하는 대로 조합하여 입력합니다.
1. **생성(Create)**을 선택합니다.
**아웃바운드 규칙을 만들려면**
1. **아웃바운드 규칙** 탭을 선택하고 **생성**을 선택합니다.
1. **규칙 이름** 상자에 고유한 이름을 입력합니다.
1. **작업**에서 목록을 열고 작업을 선택합니다. 목록의 각 항목에는 설명이 포함되며 일부는 **자세히 알아보기** 링크를 제공합니다.
**참고**
**Lambda 실행** 작업을 선택하면 추가 컨트롤이 나타납니다. 해당 제어에 대한 자세한 내용은 다음 섹션인 [Amazon WorkMail AWS Lambda 용 구성](lambda.md)을 참조하세요.
1. **발신자 도메인 또는 주소**에서 유효한 발신자 도메인과 이메일 주소를 원하는 대로 조합하여 입력합니다.
1. **대상 도메인 또는 주소**에서 유효한 대상 도메인과 이메일 주소를 원하는 대로 조합하여 입력합니다.
1. **생성(Create)**을 선택합니다.
생성한 새 이메일 흐름 규칙을 테스트할 수 있습니다. 자세한 내용은 [이메일 흐름 규칙 테스트](test-email-flow-rule.md) 단원을 참조하십시오.
# 이메일 흐름 규칙 편집
이메일 메시지에 대한 하나 이상의 [규칙 작업](email-flows.md#email-flows-rule-actions)을 변경해야 할 때마다 이메일 흐름 규칙을 편집합니다. 이 섹션의 단계는 수신 및 발신 이메일 메시지에 적용됩니다.
**이메일 흐름 규칙을 편집하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. 탐색 창에서 **조직 설정**을 선택합니다.
**조직 설정** 페이지가 나타나고 탭 세트가 표시됩니다.
1. **인바운드 규칙** 또는 **아웃바운드 규칙** 탭을 선택합니다.
1. 변경할 규칙 옆에 있는 라디오 버튼을 선택한 다음 **편집**을 선택합니다.
1. 필요에 따라 규칙의 동작을 변경한 다음 **저장**을 선택합니다.
# Amazon WorkMail AWS Lambda 용 구성
인바운드 및 아웃바운드 이메일 흐름 규칙에서 **Lambda 실행** 작업을 사용하여 규칙과 일치하는 이메일 메시지를 처리를 위해 AWS Lambda 함수에 전달합니다.
Amazon WorkMail에서 **Lambda 실행** 작업을 수행하려면 다음 구성 중에서 선택하세요.
**동기식 **Lambda 실행** 구성**
흐름 규칙과 일치하는 이메일 메시지는 전송되기 전에 처리를 위해 Lambda 함수로 전달됩니다. 이 구성을 사용하여 이메일 콘텐츠를 수정할 수 있습니다. 또한 다양한 사용 사례에 맞게 인바운드 또는 아웃바운드 이메일 흐름을 제어할 수 있습니다. 예를 들어, Lambda 함수에 전달된 규칙은 민감한 이메일 메시지의 전송을 차단하거나 첨부 파일을 제거하거나 고지 사항을 추가할 수 있습니다.
**비동기식 **Lambda 실행** 구성**
흐름 규칙과 일치하는 이메일 메시지는 전송되는 동안 처리를 위해 Lambda 함수로 전달됩니다. 이 구성은 이메일 전송에 영향을 주지 않으며 인바운드 또는 아웃바운드 이메일 메시지에 대한 지표 수집과 같은 작업에 사용됩니다.
동기식 구성을 선택하든 비동기식 구성을 선택하든 상관없이 Lambda 함수에 전달된 이벤트 객체에는 인바운드 또는 아웃바운드 이메일 이벤트에 대한 메타데이터가 포함됩니다. 메타데이터의 메시지 ID를 사용하여 이메일 메시지의 전체 콘텐츠에 액세스할 수도 있습니다. 자세한 내용은 [를 사용하여 메시지 콘텐츠 검색 AWS Lambda](lambda-content.md) 단원을 참조하십시오. 이메일 이벤트에 대한 자세한 내용은 [Lambda 이벤트 데이터](#lambda-data) 다음을 참조하십시오.
인바운드 및 아웃바운드 이메일 흐름 규칙에 대한 자세한 내용은 [이메일 흐름 관리](email-flows.md) 단원을 참조하십시오. Lambda에 대한 자세한 내용은 [https://docs.aws.amazon.com/lambda/latest/dg/welcome.html](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)를 참조하세요.
**참고**
현재 Lambda 이메일 흐름 규칙은 구성 중인 Amazon WorkMail 조직 AWS 계정 과 동일한 AWS 리전 및의 Lambda 함수만 참조합니다.
## Amazon WorkMail AWS Lambda 용 시작하기
Amazon WorkMail AWS Lambda 에서 사용을 시작하려면에서 계정으로 [ WorkMail Hello World Lambda 함수](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:489970191081:applications/workmail-hello-world-python) AWS Serverless Application Repository 를 배포하는 것이 좋습니다. 이 함수에는 필요한 모든 리소스와 사용자를 위해 구성된 권한이 있습니다. 더 많은 예를 보려면 GitHub의 [amazon-workmail-lambda-templates](https://github.com/aws-samples/amazon-workmail-lambda-templates) 리포지토리를 참조하세요.
자체 Lambda 함수를 생성하기로 선택한 경우 AWS Command Line Interface ()를 사용하여 권한을 구성해야 합니다AWS CLI. 다음 예제 명령에서 사용하려면 다음을 수행합니다.
+ `MY_FUNCTION_NAME`을 Lambda 함수의 이름으로 바꿉니다.
+ `REGION`을 Amazon WorkMail AWS 리전으로 대체합니다. 사용 가능한 Amazon WorkMail 리전에는 `us-east-1`(미국 동부(버지니아 북부)), `us-west-2`(미국 서부(오레곤)) 및 `eu-west-1`(유럽(아일랜드))가 포함됩니다.
+ `AWS_ACCOUNT_ID`를 12자리 AWS 계정 ID로 바꿉니다.
+ `WORKMAIL_ORGANIZATION_ID`를 Amazon WorkMail 조직 ID로 대체합니다. 조직 페이지의 **조직** 카드에서 찾을 수 있습니다.
```
aws --region REGION lambda add-permission --function-name MY_FUNCTION_NAME
--statement-id AllowWorkMail
--action "lambda:InvokeFunction"
--principal workmail.REGION.amazonaws.com
--source-arn arn:aws:workmail:REGION:AWS_ACCOUNT_ID:organization/WORKMAIL_ORGANIZATION_ID
```
사용에 대한 자세한 내용은 [https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) AWS CLI참조하세요.
## 동기식 **Lambda 실행** 규칙 구성
동기식 **Lambda 실행** 규칙을 구성하려면 **Lambda 실행** 작업이 포함된 이메일 흐름 규칙을 생성하고 **동기식 실행** 확인란을 선택합니다. 메일 흐름 규칙 생성에 대한 자세한 내용은 [이메일 흐름 규칙 생성](create-email-rules.md) 단원을 참조하십시오.
동기식 규칙 생성을 완료하려면 Lambda Amazon 리소스 이름(ARN)을 추가하고 다음 옵션을 구성합니다.
****폴백 작업****
Amazon WorkMail 작업은 Lambda 함수를 실행하지 못하면 적용됩니다. 이 작업은 **allRecipients** 플래그가 설정되지 않은 경우 Lambda 응답에서 생략된 모든 수신자에게도 적용됩니다. **폴백 작업**은 다른 Lambda 작업이 될 수 없습니다.
****규칙 제한 시간**(분)**
Amazon WorkMail이 호출하지 못할 경우 Lambda 함수가 다시 시도되는 기간입니다. **폴백 작업**은 이 기간이 끝날 때 적용됩니다.
**참고**
동기식 **Lambda 실행** 규칙은 **\$1** 대상 조건만 지원합니다.
## Lambda 이벤트 데이터
Lambda 함수는 다음 이벤트 데이터를 사용하여 트리거됩니다. 데이터 표시는 Lambda 함수에 사용되는 프로그래밍 언어에 따라 다릅니다.
```
{
"summaryVersion": "2018-10-10",
"envelope": {
"mailFrom" : {
"address" : "from@example.com"
},
"recipients" : [
{ "address" : "recipient1@example.com" },
{ "address" : "recipient2@example.com" }
]
},
"sender" : {
"address" : "sender@example.com"
},
"subject" : "Hello From Amazon WorkMail!",
"messageId": "00000000-0000-0000-0000-000000000000",
"invocationId": "00000000000000000000000000000000",
"flowDirection": "INBOUND",
"truncated": false
}
```
이벤트 JSON에는 다음 데이터가 포함됩니다.
**summaryVersion**
`LambdaEventData`의 버전 번호입니다. `LambdaEventData`에서 이전 버전과 호환되지 않는 변경을 한 경우에만 업데이트됩니다.
**envelope**
다음 필드가 포함된 이메일 메시지의 엔벌로프입니다.
**mailFrom**
**보낸 사람** 주소 - 일반적으로 이메일 메시지를 보낸 사용자의 이메일 주소입니다. 사용자가 다른 사용자로 또는 다른 사용자를 대신하여 이메일 메시지를 전송한 경우 **mailFrom** 필드는 이메일 메시지 전송을 위임한 사용자의 이메일 주소를 반환합니다(실제 발신자의 이메일 주소를 반환하지 않음).
**recipients**
모든 수신자 이메일 주소의 목록입니다. Amazon WorkMail은 **받는 사람**, **참조** 또는 **BCC**를 구분하지 않습니다.
인바운드 이메일 흐름 규칙의 경우, 이 목록에는 규칙을 생성한 Amazon WorkMail 조직의 모든 도메인의 수신자가 포함됩니다. Lambda 함수는 각 SMTP 대화에 대해 발신자로부터 개별적으로 호출되고, 수신자 필드에는 SMTP 대화의 수신자가 나열됩니다. 외부 도메인의 수신자는 포함되지 않습니다.
**sender**
다른 사용자를 대신하여 이메일 메시지를 전송한 사용자의 이메일 주소입니다. 이 필드는 다른 사용자를 대신하여 이메일 메시지를 전송할 때만 설정됩니다.
**subject**
이메일 제목줄입니다. 256자 제한을 초과할 경우 잘립니다.
**messageId**
Amazon WorkMail 메시지 흐름 SDK 사용 시 이메일 메시지의 전체 콘텐츠에 액세스할 때 사용되는 고유한 ID입니다.
**invocationId**
고유한 Lambda 호출의 ID입니다. 이 ID는 동일한 **LambdaEventData**에 대해 Lambda 함수가 두 번 이상 호출되는 경우에도 동일하게 유지됩니다. 재시도를 감지하고 중복을 방지하는 데 사용합니다.
**flowDirection**
이메일 흐름의 방향을 **INBOUND** 또는 **OUTBOUND**로 나타냅니다.
**truncated**
제목 행 길이가 아니라 페이로드 크기에 적용됩니다. `true`인 경우 페이로드 크기가 128KB 제한을 초과하면 제한을 충족하기 위해 수신자 목록이 잘립니다.
## 동기식 **Lambda 실행** 응답 스키마
동기식 **Lambda 실행** 작업이 포함된 이메일 흐름 규칙이 인바운드 또는 아웃바운드 이메일 메시지와 일치하면 Amazon WorkMail이 구성된 Lambda 함수를 호출하고 응답을 기다린 후 이메일 메시지에 대해 작업을 수행합니다. Lambda 함수는 작업, 작업 유형, 적용 가능한 파라미터 및 작업이 적용되는 수신자를 나열하는 미리 정의된 스키마에 따라 응답을 반환합니다.
다음 예는 동기식 **Lambda 실행** 응답을 보여줍니다. 응답은 Lambda 함수에 사용되는 프로그래밍 언어에 따라 다릅니다.
```
{
"actions": [
{
"action" : {
"type": "string",
"parameters": { various }
},
"recipients": [list of strings],
"allRecipients": boolean
}
]
}
```
응답 JSON에는 다음과 같은 데이터가 포함됩니다.
**작업**
수신자에 대해 수행할 작업입니다.
**type**
작업 유형입니다. 비동기식 **Lambda 실행** 작업에 대해 작업 유형이 반환되지 않습니다.
인바운드 규칙 작업 유형에는 **BOUNCE**, **DROP**, **DEFAULT**, **BYPASS\$1SPAM\$1CHECK** 및 **MOVE\$1TO\$1JUNK**가 포함됩니다. 자세한 내용은 [인바운드 이메일 규칙 작업](email-flows.md#email-flows-rule-actions) 단원을 참조하십시오.
아웃바운드 규칙 작업 유형에는 **BOUNCE**, **DROP** 및 **DEFAULT**가 포함됩니다. 자세한 내용은 [아웃바운드 이메일 규칙 작업](email-flows.md#email-flows-rule-outbound) 단원을 참조하십시오.
**parameters**
추가 작업 파라미터입니다. **BOUNCE** 작업 유형에 대해 **BounceMessage** 키 및 **string** 값이 포함된 JSON 객체로 지원됩니다. 이 반송 메일 메시지는 반송 이메일 메시지를 생성하는 데 사용됩니다.
**recipients**
작업을 수행해야 하는 이메일 주소의 목록입니다. 원래 수신자 목록에 포함되지 않은 경우에도 새 수신자를 응답에 추가할 수 있습니다. **allRecipients**가 작업에 대해 true인 경우에는 이 필드가 필요하지 않습니다.
인바운드 이메일에 대해 Lambda 작업이 호출되면 조직의 새 수신자만 추가할 수 있습니다. 새 수신자는 **숨은 참조**로 응답에 추가됩니다.
**allRecipients**
true인 경우 Lambda 응답에서 다른 특정 작업이 적용되지 않는 모든 수신자에게 작업을 적용합니다.
### 동기식 **Lambda 실행** 작업 제한
Amazon WorkMail에서 동기식 **Lambda 실행** 작업에 대해 Lambda 함수를 호출할 때는 다음과 같은 제한이 적용됩니다.
+ Lambda 함수는 15초 내에 응답하거나 실패한 호출로 처리되어야 합니다.
**참고**
시스템은 사용자가 지정한 **규칙 제한 시간** 간격 동안 간접 호출을 재시도합니다.
+ 최대 256KB의 Lambda 함수 응답이 허용됩니다.
+ 응답에는 최대 10개의 고유 작업이 허용됩니다. 10개 이상의 작업에는 구성된 **폴백 작업**이 적용됩니다.
+ 아웃바운드 Lambda 함수에는 최대 500명의 수신자가 허용됩니다.
+ **규칙 제한 시간**의 최대값은 240분입니다. 최소값 0이 구성되어 있으면 Amazon WorkMail이 폴백 작업을 적용하기 전에 다시 시도하지 않습니다.
### 동기식 **Lambda 실행** 작업 실패
Amazon WorkMail이 오류, 잘못된 응답 또는 Lambda 타임아웃으로 인해 Lambda 함수를 호출할 수 없는 경우, Amazon WorkMail은 지수 백오프를 사용하여 호출을 재시도하여 **규칙 제한 시간** 기간이 완료될 때까지 처리 속도를 줄입니다. 그런 다음 이메일 메시지의 모든 수신자에게 **폴백 작업**이 적용 됩니다. 자세한 내용은 [동기식 **Lambda 실행** 규칙 구성](#synchronous-rules) 단원을 참조하십시오.
## 동기식 **Lambda 실행** 응답 예
다음 예에서는 일반적인 동기식 **Lambda 실행** 응답의 구조를 보여줍니다.
**Example : 이메일 메시지에서 지정된 수신자 제거**
다음 예에서는 이메일 메시지에서 수신자를 제거하기 위한 동기식 **Lambda 실행** 응답의 구조를 보여줍니다.
```
{
"actions": [
{
"action": {
"type": "DEFAULT"
},
"allRecipients": true
},
{
"action": {
"type": "DROP"
},
"recipients": [
"drop-recipient@example.com"
]
}
]
}
```
**Example : 사용자 지정 이메일 메시지가 포함된 반송 메일**
다음 예에서는 사용자 지정 이메일 메시지로 반송하기 위한 동기식 **Lambda 실행** 응답의 구조를 보여줍니다.
```
{
"actions" : [
{
"action" : {
"type": 'BOUNCE',
"parameters": {
"bounceMessage" : "Email in breach of company policy."
}
},
"allRecipients": true
}
]
}
```
**Example : 이메일 메시지에 수신자 추가**
다음 예에서는 이메일 메시지에 수신자를 추가하기 위한 동기식 **Lambda 실행** 응답의 구조를 보여줍니다. 이렇게 해도 이메일 메시지의 **받는 사람** 또는 **CC** 필드는 업데이트되지 않습니다.
```
{
"actions": [
{
"action": {
"type": "DEFAULT"
},
"recipients": [
"new-recipient@example.com"
]
},
{
"action": {
"type": "DEFAULT"
},
"allRecipients": true
}
]
}
```
**Lambda 실행** 작업을 위한 Lambda 함수를 생성할 때 사용할 추가 코드 예제는 [Amazon WorkMail Lambda 템플릿](https://github.com/aws-samples/amazon-workmail-lambda-templates)을 참조하세요.
## Amazon WorkMail에서 Lambda 사용에 대한 자세한 내용
Lambda 함수를 트리거하는 이메일 메시지의 전체 콘텐츠에도 액세스할 수 있습니다. 자세한 내용은 [를 사용하여 메시지 콘텐츠 검색 AWS Lambda](lambda-content.md) 단원을 참조하십시오.
# 를 사용하여 메시지 콘텐츠 검색 AWS Lambda
Amazon WorkMail의 이메일 흐름을 관리하도록 AWS Lambda 함수를 구성한 후 Lambda를 사용하여 처리되는 이메일 메시지의 전체 콘텐츠에 액세스할 수 있습니다. Amazon WorkMail용 Lambda 시작하기에 대한 자세한 내용은 [Amazon WorkMail AWS Lambda 용 구성](lambda.md) 단원을 참조하세요.
이메일 메시지의 전체 콘텐츠에 액세스하려면 Amazon WorkMail Message Flow API에서 `GetRawMessageContent` 작업을 사용합니다. 호출 시 사용자의 Lambda 함수로 전달되는 이메일 메시지 ID가 API로 요청을 전송합니다. 그러면 API가 이메일 메시지의 전체 MIME 콘텐츠로 응답합니다. 자세한 내용은 [Amazon WorkMail API 참조](https://docs.aws.amazon.com/workmail/latest/APIReference/API_Operations_Amazon_WorkMail_Message_Flow.html)의 *Amazon WorkMail 메시지 흐름*을 참조하세요.
다음 예제는 Python 런타임 환경을 사용하는 Lambda 함수로 전체 메시지 콘텐츠를 검색하는 방법을 보여줍니다.
**작은 정보**
에서 계정으로 Amazon WorkMail [ Hello World Lambda 함수](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:489970191081:applications/workmail-hello-world-python)를 배포 AWS Serverless Application Repository 하는 것으로 시작하면 필요한 모든 리소스와 권한이 있는 Lambda 함수가 계정에 생성됩니다. 그런 다음 사용 사례에 따라 Lambda 함수에 비즈니스 로직을 추가할 수 있습니다.
```
import boto3
import email
import os
def email_handler(event, context):
workmail = boto3.client('workmailmessageflow', region_name=os.environ["AWS_REGION"])
msg_id = event['messageId']
raw_msg = workmail.get_raw_message_content(messageId=msg_id)
parsed_msg = email.message_from_bytes(raw_msg['messageContent'].read())
print(parsed_msg)
```
전송 중인 메시지의 콘텐츠를 분석하는 자세한 방법은 GitHub의 [amazon-workmail-lambda-templates](https://github.com/aws-samples/amazon-workmail-lambda-templates) 리포지토리를 참조하십시오.
**참고**
Amazon WorkMail Message Flow API는 전송 중인 이메일 메시지에 액세스하는 데만 사용합니다. 전송 또는 수신 후 24시간 이내에만 메시지에 액세스할 수 있습니다. 사용자의 메일박스의 메시지에 프로그래밍 방식으로 액세스하려면 Amazon WorkMail에서 지원하는 다른 프로토콜 중 하나를 사용합니다(예: IMAP 또는 EWS(Exchange Web Services)).
# AWS Lambda를 사용하여 메시지 콘텐츠 업데이트
이메일 흐름을 관리하도록 동기 AWS Lambda 함수를 구성한 후 Amazon WorkMail 메시지 흐름 API의 `PutRawMessageContent` 작업을 사용하여 전송 중 이메일 메시지의 콘텐츠를 업데이트할 수 있습니다. Amazon WorkMail용 Lambda 함수 시작하기에 대한 자세한 내용은 [동기식 **Lambda 실행** 규칙 구성](lambda.md#synchronous-rules) 부분을 참조하세요. API에 대한 자세한 내용은 [PutRawMessageContent](https://docs.aws.amazon.com/workmail/latest/APIReference/API_messageflow_PutRawMessageContent.html)를 참조하세요.
**참고**
PutRawMessageContent API에는 boto3 1.17.8이 필요합니다. 또는 Lambda 함수에 계층을 추가할 수 있습니다. 올바른 boto3 버전을 다운로드하려면 [GitHub의 boto 페이지](https://github.com/boto/boto)를 참조하세요. 계층 추가에 대한 자세한 내용은 [계층을 사용하도록 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-using)을 참조하세요.
예제 계층: `"LayerArn":"arn:aws:lambda:${AWS::Region}:489970191081:layer:WorkMailLambdaLayer:2"`. 이 예시에서는 `${AWS::Region}`을 us-east-1과 같은 적절한 AWS 리전으로 대체하세요.
**작은 정보**
AWS Serverless Application Repository에서 사용자 계정으로 Amazon WorkMail [Hello World Lambda 함수](https://console.aws.amazon.com/lambda/home#/create/app?applicationId=arn:aws:serverlessrepo:us-east-1:489970191081:applications/workmail-hello-world-python)를 배포하는 것으로 시작하면 시스템에서 필요한 리소스와 권한을 포함하는 Lambda 함수를 사용자 계정에 생성합니다. 그런 다음 사용 사례에 따라 Lambda 함수에 비즈니스 로직을 추가할 수 있습니다.
진행하면서 다음 사항을 기억해야 합니다.
+ [GetRawMessageContent](https://docs.aws.amazon.com/workmail/latest/APIReference/API_messageflow_GetRawMessageContent.html) API를 사용하여 원본 메시지 콘텐츠를 검색합니다. 자세한 내용은 [를 사용하여 메시지 콘텐츠 검색 AWS Lambda](lambda-content.md)을 참조하세요.
+ 원본 메시지를 찾았으면 MIME 콘텐츠를 변경합니다. 작업을 마치면 계정의 Amazon Simple Storage Service(S3) 버킷에 메시지를 업로드합니다. S3 버킷이 Amazon WorkMail 작업과 동일한 AWS 계정 를 사용하고 API 호출과 동일한 AWS 리전을 사용하는지 확인합니다.
+ Amazon WorkMail에서 요청을 처리하려면 S3 버킷에 올바른 정책이 있어야 S3 객체에 액세스할 수 있습니다. 자세한 내용은 [Example S3 policy](#s3example) 단원을 참조하십시오.
+ [PutRawMessageContent](https://docs.aws.amazon.com/workmail/latest/APIReference/API_messageflow_PutRawMessageContent.html) API를 사용하여 업데이트된 메시지 콘텐츠를 Amazon WorkMail로 다시 보낼 수 있습니다.
**참고**
`PutRawMessageContent` API는 업데이트된 메시지의 MIME 콘텐츠가 RFC 표준과 [RawMessageContent](https://docs.aws.amazon.com/workmail/latest/APIReference/API_messageflow_RawMessageContent.html) 데이터 유형에 언급된 기준을 충족하는지 확인합니다. Amazon WorkMail 조직으로 인바운드되는 이메일이 항상 이러한 표준을 충족하는 것은 아니므로 `PutRawMessageContent` API가 이를 거부할 수 있습니다. 이러한 경우 반환된 오류 메시지를 참조하여 문제 해결 방법에 대한 자세한 내용을 확인할 수 있습니다.
**Example 예제 S3 정책**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "workmail.REGION.amazonaws.com"
},
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::My-Test-S3-Bucket/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"Bool": {
"aws:SecureTransport": "true"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/WORKMAIL_ORGANIZATION_ID/*"
}
}
}
]
}
```
다음 예제는 Lambda 함수가 Python 런타임을 사용하여 전송 중인 이메일 메시지의 제목을 업데이트하는 방법을 보여줍니다.
```
import boto3
import os
import uuid
import email
def email_handler(event, context):
workmail = boto3.client('workmailmessageflow', region_name=os.environ["AWS_REGION"])
s3 = boto3.client('s3', region_name=os.environ["AWS_REGION"])
msg_id = event['messageId']
raw_msg = workmail.get_raw_message_content(messageId=msg_id)
parsed_msg = email.message_from_bytes(raw_msg['messageContent'].read())
# Updating subject. For more examples, see https://github.com/aws-samples/amazon-workmail-lambda-templates.
parsed_msg.replace_header('Subject', "New Subject Updated From Lambda")
# Store updated email in S3
key = str(uuid.uuid4());
s3.put_object(Body=parsed_msg.as_bytes(), Bucket="amzn-s3-demo-bucket", Key=key)
# Update the email in WorkMail
s3_reference = {
'bucket': "amzn-s3-demo-bucket",
'key': key
}
content = {
's3Reference': s3_reference
}
workmail.put_raw_message_content(messageId=msg_id, content=content)
```
전송 중인 메시지의 콘텐츠를 분석하는 방법의 더 많은 예제는 GitHub의 [ amazon-workmail-lambda-templates](https://github.com/aws-samples/amazon-workmail-lambda-templates) 리포지토리를 참조하세요.
# Amazon WorkMail Message Flow API에 대한 액세스 관리
AWS Identity and Access Management (IAM) 정책을 사용하여 Amazon WorkMail 메시지 흐름 API에 대한 액세스를 관리합니다.
Amazon WorkMail Message Flow API는 단일 리소스 유형, 즉 전송 중인 이메일 메시지에만 적용됩니다. 전송 중인 각 이메일 메시지에는 관련된 고유 Amazon 리소스 이름(ARN)이 있습니다.
다음 예제는 전송 중인 이메일 메시지와 관련된 ARN의 구문을 보여줍니다.
```
arn:aws:workmailmessageflow:region:account:message/organization/context/messageID
```
이전 예제에서 변경 가능한 필드는 다음과 같습니다.
+ **리전** - Amazon WorkMail 조직의 AWS 리전입니다.
+ **계정** - Amazon WorkMail 조직의 AWS 계정 ID입니다.
+ **조직** - 귀하의 Amazon WorkMail 조직 ID입니다.
+ **컨텍스트** – 메시지가 `incoming` 사용자 조직으로 전송되는지 또는 `outgoing` 사용자 조직에서 전송되는지 여부를 나타냅니다.
+ **메시지 ID** – 사용자의 Lambda 함수에 입력으로 전달되는 고유한 이메일 메시지 ID입니다.
다음 예제에는 전송 중인 수신 이메일 메시지와 관련된 ARN의 예제 ID가 포함됩니다.
```
arn:aws:workmailmessageflow:us-east-1:111122223333:message/m-n1pq2345678r901st2u3vx45x6789yza/incoming/d1234567-8e90-1f23-456g-hjk7lmnop8q9
```
IAM 사용자 정책의 `Resource` 섹션에서 이러한 ARN을 리소스로 사용하여 전송 중인 Amazon WorkMail 메시지에 대한 액세스를 관리할 수 있습니다.
## Amazon WorkMail 메시지 흐름 액세스에 관한 예제 IAM 정책
다음 예제 정책은 IAM 엔터티에 AWS 계정에 있는 모든 Amazon WorkMail 조직의 모든 인바운드 및 아웃바운드 메시지에 전체 읽기 액세스 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"workmailmessageflow:GetRawMessageContent"
],
"Resource": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/*",
"Effect": "Allow"
}
]
}
```
------
에 여러 조직이 있는 경우 하나 이상의 조직으로 액세스를 제한할 수도 AWS 계정있습니다. 이 기능은 특정 조직에 특정 Lambda 함수만 사용해야 할 경우에 유용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"workmailmessageflow:GetRawMessageContent"
],
"Resource": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/organization/*",
"Effect": "Allow"
}
]
}
```
------
`incoming` 조직으로 전송되거나 `outgoing` 조직에서 전송되는지에 따라 메시지에 대한 액세스 권한을 부여할 수도 있습니다. 그렇게 하려면 ARN에서 한정자 `incoming` 또는 `outgoing`를 사용합니다.
다음 예제 정책은 조직으로 수신되는 메시지에 대한 액세스 권한만 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"workmailmessageflow:GetRawMessageContent"
],
"Resource": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/organization/incoming/*",
"Effect": "Allow"
}
]
}
```
------
다음 예제 정책은 IAM 엔터티에 AWS 계정에 있는 모든 Amazon WorkMail 조직의 모든 인바운드 및 아웃바운드 메시지에 전체 읽기 및 업데이트 액세스 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"workmailmessageflow:GetRawMessageContent",
"workmailmessageflow:PutRawMessageContent"
],
"Resource": "arn:aws:workmailmessageflow:us-east-1:111122223333:message/*",
"Effect": "Allow"
}
]
}
```
------
# 이메일 흐름 규칙 테스트
현재 규칙 구성을 점검하기 위해 특정 이메일 주소에 대해 구성이 작동하는 방식을 테스트할 수 있습니다.
**이메일 흐름 규칙을 테스트하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. 탐색 창에서 **Organization settings(조직 설정)**, **Inbound/Outbound rules(인바운드/아웃바운드 규칙)**를 선택합니다.
1. **Test configuration(구성 테스트)** 옆에 테스트할 발신자 및 수신자의 전체 이메일 주소를 모두 입력합니다.
1. **테스트**를 선택합니다. 입력한 이메일 주소에 대해 수행할 작업이 표시됩니다.
# 이메일 흐름 규칙 제거
이메일 흐름 규칙을 제거하면 해당 변경 사항이 즉시 적용됩니다.
**이메일 흐름 규칙을 제거하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. 탐색 창에서 **Organization settings(조직 설정)**, **Inbound/Outbound rules(인바운드/아웃바운드 규칙)**를 선택합니다.
1. 규칙을 선택하고 [**Remove**]를 선택합니다.
1. 확인 프롬프트에서 **제거**를 선택합니다.
# 수신 이메일에 DMARC 정책 적용
이메일 도메인은 보안을 위해 도메인 이름 시스템(DNS) 레코드를 사용합니다. 스푸핑 또는 피싱과 같은 일반적인 공격으로부터 사용자를 보호합니다. DNS 레코드에는 이메일을 전송하는 DMARC(Domain-based Message Authentication, Reporting and Conformance) 레코드가 포함되는 경우가 많습니다. DMARC 레코드에는 이메일이 DMARC Check에 실패할 경우 취할 조치를 지정하는 정책이 포함되어 있습니다. 조직에 전송되는 이메일에 DMARC 정책을 적용할지 여부를 선택할 수 있습니다.
새 Amazon WorkMail 조직에는 기본적으로 DMARC 적용이 활성화되어 있습니다.
**DMARC 적용을 활성화하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. 탐색 창에서 **조직 설정**을 선택합니다. **조직 설정** 페이지가 나타나고 탭 세트가 표시됩니다.
1. **DMARC** 탭을 선택한 다음에 **편집**을 선택합니다.
1. **DMARC 적용** 슬라이더를 켜짐 위치로 이동합니다.
1. **본인은 DMARC 적용을 켜면 보낸 사람의 도메인 구성에 따라 인바운드 이메일이 삭제되거나 격리될 수 있다는 점을 인정합니다** 옆의 확인란을 선택합니다.
1. **저장**을 선택합니다.
**DMARC 적용을 비활성화하려면**
+ 이전 섹션의 단계를 따르되 **DMARC 적용** 슬라이더를 꺼짐 위치로 이동합니다.
## 이메일 이벤트 로깅을 사용하여 DMARC 적용 추적
DMARC 적용을 활성화하면 발신자가 도메인을 구성한 방법에 따라 인바운드 이메일이 삭제되거나 스팸으로 표시될 수 있습니다. 발신자가 이메일 도메인을 잘못 구성한 경우, 사용자가 적법한 이메일의 수신을 중단할 수 있습니다. 사용자에게 배달되지 않는 이메일을 확인하기 위해 Amazon WorkMail 조직의 이메일 이벤트 로깅을 활성화할 수 있습니다. 그런 다음, 발신자의 DMARC 정책에 따라 필터링되는 인바운드 이메일에 대한 이메일 이벤트 로그를 쿼리할 수 있습니다.
이메일 이벤트 로깅을 사용하여 DMARC 적용을 추적하기 전에 Amazon WorkMail 콘솔에서 이메일 이벤트 로깅을 활성화하세요. 로그 데이터를 최대한 활용하려면, 이메일 이벤트가 기록되는 동안 잠시 시간을 보내십시오. 자세한 정보와 지침은 [이메일 이벤트 로깅 켜기](tracking.md#enable-tracking) 섹션을 참조하십시오.
**이메일 이벤트 로깅을 사용하여 DMARC 적용을 추적하려면**
1. CloudWatch Insights 콘솔의 **로그** 아래에서 **Insights(인사이트)**를 선택합니다.
1. **로그 그룹 선택**에서 Amazon WorkMail 조직의 로그 그룹을 선택합니다. 예: /aws/workmail/events/organization-alias.
1. 쿼리할 기간을 선택합니다.
1. 다음 쿼리를 실행합니다. **stats count() by event.dmarcPolicy \$1 filter event.dmarcVerdict == "FAIL"**
1. **쿼리 실행**을 선택합니다.
이러한 이벤트에 대한 사용자 지정 지표를 설정할 수도 있습니다. 자세한 내용은 [지표 필터 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringPolicyExample.html)을 참조하십시오.
# 조직 태깅
Amazon WorkMail 조직 리소스에 태그를 지정하면 다음을 수행할 수 있습니다.
+ AWS 결제 및 비용 관리 콘솔에서 조직 간에 구분합니다.
+ AWS Identity and Access Management (IAM) 권한 정책 설명의 `Resource` 요소에 추가하여 Amazon WorkMail 조직 리소스에 대한 액세스를 제어합니다.
Amazon WorkMail 리소스 수준 권한에 대한 자세한 내용은 [리소스](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-resources) 단원을 참조하세요. 태그에 기반한 액세스 제어에 대한 자세한 내용은 [Amazon WorkMail 태그 기반 권한 부여](security_iam_service-with-iam.md#security_iam_service-with-iam-tags) 단원을 참조하십시오.
Amazon WorkMail 관리자는 Amazon WorkMail 콘솔을 사용하여 조직을 태깅할 수 있습니다.
**Amazon WorkMail 조직에 태그를 추가하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. [**Tags**]를 선택합니다.
1. **조직 태그**에서 **새 태그 추가**를 선택합니다.
1. **키**에 태그를 식별하는 이름을 입력합니다.
1. (선택 사항) **값**에 태그의 값을 입력합니다.
1. (선택 사항) 4\$16단계를 반복해 조직에 태그를 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.
1. **저장**을 선택하여 변경 사항을 저장합니다.
Amazon WorkMail 콘솔에서 조직 태그를 확인할 수 있습니다.
개발자는 AWS SDK 또는 AWS Command Line Interface ()를 사용하여 조직에 태그를 지정할 수도 있습니다AWS CLI. 자세한 내용은 [Amazon WorkMail API 참조](https://docs.aws.amazon.com/workmail/latest/APIReference/Welcome.html) 또는 [AWS CLI 명령 참조](https://docs.aws.amazon.com/cli/latest/reference/workmail/index.html)의 `TagResource`, `ListTagsForResource` 및 `UntagResource` 명령을 참조하세요.
Amazon WorkMail 콘솔을 사용하여 언제든지 조직에서 태그를 제거할 수 있습니다.
**Amazon WorkMail 조직에서 태그를 제거하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. [**Tags**]를 선택합니다.
1. **조직 태그**에서 제거할 태그 옆에 있는 **제거**를 선택합니다.
1. **제출**을 선택하여 변경 사항을 저장합니다.
# 액세스 제어 규칙 작업
Amazon WorkMail의 액세스 제어 규칙을 통해 관리자는 Amazon WorkMail에 대한 액세스 권한을 조직의 사용자 및 위장 역할에 부여하는 방법을 제어할 수 있습니다. 각 Amazon WorkMail 조직에는 사용 중인 액세스 프로토콜 또는 IP 주소에 관계없이 조직에 추가된 모든 사용자 및 위장 역할에게 사서함 액세스 권한을 부여하는 기본 액세스 제어 규칙이 있습니다. 관리자는 기본 규칙을 편집하거나 자신의 규칙으로 대체하거나, 새 규칙을 추가하거나, 규칙을 삭제할 수 있습니다.
**주의**
관리자가 조직에 대한 모든 액세스 제어 규칙을 삭제하면 Amazon WorkMail은 조직의 사서함에 대한 모든 액세스를 차단합니다.
관리자는 다음 기준에 따라 액세스를 허용하거나 거부하는 액세스 제어 규칙을 적용할 수 있습니다.
+ **프로토콜** - 사서함에 액세스하는 데 사용되는 프로토콜입니다. 예제로는 **자동 검색**, **EWS**, **IMAP**, **SMTP**, **ActiveSync**, **Windows용 Outlook** 및 **웹 메일**이 포함됩니다.
+ **IP 주소** – 사서함에 액세스하는 데 사용되는 IPv4 CIDR 범위입니다.
+ **Amazon WorkMail 사용자** – 사서함에 액세스하는 데 사용되는 조직의 사용자 ID입니다.
+ **위장 역할** - 사서함에 액세스하는 데 사용되는 조직 내 위장 역할입니다. 자세한 내용은 [위장 역할 관리](managing-impersonation-roles.md) 단원을 참조하십시오.
관리자는 사용자의 사서함 및 폴더 사용 권한 외에 액세스 제어 규칙을 적용합니다. 자세한 내용은 *Amazon WorkMail 사용 설명서*의 [사서함 권한을 사용한 작업](mail_perms_overview.md)와 [폴더 및 폴더 권한 공유](https://docs.aws.amazon.com/workmail/latest/userguide/share-folders.html)를 참조하세요.
**참고**
Windows용 Outlook에 대한 액세스를 활성화하는 경우 자동 검색 및 EWS에 대한 액세스도 활성화하는 것이 좋습니다.
액세스 제어 규칙은 Amazon WorkMail 콘솔 또는 SDK 액세스에 적용되지 않습니다. AWS Identity and Access Management (IAM) 역할 또는 정책을 대신 사용합니다. 자세한 내용은 [Amazon WorkMail의 Identity and Access Management](security-iam.md) 단원을 참조하십시오.
## 액세스 제어 규칙 생성
Amazon WorkMail 콘솔에서 새 액세스 제어 규칙을 만듭니다.
**새 액세스 제어 규칙을 생성하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. **Access control rules(액세스 제어 규칙)**를 선택합니다.
1. **규칙 생성**을 선택합니다.
1. **설명**에 규칙에 대한 설명을 입력합니다.
1. **효과**에서 **허용** 또는 **거부**를 선택합니다. 이렇게 하면 다음 단계에서 선택하는 조건에 따라 액세스가 허용되거나 거부됩니다.
1. **이 규칙은 다음 요청에 적용됩니다…**에서 규칙에 적용할 조건(예: 특정 프로토콜, IP 주소, 사용자 또는 위장 역할 포함 또는 제외 여부)을 선택합니다.
1. (선택 사항) IP 주소 범위, 사용자 또는 위장 역할을 입력할 때 규칙에 추가하려면 **추가**를 선택합니다.
1. **규칙 생성**을 선택합니다.
## 액세스 제어 규칙 편집
Amazon WorkMail 콘솔에서 새 액세스 제어 규칙 및 기본 액세스 제어 규칙을 편집합니다.
**액세스 제어 규칙을 편집하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. **Access control rules(액세스 제어 규칙)**를 선택합니다.
1. 편집할 규칙을 선택합니다.
1. [**Edit rule**]을 선택합니다.
1. 필요에 따라 설명, 효과 및 조건을 편집합니다.
1. **변경 사항 저장**을 선택합니다.
**중요**
액세스 규칙을 변경하면 영향을 받는 사서함이 업데이트된 규칙을 따르는 데 5분이 걸릴 수 있습니다. 영향을 받는 사서함에 액세스하는 클라이언트는 그 시간 동안 일관되지 않은 동작을 보일 수 있습니다. 하지만 규칙을 테스트하면 즉시 올바른 동작이 표시됩니다. 테스트 규칙에 대한 자세한 내용은 다음 섹션의 단계를 참조하세요.
## 액세스 제어 규칙 테스트
조직의 액세스 제어 규칙이 적용되는 방식을 보려면 Amazon WorkMail 콘솔에서 규칙을 테스트합니다.
**조직의 액세스 제어 규칙을 테스트하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. **Access control rules(액세스 제어 규칙)**를 선택합니다.
1. **Test rules(규칙 테스트)**를 선택합니다.
1. **Request context(요청 컨텍스트)**에서 테스트할 프로토콜을 선택합니다.
1. **Source IP address(소스 IP 주소)**에 테스트할 IP 주소를 입력합니다.
1. **다음이 수행하는 요청**에 테스트할 **사용자** 또는 **위장 역할**을 선택합니다.
1. 테스트할 **사용자** 또는 **위장 역할**을 선택합니다.
1. **테스트**를 선택합니다.
테스트 결과가 **효과** 아래에 나타납니다.
## 액세스 제어 규칙 삭제
Amazon WorkMail 콘솔에서 더 이상 필요하지 않은 액세스 제어 규칙을 삭제합니다.
**주의**
관리자가 조직에 대한 모든 액세스 제어 규칙을 삭제하면 Amazon WorkMail은 조직의 사서함에 대한 모든 액세스를 차단합니다.
**액세스 제어 규칙 삭제**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. **Access control rules(액세스 제어 규칙)**를 선택합니다.
1. 삭제할 규칙을 선택합니다.
1. **규칙 삭제**를 선택합니다.
1. **삭제**를 선택합니다.
# 사서함 보존 정책 설정
Amazon WorkMail 조직에 대한 사서함 보존 정책을 설정할 수 있습니다. 보존 정책은 선택한 기간이 지나면 사용자 사서함에서 이메일 메시지를 자동으로 삭제합니다. 보존 정책을 적용할 사서함 폴더를 선택할 수 있습니다. 또한 폴더마다 다른 보존 정책을 설정할지 여부를 선택할 수 있습니다. 사서함 보존 정책은 조직의 모든 사용자 사서함에서 선택한 폴더에 적용됩니다. 사용자는 보존 정책을 재정의할 수 없습니다.
**사서함 보존 정책을 설정하려면**
1. [https://console.aws.amazon.com/workmail/](https://console.aws.amazon.com/workmail/)에서 Amazon WorkMail 콘솔을 엽니다.
필요한 경우 AWS 리전을 변경합니다. 콘솔 창 상단의 표시줄에서 **리전 선택** 목록을 열고 리전을 선택합니다. 자세한 내용은 *Amazon Web Services 일반 참조*의 [리전 및 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/index.html?rande.html)를 참조하세요.
1. 탐색 창에서 **조직**을 선택한 다음 조직의 이름을 선택합니다.
1. **보존 정책**을 선택합니다.
1. **폴더 작업**의 경우 정책에 포함할 각 사서함 폴더 옆에 있는 **삭제** 또는 **영구 삭제**를 선택합니다.
1. 이메일 메시지를 삭제하기 전에 각 사서함 폴더에 보관할 일 수를 입력합니다.
1. **저장**을 선택합니다.
조직에 보존 정책을 적용하는 데 최대 48시간이 걸릴 수 있습니다. 폴더 **삭제** 작업을 선택하면 사용자가 Amazon WorkMail 웹 애플리케이션 및 지원되는 클라이언트에서 삭제된 이메일 메시지를 복구할 수 있습니다. 폴더 **영구 삭제** 작업을 선택하면 이메일 메시지를 삭제한 후 복구할 수 없습니다.
보존 정책에 따른 항목 보관 기간(일)은 항목이 생성, 수정 또는 이동된 날짜를 기준으로 합니다. 예를 들어, 보존 정책에 따라 1년이 지난 후 항목이 삭제되는 경우 정책은 해당 항목을 만들었거나 마지막으로 조치를 취한 날짜로부터 보존 일수를 계산합니다. 보존 정책을 구현한 날짜의 영향을 받지 않습니다.