[アップデート] Amazon SNS のデータ保護ポリシーで識別解除（De-identify）がアウトバウンドメッセージでも設定出来るようになりました

いわさです。

Amazon SNS にはデータ保護ポリシーというオプション機能があります。
この機能を使うとメッセージに個人情報などが含まれている場合にポリシーに基づいた動作をさせたり、監査に利用することが出来ます。

データ保護ポリシーのオペレーションは大きくは監査、拒否、識別解除の 3 つがあります。
このうち、識別解除はメッセージに含まれる個人情報を削除あるいはマスキングする機能です。

この識別解除オペレーションについては、これまでインバウンドメッセージにのみ適用が可能でしたが、本日のアップデートでアウトバウンドメッセージに適用出来るようになりました。

ただ、一見するとインバウンドの場合もアウトバウンドの場合も受信したメッセージをマスキング（あるいは削除）して送信するという点は変わらないような気もします。
本日は実動作の検証を行いながらどういった挙動の差が発生してどういうユースケースで使えそうなのかを考察してみましたので紹介したいと思います。

「匿名化」という表現が出来そうですが、本記事ではマネジメントコンソールの日本語表記に合わせて「識別解除」としています。

データ保護ポリシーの基礎

まずはじめに簡単にデータ保護ポリシーの設定方法などについておさらいしておきます。
前提としてデータ保護ポリシーはスタンダードトピックでのみ利用が可能です。

そしてトピックのオプションとしてデータ保護ポリシーを設定することが出来ます。
IAM に似たようなポリシーを設定する形となり、それぞれのオペレーション（拒否・識別解除・監査）内で複数のポリシーを設定することが可能です。

ステートメントで設定する内容は大きくはデータの方向とデータ識別子、対象プリンシパルです。

データの方向は SNS トピックに送信されるインバウンドメッセージに対して処理するのか、それとも SNS トピックからサブスクリプションで設定したエンドポイントへ送信される際のアウトバウンドメッセージに対して処理するのかを選択します。

データ識別子は個人情報や認証情報、あるいは特定の国に固有の秘匿性の高い情報など、識別子のプリセットが用意されています。
この中からデータ保護ポリシーでどういった情報を対象とするかを指定します。

そして、対象プリンシパルですが、ここが今回のアップデートで重要な点となります。
データ保護ポリシーではトピックに流れてくるすべてのメッセージを対象にすることも出来ますが、プリンシパルを指定してきめ細かいポリシーを設定することも可能です。

この対象プリンシパルはインバウンドメッセージとアウトバウンドメッセージで対象が異なっており、インバウンドメッセージはPublish操作を行った IAM プリンシパルとなります。つまり送信元ですね。これはわかりやすい。
アウトバウンドメッセージは送信先を指定出来ます。ただこれがちょっと驚いたのですが、サブスクリプションをSubscribe操作を行った IAM プリンシパルとなります。
蛇足になっちゃいますが、この挙動からするとSubscribe操作を行うユーザーって適当なユーザーだとダメですね。きっちり決めたほうが良さそうだなと思いました。

データ保護ポリシーの識別解除を試してみる

今回はインバウンドとアウトバウンドそれぞれの識別解除（マスキング）を試してみました。
まず、トピックにエンドポイントが 2 つサブスクライブしている状態です。

そして、前述のとおり対象プリンシパルの挙動の違いがポイントとなりますので、上記サブスクリプションは別々の IAM ユーザーでSubscribe操作を行いました。
そうすると対象サブスクリプションのSubscriptionPrincipalとして設定される形となります。

% aws sns get-subscription-attributes --subscription-arn arn:aws:sns:ap-northeast-1:123456789012:hoge0923protection:55e61f7e-b942-44f0-9dbe-8f8eda80011c
{
    "Attributes": {
        "SubscriptionPrincipal": "arn:aws:iam::123456789012:user/hoge1",
        "Owner": "123456789012",
        "RawMessageDelivery": "false",
        "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:hoge0923protection",
        "Endpoint": "user1@example.com",
        "Protocol": "email",
        "PendingConfirmation": "false",
        "ConfirmationWasAuthenticated": "false",
        "SubscriptionArn": "arn:aws:sns:ap-northeast-1:123456789012:hoge0923protection:55e61f7e-b942-44f0-9dbe-8f8eda80011c"
    }
}
% aws sns get-subscription-attributes --subscription-arn arn:aws:sns:ap-northeast-1:123456789012:hoge0923protection:c6e90a5e-f3d2-4248-9d43-2c4f4afc8417
{
    "Attributes": {
        "SubscriptionPrincipal": "arn:aws:iam::123456789012:user/hoge2",
        "Owner": "123456789012",
        "RawMessageDelivery": "false",
        "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:hoge0923protection",
        "Endpoint": "user2@example.com",
        "Protocol": "email",
        "PendingConfirmation": "false",
        "ConfirmationWasAuthenticated": "false",
        "SubscriptionArn": "arn:aws:sns:ap-northeast-1:123456789012:hoge0923protection:c6e90a5e-f3d2-4248-9d43-2c4f4afc8417"
    }
}

インバウンドメッセージの保護

ここでは単一の SNS トピックに対して異なる IAM ユーザーからメッセージを送信します。
その際に特定のユーザーに対してはデータ保護ポリシーを有効化したいと思います。

次のようにデータの方向を「インバウンドメッセージ」とし、対象の IAM プリンシパルにユーザーAを指定します。

この時、データ保護ポリシーの対象となっていないユーザーBから送信されたメッセージは次のように加工されずにすべてのエンドポイントへ送信されることが確認出来ます。

一方で、ユーザーAから送信されたメッセージは次のようにどちらの送信先に対しても E メールアドレス部分がマスキングされたメッセージが送信されることが確認出来ると思います。

これがアップデート前も出来ていたインバウンドメッセージに対する識別解除の動作となっています。
無条件に識別解除したい場合は問題ない挙動でしたが、マスキングしつつ特定の送信先に限っては識別情報のマスキングを解除したい、など細かい設定を行いたい場合は、トピックを多重化するなど別の工夫が必要でした。

アウトバウンドメッセージの保護

今度は次のように送信元に関してのポリシーは特に設けずに、送信先Aのメッセージのみ識別解除を導入したいと思います。

データの方向にアウトバウンドメッセージを指定しています。
対象プリンシパルは送信先AをSubscribeしたユーザーの IAM プリンシパルを指定しました。

先程と同様に E メールアドレスが含まれるメッセージをトピックに送信したところ、次のように送信先Aに対してはマスキングされ、送信先Bに対しては無加工で送信されることが確認出来ました。

期待どおり送信先に合わせたデータ保護ポリシーを適用出来ていますね。

さいごに

本日は Amazon SNS のデータ保護ポリシーで識別解除（De-identify）がアウトバウンドメッセージでも設定出来るようになったので検証してみました。

アウトバウンドメッセージのデータ保護ポリシーを組み合わせることがより細かいコントロールができ、送信先に合わせてデータ保護のステートメント設定を変更するなど複雑な要件を満たすことが出来るようになりそうです。

一方で、今回トピックサブスクリプションの作成ユーザーの仕様について知りました。
SubscriptionPrincipal属性が使われるケースもあるということを考えると、どのユーザーでサブスクリプションを作成するべきなのかをしっかり設計する必要がありますね。