Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWSのABAC「ここが嬉しいよ、ここが辛いよ」
Search
MasahiroKawahara
August 17, 2021
Technology
11k
8
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AWSのABAC「ここが嬉しいよ、ここが辛いよ」
MasahiroKawahara
August 17, 2021
More Decks by MasahiroKawahara
See All by MasahiroKawahara
GuardDuty 検知対応を DevOps Agent で効率化しようとしている話 / GuardDuty Investigations with DevOps Agent
masahirokawahara
1
130
【セミナー資料】Claude Code をセキュアに使うための考え方と設定の勘どころ / Claude Code Webinar 20260616
masahirokawahara
2
790
Claude Code で使える DuckDB Skills を試してみた / DuckDB Skills and Claude Code
masahirokawahara
2
2.9k
Claude Code を安全に使おう勉強会 / Claude Code Security Basics
masahirokawahara
20
49k
Claude Code Skills 勉強会 (DevelersIO向けに調整済み) / claude code skills for devio
masahirokawahara
1
33k
新 Security HubがついにGA!仕組みや料金を深堀り #AWSreInvent #regrowth / AWS Security Hub Advanced GA
masahirokawahara
1
4.1k
AWS環境のリソース調査を Claude Code で効率化 / aws investigate with cc devio2025
masahirokawahara
2
2.2k
ここ一年のCCoEとしてのAWSコスト最適化を振り返る / CCoE AWS Cost Optimization devio2025
masahirokawahara
1
2.7k
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
1.7k
Other Decks in Technology
See All in Technology
サーバー常駐型の 簡易障害調査AI エージェントを作ってみた話
masayoshi
1
510
Self Healing Rollouts: Automating Production Fixes with Agentic AI
kdubois
0
130
Digitization部 紹介資料
sansan33
PRO
2
7.8k
「ミスを許さない手順書」を作ってみた 〜 個人的にはこれ以上できることはあまりなさそう/20260827-ssmjp-operation-procedure-update
opelab
18
17k
生成AI時代の クレデンシャルとパーミッション設計
nrinetcom
PRO
3
1.1k
いかに伝えるか 〜新卒エンジニアの教育のための、ライトノベル活用の一例
ikedon
1
170
Introduction to Bill One Development Engineer
sansan33
PRO
0
490
PM領域でのAI Agentの活用
lycorptech_jp
PRO
0
220
振り返りこそエンジニアの本領
negima
0
130
Nav2、Nav3 ... はたまた自作?〜 作って理解する Nav3 の設計意図 〜 / Nav2, Nav3 ... or Build Your Own? — Understanding Nav3's design intent by building it from scratch
yanzm
0
170
V8コントリビュート超入門
riyaamemiya
0
110
スクラムで身についていた動き方を、XPで捉え直してみた
codmoninc
0
150
Featured
See All Featured
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
220
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
400
Docker and Python
trallard
47
4.2k
Code Review Best Practice
trishagee
74
20k
The Curse of the Amulet
leimatthew05
2
14k
Faster Mobile Websites
deanohume
310
32k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
640
A better future with KSS
kneath
240
18k
A designer walks into a library…
pauljervisheath
211
24k
KATA
mclloyd
PRO
35
15k
It's Worth the Effort
3n
188
29k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
Transcript
ここが嬉しいABAC ここが辛いよABAC AKIBA.AWS ONLINE #06 – AWS IAM 編 –
#AKIBAAWS 2021/08/17 川原 征大
自己紹介 川原 征大 • クラスメソッド • AWS事業本部 コンサルティング部所属 • 好きな
AWSサービス ◦ AWS Organizations ◦ AWS IAM https://dev.classmethod.jp/author/kawahara-masahiro/
話の流れ IAMポリシーをざっくりと: 4min RBACをざっくりと: 4min ABAC: 4min AWS ABAC ポリシーの考慮点:
5min AWS ABAC 設計/運用の考慮点: 5min AWS ABAC 嬉しいのか辛いのか: 8min ABACがどのような場面で必要か AWSでABACをどうやって実装するか 思っていること書きます
IAMポリシーをざっくりと🐬
• 誰が [Principal] • どのリソースに対して [Resource] • どのアクションを [Action] •
(オプション) どの条件下で [Condition] • 許可/拒否するか [Effect] を定めたもの IAMポリシー = 権限
IAMポリシー要素のイメージ
IAMポリシーの種類 (主要なもの) • プリンシパルに付けるポリシー ➔ アイデンティティベースのポリシー (今回の話のメイン) • リソースに付けるポリシー ➔
リソースベースのポリシー • AWSアカウントに付けるポリシー ➔ Service Control Policy(SCP)
IAMポリシーの書き方(例) 引用: IAM でのポリシーとアクセス許可 - AWS Identity and Access Management
(みなさん IAMポリシーどうやって書いていますか ...?) ・ビジュアルエディタ (便利らしい) ・JSON直書き ・YAML (CloudFormation) ・ほか (CDK, Terraform, …)
やってみよう、IAMポリシー設計
登場人物
設計してみた
・・・イケてない😨 ▶▶▶ [next] RBAC の話
RBACをざっくりと👺
先程のポリシー設計の問題点 • ヒトが増えたときにどうするか ◦ その都度、ヒトの権限を精査して IAMポリシーを作成する? (タイヘン) • 共通して制限(or 追加)したい権限が出たときにどうするか
◦ 人数分のIAMポリシーを編集する? (タイヘン) ➔ 解決策が RBAC
RBACとは • Role Based Access Control (役割ベースのアクセス制御 ) • プリンシパルの役割(ロール)に基づいてポリシー設計を行う
RBAC のイメージ
RBACの特徴 • ヒトと権限(ポリシー) の間に 役割を挟む • 権限(ポリシー) がヒトに左右されない • IAMポリシー設計の最も基本
• 設計/運用がシンプル、分かりやすい ◦ 役割を洗い出す ◦ 役割に対応するポリシーを設計する ◦ 役割とユーザーを紐付ける
RBAC ポリシー設計Tips • まずは『職務機能のAWS管理ポリシー』を見てみよう ◦ 管理者: AdministratorAccess ◦ パワーユーザー :
PowerUserAccess ◦ セキュリティ監査 : SecurityAudit ◦ ...など • より細かく、柔軟に制御したいときは『 カスタマー管理ポリシー』を活用 ✍ 『職務機能のAWS管理ポリシー』をベースに、不足 ( or 過剰) 権限を『カ スタマー管理ポリシー』で補おう
RBACが辛くなる場面?🤔
▲『プロジェクト/チーム』単位の役割でアクセス制御
None
RBAC辛い 😥 ▶▶▶ [next] ABACの話
ABAC 🔖
RBACの課題? • スケールし続ける複数プロジェクト単位 で細かくアクセス制御を実現したいときに起きがち • 「役割」が増えたときにどうするか ◦ その都度、「役割」の権限を精査して IAMポリシーを作成する? (タイヘン)
➔ 解決策が ABAC
ABACとは • Attribute Based Access Control (属性ベースのアクセス制御 ) • プリンシパルの属性に基づいてポリシー設計を行う
ABAC のイメージ
▲比較
ABACの特徴 • プリンシパル(+ アクセス先リソース) に属性を付与する • 管理するポリシー数が少なくなる • プロジェクトやチーム数の スケールに強い
◦ RBACは「ヒト」に左右されない ➔ ABACは「役割」に左右されない • きめ細かなアクセス制御を実現できる ◦ 複数の属性を付与して、より柔軟 (複雑) な制御も可能
AWSのABAC AWSのABACは『タグ』を活用
AWS ABAC ポリシーの考慮点📚
ABACの範囲を決めよう • まずは 範囲をしっかり定めましょう ◦ どのサービス、どのリソース を制御対象とするか ◦ どのタグキーをアクセス制御に用いるか •
範囲に合わせたポリシーを設計していく
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
ABAC ポリシー例 引用: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセ ス許可を定義する -
AWS Identity and Access Management
ABAC ポリシー例 引用: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセ ス許可を定義する -
AWS Identity and Access Management
ABAC ポリシー例 引用: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセ ス許可を定義する -
AWS Identity and Access Management
ABAC ポリシー例 引用: IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセ ス許可を定義する -
AWS Identity and Access Management
参考: Condition(特に条件キー) 周りの深堀り https://dev.classmethod.jp/articles/aws-iam-condition-key-availability/
AWS ABAC 設計/運用の考慮点🔍
属性(タグ)を「付与する人」「付与される人」 • 付与する人(=管理者)がすべきこと ◦ 開発者(IAMロール等)へのポリシー付与 (RBACでも同じ) ◦ 開発者へのタグ付け ◦ リソースへのタグ付け
(開発者に任せるケースもある ) • 付与される人(=開発者など) に「されてほしくないこと」 ◦ 自身(もしくは他者) のポリシーを変更される (RBACでも同じ) ◦ 自身(もしくは他者) のタグを変更される ◦ リソースのタグを変更される
属性(タグ)を「付与する人」「付与される人」 • 付与する人(=管理者)がすべきこと ◦ 開発者(IAMロール等)へのポリシー付与 (RBACでも同じ) ◦ 開発者へのタグ付け ◦ リソースへのタグ付け
(開発者に任せるケースもある ) • 付与される人(=開発者など) に「されてほしくないこと」 ◦ 自身(もしくは他者) のポリシーを変更される (RBACでも同じ) ◦ 自身(もしくは他者) のタグを変更される ◦ リソースの特定タグを変更される 『タグが付与されていること、タグが破壊されないこと』 を守り続ける必要がある!
予防的ガードレール(タグを破壊されないために) • (必須) 開発者へのタグ編集権限を剥奪しておく ◦ プリンシパル … “iam:TagRole” および “iam:UnTagRole”
など ◦ リソース … “ec2:CreateTags” および “ec2:DeleteTags” など • (オプション) Organizations のタグポリシーで タグの値を強制 ◦ 参考: [新機能] タグポリシー機能が Organizationsに追加されてタグの値を制御できるようになりました | DevelopersIO
発見的ガードレール(タグ欠落/不備を見つけるために) • AWS Config Rule の required-tags が便利 ◦ 「AWSリソースに特定タグが付いているか」検知するための
AWS管理ルール ◦ 自動化にも活用できる (Eventをトリガーに Lambda実行 等) https://dev.classmethod.jp/articles/config-rule-required-tags/
便利ツール: タグエディタ • AWSリソースのタグ付与状況を検索するツール • 検索結果から複数リソースへの一括タグ付与も可能 • オンデマンドなタグ調査/整備のオトモ https://dev.classmethod.jp/articles/cleanup-with-tageditor/
まとめ ✍
まとめ • Attribute Based Access Control (属性ベースのアクセス制御 ) • プリンシパルやリソースに属性
(タグ) を付与してアクセス制御を実現 • プロジェクトやチームのスケールに強い • Condition をフル活用したポリシー設計 • 属性(タグ)の適用状況を監視し続ける必要がある
...で、結局AWSでABACは 嬉しいの?辛いの?👀
嬉しいところ(ABACの特徴 再掲) • プリンシパル(and アクセス先リソース) に属性を付与する • 管理するポリシー数が少なくなる • プロジェクトやチーム数の
スケールに強い ◦ RBACは「ヒト」に左右されない ➔ ABACは「役割」に左右されない • きめ細かなアクセス制御を実現できる ◦ 複数の属性を付与して、より柔軟 (複雑) な制御も...
辛いところ 目次 • ポリシー設計 ◦ IAM Actionの設計 ◦ IAM Conditionの設計
• タグの運用
ポリシー設計の辛み🌶
ABACポリシー設計でほぼほぼ読み込むページ AWS のサービスのアクション、リソース、および条件キー - サービス認証リファレンス
IAM Actionの設計 • より一層、AWSドキュメントを読み込むことになる ◦ アクション名 ◦ アクションで指定するリソース (+そのARN形式) ◦
アクションで指定できる条件キー ◦ ...等 • EC2系のアクション(ec2:xxx)が魔境 • そもそも ABACが対応しているかどうか、要確認 https://dev.classmethod.jp/articles/iam-reference-map-abac-rbac/
ABACポリシー設計でまあまあ読み込むページ IAM JSON ポリシーの要素 : Condition - AWS Identity and
Access Management AWS グローバル条件コンテキストキー - AWS Identity and Access Management
IAM Condition の設計 • まずは Condition を理解するところから ◦ 条件演算子(StringEquals, StringNotEquals,
...IfExists 等) ◦ 条件キー(aws:PrincipalTag, aws:ResourceTag 等) ◦ ポリシー変数 ◦ ...など • 意図通りの挙動にならなかったときのトラブルシューティングが難しい • 『もし属性(タグ)が無かったときにどうなるか ...?』を考え出すと頭を抱える ◦ 参考: 【AWS IAM】Condition の条件キーやポリシー変数は可用性を意識しよう!という話 | DevelopersIO
タグの運用の辛み🌶🌶🌶
タグの運用 • 『ABACを維持する』ことの大変さ • AWSのタグは様々な用途で使われている。 自由度が高すぎる ◦ タグが編集されないためのガードレールは必ず敷きたい ◦ 『属性以外のタグ』は編集可能とする制御もできるが、
Conditionが煩雑化 ◦ 継続的なタグの監視が大変 • 『どのタグをどう運用していくか』しっかりとドキュメント化することが大事
そもそも... • プロジェクト単位でAWSアカウントを分けることができないか検討しよう • AWSアカウント分割が一番簡単な「 API・リソースの分離」 • 「特定AWSアカウントのリソースを複数プロジェクトで使用したい ...」➔ クロスアカウントアクセスできるか
も ◦ リソースベースのポリシーで解決できるかも ◦ AWS Resource Access Manager(RAM) で解決できるかも
改めて まとめ ✍
改めて まとめ • ABACは RBACの課題を解決する1手段 ◦ プロジェクトやチーム数のスケールに強い ◦ きめ細かなアクセス制御 •
でもAWS環境においては 辛いことが多い ◦ ポリシー設計 ◦ 属性(タグ)の運用 • まずは AWSアカウント分離で対応できないか、検討したい!
None
参考 • 属性ベースのアクセス制御( 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