こんにちは。CS課の坂本です。
タイトルは違いますが、前回の続きです。前回の処理は、2つのアカウントにまたがって実行されていました。
1. 開発アカウントのLambdaから処理を実行
2. 本番アカウントのCloudWatchのデータを取得
3. 取得したデータを開発アカウントのDynamoDBに入れる
という流れでした。
このように別のアカウントにアクセスする場合、ユーザーの「アクセスキー、シークレットアクセスキー」をもう一方のアカウントに知らせて、そのキーを使ってアクセスすることもできますが、ユーザーとキーの管理をしっかりおこなわないといけません。しかし、「AWS STS」を使うとユーザーとキーの管理がいらなくなり、よりセキュアな運用ができます。
「AssumedRoleUser」の部分が動的に作成されるユーザーの情報で、「Credentials」の部分には、「AccessKeyId」と「SecretAccessKey」、「SessionToken」の3つがあり、これが一時的な認証情報であることがわかると思います。 上記の場合は、Lambdaファンクションを作成するときに「LambdaRole」を選んでいるので、ちゃんと想定した結果が返ってきていますが、たとえば「TestRole」を選ぶと以下のようなエラーが返ってきます。このことから、想定していないリソースからはきちんとアクセスできないようになっていて、本番アカウントがセキュアに守られている、ということがおわかりいただけるのではないかと思います。
1. AWS STSとは？
「AWS STS」とは、「AWS Security Token Service」の略で一時的な認証情報を発行してくれるサービスです。 一時的な認証情報は、「アクセスキー」と「シークレットアクセスキー」、「セッショントークン」の3つから成り立っています。 この3つの一時的な認証情報を使うことで、許可された別のアカウントのリソースにアクセスすることができます。STSを使った別のアカウントのリソースへのアクセス（イメージ図）
2. 開発アカウント（アカウントA）の設定
ロールの設定内容を確認（LambdaRole）
アクセスする側のアカウントもアクセスされる側のアカウントも「ロール」を作成して設定する必要があります。「ロール」の詳しい説明はこちらにあるので省きますが、簡単に説明すると「ユーザーやグループに紐付かないで、AWSのサービスやリソースに対して操作権限を付与することができる」というモノです。AWS IAMというサービスに属しています。 以下の画像は、IAMのマネジメントコンソールで確認したアクセスする側の開発アカウントのロール、「LambdaRole」の設定です。まずは「アクセス許可」タブを確認します。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::XXXXXXXXXXXX:role/DevReadOnlyRole"
}
}
「XXXXXXXXXXXX」のところは本番アカウントのIDだと思ってください。STSのAssumeRoleというアクションを本番アカウントの「DevReadOnlyRole」ロールというリソースに対して実行することを許可している、という意味の内容です。
次に「信頼関係」タブを確認します。こちらもSTSに関する設定です。「信頼されたエンティティ」が「lambda.amazonaws.com」となっています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
3. 本番アカウント（アカウントB）の設定
ロールの設定内容を確認（DevReadOnlyRole）
次は、本番アカウントのロールの確認です。以下の画像がIAMのマネジメントコンソールで確認したアクセスされる側のアカウントのロール、「DevReadOnlyRole」の設定です。こちらもまずは「アクセス許可」タブを確認します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::YYYYYYYYYYYY:role/LambdaRole"
},
"Action": "sts:AssumeRole"
}
]
}
たとえば、もし開発アカウントであれば全て「AssumeRole」することを許可するのであれば、以下のような設定になります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::YYYYYYYYYYYY:root"
},
"Action": "sts:AssumeRole"
}
]
}
今回は、「LambdaRole」のみ許可するようにします。自分が持っている開発環境からのアクセスであっても、想定していないリソースからはアクセスできないようにして、よりセキュアに運用できるようにしたいと思います。
4. LambdaからSTSのサンプルコードを実行
STSのサンプルコードを準備したので、Lambdaから実行してみます。 実行すると、以下のような形で結果が返ってきます。{u'AssumedRoleUser': {u'Arn': 'arn:aws:sts::XXXXXXXXXXXX:assumed-role/DevReadOnlyRole/kokeshi',
u'AssumedRoleId': 'AAAAAAAAAAAAAAAAAAAAA:kokeshi'},
u'Credentials': {u'AccessKeyId': 'BBBBBBBBBBBBBBBBBBBB',
u'Expiration': datetime.datetime(2016, 5, 16, 0, 0, 0, tzinfo=tzlocal()),
u'SecretAccessKey': 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC',
u'SessionToken': 'FQoDYXdzEIj//////////wEaDDz1NcYJo/Ai7x5MDiKAAkupwvZ8Dy1y84tblLQpn3LivwP91YT3BSlNgAyTf1c3VcqRUh7RHLyrkGX+Q7AKMAxnkRWEk3gDSXa9EucVocy49z0p7O+SIBYw75jbmrFK+jQvN58HpDbFg93MgSyXMU++kIEuG9mss0pWApxzzGg4hXi9nY5th/fPVn1rXZYZHJ/tQK8CA1iQj68V3HJ8HXlnbq2FGoth/guwl38gGumG6F7+XgCvBH7AvIpacNE32INMVPLQGicwDvBcttXhAY8eIVzi+U2S0zFtTLSjumKkg5wIi5IxhZH5zFXAJueo4ZdfF/X9sdUGgmo7D7SoYOPCOZAfmO9WMpy0bgWNkS0otOPluQU='},
'ResponseMetadata': {'HTTPStatusCode': 200,
'RequestId': 'DDDDDDDD-DDDD-DDDD-DDDD-DDDDDDDDDDDD'}}
「AssumedRoleUser」の部分が動的に作成されるユーザーの情報で、「Credentials」の部分には、「AccessKeyId」と「SecretAccessKey」、「SessionToken」の3つがあり、これが一時的な認証情報であることがわかると思います。 上記の場合は、Lambdaファンクションを作成するときに「LambdaRole」を選んでいるので、ちゃんと想定した結果が返ってきていますが、たとえば「TestRole」を選ぶと以下のようなエラーが返ってきます。このことから、想定していないリソースからはきちんとアクセスできないようになっていて、本番アカウントがセキュアに守られている、ということがおわかりいただけるのではないかと思います。
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::YYYYYYYYYYYY:assumed-role/TestRole/awslambda_000_20160516000000000 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::XXXXXXXXXXXX:role/DevReadOnlyRole NG
