【AWS】SESでリソースを絞りSMTP認証情報が漏洩してもセキュアにする設定方法

公開日時:2022年12月17日 / 最終更新日時:2022年12月17日

マネージドの SES は便利なので簡単に利用できますが、通常はその際に SMTP 認証情報を作成すると思います。

下図は SMTP 認証情報を作成する際の画面です。

【AWS】SESでリソースを絞りSMTP認証情報が漏洩してもセキュアにする設定方法

 

 

 

SMTP 認証情報作成時に作成される IAM ユーザーとポリシー

SMTP 認証情報を作成すると以下のような IAM ユーザーとポリシーが作成されます。

 

■IAM ユーザー

【AWS】SESでリソースを絞りSMTP認証情報が漏洩してもセキュアにする設定方法

 

ポリシーは「AmazonSesSendingAccess」でポリシータイプは「インラインポリシー」です。

AmazonSesSendingAccess ポリシーの内容は以下です。

 

 

■AmazonSesSendingAccess ポリシー


    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": "ses:SendRawEmail", 
            "Resource": "*" 
        } 
    ] 
}

 

 

このポリシー「AmazonSesSendingAccess」を見ていて気が付いたのですが、リソースの設定は "Resource": "*" となっています。

つまり、作成した SMTP 認証を使えばどこからでも何のメールアドレスでも出せてしまいます。

ここまで言って気が付いたのですが、何のメールアドレスではなくきちんとした手続きを得て AWS 検証済みのドメインもしくはメールアドレスです。

例えば、tama-chan.com ドメインで検証済みになったのに、SMTP 認証情報が漏洩したら検証されていない kuma-chan.com ドメインなどで SES を使ってメールを送信できるようになるとは思いません。

しかし念のために絞れるなら絞った方が安心です。

仮に何かあっても説明できます。情報が漏洩した後に「多分、常識的にこうなんだろうと思ったから特に何もしなくてもいいと思った」というような説明をするとつらくなります。

 

そこでこの SMTP 認証情報作成時に自動的に作成されるインラインポリシーについてどこまで絞れるのか調査してみました。

 

 

 

SMTP 認証情報とは何か?

通常 SES を利用する際に SMTP 認証情報を作成すると思います。

よほど AWS 全般に知見があり、開発する前の段階から SMTP 認証情報を利用しないように設計しようと考えていればいいですが、通常は開発の最終段階くらいになったら「SES からメールを送信したいんだけどどうすればいい?」と確認してくると思います。

ここまで来るとシンプルに SES でメールを送信する為に SMTP 認証情報を作成してアカウントとパスワードを引き渡すことになると思います。

今更外部ベンダーにメールサービスを利用する為に NDA を締結したり与信を調査したり社内稟議を通したりする時間がなくなっている状態だと思います。

 

以下、SES SMTP 認証情報の公式サイトです。詳細な説明があります。

 

Amazon SES SMTP 認証情報を取得

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/smtp-credentials.html

 

Amazon SES 認証情報の種類

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-concepts-credentials.html

 

SES を利用する為には SES SMTP のユーザー名とパスワードが必要です。

SES を介してメールを送信するために使用する認証情報は各 AWS リージョンに固有のものです。

SES で複数の地域にメールを送信する場合は、各リージョンで SMTP 認証情報を作成する必要があります。

SMTP パスワードは、AWS シークレットアクセスキーとは異なります。

SMTP アカウントはアクセスキーID と一緒です。

ただし SES SMTP 認証情報は、アクセスキー ID とは異なるが、実際には IAM 認証情報の一種です。

いまいちよく分かりませんが SMTP 認証情報は IAM ユーザーのアクセスキーIDとシークレットアクセスキーとは違いますが、IAM 認証情報の一種ということです。

 

 

 

 

SMTP 認証情報を利用しなくても API で SES からメールを送信できる

SES では SMTP 認証情報か API を使用してメールを送信することが可能です。

 

Amazon SES API を使用して E メールを送信する

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-api.html

 

SES API を使用してメールを送信する場合は、メッセージの内容を指定して SES は MIME メールを作成します。

 

以下の3つの方法で API を呼び出すことができます。

 

AWS CLI から aws ses send-email コマンドで SES でメールを送信する方法が一番簡単そうですね。

複雑なことをしようとするなら API リファレンスを読んでリクエストを作成することになると思いますがハードルは上がると思います。

AWS CLI から SES を利用してメールを送信するなら AWS 管理コンソール画面より SMTP 認証情報を発行する必要はありません。

SMTP 認証情報を発行しなければそもそも SMTP 認証情報の漏洩は発生しません。

 

例えば EC2 インスタンスから aws ses send-email コマンドを実行すればメールを送信できますが、そのためには EC2 のインスタンスプロファイルに必要な権限が割り当たっている必要があります。

もしインスタンスプロファイルが割り当てられていない、もしくはインスタンスプロファイルが割り当てられていても権限が足りない場合は、権限を持ったアクセスキーIDとシークレットアクセスキーを発行し、この権限を元に SES からメールを送信するということになります。

 

 

 

