こんにちは。Microsoft Azure を使用して、ちょっとしたセキュリティファンクションの開発を行っている安藤です。
当ブログでは、Microsoft 365 のデフォルト機能と Azure Logic App を使用して、自組織からパスワード付き暗号化ファイル（ZIPファイル、Office ファイルなど）を送信すること、また自組織でパスワード付き暗号化ファイルを受信することを遮断、さらに遮断した際に自組織の担当者へ連絡する実装について解説します。
目次
PPAP とは
PPAP は“Postpone Password of Attachments Protocol”の略…ではなく、「パスワード付き ZIP ファイルを送信」「パスワードを送信」「暗号化」「プロトコル」の頭文字をとったものです。長年、経路中の情報窃取を危惧してメール添付ファイルの平文送信を避けるために使用されていた手段であり、多くの場合パスワード付き ZIP ファイルを使用して添付ファイルとパスワードを別送することを指します。
しかし、実際にメール送信経路中の情報を窃取するには多くの前提条件を必要とするため、攻撃手段としては極めて難度が高いことや、かける手間の割に同じ通信手段であるメールで別送することによるリスク回避の効果が非常に小さいことなどから、いつしかその効果が怪しまれるようになりました。また、暗号化されたパスワード付きファイルはメールセキュリティを素通りしてしまうことから、マルウェアを感染させる手段として PPAP 方式の運用を逆手に取られるケースがあり、デメリットも表面化してきました。
なお、当社では本記事でご紹介する内容とは別に、クラウド型のPPAP 対策およびメール誤送信防止対策サービスとして「Mail Safe」をご用意しております。
無料トライアルも可能となっておりますので、ご興味がございましたらサービスページからお気軽にお問い合わせください。
PPAP の廃止
さて、PPAP の廃止というと『送信時にパスワード付き ZIP ファイルを送信しない』『パスワードを別送しない』ことで自組織からのメール送信時の手間をなくすことを目標とする場合が多いと思いますが、今回は『パスワード付き ZIP ファイルを受信しない』ことも含めて検討します。
また、ただ遮断するだけでは不便もあります。遮断されたことがわからなければ、パスワード付き ZIP ファイルを添付してメール送信したつもりが実はされていなかった、なんて事故が起きてしまうかもしれません。そのためメールの遮断と同時に組織内の関係者へ通知を行う必要があります。要件をまとめると以下となります。
※ 要件は一部の代表的なものを抜粋しています。実際には、組織内人事部からのメールや役員・経営幹部間での機微な情報を含むメールなどでは、組織内であってもパスワード付き添付ファイルを使用することから、「組織内⇒組織内」の場合は対象外とするケースなどが含まれます。
当社では Microsoft 365 に関するサービス提供を複数行っているため、お客様も Microsoft 365 ユーザーが多く、PPAP の廃止に向けて Microsoft 365 のデフォルト機能で対応したいというお声も伺っておりました。
そのため本記事では以下の構成図のように、パスワード付き添付ファイルを遮断しつつ、通知が必要な関係者に向けて遮断通知メールを送信する仕組みについて解説します。
実装は以下のステップで行います。
前提条件
この後にご説明する内容を実現するためには以下が必要となります。
- Exchange Online Plan1 以上（組織全体＋通知用アカウントのメールボックス）
- Microsoft Azure のサブスクリプション
メールフロールールによるパスワード付き添付ファイルの遮断
Exchange Online にはメールフロールール（旧トランスポートルール）と呼ばれるメールのフィルタリング機能があります。今回は以下のメールフロールールを使用します。
左右にスクロールしてご覧ください。
| 条件 | 説明 |
|---|---|
| Any attachment is password protected |
メールの添付ファイルのいずれかにおいてパスワード付きのファイルが存在する場合 （ファイルは Office ファイル、ZIP ファイル、7z ファイルを対象） |
メール送受信時に上記の条件でメールフロールールを作成します。ルールの作成は以下から進めることができます。
https://admin.exchange.microsoft.com/#/transportrules
[ルールの追加＞新しいルールの作成]をクリックします。
条件を設定しますが、ここで実行するアクションとしては [メッセージをブロックする：だれにも通知せずにメッセージを削除する] を選択します。
その他のアクションとしてメッセージブロック後に通知を送信するアクションもあります。しかし、これを使用した場合、組織外からパスワード付き添付ファイルを送信された際に外部のメール送信者に対して通知が送信されますが、組織内の受信予定者は気づくことができません。もちろん、それで問題ない場合はこのアクションを使うことだけで PPAP 方式を廃止することは可能です。
今回は外部からパスワード付き添付ファイルが送信された際、遮断はしつつも受信予定者に対して通知を送信することを要件とするため、[だれにも通知せずにメッセージを削除する] を使用します。
※ 以降の方法は [メッセージを拒否してその説明を含める] [次の拡張状態コードのメッセージを拒否する] と組み合わせても動作はします。
遮断されたメールを他のメールと区別する
メールが遮断されたことは以下のログ上で確認することができます。
- Exchange Online のメッセージ追跡ログ
- Microsoft Sentinel または Microsoft Defender XDR の EmailEvents ログ
- Microsoft Defender XDR のエクスプローラー
しかし、これらを使用して特定のメールフロールールで遮断されたログを特定するのは非常に手間がかかります。そのため、遮断後のログを確認するのではなく、メールフロールールで対象のメールを遮断と同時に通知用のメールボックスにコピーすることで特定します。図示すると以下のようになります。
メールフロールールには以下のアクションを追加します。
送信先には事前に準備していただいた「通知用メールボックス」を指定します。
Azure Logic App で通知用メールボックスのメールを確認する
Azure Logic App でメールボックスのメールを確認する場合、以下の2つの方法があります。
フロートリガーでメールを受信するたび（メールフロールールで受信者追加するたび）に起動してメール情報取得
スケジュールトリガーで定期的に実行してメール取得アクションでメール情報取得
ここで考慮が必要なのは、通知用メールボックスでパスワード付きファイル添付のメールを受信した場合、受信フォルダだけでなく迷惑メールフォルダに保存される可能性があることです。
その場合、それぞれ以下の2つのような実装案が検討できます。
フロートリガーを使用（受信トレイ用と迷惑メール用の2つを用意）
スケジュールトリガーで定期的に受信トレイと迷惑メールを取得
※ スケジュールトリガーを使用する場合は通知済みのメールを除外するため、通知したメールを既読に変えるなどの処理を行いますが、ここでは省略します。
上記いずれかの方法で、パスワード付き添付ファイル遮断用メールフロールールに該当したメールを区別して Azure Logic App へ情報を取り込むことができます。
Internet Message ID で BCC 宛メールの情報を取得する
ここまでの方法でパスワード付き添付ファイルを遮断し、さらにそのメールを特定することができました。当該メールの情報を確認することで、[送信元メールアドレス][宛先メールアドレス（TO）][宛先メールアドレス（CC）][件名][本文][添付ファイル名]などを Azure Logic App で取り扱うことができます。
しかし Azure Logic App で取得できる情報には以下が不足しています。
- 宛先メールアドレス（BCC）
滅多に該当しないケースだとは思いますがパスワード付き添付ファイルが BCC で送信されていた場合、宛先メールアドレス（BCC）のユーザーは送信されたことに気づくことができません。
また、外部の配布リストに自組織のメールアドレスが含まれているケースも同様に、遮断通知先を特定することができません。
これらの情報を取得するには「メッセージ追跡ログ」あるいは「Microsoft Sentinel または Microsoft Defender XDR の EmailEvents」を参照する必要がありますが、前述の通り特定のメッセージフロールールに該当したログを特定するには非常に手間がかかります。そこで、“通知用メールボックス宛に BCC で送信されたメールと同じログ”を探すこととします。
Azure Logic App で取得可能な情報の一つに「Internet Message ID」と呼ばれる情報があります。これは RFC5322 によって定義されているフィールドである Message-ID を示しており、送信ドメインの MTA によって付与されます。
※ RFC5322 では Message-ID の付与が SHOULD として定義されており、必ずしも付与される情報ではないことに注意が必要です。
※ RFC5322 では、Message-ID は原則として山括弧（<>）で囲まれたメールアドレスと同じ形式で定義されますが、この形式以外で付与される場合もあります。
幸いにも「メッセージ追跡ログ」や「Microsoft Sentinel または Microsoft Defender XDR の EmailEvents」には Internet Message ID のフィールドが存在するため、通知用メールボックスに送信されたメールと同じログを Internet Message ID を使用して特定することができます。メッセージ追跡ログや EmailEvents を機械的（Machine-to-Machine）に使用し、該当メールのログを特定する手段として以下の方法があります。
- メッセージ追跡ログ
- Get-MessageTrace コマンドを実行する
- EmailEvents
- Microsoft Defender XDR の API
- Microsoft Sentinel の API（Log Analytics API）
このうち、メッセージ追跡ログのコマンド実行では Message-ID を引数としてログを特定することができますが、引数となる Message-ID が RFC5322 で定義されているフォーマットに従わない場合、該当するログが存在したとしても出力されない仕様となっています。このようなケースではメッセージ追跡ログを使用することはできません。さらに Microsoft Sentinel の API を使用するには Microsoft Sentinel 上に EmailEvents ログを保管する必要があるため、ここでは Microsoft Defender XDR の API を使用する方法についてご紹介します。詳細は以下リンクからご確認ください。
https://learn.microsoft.com/en-us/microsoft-365/security/defender/api-advanced-hunting?view=o365-worldwide
Microsoft Defender XDR の API の利用には Microsoft Entra ID 上でサービスプリンシパルを作成する必要があります。
※ Azure Logic App リソースに付与したマネージド ID によって認証することで、後述する手順よりもセキュアに実装することが可能ですが本稿では割愛します。必要に応じてお問い合わせください。
1. Microsoft Entra ID で[アプリの登録]ブレードをクリックします。
2. [新規登録]をクリックします。
3. [名前]を入力して[登録]ボタンをクリックします。
4. [API のアクセス許可]をクリックします。
5. [アクセス許可の追加]をクリックします。
6. [Microsoft Graph]をクリックします。
7. [アプリケーションの許可]をクリックします。
8. [ThreatHunting.Read.All]にチェックを付けます。
9. [～（テナント名）に管理者の同意を与えます]をクリックします。
10. 管理者同意の確認画面が表示されるため、[はい]をクリックします。
11. [証明書とシークレット]をクリックします。
※ サービスプリンシパルに対しては、クライアントシークレットまたは証明書を使用した認証が選択可能です。MSAL ライブラリなどによって証明書を使用するほうがよりセキュアに実装が可能ですが、当ブログでは割愛します。必要に応じてお問い合わせください。
12. [新しいクライアントシークレット]をクリックします。
13. クライアントシークレットの[説明]と[有効期限]を設定します。
14. [追加]をクリックします。
15. 表示されるクライアントシークレットの値をテキストファイルなどにコピーしてください。
※ 再表示できず、紛失した場合再発行が必要となります。
サービスプリンシパルの準備は以上で完了です。以降は runHuntingQuery API リクエストを Azure Logic App から実行します。
security: runHuntingQuery - Microsoft Graph v1.0 | Microsoft Learn
サービスプリンシパル作成時に[概要]ブレードから以下を確認してください。
- テナント ID
- アプリケーション ID
これらと先ほど発行いただいたクライアントシークレットの値を使用して下図のパラメータを設定します。
※ 対象ユーザーと記載されているものは、どのサービスに対する API リクエストかを表すもので、[00000003-0000-0000-c000-000000000000]は Microsoft Graph を表します。
左右にスクロールしてご覧ください。
| 方法 | POST |
|---|---|
| URI | https://graph.microsoft.com/v1.0/security/runHuntingQuery |
| ヘッダー | Content-Type: application/json |
| 本文 |
{ "Query": "EmailEvents | where InternetMessageId == '@{items('For_each')?['internetMessageId']}'" } |
| 認証の種類 | Active Directory OAuth |
| 機関 | https://login.microsoftonline.com/ |
| テナント | <テナント ID> |
| 対象ユーザー | 00000003-0000-0000-c000-000000000000 |
| クライアント ID | <クライアント ID> |
| 資格情報の種類 | シークレット |
| シークレット | <シークレット> |
このようにすることで BCC 宛のメールや外部メーリングリストに含まれる自組織メールアドレス宛のメールについても宛先を特定することができます。
ただし、EmailEvents はログとして反映されるまでに若干のリードタイムがありますので、該当の InternetMessageId のログが見つかるまでに [Until] アクションを使用するなど、処理を待機させる必要がある点にご注意ください。
遮断通知メールを送信する
ここまでで PPAP として送信されたメールを遮断し、そのメールの情報を得ることができました。ここまで得られた内容は、遮断通知メールとして以下のような文面での送信が想定されます。
以下メールはパスワード付きファイルが添付されていたため削除されました。
ファイルの送受信には指定された手段を使用してください。
送信元メールアドレス：～～@～～
宛先メールアドレス：～～@～～
件名：～～@～～
今回ご紹介した手法では、通知用メールボックスに遮断されたメールの BCC が保管されています。そのため、遮断されて困ってしまうメールについても最悪の場合は通知用メールボックスから転送することでリカバリーが可能です。その際はメールを特定しやすいように Internet Message ID を通知メール本文に含めるなど工夫が必要です。
まとめ
いかがでしたでしょうか。PPAP を Microsoft 365 と Azure Logic App で廃止する手段の一つをご紹介しました。当社では PPAP 遮断時にも添付ファイル送信のセキュリティ担保と手間を軽減するソリューションとして「Mail Safe」をご用意しております。Mail Safe を使用すれば、メール送信時に添付されたファイルを自動的にウェブダウンロードに置き換えることが可能です。詳細は以下リンクからお気軽にお問い合わせください。
今後も Microsoft 365 の活用方法についてブログを公開してまいりますので、ご覧いただければ幸いです。
関連ページ |
