🏢 オフィスビルのセキュリティで例えると超わかりやすい！
ABAC（属性ベースアクセス制御）は「タグの一致」でアクセス許可を決める仕組み！
オフィスビルに入るとき、あなたの
社員証
と
部屋のドア
両方に
同じ「部署タグ」が付いていたら入室OK、というイメージです。
PrincipalTag
：あなた（社員）に付いているタグ 👤
ResourceTag
：リソース（部屋）に付いているタグ 🚪
この2つを比較してアクセス制御を実現します！✨
🎯 そもそもABACって何？
従来のRBAC（ロールベース）
「誰が」「何に」アクセスできるかを 個別に定義
😓 問題点：
• 新しいリソースができるたびにポリシー更新
• 新しいユーザーが増えるたびにロール割り当て
• ポリシーが増えすぎて管理が大変！
「田中さんは EC2-001 にアクセスできる」
「佐藤さんは EC2-002 にアクセスできる」
→ 100人×100リソース = 管理地獄！
新しいABAC（属性ベース）
「タグが一致したら」アクセスOKと ルールで定義
😊 メリット：
• 新リソースにタグを付けるだけで自動適用
• 新ユーザーにタグを付けるだけで自動適用
• ポリシーは1つでOK！超シンプル！
「ユーザーのDepartmentタグとリソースの
Departmentタグが一致したらアクセスOK」
→ これ1つで全員・全リソースをカバー！
🏢 オフィスビルのセキュリティシステムで理解しよう！
PrincipalTag
「あなたの社員証のタグ」
あなたは営業部所属の社員。社員証には
「Department: Sales」 というタグが付いています。
• IAMユーザー/ロール に付けるタグ
• 「この人は誰？どんな属性？」を表す
• aws:PrincipalTag で参照
• IAMユーザー
• IAMロール
• フェデレーテッドユーザー（SAML/OIDC）
ResourceTag
「部屋のドアのタグ」
営業部の会議室のドアには
「Department: Sales」 というタグが付いています。
• AWSリソース （EC2/S3等）に付けるタグ
• 「このリソースは何用？誰の持ち物？」を表す
• aws:ResourceTag で参照
• EC2インスタンス
• S3バケット
• RDS、Lambda、その他AWSリソース
🔓 入室の仕組み
社員証のタグ
（PrincipalTag）と
ドアのタグ
（ResourceTag）が
一致したら入室OK！🎉
営業部の社員（Department: Sales）は
営業部の部屋（Department: Sales）に入れる！
❌ 経理部の部屋（Department: Finance）には入れない！
aws:PrincipalTag/タグキー
例：aws:PrincipalTag/Department
例：aws:PrincipalTag/Project
例：aws:PrincipalTag/CostCenter
• IAMロールの「タグ」タブ
• SAML/OIDCのセッションタグ
• AssumeRole時のタグ
• 人事異動時はタグを変更するだけ
• フェデレーションでも使える
• アイデンティティの属性を表す
aws:ResourceTag/タグキー
例：aws:ResourceTag/Department
例：aws:ResourceTag/Project
例：aws:ResourceTag/Environment
• S3バケットのタグ
• RDSインスタンスのタグ
• その他AWSリソースのタグ
• リソースの所有者/用途を示す
• コスト配分にも活用可能
• リソースの属性を表す
🔄 ABACの動作フロー
PrincipalTag:
Department=Sales
タグ一致を
チェック
ResourceTag:
Department=Sales
📊 タグ一致の判定パターン
Principal: Sales
Resource: Sales
Principal: Sales
Resource: Finance
Principal: Sales
Resource: (なし)
📊 PrincipalTag vs ResourceTag 完全比較
| 項目 | PrincipalTag | ResourceTag |
|---|---|---|
| 対象 | IAMユーザー / IAMロール | AWSリソース（EC2、S3など） |
| 表すもの | 「誰が」アクセスするか | 「何に」アクセスするか |
| 構文 |
aws:PrincipalTag/キー
|
aws:ResourceTag/キー
|
| 設定タイミング | ユーザー/ロール作成時 | リソース作成時 |
| 例え話 | 社員証のタグ 🪪 | 部屋のドアのタグ 🚪 |
| 変更頻度 | 人事異動時など | リソース再割り当て時など |
| 典型的なタグ | Department, Team, Role | Department, Project, Environment |
| 管理者 | IAM管理者 / HR連携 | リソース管理者 / 開発チーム |
📝 実際のIAMポリシー例
🔑 よく使う条件キー一覧
👤 PrincipalTag関連の条件キー
🚪 ResourceTag関連の条件キー
💼 実践ユースケース
部署別アクセス制御
プロジェクト別制御
環境別アクセス
コストセンター制御
マルチテナント分離
機密レベル制御
Department/department/dept など表記ゆれを防ぐため、 大文字小文字も含めて統一 しよう。PascalCase推奨！
2. タグの必須化を徹底：
リソース作成時にタグを必須にするSCP/ポリシーを設定。タグなしリソースはABACで制御できない！
3. タグの値を標準化：
「営業部」「営業」「Sales」など値がバラバラだと一致しない。 マスターデータを定義 しよう。
4. 段階的に導入：
いきなり全社適用せず、まず1つのプロジェクトや部署で試して、問題がないことを確認してから拡大。
5. IAM Access Analyzerを活用：
意図しないアクセスがないか定期的にチェック。ABACポリシーの検証にも使える！
ユーザーが 自分のPrincipalTagを変更できると 、任意のリソースにアクセスできてしまう！タグ変更権限は厳密に制限しよう。
2. リソースタグの保護：
ユーザーが リソースのタグを変更できると 、アクセス制御を迂回できる。タグ変更アクションも制限が必要！
3. タグなしリソースへのアクセス：
ResourceTagがないリソースは条件にマッチしない。 明示的な拒否ポリシー も検討しよう。
4. サービスによるタグサポートの違い：
すべてのAWSサービス/アクションがResourceTagをサポートしているわけではない。事前に確認が必要！
5. タグの伝播：
Auto Scalingで起動したEC2など、自動作成されるリソースにタグが 正しく伝播されるか 確認しよう。
✅ ABACベストプラクティス
1 タグ戦略を文書化
どのタグキーを使うか、値の規則は何か、誰がタグを管理するかを明文化。全チームで共有しよう。
2 AWS Organizationsタグポリシー活用
組織全体でタグキーの大文字小文字、許可される値を強制。表記ゆれを防止できる。
3 SCPでタグ必須化
リソース作成時に特定のタグがないと拒否するSCPを設定。タグ漏れを防止。
4 定期的なタグ監査
AWS Configルールでタグ付けコンプライアンスを監視。非準拠リソースを検出・修正。
5 最小権限の原則
ABACでもアクションは必要最小限に。「ec2:*」ではなく具体的なアクションを指定。
6 テスト環境で検証
本番適用前にテスト環境でポリシーを検証。IAM Policy Simulatorも活用しよう。
🎓 まとめ
🏢 オフィスビルのセキュリティ = ABAC
社員証のタグ（PrincipalTag）と部屋のドアのタグ（ResourceTag）が
一致したらアクセスOK！
というシンプルな仕組み
「誰が」アクセスするか
ユーザー/ロールに付ける
社員証のタグ🪪
「何に」アクセスするか
AWSリソースに付ける
部屋のドアのタグ🚪
"aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
→ タグが一致したら許可、一致しなければ拒否！
ポリシーは1つでOK！新しいユーザーやリソースが増えても
タグを付けるだけで自動的にアクセス制御が適用される！🎉
ABACを使いこなせば、
スケーラブルで管理しやすい
アクセス制御が実現できます！
まずは1つのタグ（Department等）から始めて、徐々に拡大していこう！🚀