Save 37% off PRO during our Black Friday Sale! »

AWSのABAC「ここが嬉しいよ、ここが辛いよ」

 AWSのABAC「ここが嬉しいよ、ここが辛いよ」

6d161fe47f36ac295189c3b6a0db2a9a?s=128

MasahiroKawahara

August 17, 2021
Tweet

Transcript

  1. ここが嬉しいABAC ここが辛いよABAC AKIBA.AWS ONLINE #06 – AWS IAM 編 –

    #AKIBAAWS 2021/08/17 川原 征大
  2. 自己紹介 川原 征大 • クラスメソッド • AWS事業本部 コンサルティング部所属 • 好きな

    AWSサービス ◦ AWS Organizations ◦ AWS IAM https://dev.classmethod.jp/author/kawahara-masahiro/
  3. 話の流れ IAMポリシーをざっくりと: 4min RBACをざっくりと: 4min ABAC: 4min AWS ABAC ポリシーの考慮点:

    5min AWS ABAC 設計/運用の考慮点: 5min AWS ABAC 嬉しいのか辛いのか: 8min ABACがどのような場面で必要か AWSでABACをどうやって実装するか 思っていること書きます
  4. IAMポリシーをざっくりと🐬

  5. • 誰が [Principal] • どのリソースに対して [Resource] • どのアクションを [Action] •

    (オプション) どの条件下で [Condition] • 許可/拒否するか [Effect] を定めたもの IAMポリシー = 権限
  6. IAMポリシー要素のイメージ

  7. IAMポリシーの種類 (主要なもの) • プリンシパルに付けるポリシー ➔ アイデンティティベースのポリシー (今回の話のメイン) • リソースに付けるポリシー ➔

    リソースベースのポリシー • AWSアカウントに付けるポリシー ➔ Service Control Policy(SCP)
  8. IAMポリシーの書き方(例) 引用: IAM でのポリシーとアクセス許可 - AWS Identity and Access Management

    (みなさん IAMポリシーどうやって書いていますか ...?) ・ビジュアルエディタ (便利らしい) ・JSON直書き ・YAML (CloudFormation) ・ほか (CDK, Terraform, …)
  9. やってみよう、IAMポリシー設計

  10. 登場人物

  11. 設計してみた

  12. ・・・イケてない😨 ▶▶▶ [next] RBAC の話

  13. RBACをざっくりと👺

  14. 先程のポリシー設計の問題点 • ヒトが増えたときにどうするか ◦ その都度、ヒトの権限を精査して IAMポリシーを作成する? (タイヘン) • 共通して制限(or 追加)したい権限が出たときにどうするか

    ◦ 人数分のIAMポリシーを編集する? (タイヘン) ➔ 解決策が RBAC
  15. RBACとは • Role Based Access Control (役割ベースのアクセス制御 ) • プリンシパルの役割(ロール)に基づいてポリシー設計を行う

  16. RBAC のイメージ

  17. RBACの特徴 • ヒトと権限(ポリシー) の間に 役割を挟む • 権限(ポリシー) がヒトに左右されない • IAMポリシー設計の最も基本

    • 設計/運用がシンプル、分かりやすい ◦ 役割を洗い出す ◦ 役割に対応するポリシーを設計する ◦ 役割とユーザーを紐付ける
  18. RBAC ポリシー設計Tips • まずは『職務機能のAWS管理ポリシー』を見てみよう ◦ 管理者: AdministratorAccess ◦ パワーユーザー :

    PowerUserAccess ◦ セキュリティ監査 : SecurityAudit ◦ ...など • より細かく、柔軟に制御したいときは『 カスタマー管理ポリシー』を活用 ✍ 『職務機能のAWS管理ポリシー』をベースに、不足 ( or 過剰) 権限を『カ スタマー管理ポリシー』で補おう
  19. RBACが辛くなる場面?🤔

  20. ▲『プロジェクト/チーム』単位の役割でアクセス制御

  21. None
  22. RBAC辛い 😥 ▶▶▶ [next] ABACの話

  23. ABAC 🔖

  24. RBACの課題? • スケールし続ける複数プロジェクト単位 で細かくアクセス制御を実現したいときに起きがち • 「役割」が増えたときにどうするか ◦ その都度、「役割」の権限を精査して IAMポリシーを作成する? (タイヘン)

    ➔ 解決策が ABAC
  25. ABACとは • Attribute Based Access Control (属性ベースのアクセス制御 ) • プリンシパルの属性に基づいてポリシー設計を行う

  26. ABAC のイメージ

  27. ▲比較

  28. ABACの特徴 • プリンシパル(+ アクセス先リソース) に属性を付与する • 管理するポリシー数が少なくなる • プロジェクトやチーム数の スケールに強い

    ◦ RBACは「ヒト」に左右されない ➔ ABACは「役割」に左右されない • きめ細かなアクセス制御を実現できる ◦ 複数の属性を付与して、より柔軟 (複雑) な制御も可能
  29. AWSのABAC AWSのABACは『タグ』を活用

  30. AWS ABAC ポリシーの考慮点📚

  31. ABACの範囲を決めよう • まずは 範囲をしっかり定めましょう ◦ どのサービス、どのリソース を制御対象とするか ◦ どのタグキーをアクセス制御に用いるか •

    範囲に合わせたポリシーを設計していく
  32. ABAC ポリシー設計 Tips • Condition をフル活用します • 主に以下情報(条件キー)を活用。それぞれの値を比較して許可 or 拒否を判断

    ◦ プリンシパルのタグ情報 ... aws:PrincipalTag/tag-key ◦ リソースのタグ情報 … aws:ResourceTag/tag-key ✍ 初めは Condition の構文や仕様で悩みがち。サンプルポリシーを参考にしよう • IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する - AWS Identity and Access Management • EC2インスタンスの作成や起動 /停止をタグベースの IAMポリシーで制御する例 | DevelopersIO • リモートワークで Security Groupの変更をユーザーの所属するプロジェクトだけ許可する設定を ABACでやってみた | DevelopersIO
  33. ABAC ポリシー例 引用: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセ ス許可を定義する -

    AWS Identity and Access Management
  34. ABAC ポリシー例 引用: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセ ス許可を定義する -

    AWS Identity and Access Management
  35. ABAC ポリシー例 引用: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセ ス許可を定義する -

    AWS Identity and Access Management
  36. ABAC ポリシー例 引用: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセ ス許可を定義する -

    AWS Identity and Access Management
  37. 参考: Condition(特に条件キー) 周りの深堀り https://dev.classmethod.jp/articles/aws-iam-condition-key-availability/

  38. AWS ABAC 設計/運用の考慮点🔍

  39. 属性(タグ)を「付与する人」「付与される人」 • 付与する人(=管理者)がすべきこと ◦ 開発者(IAMロール等)へのポリシー付与 (RBACでも同じ) ◦ 開発者へのタグ付け ◦ リソースへのタグ付け

    (開発者に任せるケースもある ) • 付与される人(=開発者など) に「されてほしくないこと」 ◦ 自身(もしくは他者) のポリシーを変更される (RBACでも同じ) ◦ 自身(もしくは他者) のタグを変更される ◦ リソースのタグを変更される
  40. 属性(タグ)を「付与する人」「付与される人」 • 付与する人(=管理者)がすべきこと ◦ 開発者(IAMロール等)へのポリシー付与 (RBACでも同じ) ◦ 開発者へのタグ付け ◦ リソースへのタグ付け

    (開発者に任せるケースもある ) • 付与される人(=開発者など) に「されてほしくないこと」 ◦ 自身(もしくは他者) のポリシーを変更される (RBACでも同じ) ◦ 自身(もしくは他者) のタグを変更される ◦ リソースの特定タグを変更される 『タグが付与されていること、タグが破壊されないこと』 を守り続ける必要がある!
  41. 予防的ガードレール(タグを破壊されないために) • (必須) 開発者へのタグ編集権限を剥奪しておく ◦ プリンシパル … “iam:TagRole” および “iam:UnTagRole”

    など ◦ リソース … “ec2:CreateTags” および “ec2:DeleteTags” など • (オプション) Organizations のタグポリシーで タグの値を強制 ◦ 参考: [新機能] タグポリシー機能が Organizationsに追加されてタグの値を制御できるようになりました | DevelopersIO
  42. 発見的ガードレール(タグ欠落/不備を見つけるために) • AWS Config Rule の required-tags が便利 ◦ 「AWSリソースに特定タグが付いているか」検知するための

    AWS管理ルール ◦ 自動化にも活用できる (Eventをトリガーに Lambda実行 等) https://dev.classmethod.jp/articles/config-rule-required-tags/
  43. 便利ツール: タグエディタ • AWSリソースのタグ付与状況を検索するツール • 検索結果から複数リソースへの一括タグ付与も可能 • オンデマンドなタグ調査/整備のオトモ https://dev.classmethod.jp/articles/cleanup-with-tageditor/

  44. まとめ ✍

  45. まとめ • Attribute Based Access Control (属性ベースのアクセス制御 ) • プリンシパルやリソースに属性

    (タグ) を付与してアクセス制御を実現 • プロジェクトやチームのスケールに強い • Condition をフル活用したポリシー設計 • 属性(タグ)の適用状況を監視し続ける必要がある
  46. ...で、結局AWSでABACは 嬉しいの?辛いの?👀

  47. 嬉しいところ(ABACの特徴 再掲) • プリンシパル(and アクセス先リソース) に属性を付与する • 管理するポリシー数が少なくなる • プロジェクトやチーム数の

    スケールに強い ◦ RBACは「ヒト」に左右されない ➔ ABACは「役割」に左右されない • きめ細かなアクセス制御を実現できる ◦ 複数の属性を付与して、より柔軟 (複雑) な制御も...
  48. 辛いところ 目次 • ポリシー設計 ◦ IAM Actionの設計 ◦ IAM Conditionの設計

    • タグの運用
  49. ポリシー設計の辛み🌶

  50. ABACポリシー設計でほぼほぼ読み込むページ AWS のサービスのアクション、リソース、および条件キー - サービス認証リファレンス

  51. IAM Actionの設計 • より一層、AWSドキュメントを読み込むことになる ◦ アクション名 ◦ アクションで指定するリソース (+そのARN形式) ◦

    アクションで指定できる条件キー ◦ ...等 • EC2系のアクション(ec2:xxx)が魔境 • そもそも ABACが対応しているかどうか、要確認 https://dev.classmethod.jp/articles/iam-reference-map-abac-rbac/
  52. ABACポリシー設計でまあまあ読み込むページ IAM JSON ポリシーの要素 : Condition - AWS Identity and

    Access Management AWS グローバル条件コンテキストキー - AWS Identity and Access Management
  53. IAM Condition の設計 • まずは Condition を理解するところから ◦ 条件演算子(StringEquals, StringNotEquals,

    ...IfExists 等) ◦ 条件キー(aws:PrincipalTag, aws:ResourceTag 等) ◦ ポリシー変数 ◦ ...など • 意図通りの挙動にならなかったときのトラブルシューティングが難しい • 『もし属性(タグ)が無かったときにどうなるか ...?』を考え出すと頭を抱える ◦ 参考: 【AWS IAM】Condition の条件キーやポリシー変数は可用性を意識しよう!という話 | DevelopersIO
  54. タグの運用の辛み🌶🌶🌶

  55. タグの運用 • 『ABACを維持する』ことの大変さ • AWSのタグは様々な用途で使われている。 自由度が高すぎる ◦ タグが編集されないためのガードレールは必ず敷きたい ◦ 『属性以外のタグ』は編集可能とする制御もできるが、

    Conditionが煩雑化 ◦ 継続的なタグの監視が大変 • 『どのタグをどう運用していくか』しっかりとドキュメント化することが大事
  56. そもそも... • プロジェクト単位でAWSアカウントを分けることができないか検討しよう • AWSアカウント分割が一番簡単な「 API・リソースの分離」 • 「特定AWSアカウントのリソースを複数プロジェクトで使用したい ...」➔ クロスアカウントアクセスできるか

    も ◦ リソースベースのポリシーで解決できるかも ◦ AWS Resource Access Manager(RAM) で解決できるかも
  57. 改めて まとめ ✍

  58. 改めて まとめ • ABACは RBACの課題を解決する1手段 ◦ プロジェクトやチーム数のスケールに強い ◦ きめ細かなアクセス制御 •

    でもAWS環境においては 辛いことが多い ◦ ポリシー設計 ◦ 属性(タグ)の運用 • まずは AWSアカウント分離で対応できないか、検討したい!
  59. None
  60. 参考 • 属性ベースのアクセス制御( ABAC)とは? メリットと適切なアクセス制御モデル | okta • AWS の

    ABAC とは - AWS Identity and Access Management • IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する - AWS Identity and Access Management • IAM でのポリシーとアクセス許可 - AWS Identity and Access Management • SaaSテナント分離をAWS IAMとABACで実装する方法 | Amazon Web Services • AWSのABAC(タグに基づいたアクセス制御 )の設計/運用のポイントを考える | DevelopersIO • 【AWS IAM】Condition の条件キーやポリシー変数は可用性を意識しよう!という話 | DevelopersIO • リモートワークでSecurity Groupの変更をユーザーの所属するプロジェクトだけ許可する設定を ABACでやってみた | DevelopersIO • Configルールを使ってAWSリソースの特定タグ有無をチェックする | DevelopersIO • 散らかったAWS環境の整理のためタグエディタを活用する | DevelopersIO • このアクション、ABAC ないし RBAC に対応してる?難解な IAM リファレンスに立ち向かうための地図を描いてみた | DevelopersIO