タグ情報を使用したIAMポリシー制御

Question

特定のタグ情報(キーと値)が付与されたリソース（EC2インスタンス、S3バケット）の操作が可能となる制御をポリシーで実装したいと考えております。  
「ec2:ResourceTag」や「s3:ResourceTag」を使用することで実現できると想定しており、以下のポリシーを適用したところ、マネジメントコンソール上から全てのEC2インスタンス、S3バケットが表示されない状態となってしまいます。  
エラーメッセージは「インスタンスデータ You are not authorized to perform this operation. の取得中にエラーが発生しました。」と表示されます。  
IAMポリシーにて特定のタグ情報が付与されたリソースのみ操作可能とする制御の実現可否及び実現可能な場合、ポリシーの例をご教示頂けませんでしょうか。  
なお、ポリシーは可能な限り簡素化して作成したく、Actionを細かく設定することは避けたいと考えております。  
  
■適用したポリシー  
{  
    "Version": "2012-10-17",  
    "Statement": \[  
        {  
            "Sid": "VisualEditor0",  
            "Effect": "Allow",  
            "Action": "ec2:*",  
            "Resource": "*",  
            "Condition": {  
                "StringEquals": {  
                    "ec2:ResourceTag/tag-key": "tag-value"  
                }  
            }  
        },  
        {  
            "Sid": "VisualEditor1",  
            "Effect": "Allow",  
            "Action": "s3:*",  
            "Resource": "*",  
            "Condition": {  
                "StringEquals": {  
                    "aws:ResourceTag/tag-key": "tag-value"  
                }  
            }  
        }  
    ]  
}

Answer

ご回答頂きありがとうございます。  
  
頂いたページを確認させて頂きました。  
ec2:Describe*アクションを許可することで、EC2については、タグによる制御を実装することができました。  
※ResourceTagを使用する時点で、対応していないActionがあるため、Actionレベルで操作を明確にする必要があると理解しました。  
  
以下に具体的な目的を記載させて頂きます。  
ポリシーに落とし込む上で、どういった構文で記載するとシンプルに作成できるか知見やアドバイスがございましたらご回答頂けると助かります。  
  
既存のルートアカウント上で、下記の作業を実施するための構築作業用IAMユーザを作成したいと考えております。  
【想定している作業内容】  
・新規VPCの作成  
・新規VPC(のVGW)を既存DXGWに接続  
・新規VPC-既存VPC間をVPC peeringで接続  
・新規VPC内にEC2インスタンスを作成  
・S3バケットを新規作成  
・新規VPCに、S3エンドポイントを作成  
・上記で作成したEC2インスタンスやS3バケットに対する監視設定（cloudwatch）  
  
【ポリシー制御方針】  
・既存のリソースに影響を与えないため、構築用IAMユーザには既存リソースに対する権限（参照含む）を与えない  
・構築作業用IAMユーザは上記で必要な権限のみを割り当てる  
　制御のレベルはAWSサービス単位で検討中  
  
【前提】  
・AWSアカウントの分割は実施しない  
・構築作業用IAMユーザは、構築作業完了後削除する  
・上記作業で作成するリソース（vpc,ec2,s3）に対しては、共通のタグを付与する  
  
上記で作成するリソースに対しては共通のタグを付与することから、タグによるポリシー制御の実装を検討した次第です。（特定のtagが無いリソースに対するactionを拒否する）  
構築用のユーザであるため、幅広い権限を与える必要はありますが、大まかに権限に絞りたいといったイメージです。やはり上記作業をActionレベルまで落とし込む必要があるでしょうか。

Answer

具体的な要件のご説明、ありがとうございます。  
一過性の作業に対する対応で実施するには重たい設計になりそう、という印象です。  
  
以下のページに記載されているように StringNotEquals を使用して、許可しない Action を明示的に拒否するポリシーは設計できそうです。  
  
> IAMポリシーで自分の所有リソース以外の操作を制限する - HANDS LAB  
> https://www.hands-lab.com/tech/entry/2437.html  
  
ただし CreateTags Action は (Tag を付け替えて操作できるため) 無条件に許可できないと思いますので、注意が必要と考えます。  
  
> リソース作成時にタグ付けするアクセス許可の付与  
> https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/supported-iam-actions-tagging.html  
  
相変わらず別の手段を提案するようで申し訳ありませんが、人的リソースを追加しての作業監督方法見直しや、CloudTrail で不必要な操作が行われなかった事を後から確認できるようにするなど、ポリシー設計しないで回避する手段は検討できそうにないでしょうか。

Answer

既にこちらのページは確認済みでしょうか？  
https://aws.amazon.com/jp/premiumsupport/knowledge-center/iam-ec2-resource-tags/  
  
> 特定のタグ情報が付与されたリソースのみ操作可能とする  
> ポリシーは可能な限り簡素化して作成したく、Actionを細かく設定することは避けたい  
  
操作の内容が具体的ではないので、まずは役割 (Role) の定義とそれぞれの Role が可能、不可能な操作 (Action) を明確にするところ (非常に煩雑で避けたい要件定義) から開始する必要があります。  
(大変申し訳ありませんが ResourceTag まで踏み込んだ時点で複雑な設計は避けらず、闇落ちする可能性があると申し上げています)  
  
状況が許すのであれば AWS アカウントの分割など、IAM だけではなく広い範囲で設計検討されるとポリシーのシンプルさを保つことにつながるのではないかと考えますが、いかがでしょうか。

Answer

返信が遅れてしまい大変申し訳ありませんでした。  
質問させて頂いた件につきまして、最終的な方針が固まりましたので、ナレッジとして共有させて頂きます。  
  
結論としては、以下２点で整理する方針としました。  
１．AWSアカウントの分離  
２．作成用IAMユーザと削除用IAMユーザの作成  
  
１につきましては、御提案頂いたように、既存の環境に影響を与えない最良な手として、既存のアカウントと分離する方針としました。  
これまでシングルアカウントでの運用でしたので、マルチアカウント構成に移行するという別な手間は増えましたが、システム毎にアカウントを分けることでIAMポリシー観点では制御が容易になりました。  
２につきましては、新規システム用に作成したAWSアカウントに対して、「リソース作成用のIAMポリシー」と「リソース削除用のIAMポリシー」を作成しました。ポリシーの概要は以下となります。  
・リソース作成用のIAMポリシー  
EC2,S3等の構築対象サービスに対して、create*等の作成や参照に係るactionのみを許可とするポリシーを作成しました。  
また、このポリシーに対しては、delete*等の削除に係るacitionを与えないことで、作業ミス等による削除が発生しないようにしました。  
・リソース削除用のIAMポリシー  
EC2,S3等の操作対象サービスに対して、delete*等の削除や参照に係るactionのみを許可とするポリシーを作成しました。  
また、削除に係るactionについては、EC2であればtag,S3であれば、バケット名称で対象リソースを制限することで、構築対象のリソース以外のリソースを誤って削除してしまわないよう制御しました。  
  
以上、簡単ですが本問い合わせに係る整理結果となります。  
この度は、ご回答頂きありがとうございました。

タグ情報を使用したIAMポリシー制御

Relevanter Inhalt