概要
Auth0 を利用し、以下のようなAWSコンソールログインの仕組みを構築することが可能です。
図中の「フェデレーションログイン」「スイッチロール」は AWS API でいうと AssumeRoleWithSAML と AssumeRole になります。
これらの API では、AWS 上の操作に対する追跡性を高めることのできる SourceIdentity
というパラメータが用意されています。
この SourceIdentity
を上記のコンソールログインの仕組みに導入する機会がありましたので内容を紹介します。
SourceIdentity の意義
SourceIdentity を利用しない場合の追跡性
SourceIdentity
を利用しない場合、Auth0 や AWSアカウント間で以下のような情報がやりとりされています。
(あくまで例なので、Auth0 等の設定内容により異なります)
注目していただきたいのは、Auth0 にログインしたユーザーのメールアドレス(xxxx@skyarch.net)が RoleSessionName
というパラメータとして渡されていることです。
このパラメータは、CloudTrail のコンソールで「ユーザー名」として表示されるので、AWS 上の操作のトラッキングに役立ちます。
ただし「踏み台AWSアカウント」にログインした後は、各ユーザー(xxxx@skyarch.net)が AWS CLI や SDK を使うことで任意の RoleSessionName
を設定することが出来てしまいます。
そのため、場合によっては「実利用AWSアカウント」の CloudTrail ログに残る RoleSessionName
(メールアドレス) が実際にログインしたユーザー(xxxx@skyarch.net)と異なる、ということが起こり得ます。
※この場合でも「踏み台AWSアカウント」の CloudTrail ログまでさかのぼって調べれば実際にログイン/操作したユーザーを特定することは可能です
SourceIdentity を利用した場合の追跡性
SourceIdentity
を利用した場合、Auth0 や AWSアカウント間で以下のような情報がやりとりされています。
SourceIdentity
が RoleSessionName
と大きく異なるのは、ロールセッションで最初に設定した SourceIdentity
は変更できないという点です。
以下のように、AWS CLI などによる AssumeRole
で RoleSessionName
を変更しても、SourceIdentity
は元の値が保持されます。
CloudTrail では、以下のように確認可能です。
つまり、SourceIdentity
を利用することでより正確に AWS 上の操作を行った個人をトラッキングすることが可能になります。
SourceIdentity の導入
導入前の設定
SourceIdentity
導入前は、各種設定は以下のようになっています。
Auth0 Rule (1-1) は、踏み台AWSアカウントのロール名などを含んだ SAML アサーションを生成します。
参考: Auth0 - Configure Amazon Web Services for Single Sign-On
1 2 3 4 5 6 |
# (1-1) Auth0 Rule JavaScript の一部 context.samlConfiguration.mappings = { 'https://aws.amazon.com/SAML/Attributes/Role': 'YOUR-AWS-ROLE-NAME', 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'YOUR-AWS-ROLE-SESSION-NAME', 'https://aws.amazon.com/SAML/Attributes/SessionDuration': 'time' }; |
IAMロールの設定 (1-2 ~ 1-4) についてはそれぞれ以下になっています。
細かい内容は置いておいて、sts:AssumeRoleWithSAML
と sts:AssumeRole
を許可していることが分かります。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
# (1-2) ロールの信頼ポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "[SAML ID Provider の ARN]" }, "Action": [ "sts:AssumeRoleWithSAML" ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } } ] } # (1-3) ロールのIAMポリシー { "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Resource": [ "[実利用ロール ARN]" ], "Effect": "Allow" } ] } # (1-4) ロールの信頼ポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "[踏み台ロール ARN]" ] }, "Action": [ "sts:AssumeRole" ] } ] } |
SourceIdentity を導入するための設定
本記事で書きたかったメインの部分です。
SourceIdentity
を導入するにあたり、各種リソースに以下のように設定を加えました。
Auth0 Rule (2-1) では、踏み台AWSアカウントのロール名に加え、SourceIdentity
を含んだ SAML アサーションを生成します。
参考: SAML SourceIdentityAttribute
※今回は RoleSessionName
と SourceIdentity
に同じ値(メールアドレス=xxxx@skyarch.net)を設定しています
1 2 3 4 5 6 7 |
# (2-1) Auth0 Rule JavaScript の一部 context.samlConfiguration.mappings = { 'https://aws.amazon.com/SAML/Attributes/Role': 'YOUR-AWS-ROLE-NAME', 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'YOUR-AWS-ROLE-SESSION-NAME', 'https://aws.amazon.com/SAML/Attributes/SessionDuration': 'time', <span style="color: #ffff00;">'https://aws.amazon.com/SAML/Attributes/SourceIdentity': 'YOUR-AWS-ROLE-SESSION-NAME'</span> }; |
IAMロールの設定 (2-2 ~ 2-4) についてはそれぞれ以下になっています。
sts:AssumeRoleWithSAML
と sts:AssumeRole
に加え、sts:SetSourceIdentity
を許可していることが分かります。
STS には SetSourceIdentity
という API はありませんが、SourceIdentity
を指定して AssumeRole
/ AssumeRoleWithSAML
API を叩く場合に必要となる権限です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
# (2-2) ロールの信頼ポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "[SAML ID Provider の ARN]" }, "Action": [ "sts:AssumeRoleWithSAML", <span style="color: #ffff00;">"sts:SetSourceIdentity"</span> ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } } ] } # (2-3) ロールのIAMポリシー { "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole", <span style="color: #ffff00;">"sts:SetSourceIdentity"</span> ], "Resource": [ "[実利用ロール ARN]" ], "Effect": "Allow" } ] } # (2-4) ロールの信頼ポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "[踏み台ロール ARN]" ] }, "Action": [ "sts:AssumeRole", <span style="color: #ffff00;">"sts:SetSourceIdentity"</span> ] } ] } |
sts:SetSourceIdentity
の許可設定は、フェデレーションログイン用ロール(踏み台AWSアカウントのロール)だけでなくスイッチロール用ロール(実利用AWSアカウントのロール)にも設定する必要があります。
- アカウントの境界を越えてソースIDを設定するには、2 箇所に
sts:SetSourceIdentity
アクセス許可を含める必要があります。これは、元のアカウントのプリンシパルのアクセス許可ポリシーと、ターゲットアカウントのロールのロール信頼ポリシーにある必要があります。たとえば、ロールがロールの連鎖を使用して別のアカウントでロールを引き受けるために使用される場合、これを行う必要がある場合があります。
所感など
RoleSessionName
が個人を特定する確実な証跡にはならないことを知り、SourceIdentity
を導入してみたいと考えるようになりました。
ただ Auth0 へ SourceIdentity
を導入するようなドキュメントやブログ記事が見つけられなかったので、設定箇所・設定値が分からず試行錯誤していました。
同じような状況で苦労している方がこの記事を見つけていただけると嬉しいです。
投稿者プロフィール
- 2015年8月入社。弊社はインフラ屋ですが、アプリも作ってみたいです。