AWSのABAC(タグに基づいたアクセス制御)の設計/運用のポイントを考える

川原征大

2021.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ABAC について思っていること書いていこうと思います。

2021/08/20 追記

以下登壇スライドで改めて説明しています。こちらを御覧ください。

[前提] そもそも ABACとは何か？

ABAC は Attribute-based access control のそれぞれ頭文字です。日本語では「属性ベースのアクセス制御」です。 AWSにおける ABACはタグを活用するため、「タグベースのアクセス制御」と言っても同じです。

以下 ABACのイメージ図です(AWSドキュメントからの引用)

画像: AWS の ABAC とは - AWS Identity and Access Management

上図では各ロールやリソース(バケットオブジェクト, インスタンス) に マーク(ハート、太陽、雷) が付いています。

ハートマークのロール は ハートマークのリソースのみ アクセスできる
太陽マークのロール は 太陽マークのリソースのみ アクセスできる
雷マークのロール は 雷マークのリソースのみ アクセスできる

各マークの実態はタグです。ロールやリソースへタグ付けを行い、アクセス制御を実現しています。

新しいロールやリソースができる際には、基本的にはタグを付与するだけでアクセス制御の枠組みに入れることができます。タグの値のバリエーションを増やすことでより細かな区分も可能です。この拡張性が ABAC のメリットです。

※ 以降の ABAC設計/運用は「ロール、リソース双方に属性(タグ)を加えて、アクセス制御を行っていく仕組み」を前提に話します。

そもそも ABAC をする必要があるか検討しよう

ABACの考慮点は多いです。単にロールやリソースへタグ付を行うだけで ABAC が完成するわけではありません。

タグ付けルールの設計
IAMポリシーの設計/ロールへのアタッチ
ポリシー・タグ状況の継続的な監視

など、設計/運用のポイントが多いです。なので、まずは「本当に ABAC を使わないといけないのか」検討すると良いでしょう。

基本は AWSアカウントを分ける ことでアクセス制御を実現できないか検討しましょう。 AWSアカウント分割が一番簡単な「マネコン・API単位の分離」の方法です。

「1アカウント内に複数プロジェクトが関与するリソース群があり、どうしてもそのアカウント内にアクセスしてそれらを使わないと行けない」といった場合に ABAC は候補にあがるでしょう。

役割を意識しよう

「タグを管理する人(管理者)」 と 「タグを付与され、制御される人(利用者)」 の 2つの役割があることを意識して、設計・運用を考えましょう。

管理者のするべき業務としては以下あるでしょう

利用者のロール等への ABAC 用ポリシーの付与
利用者のロール等へのタグ付け
リソースへのタグ付け (利用者に委任する構成もある)

利用者は制御される側なので、ABACを意識して行動する必要は基本無いでしょう。ここではできてしまってはマズイことを考えましょう。

自身(もしくは他者)のロール等のポリシーを変更できてしまう
自身(もしくは他者)のロール等のタグを変更できてしまう
リソースの特定タグを変更できてしまう

上記のような「利用者が禁止すべきアクション」も ABACのIAMポリシーで考慮する必要があります。

まずは ABAC のスコープを決めよう

ABAC設計を進めるに当たって、IAMポリシー設計は必要不可欠です。 AWS管理者が実現したい ABAC に合わせたカスタムポリシーを作成して、各AWS利用者(ロール等) へ割り当てる必要があります。そのため「 どのサービス、どのアクション 」を制限したいか、スコープをしっかりと定めないと始まりません。

サービスを決めましょう。「よく使われるサービスをタグベースで制御したい」ではいけません。制御したいサービスをリストアップします。例えば EC2, RDS, SagaMaker,... などです。

次にアクションを決めます。例えば「EC2インスタンスの操作をタグベースで制御したい」要件があったとします。これだけでは不十分です。具体的な操作を明らかにする必要があります。例えばインスタンスの「起動/終了」なのか、「開始/停止」なのか、「セキュリティグループ変更」なのか、などです。

これらはっきりさせることで後続のポリシー設計がしっかりと進むでしょう。

ABAC用ポリシーを設計しよう

前述の「ABACのスコープ」が定まったら、サービス毎の ABACポリシーを設計していきます。

ABACポリシーの設計とはいいつつ、実は全ての AWSサービスが ABACに対応しているわけではありません。各サービスの ABAC 対応/非対応は以下ドキュメントの表から分かります。

画像: IAM と連携する AWS のサービス - AWS Identity and Access Management

ABACに対応していないものは仕方がないので、諦めるか RBAC(ロールベースのアクセス制御) で対応していくか、選択しましょう。

