【ITニュース解説】Fixing the “Invalid Parameter” Error When Registering an SNS Topic for SES Feedback Notifications

AWSのクラウドサービスを使っていると、複数のサービスを連携させる場面が多くある。その中で、メール送信サービスのAmazon SES（Simple Email Service）が送信したメールの状況（例えば、メールが受信者に届かなかった「バウンス」、受信者から迷惑メールとして報告された「苦情」、あるいは無事に届いた「配信完了」といった情報）に関する通知を、メッセージングサービスであるAmazon SNS（Simple Notification Service）を通して受け取る設定を行う際に、「無効なパラメータ」というエラーが発生するケースがある。これは、既存のサービスを新しいAWSアカウントに移行する際に遭遇しやすい問題の一つだ。

通常、SESのフィードバック通知をSNSトピックで受け取るためには、SNSトピックをSESと同じAWSリージョン（データセンターの地理的な場所）に作成し、SESサービスがそのSNSトピックに対してメッセージを送信する権限（sns:Publish）を付与すれば良い。今回の事例でも、SNSトピックは標準タイプとして作成され、SESと同じリージョンにあり、アクセスポリシーも適切に設定されているように見えた。しかし、実際にSESからSNSトピックを設定しようとすると、「入力パラメータに無効または範囲外の値が指定された」というエラーが表示され、設定を完了することができなかった。

このエラーの根本的な原因は、SNSトピックのメッセージが暗号化されており、その暗号化に使われているAWS Key Management Service（KMS）のキーに対する権限が不足していた点にあった。SNSトピックは、送受信されるメッセージの内容を保護するために、KMSで管理されている暗号化キーを使用してメッセージを暗号化する機能を持っている。この機能が有効なSNSトピックに対して、SESのような別のサービスがメッセージを公開（送信）しようとする場合、SESは単にSNSにメッセージを送信する権限だけでなく、そのSNSトピックの暗号化に使われているKMSキーにアクセスし、一時的にデータを暗号化・復号化するための特別なデータキーを生成したり、暗号化されたデータを復号化したりする権限も必要となるのだ。

具体的には、メッセージをSNSトピックに公開するサービスであるSESは、KMSキーに対して「kms:GenerateDataKey」と「kms:Decrypt」という二つの権限を持っていなければならない。kms:GenerateDataKeyは、実際にメッセージデータを暗号化・復号化するためのキーを生成する権限であり、kms:Decryptは、暗号化されたデータやキーを復号化する権限である。実際の暗号化と復号化の処理はSNSサービス自身がKMSと連携して行うが、SESはこれらの処理を開始するためのKMS APIコールをトリガーする必要があるため、これらの権限が求められるのだ。

今回の問題で特に注意が必要だったのは、SNSトピックの暗号化に「AWSマネージドキー」という種類のKMSキーが使われていた点にある。AWSマネージドキーは、AWSサービスがデフォルトで提供する暗号化機能で使われるキーであり、そのセキュリティポリシー（キーポリシー）はAWSによって厳密に管理されている。そのため、ユーザーが個別にキーポリシーを編集して、特定のサービス（この場合はSES）にKMSキーの利用権限を追加することはできないという制約がある。つまり、SESにKMSキーの利用権限を与えようとしても、AWSマネージドキーのポリシーは変更できないため、必要な権限を付与できず、これが「無効なパラメータ」エラーの原因となっていたのだ。

この問題を解決するためには、AWSマネージドキーの代わりに、ユーザー自身が管理できる「カスタマーマネージドキー（CMK）」を新しく作成し、それをSNSトピックの暗号化に利用する必要があった。CMKはユーザーがそのキーポリシーを自由に定義できるため、SESに必要なKMS権限を明示的に付与することが可能になる。

具体的な解決策としては、まずAWS KMSサービス内で新しいCMKを一つ作成する。例えば「sns-ses-dev-1」のような名前を付けることができる。次に、この新しく作成したCMKのキーポリシーに、SESサービスが必要とする以下の権限を追加する。キーポリシーはJSON形式で記述され、その内容は以下の通りだ。

Copy
1{
2    "Version": "2012-10-17",
3    "Statement": [
4        {
5            "Sid": "AllowSESToUseKMSKey",
6            "Effect": "Allow",
7            "Principal": {
8                "Service": "ses.amazonaws.com"
9            },
10            "Action": [
11                "kms:GenerateDataKey",
12                "kms:Decrypt"
13            ],
14            "Resource": "*"
15        }
16    ]
17}

このポリシーは、「Version」でポリシーの記述形式のバージョンを指定し、「Statement」内で具体的な許可ルールを定義する。「Sid」（ステートメントID）は、このルールに人間が識別しやすい名前を付けるものだ。「Effect": "Allow"」は、このルールがアクセスを許可することを示している。「Principal」は、この許可が誰に対して与えられるかを示す部分で、「Service": "ses.amazonaws.com"」と記述することで、Amazon SESサービス自体がこのポリシーの対象となることを明確にしている。これは、SESサービスにこのKMSキーの使用を許可するという意味である。「Action」は、許可する具体的な操作を指定する部分で、「kms:GenerateDataKey」と「kms:Decrypt」が列挙されている。これにより、SESはデータキーの生成とデータの復号化という二つのKMS操作を実行できるようになる。「Resource": "*"」は、このキーポリシーが適用されるリソース、ここでは作成したCMK全体に対してこれらの権限を付与することを意味している。

この新しいCMKを作成し、上記のキーポリシーを適用した後、最後にSNSトピックの設定画面で、この新しく作成したCMKを暗号化キーとして選択し直す。この変更を適用することで、SESはSNSトピックにメッセージを公開する際に、CMKを通じてKMSの必要な操作を実行できるようになり、結果として「無効なパラメータ」エラーは解消され、SESフィードバック通知のためのSNSトピック設定が無事に完了する。

この経験から学べる重要な教訓は、AWSのサービスを連携させる際には、単に一方のサービスからもう一方のサービスへの基本的なアクセス権限だけでなく、特に暗号化が絡む場合に、その暗号化を管理するKMSキーに対する権限も詳細に考慮する必要があるということだ。また、AWSマネージドキーとカスタマーマネージドキーの違いを理解し、それぞれのキーポリシーの制約や柔軟性を把握しておくことも、クラウド環境での適切なセキュリティ設定とトラブルシューティングにおいて極めて重要となる。

なお、CMKを使用すると、その利用に対してAWSから追加費用が発生する点にも注意が必要である。そのため、開発環境のように厳密なセキュリティ要件が求められない場面では、SNSトピックの暗号化自体を無効にするか、AWSマネージドキーのまま運用することも検討できる。費用対効果を考慮し、本番環境など特にセキュリティが重要な場面でのみCMKによる暗号化を有効にする、といったバランスの取れたアプローチが推奨される。この一連の対応は、AWS環境におけるサービス連携、IAM（Identity and Access Management）による権限管理、そしてKMSによる暗号化の深い理解に繋がる貴重な経験となるだろう。