概要
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月入社。弊社はインフラ屋ですが、アプリも作ってみたいです。