SMTP 認証情報を定期的に自動更新することはできるか

一度 SMTP 認証情報を作成するとなかなか更新する機会はないと思います。

数年前、4,5年前に作成した SMTP 認証情報を使い続けているというケースもあると思います。

本番環境で問題なく稼働している状況でなかなか構成を変更する工数が取れないでしょう。

理想を言えばいくらでも言えますが現実の業務の工数とのトレードオフで優先度が下がったり放置されてしまうと思います。

そんな時に SMTP 認証情報を定期的に自動更新ができると手間もかからず安心です。

 

SES のダッシュボードより手動で SMTP ユーザーを新規に作成して入れ替える方法以外だと、API 経由で既に使用されている IAM ユーザーに対して新しいアクセスキーを作成し、アクセスキーの情報を用いて SMTP 認証情報に変換する方法があります。

シークレットアクセスキーを SMTP パスワードへ変換する方法は以下の公式サイトで記載があります。

 

既存の AWS認証情報を変換して Amazon SES SMTP 認証情報を取得する

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/smtp-credentials.html#smtp-credentials-convert

 

既存の Amazon SES SMTP IAM ユーザーのアクセスキーを更新するにはどうすればよいですか?

https://aws.amazon.com/jp/premiumsupport/knowledge-center/ses-rotate-smtp-access-keys/

 

 

 

 

SMTP 認証情報作成時に作成されるポリシーを絞る方法

ようやく本題ですが SMTP 認証情報作成時に作成されるポリシーを絞ってセキュリティを向上させます。

 

特にリソースを絞ることでよりセキュアになりそうです。

 

Amazon SES で定義されるリソースタイプは以下の 4つになります。

 

この中で SMTP 認証情報を使用してメールを送信する場合は、Resource に identity と configuration-set を指定することができます。

ポリシーのリソースにこれらのリソースタイプを指定する場合、それぞれのリソースを識別する ARN を入力する必要があります。

 

参考情報

Amazon SES のアクション、リソース、および条件キー

https://docs.aws.amazon.com/ja_jp/service-authorization/latest/reference/list_amazonses.html#amazonses-resources-for-iam-policies

 

 

identity

AWS 管理コンソールの SES ダッシュボードより、[Configuration] > [Verified identities] から対象のアイデンティティを選択すると [Amazon Resource Name (ARN)] が確認できます。

なお、まだ SES サンドボックス内にいる場合は、送信元ドメイン・メールアドレスのアイデンティティを識別する ARN と送信先の ARN の入力も必要になります。

 

configuration-set

AWS 管理コンソールの SES ダッシュボードより、[Configuration] > [Configuration sets] から対象の [Name] 値を確認し、以下の[${ConfigurationSetName} ]に代入する事で ARN として使用できます。

 

arn:${Partition}:ses:${Region}:${Account}:configuration-set/${ConfigurationSetName}

 

 

SMTP 認証情報(アクセスキーID、シークレットアクセスキー)が漏洩した場合の影響

上記を参考にリソースを絞っても、SMTP 認証情報(アクセスキーID、シークレットアクセスキー)が漏洩した際に、その指定したリソースを用いてメールの送信が可能です。

(とはいうものの、外部からどのような設定をしているのか推測することはかなり大変。あるとしたら内部からの流出ということになりそうですが)

しかしこれに対応する一例としましては、送信元 IP に基づいてアクセスを制限する方法もあります。

 

AWS: 送信元 IP に基づいて AWS へのアクセスを拒否する

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html

 

■IPアドレスで絞るポリシー例


    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": "ses:SendRawEmail", 
            "Resource": "*", 
            "Condition": { 
                "IpAddress": { 
                    "aws:SourceIp": "<NAT ゲートウェイ の EIP>" 
                } 
            } 
        } 
    ] 
}

 

Conditionで絞っています。

通常 EC2 インスタンスや ECS などはプライベート IP で構築していると思います。

しかしここの Condition はグローバル IP のみ設定できるという制限があるので、NAT ゲートウェイの EIP を設定する必要があります。

 

仮に ECS をパブリックで構築していた場合は、コンテナのデプロイやタスクの増減などで IP アドレスが変わるので Condition で絞るのは難しくなりそうです。

 

VPC エンドポイントを使用した方法の場合には、VPC エンドポイントにアタッチするセキュリティグループにて、VPC エンドポイントにアクセス可能なリクエスト元をプライベート IP アドレスの CIDR で制限することができます。

 

Amazon SES を用いた VPC エンドポイントの設定

https://docs.aws.amazon.com/ja_jp/ses/latest/dg/send-email-set-up-vpc-endpoints.html

 

 

 

 

Posted by 100%レンタルサーバーを使いこなすサイト管理人

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

AlphaOmega Captcha Medica  –  What Do You See?
     
 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

Secured By miniOrange