Amazon WorkMailを一度も利用したことがなかったので、学習の為に実際にさわりながら自分へのメモを兼ねて情報を残します。
Amazon WorkMailとは
"既存のデスクトップおよびモバイル Eメールクライアントをサポートする、セキュアなマネージド型のビジネス用Eメールおよびカレンダーサービス"との事です。
"〜およびカレンダーサービス"という内容について知らなかったのでちょっと意外でした。 すっかり忘れていましたが、そういえばMUAによってはカレンダー機能なんてあったりしましたね。
"既存の〜Eメールクライアント"とは、要するにIMAPに対応しているMUAであれば使えますよという意味合いになりそうです。 特にMicrosoft Outlook製品と親和性が高いようで、例えば空き時間情報のスケジュール設定、委任、不在時の返信など、ユーザーが依存する高度なMicrosoft Outlook機能をすべてサポートするそうです。
Amazon WorkMailにはWebアプリケーションがあり、ブラウザからセキュアに利用することが可能で、設定さえすれば独自ドメインで利用も可能です。
提供リージョン
AWSで提供されているリージョンは執筆時点で3リージョンとなっています。
米国東部(バージニア北部) / 米国西部(オレゴン) / 欧州(アイルランド)
ということで(執筆時点で)東京リージョンで利用は出来ません。
もし、国外にEメールのデータを保管してはならないような会社ポリシーがあったりする場合には注意が必要です。
各種制限
以下に情報が纏まっています。
Amazon WorkMail quotas - Amazon WorkMail
メールボックスのデフォルトかつ上限が50GiBな点が利用するうえで意識が必要かもしれませんが 受信/送信メッセージの最大サイズ等をはじめ一般的な範囲かなと思います。
マルウェア対策
ユーザー側でその手の製品を別途導入しなくともAmazon WorkMailを利用するだけで自動的に悪意のあるEメールからユーザーを保護するために、送受信されるすべてのEメールをスキャンしてスパム、マルウェア、ウイルスがないかの確認をしてくれるそうです。
便利ですね。
モニタリング
Amazon CloudWatch
Amazon WorkMail は Amazon CloudWatch と連携してモニタリングが可能となっています。
Amazon CloudWatch による Amazon WorkMail のモニタリング - Amazon WorkMail
メトリクスの例
・受信されたEメールの数
・個々のメールボックスに配送されたEメールの数
・mailbox full や UserUnknown等のエラーで返送された受信メールの数
・bouncedとなったメールの数
・Amazon WorkMail側から正常にSentしたEメールの数
またAmazon WorkMailにてイベントログ記録機能を有効にすることで、
イベントログを取得でき、Cloudwatch Insight を使ったクエリで抽出が可能です。
( /var/log/maillogの抽出とかに相当する内容がこちらです)
コピー&ペーストするだけで使えるサンプルのクエリも多数紹介されています。
クエリの例
・ユーザー B がユーザー A から送信された電子メールを受信しなかった理由を確認
・bouncedメールを誰が送信したかを確認
・どのドメインがspamメールを送信しているかを確認
・組織が受信または送信した Eメールの数を確認
CloudTrail
Amazon WorkMailはAWS CloudTrailと統合されているので、APIログが取得可能です。 以下の取得サンプルが紹介されています。
AWS CloudTrail による Amazon WorkMail API コールのログ記録 - Amazon WorkMail
取得の例
・CreateUser
・CreateAlias
・GetRawMessageContent
その他連携するAWSサービス
ディレクトリサービス
AWS Simple AD、AWS Managed AD、または AD Connector(経由のオンプレミスAD環境)と統合できます。 既存AD環境があれば連携するだけユーザーは既存の認証情報で利用できるようになります。
Amazon Simple Email Service(以後SES)
Amazon WorkMailは、Amazon SESを使用してすべてのメールを送信します。 Amazon WorkMailから送信されるEメールについて料金は発生しませんとあるので送信は無料というイメージで良さそうです。
AWS Key Management Service(以後KMS)
Eメールであろうと何であろうと暗号化の時にはとりあえずKMSという事で指定可能となっており、必要に応じて利用出来ます。セキュリティスペシャリティ試験で習いました。
Amazon Workdocs
Amazon WorkMailのWebクライアントはAmazonWorkDocsと統合されており、設定すればWorkDocsに保存されているファイルを電子メールに添付したり、既存の電子メールの添付ファイルをWorkDocsリンクに置き換えたり、添付ファイルをWorkDocsに安全に保存できるようです。
料金
料金ページは以下となります。
料金 - Amazon WorkMail | AWS
執筆時点でAmazon WorkMailの料金はユーザーあたり月額$4.00で、ユーザーごとに50GiBのメールボックスストレージが含まれていす。最大25人のユーザーを対象とした30日間の無料試用期間があるので検証はもちろん指定人数以下であればPoCとかも無料枠内で実施出来そうです。
座学はこのへんにして実際に触っていきます。
やってみた
やること概要
軽く探したのですが Amazon WorkMail関連のチュートリアルは見当たらなかったので、自身のAWS検証環境にて最低限必要なAmazon WorkMailのセットアップを実施し、テストユーザー同士でEメールの送受信をしたり簡単なログ確認とかをしてみようと思います。
1.初期セットアップ
AWSマネジメントコンソール -> サービス -> Amazon WorkMail を押下
東京リージョン(というかサービス提供されていないリージョン)で開いた場合、 以下のような画面でサービス提供しているリージョンへ移動が促されるので選択して切り替えます。 日本だと物理的に近く無難としてよく使われる皆大好きオレゴンリージョン(us-west-2)で今回は試してみます。
何もリソースがない初期状態だとこのような画面遷移します。Create Organization を押下して作成に進んでいきます。
2.Organization の作成
こちらはAWS Organizationとはまったくの別物で、Amazon WorkMail内で管理するドメイン単位の組織のようなイメージになります。この先進める設定はすべて作成したOrganizationという大枠の内で有効な内容となってきます。
Organization settings にて Eメールで利用するドメインの情報を指定していきます。Amazon Route53やそれ以外ももちろん対応しています。 今回の場合は、自分のAWS検証環境でAmazon Route53がレジストラな検証用ドメインを既に持っていたのでそれを指定し使うことにします。(贅沢に.comなのは内緒...)
既存の Amazon Route53 にある hosted zone 選択に加え Alias を指定して Create Organization を押下します。
作成が完了すると以下画面のように Origanizationが作成されます。
3.Domainsの設定
Orginizationの枠のドメインを押下すると、そのOriganization内での各種 Amazon WorkMailの設定画面に遷移しますので Domains の設定について見ていきます。
左ペイン Domains -> 指定したドメイン名をクリックします。
以下のようなドメイン検証ステータスの画面が表示されます。 この時点でおわかりかもしれませんが、Amazon Route 53の当該ゾーンを確認すると画面の通り MXレコードやDKIMのCNAMEレコードやAutoDiscoverのCNAME等が既に自動的に追加されている事が確認できます。
私の環境の場合は、既存でもっていたゾーン選択だからという理由もありそうですが、SPFレコードとDMARCの箇所およびカスタムメールドメインの箇所でMissingが出ていましたので、 ドキュメントに従い設定します。(親切にも最低限このレコードをしてくださいねといった内容が示されていますし、リロードの隣の？ボタンから当該マニュアルサイトへ飛べますので迷いません)
Amazon Route53の当該ゾーンにて、Amazon WorkMailのフォームで確認出来る内容のSPFとDMARCのTXTレコードを追加します。
もしDMARCレコードで ruaやrufとかを指定したい場合等は Amazon Route53から直接お好きなようにいじればよさそうです。 p=quarantine なので、認証失敗した場合は迷惑メール扱いされる挙動がサンプル通り設定すればデフォルトのようです。
カスタムの MAIL FROMドメイン設定についての詳細は以下を参照してSES側で対応します。
のカスタム MAIL FROM ドメインの構成 Amazon WorkMail - Amazon WorkMail
よしなに設定を進め、オールグリーンになったら次へ進みます。
制御系画面の確認
今回、何かを設定し試す訳ではないですが折角なので制御系の設定画面についてもついでに見ていきます。
アクセスコントロールルール
左ペインの Access control rules を確認すると以下画面となっており、管理者として利用できるプロトコル、From IPアドレス、ユーザー等が制御できます。
アクセスコントロールルールの使用 - Amazon WorkMail
メールボックス保持ポリシー
左ペインの Retention policies を確認すると以下画面となっており、管理者としてメールボックスの保持期間などを指定できます。
メールボックス保持ポリシーの設定 - Amazon WorkMail
モバイルポリシー
左ペインの Mobile policies を確認すると以下画面となっており、管理者としてモバイル端末で利用する際の制限がかけられます。
組織のモバイルデバイスポリシーの編集 - Amazon WorkMail
ユーザー/グループの登録
4.ユーザー作成
今回、AD連携ではないのでユーザー作成画面にてサンプルユーザーを作成していきます。 左ペインの Users から Create User を押下します。
すると以下のような入力フォーム画面が出るので必要な情報を入力して Add User を押下します。
同じ要領でサンプルユーザーを3人追加しました。
5.グループ作成とメンバー登録
次にグループを作成しグループへ参加させるユーザーを選択します。
わかりやすいフォームで楽々ですね。
ポイントなのがグループを作成した時点で、そのグループ名がlocalpartとなったML(メーリングリスト)として使える点です。別途MLドライバーを導入したり個別に作り込む必要がなく、GUIでぽちぽちと簡単に運用できそうです。
ログイン確認およびテストメールの送受信
6.Webアプリケーションに接続
Webアプリケーションの接続するためのURIは、左ペイン Organization Setting -> General タブの Web Application から確認出来ます。
任意のWebブラウザにてそのURIにアクセスすると以下のような認証画面が表示されます。
なんともうログイン出来ました。
UIを眺めポチポチと触ってみましたが、全体的にいい感じです(語彙力MAX)
過去にオンプレミス環境でWebメールシステムの構築/運用を担当をしたことがありこの手の製品評価とかを色々とした経験があるのですが、かなりシンプルで使いやすい部類ではないでしょうか？
7.任意のMUAにて接続
異なるユーザーではせっかくなので異なるMUAで使ってみようという事で、今回はSparkを利用してみました。 サポートされているClientへの接続手順はすべて先の手順で実施した Origanization Settiing -> General タブにあるリンクから対象ドキュメントへ飛べます。
今回はIMAPのクライアントなので以下ドキュメントの内容に従って
IMAP(S)とSMTP(S)のサーバー、認証情報、利用プロトコルやポート等を指定していきます。
の IMAP の設定 Amazon WorkMail - Amazon WorkMail
以下がSparkのアカウント設定画面です。
マニュアル通り、SMTP(S)と
IAMP(S)の設定を実施していきます。(リージョンにより指定サーバーが異なる点は注意です)
SMTPもIMAPもTLS暗号化が必須となっている点が好感もてますね。
問題なく接続できました。
8.テストメールの送受信
Webアプリケーションのユーザー -> Spark(任意MUA)のユーザー宛にテストメールを送信してみます。
正常に受信しました。
返信してみます。
問題なく送受信が出来てコミュニケーションが取れました。
メール不達の場合の確認
次に意図せずメールが届かない場合の動作やら管理者としての確認方法についてもみていきましょう。 その前に、管理者としてログを確認するためには、以下ドキュメントに従いEメールイベントログ記録をオンにする必要がありますので実施します。
9.Eメールイベントログ記録をオンにする
左ペイン Organization Setting -> Monitoring -> Log settings の Edit を押下
設定有効化および同意に関するチェックをつけて Save を押下
すると、必要な CloudWatch のロググループとストリーム IAMロール(Cloudwatch Logsへ書き込み権限付与)が自動的に作成され以下のような画面になります。
青文字の View のリンクを押下すると対象画面に遷移します。
10.配送エラーとなるメールの送信
配送エラーを意図的に出すために存在しない宛先にEメールを送信してみます。
今回は意図的に、localpartを実際に存在する「Michael」ではなく「Mical」として送っています。 どうでもいい話ですが、名前のマイケル(マイコー)は様々なスペルが存在しており、実際この手のミスは多いようですね。
ユーザー側だとこのように、存在しない宛先に出した場合は mailer-daemon@amazonses.com からメッセージが届きます。
「Technical report」として、どこのMTAでどのようなステータスとなったかの情報も表示してくれるので分かりやすいですね。
11.管理者としてログの確認
次に管理者視点ですが、一般的にメールログ調査といえば /var/log/maillog を grepしたり、大規模環境だとSplunkとかを導入したりが多いと思いますが、
Amazon WorkMailではCloudWatch Logsの当該ログストリームから確認となります。
先程の配送エラーのログは以下のようになっていました。
先に書きましたがCloudWatch Logs Insightがログ抽出ではかなり強力で便利です。
試しにサンプルにある bouncedしたEメールのログを抽出してみるとこんな感じです。
過去にメールシステム管理者をやっていた頃によくやっていたので、message-id での抽出を試してみるとこんな感じです。
管理者となる場合は、Cloud Watch Logs Insightでのクエリやログ解析方法についてキャッチアップする必要がありますが、少し触って慣れれば生ログからgrep駆使しして突き合わせとかよりは全然楽かもしれません。
マルウェア添付時の挙動確認
おまけで最後にマルウェアが添付されたEメール送信時の挙動についても簡単に確認してみます。 ユーザーから EICAR Standard Anti-Virus Test Fileを添付して送ってみました。(自端末だと問題があったのでEC2インスタンスで試しました)
12.EICARテストファイルを添付してメールを送信
するとこのように以下のように Illegal filename 'eicar.com'. といったメッセージを返しつつMTAで弾いてくれました。
Amazon WorkMailを触ってみて
開始からわずか数分の設定で登録したユーザーがWebアプリケーションにログイン出来るようになり、メール送受信まで出来るようになるとまでは思っていなかったので正直あっけに取られました。
過去にオンプレミスでOSインストールからMTA,MDA,MRA周り設定からやっていたあの頃の苦労は一体...。
昨今、Slack、Microsoft Teams、Amazon Chime等のビジネスチャットツールやらWebIFで低コストにコミュニケーションがとれるツール等の普及に伴い、Eメールはビジネスシーンから今後も衰退していくであろうと思われますが、無くならないモノでもあり続ける事でしょう。
サーバーワークスでも社内コミュニケーションに関しては2014年の4月からSlackで統一され、レガシーなEメールでの社内やりとりはそれより前のずいぶん昔から禁止されていたりしますが、システム類の通知やら営業による企業間のコミュニケーション用途では現役です。
企業としてプライオリティが下がろうと無くては困るようなものであれば、細かいことには拘らず、その分低コストで身軽に運用したいものだと思います。 メールの移行ツールが用意されていたり、既存のExchangeサーバーとの相互運用とかも可能となっているので、要件を満たせば既存の独自メールシステムの移行先として候補になるのではないでしょうか。
まとめ
もし、誰かにメールシステムを作ってくれと依頼された際には使います。
