web-dev-qa-db-ja.com

AWS-組織アカウントのメンバーのリソースアクセスを制限する

お客様に提供する特定のAWSラボがあります。ユーザーがラボを開くたびに、新しいメンバーアカウントが作成され、組織アカウントに追加されます。

これは、ユーザーがラボに初めてログインしたときにのみ発生します。このメンバーアカウントにはリソース制限がなく、ユーザーが望むことは何でもできます。

例えば。

  1. 任意のタイプと数のec2インスタンスを起動します。
  2. できるだけ多くのs3バケットを作成し、任意のサイズのファイルをアップロードします。
  3. 任意のタイプのRDSおよびElastiCacheクラスターを起動します。

これは私たちにとって大きな問題を引き起こしており、ラボで実行するために必要なものに応じてリソースを制限したいと考えています。

多くの研究の後、私はこれを思いついた：

Resource restrictions on OU level using SCP:
1. Deny every service by default.
2. Allow only those services which are used in tasks.
3. Allow those services in 1 particular region only (For e.g. us-east-1)
4. Limit what type of instances can be launched (For e.g. t2.micro only)
5. Limit specific AMI's using which instances can be launched (For e.g. Only free AMI's like ubuntu and linux AMI's, no windows AMI's)
6. Policy for limiting s3 bucket sizes is not possible.

Organisation account removal:
1. Can't remove member account if they don't have required information to become standalone account.
2. This information includes:
    - AWS Customer Agreement
    - choose a support plan
    - provide and verify the required contact information
    - provide a current payment method
3. This can't be automated so the idea is to create 2 OU's "Organisational units".
    - Working accounts
    - Disabled accounts
4. 1st OU will have required permissions to perform the lab tasks only (Principle of least privilege)
5. 2nd OU will have no permissions, Deny All for all services and actions.

OUの管理

https://docs.aws.Amazon.com/organizations/latest/userguide/orgs_manage_ous.html

あるOUから別のOUへのアカウントの移動プログラムは、「作業アカウントOU」の下のリストアカウントに書き込むことができます

https://docs.aws.Amazon.com/cli/latest/reference/organizations/list-accounts-for-parent.html

出力から、「JoinedTimestamp」パラメーターをフィルターで除外し、xx日より古いアカウントで移動操作を実行します。

https://docs.aws.Amazon.com/cli/latest/reference/organizations/move-account.html

経験豊富なAWSアーキテクトから、「組織単位」の2番目の部分が可能かどうかを知りたいです。

はいの場合、プログラミングの経験があまりないので、誰かがそれを達成する方法を理解するのを手伝ってくれませんか。

amazon-web-servicesaws-cliamazon-iamaws-organizations
1
Axel

あなたのアプローチは有効です。そのほとんどはSCPではなくIAMの役割を使用することを検討できますが、SCPは中央制御であるため、アカウントをOUに配置するだけで、状況に応じたIAMポリシーよりも優れていると思います。

S3/IAMなどの他のリージョンに依存するIAM/S3のようなものについては、おそらく「拒否」と「アクションなし」が必要になるでしょう。これはかなりのリストになる可能性があることに注意してください。次に、許可されたサービスの地域のホワイトリスト-必要なものはたくさんありますが、それらは見つかります。

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Sid": "AllowOutsideSingapore",
          "Effect": "Deny",
          "NotAction": [
              "iam:*",
              "aws-portal:*",
              "organizations:*",                  
              "s3:PutEncryptionConfiguration"
          ],
          "Resource": "*",
          "Condition": {
              "StringNotEquals": {
                  "aws:RequestedRegion": [
                      "ap-southeast-1"
                  ]
              }
          }
      },
      {
          "Sid": "WhitelistAllowedServices",
          "Effect": "Allow",
          "Action": [
              "ec2:*",
              "autoscaling:*"
  }
}

特定のAMIのみを適用するのは非常に面倒です。それらをAMIIDでリストするポリシーを作成する必要があります。その後、新しいAMIがリリースされるたびにポリシーを手動で更新する必要があります。

OUの移動に関する質問は申し訳ありません。ここでの別のアプローチは、許可権限を上書きするため、SCPのアカウントに「すべて拒否」ポリシーを直接添付するか、IAMロールに「すべて拒否」権限を追加することです。

1
Tim