サイバーセキュリティの観点で考えるメールセキュリティ

# はじめに
本記事は「[エンジニアが知っておくべき メール送信・運用ノウハウ、メールの認証技術やセキュリティについて投稿しよう！ Advent Calendar 2024](https://qiita.com/advent-calendar/2024/blastengine)」に沿ってサイバーセキュリティにフォーカスし、メールセキュリティについて記載しています。

メールセキュリティとは、電子メールに関連するデータや通信を保護するための技術を指します。

メールセキュリティを実現するためには、暗号化や送信ドメイン認証技術など様々な技術が活用されています。また、近年ではフィッシング詐欺などメールを介したサイバー攻撃が増加しており、個人情報や企業の重要なデータを守るための取り組みが欠かせません。

本記事では、メールセキュリティの重要性や現在直面している課題についてまとめています。

## 送信ドメイン認証技術
### 課題
Simple Mail Transfer Protocol（SMTP）は、1982年に[RFC 821](https://www.rfc-editor.org/rfc/rfc821.html)として正式に標準化されました。

SMTPは、現在でも電子メールの配送に関する重要な役割を担っていますが、様々な課題が存在します。送信ドメイン認証技術は、フィッシング対策にも影響する重要な課題の一つです。

総務省で公開されてる令和6年版　情報通信白書の「第Ⅱ部　情報通信分野の現状と課題」- 「第10節　サイバーセキュリティの動向」 - 「[（4）　送信ドメイン認証技術の導入状](https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r06/html/nd21a240.html)」を参考にすると、2023年12月時点で、SPFは約82.9％、DMARCは約10.2％となっており、いずれも微増傾向であることが分かります。

しかし、SPF、DKIM、DMARCを正確に設定するには専門知識が必要です。小規模な組織ではインフラなどに詳しい人がいない場合、ボトルネックになりやすいです。また、多くの企業がSPFやDKIMを設定しているものの、DMARCポリシーがnoneに留まっているケースが多いのではないでしょうか。

::: note
送信ドメイン認証の仕組みについては、以前書いた[「迷惑メールから学ぶメール技術　送信ドメイン認証の仕組み」](https://qiita.com/Brutus/items/8339202801638afa7496)をご参照ください。
:::

### 施策
送信ドメイン認証について考える場合、ビジネス観点ではメールの到達率などを重要視しますが、セキュリティ観点だと視点が変わります。

ビジネス観点の勘所としては、以下のブログ記事が参考になります。

https://blastengine.jp/blog_content/transactional-email/

送信ドメイン認証技術の普及と適切な活用は、メールセキュリティ向上の鍵となります。しかし、技術的・運用的な課題を克服するためには、ツールの利用や標準化が必要です。

以下では、システム運用で有効なツールや外部サービスについて紹介しています。組織内でメール技術を補完するのが難しい場合、外部サービスを利用するのも一つの選択肢だと思います。

#### ツールの利用
2024年2月以降、Gmailアカウントに対してメールを送信する送信者は、Googleから公開されている[メール送信者のガイドライン](https://support.google.com/a/answer/81126?visit_id=638418586891004291-3788428211&rd=1)に沿った対応が必要になりました。

従ってガイドラインに準拠しない場合、Gmailアカウントのメールアドレスに対してメールが届かなくなるため、Gmail宛のメールの到達率の低下が懸念されています。

[**Postmaster Tools**](https://gmail.com/postmaster/)は、メールのパフォーマンスを分析し、Gmailがメッセージを適切にルーティングできるようにするためのツールです。

利用するためには、GoogleアカウントとDNSの設定などが必要になってきますが、ダッシュボードが用意されているため、メール配信に関わる評価指標を確認することで、改善に役立ちます。

https://blastmail.jp/blog/mail-delivery/howto-postmastertools

その他DMARCについて検証したい場合、**MxToolBox**で公開さている以下DMARC Check ToolなどDMARCを評価するツールが有効です。

https://mxtoolbox.com/dmarc.aspx

#### 外部サービス
メールに関する外部サービスは、国内だとプレゼントカレンダーのスポンサーとなっているblastengine社のサービスや国外のサービスなど色々なサービスが存在します。

https://blastengine.jp/

国外のサービスだと、SendGridを使用して開発している組織も多いのではないでしょうか。

https://sendgrid.com/en-us

参考までに構造計画研究所は、SendGridのリセラーパートナーです。正規代理店となっているため、支払いは円で行うなど国内の利用に応じた恩恵を受けることができます。

https://sendgrid.kke.co.jp/

その他国外のサービスとしては、シンプルなSMTPを必要とする場合、Postmarkなどがあります。

https://postmarkapp.com/

最近だと2022年にオープンソースプロジェクトとしてスタートして、現在は開発者向けのメール送信プラットフォームを提供しているResendというサービスがあります。

https://resend.com/

## 生成AIによるフィッシングメール増加
### 課題
2024年も生成AIに関するニュースには話題が尽きませんでしたが、セキュリティの分野でも影響を受けています。

以下は2024年5月30日、IPAによって公開されている「米国におけるAIのセキュリティ脅威・リスクの認知調査レポート」の資料です。

https://www.ipa.go.jp/security/reports/technicalwatch/20240530.html

上記URLにリンクされているレポートを踏まえて、ChatGPTなど生成AIの登場により従来のサイバー攻撃はTTPを強化し、フィッシングメールが増加していることが明らかになっています。

- [AI Risks and Threats](https://www.ipa.go.jp/security/reports/technicalwatch/m42obm000000hzkm-att/2024_IPA_Report1_FINAL_forPublic.pdf) p.19
>Research indicates a sharp rise in phishing since the release of ChatGPT, with malicious phishing emails increasing by 1,265% since the end of 2022.63 Of that figure, 68% of the emails used text-based BEC tactics which are significantly easier with malicious AI models.

また、フィッシング対策協議会によってフィッシングの被害状況、フィッシングの攻撃技術・手法などをとりまとめた「フィッシングレポート 2024」が公開されています。

- [資料公開: フィッシングレポート 2024 の掲載について](https://www.antiphishing.jp/report/wg/phishing_report2024.html)

上記レポートより国内については、フィッシング情報の届け出件数について、2023年は前年と比較して増加していることが明らかになっています。

傾向として、EC サイト大手、クレジットカード会社のほか、マイナポイント事務局など公共サービス、交通系サービスのなりすましが報告されています。

### 施策
外部からのサイバー攻撃は、生成AIが悪用されることで、より高度化された攻撃が今後も増加してくると思われます。

従って組織でセキュリティを推進する立場の場合、教育によるセキュリティ意識の向上は、今度も重要になってきます。

#### フィッシングメールの報告
フィッシングメールの対策を考えるにあたり、どの様に実装するかは組織で利用しているオフィススイートに依存する部分が大きいと思います。

例えば、Microsoft 365を利用している組織の場合、フィッシングメールなど疑わしいメールを報告するためのアドインを付けて、従業員に報告をさせる運用を行うことができます。

大規模な組織では、標的型攻撃メール訓練など啓蒙活動も有効です。訓練後アンケートを行いフィードバックを得ることで、開封率や報告率などの数字を評価して、改善していく仕組みが重要です。

::: note
参考：[管理者向け Outlook でフィッシングと疑わしいメールを報告する](https://learn.microsoft.com/ja-jp/defender-office-365/submissions-outlook-report-messages)
:::

## 内部不正による情報漏えい
### 課題
2024年、日本ではランサムウェアによるサイバー攻撃の話題が印象深かったと思いますが、内部不正によって引き起こされた情報漏洩などのセキュリティ事故も課題となっています。

IPAが毎年発行している情報セキュリティ10大脅威 2024の「組織向け」では、「**内部不正による情報漏えい等の被害**」が3位（9年連続9回目）にランクインしています。

https://www.ipa.go.jp/security/10threats/10threats2024.html

内部不正とは、一般的に従業員や組織関係者によって企業が保有する機密情報（営業秘密、個人情報、技術情報など）を何らかの手段を用いて、情報を持ち出す行為等を指します。情報持ち出しは、USBなどの外部媒体やメール、クラウドストレージなど多種多様な手段が存在します。

アメリカ合衆国の犯罪学者及び社会学者であるドナルド・レイ・クレッシーによって提唱された不正のトライアングルは、以下3つの要素で構成されています。

- 機会
- 動機
- 正当化

従って内部不正などによる情報漏洩を防ぐためには、不正のトライアングルに対する対策が必要です。

例えば、会社で使用している組織のメールアドレスから個人のフリーアドレス宛にメールが送信できる環境の場合、内部不正を起こしやすくなる機会が生まれます。

この様な背景から昨今注目されているのが、[Data loss prevention software](https://en.wikipedia.org/wiki/Data_loss_prevention_software)の技術です。

### 施策
DLPに関するソリューションは色々なサービスがありますが、代表的なグループウェアについては、以下のDLPソリューションが存在します。

#### Microsoft 365
[**Microsoft Purview**](https://www.microsoft.com/ja-jp/security/business/microsoft-purview)は、DLPポリシーを定義して適用することで、データ損失防止を実装します。

例えば、大量の個人情報をメールで送信しようとした場合、そのメールを検知して制御を行いブロックするなどの運用も可能です。

::: note
参考：[データ損失防止について](https://learn.microsoft.com/ja-jp/purview/dlp-learn-about-dlp)
:::

#### Workspace 
本記事執筆時点ではベータ版となっていますが、GmailでもDLPの機能が提供されています。

Workspaceを利用するユーザーがメールを送信すると、コンテンツのスキャンを行われてルールが一致する場合、DLPはルールで定義されたアクションを適用することができます。

::: note
参考：[メールと添付ファイルのデータ漏洩を防止する（ベータ版）](https://support.google.com/a/answer/14767988)
:::

## クラウドセキュリティ
### 課題
AWSなどクラウドを利用して、メールシステムを構築しているケースも少なくはないと思います。

以下はDatadogが公開している2024年のクラウドセキュリティの現状に関するレポートです。

https://www.datadoghq.com/state-of-cloud-security/

調査結果を踏まえて、セキュリティに対する意識が高まりクラウド環境は改善されつつあるものの、2023年に引き続き、長期間にわたって有効なクラウド認証情報を保持していることが明らかになりました。

興味深いのがほとんどの組織では、AWSコンソールのアクセスを行うにあたりAWS IAM Identity Centerなどのフェデレーション認証が増加しているものの、ほぼ半数 (46%) はIAMユーザーを利用しているとのことです。

また、使用していないAWSのアクセスキーの存在などは、よくある話だと思いますが、セキュリティに携わる者として見過ごせません。

例えば、AWSのAmazon SES(以下、SES)を用いてメール送信の仕組みを実装するために、認証情報としてアクセスキーを使用しているとします。

アプリケーションのソースコード内にアクセスキーをハードコーディングしていて、何らかの原因でアクセスキーが漏洩した場合のシナリオを想像することはできますでしょうか？SESのバウンス率向上などのアラートで気づいたときには、漏洩しているかもしれません。

### 施策
AWSのSESを安全に利用するための施策の例について、以下に記載します。

#### 最小権限の原則
AWS環境でSESを利用するためには、公式ドキュメントの[Types of Amazon SES credentials](https://docs.aws.amazon.com/ses/latest/dg/send-email-concepts-credentials.html)を踏まえて、AWS アクセスキーやSMTPの認証情報を使用します。

システム構成にもよりますが、基本はIAMロールを利用することが望ましいです。認証情報としてアクセスキーを使用する場合は、IAMユーザーを作成して最小権限を適用しましょう。

また、AWSではルートユーザーのアクセスキーを作成することは推奨されていません。

#### AWS IAM Access Analyzer
大規模な組織では、AWS IAM Identity Centerなど用いたアカウント管理が最適なアプローチだと思いますが、スタートアップなど小規模な組織ではIAMユーザーを利用する運用が多いと思います。

IAMユーザーの運用は煩雑になりやすいですが、AWSでは**IAM Access Analyzer**という便利なツールが存在します。

https://aws.amazon.com/jp/iam/access-analyzer/

::: note
IAM Access Analyzerを使用することで、長期間使用していないアクセスキーなどを迅速に検出できます。
:::

#### モニタリング
セキュリティ観点で異常なアクティビティを検出するためには、後述するAmazon GuardDutyなどのサービスを利用することでセキュリティ監視を実現できますが、監視の範囲を広げることでより高度な監視が可能です。

SESの運用の場合、バウンス率または苦情率のしきい値に関する通知を受け取るには、Amazon Simple Notification Service (Amazon SNS) のトピックを使用して、Amazon CloudWatchのアラームを設定します。

::: note
参考：[How can I use the reputation dashboard to find out when my Amazon SES bounce rate is high?](https://repost.aws/knowledge-center/ses-reputation-dashboard-bounce-rate)
:::

#### 監査ログ
AWS CloudTrailは、デフォルトで管理イベントを記録します。

従ってメール送信などの記録は残らないため、メール送信の記録を行いたい場合は、データイベントを有効にする必要がります。

詳細については[Logging Amazon SES API calls with AWS CloudTrail](https://docs.aws.amazon.com/ses/latest/dg/logging-using-cloudtrail.html)をご参照ください。

#### AWS Security Hub
AWS Security Hubは、セキュリティのベストプラクティスのチェックを自動化します。

https://aws.amazon.com/jp/security-hub/

アクセスキーを監視したい場合、以下の様なチェック項目を活用できます。

- [[IAM.3] IAM users' access keys should be rotated every 90 days or less](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-3)
- [[IAM.4] IAM root user access key should not exist](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-4)

#### Amazon GuardDuty
Amazon GuardDutyは、AWS環境におけるセキュリティの異常検知が可能です。

IAMを例にすると、異常なAPIリクエストなどを検知することができます。False Positiveもありますが、有効にすることをお勧めします。

https://aws.amazon.com/jp/guardduty/

::: note
参考：[GuardDuty IAM finding types](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html)
:::
## おわりに
本記事を書くにあたり改めてメールセキュリティについて考えさせられました。

余談ですが量子コンピュータは、将来的にRSAなど従来の公開鍵暗号を短時間で解読できる可能性があります。

S/MIMEやPGPなど現在のメール暗号化技術の信頼性が失われるため、メール送信者の身元を証明する認証プロセスのアップグレードが必要になると思われます。

従って量子耐性を持つ新しい署名方式や認証技術が開発されるなど、既存のプロトコルを置き換える時代が来るのでしょうか。

## 参考
- [メール セキュリティとは?](https://www.microsoft.com/ja-jp/security/business/security-101/what-is-email-security)
- [Free SMTP Servers Compared: Choose the Best One for Sending Transactional and Marketing Emails](https://mailtrap.io/blog/free-smtp-servers/)
- [Postmaster Tools で送信メールを監視する](https://support.google.com/a/topic/6259779)
- [組織における内部不正防止ガイドライン](https://www.ipa.go.jp/security/guide/insider.html)
- [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
- [Best practices for sending email using Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/best-practices.html)
- [Identity and access management in Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/control-user-access.html)

- [How Will Quantum Computing Impact Email Security?](https://www.digicert.com/blog/how-quantum-computing-impacts-email-security)