DEA / ドメイン4 データセキュリティとガバナンス
認可の方式と最小権限
データ基盤では、利用者とデータセットの組み合わせが急に増えます。部門が増え、テーブルが増えるたびにポリシーを書き足していると、権限が広がりすぎるか、管理できなくなります。 DEA では、ビジネスの要件に合う認可の方式 (ロールベース、タグベース、属性ベース) を選び、マネージドポリシーで足りないときにのカスタムポリシーを書く力が問われます。
Point
- RBAC = Role-Based Access Control (ロールベースのアクセス制御) の略です。
- ABAC = Attribute-Based Access Control (属性ベースのアクセス制御) の略です。AWS では主にタグを属性として使います。
- TBAC = Tag-Based Access Control は、Lake Formation の LF タグによる方式を指すことが多い略称です。
- 和訳
- Attribute: 属性
- Least privilege: 最小権限
- Weblio英和辞書「attribute」
概要
認可は「認証された主体に、何をさせてよいか」を決める仕組みです。
AWS の ポリシーでは、アクション (Action)、対象 (Resource)、条件 (Condition) の3つで許可の範囲を絞ります。
| 見るポイント | 代表的な判断 |
|---|---|
| 職務の種類が少なく安定しているか | ロールベースで、職務ごとのロールを作ります。 |
| プロジェクトやチームが頻繁に増えるか | 属性ベースで、タグの一致を条件にします。ポリシーを書き換えずに済みます。 |
| 対象がのテーブル・列か | IAM のタグではなく の を使います。 |
| マネージドポリシーが広すぎるか | 必要なアクションとリソースに絞ったカスタムポリシーを書きます。 |
主要技術
①ロールベースのアクセス制御 (RBAC)
職務 (データエンジニア、アナリスト、監査担当など) ごとにロールを作り、そのロールに必要な権限を付けます。 利用者は自分の職務のロールを引き受けて作業します。
| 長所 | 短所 |
|---|---|
| 職務と権限の対応が分かりやすく、監査しやすいです。 | 新しいプロジェクトやデータセットが増えるたびに、ロールやポリシーの追加・修正が必要です。 |
| AWS マネージドポリシーの「職務機能」ポリシー (例: データサイエンティスト向け) を出発点にできます。 | 細かく分けるとロールの数が爆発します (ロールの爆発)。 |
データベースの中の権限 ( のロール、GRANT) もロールベースで設計するのが一般的です (「Redshift のアクセス制御とデータ共有」の章)。
②属性ベースのアクセス制御 (ABAC) ⚠️ 頻出
プリンシパル (ロールやセッション) のタグと、リソースのタグが一致する場合だけ許可します。
たとえば「project タグが一致する オブジェクトと ジョブだけを操作できる」というポリシーを1つ書けば、新しいプロジェクトが増えてもタグを付けるだけで済みます。
{
"Effect": "Allow",
"Action": ["glue:StartJobRun", "glue:GetJobRun"],
"Resource": "*",
"Condition": {
"StringEquals": {"aws:ResourceTag/project": "${aws:PrincipalTag/project}"}
}
}
| 条件キー | 意味 | 使い道 |
|---|---|---|
aws:PrincipalTag/キー | リクエストした主体のタグ | 主体がどのチームかを表します。 |
aws:ResourceTag/キー | 操作対象のリソースのタグ | リソースがどのチームのものかを表します。 |
aws:RequestTag/キー | 作成時などにリクエストで付けようとしているタグ | 作成するリソースに正しいタグを強制します。 |
aws:TagKeys | リクエストに含まれるタグのキー | 付けてよいタグのキーを制限します。 |
や SAML では、ID プロバイダーの属性 (部署など) をセッションタグとして渡せます。これにより、社員の所属が変わると自動で権限も変わります。
注意点として、ABAC はタグを付け替えられると権限も変わります。タグの付け外し (iam:TagRole、s3:PutObjectTagging など) の権限を絞らないと、自分でタグを変えて権限を広げられてしまいます。また、すべてのサービス・アクションがリソースタグの条件に対応しているわけではないため、公式ドキュメントの「ABAC に対応するサービス」で確かめます。
③タグベースのアクセス制御 (LF タグ)
のテーブルや列の単位でタグベースの制御をしたい場合は、 の を使います。 LF タグは のタグとは別物で、互いに置き換えられません。
| 方式 | 対象 | 判断ポイント |
|---|---|---|
| IAM のタグ (ABAC) | AWS リソース ( 、 ジョブ、 クラスターなど) | AWS の 操作の可否を決めます。 |
| LF タグ (LF-TBAC) | Data Catalog のデータベース・テーブル・列 | 分析エンジンからのデータの読み書きの可否を決めます。 |
詳細は「AWS Lake Formation」の章で扱います。
④マネージドポリシーとカスタムポリシー
| ポリシー | 管理者 | 向いている場面 | 注意点 |
|---|---|---|---|
| AWS マネージドポリシー | AWS | 素早く始めたい、職務機能に合うものがある | 対象リソースが * のものが多く、にはなりにくいです。AWS が内容を更新することがあります。 |
| カスタマー管理ポリシー | 利用者 | 特定の・テーブル・キーに絞りたい | 複数のロールに付けて再利用でき、バージョン管理されます。 |
| インラインポリシー | 利用者 (1つの主体に埋め込む) | その主体だけの例外的な権限 | 再利用できず、棚卸しが難しくなります。 |
マネージドポリシーで足りない典型は、「AmazonS3ReadOnlyAccess ではすべてのバケットを読めてしまう」「AWSGlueServiceRole にない の復号が必要」といった場面です。
この場合、必要なアクションを、必要なリソース ARN に、必要な条件付きで許可するカスタマー管理ポリシーを作ります。
⑤最小権限のポリシーの組み立て方 ⚠️ 頻出
| 絞る要素 | 例 |
|---|---|
| アクション | s3:* ではなく s3:GetObject と s3:ListBucket |
| リソース | arn:aws:s3:::sales-lake/curated/* のようにプレフィックスまで指定します。ListBucket はの ARN に、GetObject はオブジェクトの ARN に付けます。 |
| 条件 | aws:SourceVpce (特定の経由だけ)、aws:SecureTransport ( だけ)、s3:prefix (一覧できるプレフィックス) |
| 拒否 | 一部だけ除きたいときは、許可を広げてから明示的な Deny で外します。 |
サービス固有の条件キーで、データの単位まで絞れるものもあります。 の dynamodb:LeadingKeys はリクエストのの値を条件にでき、${aws:PrincipalTag/tenant} のようなポリシー変数と組み合わせると「自分のテナントの項目だけ」を許可できます (ForAllValues:StringEquals で書きます)。Scan はキーに関係なく全項目を返すため、この方式では許可しません。AmazonDynamoDBReadOnlyAccess のようなマネージドポリシーでは表現できない、カスタムポリシーが必要な典型です。
Access Analyzer はづくりの道具です。
| 機能 | 使い道 |
|---|---|
| ポリシーの生成 | のログから、そのロールが実際に使ったアクションを基にポリシーの案を作ります。 |
| ポリシーの検証 | 文法の誤りや、ベストプラクティスに反する書き方 (広すぎる PassRole など) を指摘します。 |
| カスタムポリシーチェック | 変更後のポリシーが新しいアクセスを許していないか、特定の重要なアクションを許していないかを確かめます (有料)。 |
| 外部アクセスの分析 | バケット、 キー、IAM ロールなどがアカウントや組織の外へ共有されていないかを検出します。 |
| 未使用のアクセスの分析 | 使われていないロール、、アクションを見つけます (有料)。 |
試験対策
認可の問題では、まず「権限を与える単位が増え続けるか」を見ます。増え続けるならタグによる方式、安定しているならロールベースです。 次に「対象が AWS リソースの操作か、のテーブル・列か」で と を分けます。
①判断マトリクス
| 問題文のキーワード | 選ぶもの | 理由 |
|---|---|---|
| プロジェクトが頻繁に増え、ポリシーの修正を減らしたい | ABAC (aws:PrincipalTag と aws:ResourceTag の一致) | タグを付けるだけで権限が決まります。 |
| 社員の部署の異動に合わせて自動で権限を変えたい | ID プロバイダーの属性をセッションタグにする ABAC | 所属の変更が権限に反映されます。 |
| 職務ごとに固定の権限を与えたい | RBAC (職務ごとのロール) | 対応が分かりやすく監査しやすいです。 |
| 数百のテーブルを機密度ごとに分けて許可したい | の | 表・列の単位でタグを付けて許可できます。 |
| マネージドポリシーでは全を読めてしまう | 特定のバケット ARN に絞ったカスタマー管理ポリシー | にします。 |
| 実際に使った権限だけのポリシーを作りたい | Access Analyzer のポリシー生成 | の利用実績から作ります。 |
| ポリシー変更で新しいアクセスが増えないか確かめたい | Access Analyzer のカスタムポリシーチェック | 変更前後の差を検証します。 |
| 使っていないロールや権限を棚卸ししたい | Access Analyzer の未使用のアクセスの分析 | 不要な権限を外せます。 |
| 特定の 経由のときだけ許可 | aws:SourceVpce 条件 | ネットワーク経路を条件にできます。 |
②よくある誤答
- のタグと を同じものと考えること。別の仕組みで、互いに置き換えられません。
- ABAC でタグの変更権限を絞らないこと。利用者がタグを付け替えて権限を広げられます。
- を「マネージドポリシーを付けること」と考えること。マネージドポリシーはリソースを絞れないものが多いです。
- 一部を除外したいのに Allow の書き方だけで解こうとすること。明示的な Deny で除外するほうが確実です。
参考文献
- Define permissions based on attributes with ABAC authorization
- Managed policies and inline policies
- AWS global condition context keys
- Using AWS Identity and Access Management Access Analyzer
- IAM Access Analyzer policy generation
- Lake Formation tag-based access control
- AWS Certified Data Engineer - Associate 試験ガイド