ABACに対応していることが確認できれば、設計していきましょう。 ABACのポリシーでは Condition をほぼ使います。また条件キーとして「リソースのタグ情報: aws:ResourceTag/tag-key」や「プリンシパルのタグ情報 aws:PrincipalTag 」あたりはほぼ活用されます。

公式のドキュメントや弊社ブログにいくつか ABACポリシーの例があるので、参考にしながら進めると良いでしょう。

また、ABACポリシー設計でよく参照する AWSドキュメントの解読には以下ブログが役立ちます

このアクション、ABAC ないし RBAC に対応してる？難解な IAM リファレンスに立ち向かうための地図を描いてみた | DevelopersIO

リソースへのタグ付けを誰が行うかはっきりさせる

制御に用いるリソースへのタグ付けを「管理者が行うか」、「利用者に委ねるか」を決めることは重要です。それによって、ABACの設計/運用が変わってきます。

パターンとしては2つ、「案1: タグ付まで管理者が行う」と「案2: リソース作成から利用者に任せる」あると思います。

「案1: タグ付まで管理者が行う」は以下のようなフローがよくあります。

利用者はリソース作成の 申請 を出す
管理者は 申請 を元にリソース作成、利用者のタグを付与する
利用者は作成されたリソースを活用していく

管理者の 申請対応 を効率化するために CloudFormation などでテンプレート化したり、 SSM Automation などを活用して承認フロー化・自動化すると良いでしょう。

参考: AWS Systems Manager Automation を使って CFnスタック展開の承認フローを作ってみる | DevelopersIO

「案2: リソース作成から利用者に任せる」はリソース作成も利用者が自由に実行できるようにする方式です。「自由に」とは書いていますが、ABACを機能させるためにリソースへの適切なタグ付けを強制させないといけません。そのため「案1」に比べると、ポリシー設計が少々煩雑になります。 aws:RequestTag/tag-key 条件キーがよく使われます。

また、利用者の展開できるアプリケーション(リソース)を絞るために、 AWS Service Catalog も活用できるでしょう。

タグの監視/統制も忘れずに

予防的ガードレール

自身(もしくは他者)のロール等のタグを変更できてしまう

リソースの特定タグを変更できてしまう

"[Tips] 役割を意識しよう" で書いたように「利用者にタグを更新されないようにする」ガードレールを敷く必要があります。

例えば、ロールに付与されたタグを削除/更新されないようにするために、以下のような制限が利用者には必要でしょう。

{
    "Sid": "DenyTagUpdateForRole",
    "Effect": "Deny",
    "Action": [
      "iam:TagRole",
      "iam:UntagRole"
    ],
    "Resource": "*"
}

また、Organizations 環境であればタグポリシーを使って、「大文字小文字のルール化」や「タグ値の指定」、「特定リソースへのタグ付け強制」など行えます。

参考: 【新機能】タグポリシー機能がOrganizationに追加されてタグの値を制御できるようになりました | DevelopersIO

発見的ガードレール

AWS Config Rule の required-tags を使うことで、「AWSリソースに特定タグが付いているかどうか」検知することができます。制御対象のリソースに適切なタグが付与されているか、監視に役立ちます。

参考: Configルールを使ってAWSリソースの特定タグ有無をチェックする | DevelopersIO

便利ツール

タグの整理にはタグエディタが役に立ちます。複数リソースへの一括タグ設定や、タグ付け状況の検索などができます。オンデマンドにタグ周りの整備/調査を行いたいとき役立つ便利ツールです。

参考
- 散らかったAWS環境の整理のためタグエディタを活用する | DevelopersIO
- リソースへのタグ付けを一網打尽にする(タグエディタ編/AWS CLI編) | DevelopersIO

おわりに

以上、ABACの考慮点を書いてみました。

始めは ABACのポリシー設計が難しいと感じると思います。 Condition や条件キーを駆使する必要があるからです。しかし、最終的には ABACのポリシー設計ではなく、ABACポリシーを適用してからの運用が一番難しいところだと思っています。

タグ付けルールをどうするか、タグ付けのガードレールをどう実装するか、しっかりとチーム内で規則化・ドキュメント化する必要があるでしょう。

AWSのABAC(タグに基づいたアクセス制御)の設計/運用のポイントを考える

2021/08/20 追記

[前提] そもそも ABACとは何か？

そもそも ABAC をする必要があるか検討しよう

役割を意識しよう

まずは ABAC のスコープを決めよう

ABAC用ポリシーを設計しよう

リソースへのタグ付けを誰が行うかはっきりさせる

タグの監視/統制も忘れずに

予防的ガードレール

発見的ガードレール

便利ツール

おわりに

参考

関連記事

主なカテゴリ

AWS

おすすめ

プロダクト

コンテンツ

お問い合わせ

運営会社