この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、ID管理していますか？
今回はIDフェデレーションでIAMを利用している際に、IdPから属性(Attribute)をAWSのタグとして受け取ることができるSession Tagの機能がリリースされたので紹介します。
New for Identity Federation – Use Employee Attributes for Access Control in AWS | AWS News Blog
RBACとABAC
良さを知るにはまず背景から。
アクセス制御の方式としてRBAC(Role-based Access Control)がよく使われます。RBACでは、権限を個人ではなくRole(役割)に割り当てて管理する方法で、個人ごとポリシーをメンテナンスしなくて良くなるのでユーザが増えても管理が楽になる仕組みでした。
しかしこれも進んでくると、今度はリソースが増えてきてアクセス制御を行うのが大変になってきます。例えば1つのEC2が増えたときに、誰がそのEC2にアクセスできて、誰がアクセスできないのかRoleをメンテナンスする必要があります。そこでユーザとリソース、及びその間にある関係や動的情報を紐付けてアクセス制御を簡単に行う方法としてABAC(Attribute-based Access Control)が使われるようになりました。
ABACではユーザやリソースに属性(Attribute)をもたせて、それをIF, THENのポリシーで制御します。例えばrole属性がmanagerのユーザはsensitivity属性がconfidentialのリソースにアクセスできる、という感じです。これによってユーザが増えてもリソースが増えても、増えたリソースに適切な属性を設定しておけばいいだけなのでポリシーのメンテナンスが不要で管理が楽になります。
AWSでは属性の役割はタグが担います。EC2にタグを付けておいて、そのタグがついているアクセスをIAMポリシーで許可するように使えます。
新機能: Session Tag
これまでAWSでのABACではタグをAWS内でしか利用できませんでした。つまりIAMでユーザ側の属性を管理することはできますが、IdPと連携している場合にはうまく活用することはできませんでした。
今回リリースされたSession Tagは、IdPを利用してSAMLやOIDCでフェデレーションを行う際に属性をAWSのタグとしてSTSで渡すことができる機能です。
図で見るとこのような形です。
IdP側のユーザで属性を管理し、利用するFederated Roleは1つでも、アクセスできるEC2を制御できます。具体的なポリシーの実装例は下記のとおりです.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "ec2:DescribeInstances"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["ec2:StartInstances","ec2:StopInstances"],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"
}
}
}
]
}Conditionの"ec2:ResourceTag/CostCenter"でEC2につけられたCostCenterタグを参照していて、"${aws:PrincipalTag/CostCenter}"でIdP側の属性と突き合わせています。渡し方はこちらに詳しくあります。
この例の場合、IdP側であるユーザの属性: CostCenterにblueとつけておくと、EC2のタグ: CostCenterがblueのものにだけ起動・停止のアクセスできるようになります。
Auth0, ForgeRock, IBM, Okta, OneLogin, Ping Identity, RSA にて動作確認されており、他のSAML 2.0やOIDCを利用したIdPでも連携できる可能性があります。
Session Tagはすべてのリージョンで追加費用無しで利用できます。
まとめ
フェデレーションでABACが利用できるようになったので、IdPを利用してユーザを管理していた環境では非常に嬉しいアップデートではないでしょうか？
是非試してみてください！