タイトルの内容。
マスターAWSアカウント内に、いくつかの個人アカウント、つまりAWS Identity and Access Management(IAM)ユーザーがいます。特定のIAMユーザーをグループに割り当て、特定のAmazon EC2インスタンスを終了したり、特定のAmazonマシンイメージ(AMI)の登録を解除したりしないようにしたい。
彼らが自分のもので遊んでいるかどうかは気にしませんが、私は彼らに私のものに触れてほしくないです。
それは可能ですか?
タイトルの内容。
マスターAWSアカウント内に、いくつかの個人アカウント、つまりAWS Identity and Access Management(IAM)ユーザーがいます。特定のIAMユーザーをグループに割り当て、特定のAmazon EC2インスタンスを終了したり、特定のAmazonマシンイメージ(AMI)の登録を解除したりしないようにしたい。
彼らが自分のもので遊んでいるかどうかは気にしませんが、私は彼らに私のものに触れてほしくないです。
それは可能ですか?
AWSは、EC2およびRDS内のIAMサポートのこの長年の欠点に対処するためにAmazonEC2およびAmazonRDSのリソースレベルのアクセス許可を発表しました(他のAWSサービスと比較して、詳細/背景については以下の元の回答を参照してください)。
今日、 AmazonEC2とAmazonRDSにリソースレベルのパーミッションを導入することで、IAMをさらに強力にしています。[...]
EC2側では、IAMポリシーを作成して使用し、EC2インスタンス、EBSボリューム、イメージ、ElasticIPアドレスへのアクセスを制御できるようになりました。[...]
できることのほんの一部を次に示します。
- より大規模なマルチユーザーEC2環境内で、ユーザーが限られたリソースセットを操作できるようにします。
- 「開発」リソースと「テスト」リソースに異なる権限を設定します。
- どのユーザーがどのインスタンスを終了できるかを制御します。
- 特定のリソースを操作する場合は、MFA認証などの追加のセキュリティ対策を要求します。
これにより、多数のセキュリティの問題が解決され、かなりの数の新しいユースケースも可能になります。
さらに、EC2ポリシーステートメントには、EC2リソース上のタグへの参照を含めることができます。これにより、パーミッションと請求レポートに同じタグ付けモデルとスキーマを使用できます。最後に、ec2:Region、ec2:Owner、ec2:InstanceTypeなどの条件タグの拡張セットがあります[...] 。詳細については、AmazonEC2の条件キーを参照してください。
例3のバリエーションを次に示します。ユーザーが手元のユースケースの特定のインスタンスのみを停止および開始できるようにします。これにより、ユーザーはタグ「department=dev」を持つインスタンスのみを開始および停止[および終了]できます。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:StopInstances",
"ec2:StartInstances",
"ec2:TeminateInstances"
],
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/department": "dev"
}
}
}
]
}
リソースレベルのアクセス許可のサポートは、指定されたリソースに対する次の一連のアクションに制限されます。これは、ユースケースの一部(AMIの登録解除など)を除外します。この複雑で広範囲にわたる機能の基盤に対する信頼 は明らかです。ただし、2013年の残りの期間に追加のAPIのサポートを追加する予定であることを発表するには十分な高さです(AWSは通常、ロードマップを公開していません)。
- インスタンス-再起動、開始、停止、終了。
- EBSボリューム-アタッチ、削除、デタッチ。
これはあなたが望む方法では不可能だと思います(そして私を含む他の多くの人も)。
アクションではなく特定のサービスのリソースへのアクセスを制限したい-AWSIdentityand Access Management(IAM)は原則として両方をサポートしていますが、すべてのAWS製品/サービスがリソースに基づく制限を提供しているわけではありません。残念ながら、 Amazon EC2はこれらの1つであり、この違いの例としても取り上げられています。他のAWS製品との統合を参照してください。
次の表は、サービスのアクション、リソース、またはその両方へのアクセスを制御するIAMアクセス許可を付与できるかどうかをまとめたものです。たとえば、IAMを使用して、ユーザーがアクセスできるAmazon EC2アクションを制御できますが、IAMを使用して、AMI、ボリューム、インスタンスなどへのユーザーのアクセスを制御することはできません。 [強調鉱山]
他のアカウントのニーズによっては、破壊的と見なされるアクションを実行する能力を少なくとも制限できる場合があります。たとえば、AWSPolicyGeneratorを介して利用可能なアクションを調べることができます。
ec2:DeregisterImage
-ユーザー/グループに対して拒否された場合の明らかな効果ec2:ModifyInstanceAttribute
-これは、ユーザー/グループに対して拒否された場合に、インスタンスの終了保護を有効にすることで役立ちます。デフォルトでは、起動したインスタンスをすべて終了できます。インスタンスの偶発的な終了を防ぎたい場合は、インスタンスの終了保護を有効にすることができます。
つまり、終了保護を有効にすると、使用許可のない人ec2:ModifyInstanceAttribute
はこれらのインスタンスをまったく終了できなくなります。
明らかに、それぞれ制限されたアカウントは、もはや自分のリソースの呼び出しを容易にすることはできません。
さらに、これは彼らが派手なクラスターコンピューティングエイトエクストララージインスタンスなどを実行することを妨げることはなく、それぞれのコストが順番に発生します;)
セットアップ/環境によっては、代わりに統合請求を検討することをお勧めします。これは、基本的に、他のアカウントが使用するリソースの料金を支払っている別のアカウントの下に1つまたは複数のAWSアカウントを収集する方法を提供します。
これは主に会計機能ですが、関心のある領域を分離するためにも使用できます。たとえば、IAMの権利などに関して、それぞれ独立した運用を実現するために、開発アカウントと本番アカウントを分離することは非常に一般的です。
紹介ブログの投稿「新しいAWS機能:統合請求」では、概要がわかりやすく説明されています。ここでは、AWS統合請求ガイドの明らかなユースケースに関するトピックを紹介します。
有料アカウントには、リンクされたアカウントのすべての費用が請求されます。 ただし、リンクされた各アカウントは、他のすべての点で完全に独立しています(サービスへのサインアップ、リソースへのアクセス、AWSプレミアムサポートの使用など)。有料アカウントの所有者は、リンクされたアカウントの所有者に属するデータ(Amazon S3のファイルなど)にアクセスできません。各アカウント所有者は、独自のAWSクレデンシャルを使用して、リソースにアクセスします(たとえば、独自のAWSシークレットアクセスキー)。 [強調鉱山]
明らかに、この機能は大規模な顧客を対象としていますが、シナリオによっては、必要に応じてAWSアカウントとリソースを分離するソリューションを考え出すことができる場合があります。