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

2021.07.07

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

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

2021/08/20 追記

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

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

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

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

img

画像: 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 対応/非対応は以下ドキュメントの表から分かります。

img

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

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

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

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

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

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

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

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

img

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

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

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

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

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

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

予防的ガードレール

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

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

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

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

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

発見的ガードレール

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

便利ツール

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

おわりに

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

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

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

参考