Amazon Web Services(AWS)は先頃、IAMリソース管理の容易化を目的として、IAMのユーザとロールのタグを利用可能にした。さらにこのリリースでは、属性ベースのアクセス制御(ABAC)機能と、AWSリソースとIAMプリンシパルを動的にマッチさせて"大規模運用での権限管理を簡略化"する機能も含まれている。
AWS Identity and Access Management (IAM)は、AWSのサービスとリソースの詳細なアクセス制御を安全に管理する上で中心となる、アカウントレベルの機能である。基本的にはポリシ内で権限を定義して、適切なプリンシパル(IAMユーザおよびロール)にアタッチするという、ロールベースのアクセス制御(RBAC)パラダイムをサポートする。IDベースとリソースベースのポリシに加えて、IAMでは、オプションである条件ポリシ要素と、IPアドレスや時刻(time of dayといった"リクエストの値に対する条件を条件演算子(等しい、より小さい、など)を用いてポリシ内に記述した式"による、属性ベースのアクセス制御(ABAC)もサポートしている。さらに、タグに基づく認証をサポートするリソースタイプ(比較的少数)を対象として、タグを使ったアクセス制御を動的に行うことも可能だ。
AWSに今回，IAMのユーザとロールをタグ付けする機能が追加されたことで、タグ付け権限の移譲とタグ付けスキームの適用が可能になり、IAMエンティティの管理が容易になった。詳細はSulay Shah氏(IAMのプロダクトマネージャ)による紹介記事に説明されている。Shah氏は別の記事で、今回の変更により，下記の２つの条件コンテキストキーを通じて、"大規模運用における権限管理を簡略化する属性ベースのアクセス制御(ABAC)"が利用可能になる，と説明している。
aws:PrincipalTag/<key-name>– このグローバル条件キーは、リクエストを生成したプリンシパル(ユーザまたはロール)にアタッチされたタグが、指定されたキー名と値にマッチすることをチェックする。iam:ResourceTag/<key-name>– このIAM条件キーは、要求の対象となるアイデンティティリソース(ユーザまたはロール)にアタッチされタグが、特定のキー名と値にマッチすることをチェックする。
新機能のおもなユースケースは、IAMプリンシパルに対して属性に基づいたAWSリソースへのアクセス権を動的に付与する、というものだ。これは、AWSリソースタグと条件内のプリンシパルタグを比較することで実現可能になる。以下の例では、各チームの現在および今後のインスタンスとメンバに対してEC2インスタンスの操作を許可すると同時に、インスタンスとメンバの"team"タグの値を変更することによる別チームへの移動を可能にしている。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RebootInstances",
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/team": "${aws:PrincipalTag/team}"
}
}
}
]
}
もうひとつの重要なユースケースは、属性に基づいてIAMプリンシパルにIAMロールを動的に割り当てを可能にする、というものだ。マルチアカウントの使用や、AWS Organizationsを通じたポリシベースのアカウント管理が一般的になりつつある(以前の記事)が、これまでは、その基盤となるクロスアカウントIAMロールのセキュリティ管理が面倒なプロセスだった。IAMプリンシパルへのアクセス許可が必要な新しいロールひとつひとつに、ターゲット"リソース"として固有のARNを使った"AssumeRole"文を繰り返す必要があったのだ。この定義が、ワイルドカードオペレータ"*"を使ってすべてのロールをターゲットとするだけで、条件に一致するIAMリソースタグによる適切な粒度のアクセス定義に基づいて定義できるようになった。以下の例では、ロールが"audit"タグに"true"の値を持っている場合にのみ、セキュリティ監査を行う権限を持ったロールとしてプリンシパルにその権限を付与している。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Resource": "*",
"Condition": {
"Bool": {
"iam:ResourceTag/audit": "true"
}
}
}
]
}
それぞれのドキュメントによると、MicrosoftのAzure Resource ManagerとGoogleのCloud IAMはいずれも現時点でRBACをサポートしているが、後者の条件式はプライベートベータ版の提供に留まっている(以前の記事)。注目すべき例外はKubernetesで、ABACおよびRBAC認証モジュールをともにサポートしている。ただし、KubernetesのRBACサポートに関する紹介記事では、ABACは強力だが"Kubernetes内に実装されいるため、[...] 管理や理解が難しい"ことを認めており、"コミュニティが開発対象として注力する"方向に基づいたアプローチであるRBACの方を推奨している。
関連するニュースとして，AWSは先日，サービスが最後にアクセスしたデータを表示するAPIを追加することで，それまではAWS Management Consoleを使って手作業で検査する必要のあったアクセス許可分析の自動化を可能にした。IAMロールに基づくIDフェデレーションや一時的なセキュリティ認証ではなく，依然として専用のIAMユーザを必要とするようなシナリオであっても，"My Securify Credentials"ページを通じて，認証情報の自己管理に関するユーザビリティが向上する，というメリットがある。
IAMのドキュメントにはユーザガイドが用意されており，IAMの仕組みやポリシ評価のロジック，AWSサービスがサポートするIAM機能について，それぞれ専用のセクションを割り当てて説明している。IAMのベストプラクティスとAWSのタグ付け方法に関するガイダンスも提供されている。サポートはIdentity and Access Managementフォーラム経由で受けられる。IAMはアカウントレベルのAWS機能として，追加料金なしで提供される。