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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
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
【セミナー資料】Claude Code をセキュアに使うための考え方と設定の勘どころ / Claude Code Webinar 20260616
masahirokawahara
2
410
Claude Code で使える DuckDB Skills を試してみた / DuckDB Skills and Claude Code
masahirokawahara
2
2.5k
Claude Code を安全に使おう勉強会 / Claude Code Security Basics
masahirokawahara
19
46k
Claude Code Skills 勉強会 (DevelersIO向けに調整済み) / claude code skills for devio
masahirokawahara
1
32k
新 Security HubがついにGA!仕組みや料金を深堀り #AWSreInvent #regrowth / AWS Security Hub Advanced GA
masahirokawahara
1
3.9k
AWS環境のリソース調査を Claude Code で効率化 / aws investigate with cc devio2025
masahirokawahara
2
2.1k
ここ一年のCCoEとしてのAWSコスト最適化を振り返る / CCoE AWS Cost Optimization devio2025
masahirokawahara
1
2.5k
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
1.6k
Amazon DevOps Guru のベースラインを整備して1ヶ月ほど運用してみた #jawsug_asa / Amazon DevOps Guru trial
masahirokawahara
3
860
Other Decks in Technology
See All in Technology
MCP Appsを作ってみよう
iwamot
PRO
4
680
MUSUBI 田中裕一『AIと共に行う「しごとのリデザイン」- スモールバックオフィス編』AI Ops Lab #4
musubi
0
230
GitHub Copilot 最新アップデート – 「一歩先」の実践活用術
moulongzhang
4
1.5k
Agent Skills設計で柔軟性と硬さのバランスが難しい話
nassy20
0
140
Oracle AI Database@Google Cloud:サービス概要のご紹介
oracle4engineer
PRO
6
1.5k
SONiCのLinuxベースを活かしたZabbix監視
sonic
0
220
日本 Fintech 未来予測レポート 2027〜2028年(オリジナル版)
8maki
0
2.3k
気づかぬうちにセキュリティ負債を生むAPIキー運用
sgwrmctk
0
180
新しいUbuntu/GNOMEが使いたいからXからWaylandへ移行頑張ってるの巻 2026-06-20
nobutomurata
0
140
【2026年版】 ベクトル検索とEmbedding最前線
mocobeta
13
3.7k
自分が詳しくない領域でAIを使う #プロヒス2026
konifar
4
1.1k
プロダクト開発から業務改善コンサルまで。事業全体へ「染み出す」ことで広がるエンジニアの可能性
ham0215
0
140
Featured
See All Featured
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.6k
Statistics for Hackers
jakevdp
799
230k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
290
Producing Creativity
orderedlist
PRO
348
40k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
Testing 201, or: Great Expectations
jmmastey
46
8.2k
Being A Developer After 40
akosma
91
590k
The SEO identity crisis: Don't let AI make you average
varn
0
490
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.3k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
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