« 【開催報告】IVS CTO Night and Day 2016 Winter powered by AWS | メイン | AWS Certificate Manager (ACM) 証明書の自動更新時の注意点 »

AWS Organizations の発表: 複数 AWS アカウントの一元管理

本日(訳者注:2016年11月29日)、AWS はAWS Organizations の提供を開始しました。組織内の全ての AWS アカウントを一元管理する新しい方法です。AWS アカウントを組織単位(OU)と呼ばれるグループに分け、ポリシーを組織単位やアカウント毎に適用できます。たとえば、アプリケーション、環境、チーム、その他ビジネスにとって意味のあるグループ毎に、AWS アカウントを組織化できるようになります。

Organizations があれば、複数のAWS アカウントのセキュリティポリシーをそれぞれ管理する必要がなくなります。Organizations が提供される前は、もし複数の AWS アカウントがある場合、それら AWS アカウントにおけるユーザーに、各 AWS サービスに対して適切なアクセス権を 付与する必要がありました。それぞれのアカウント上でセキュリティ設定を個別に行うか、各アカウントに繰り返し設定を適用するためのカスタムスクリプトを書かなければなりませんでした。それにも関わらず、それら AWS アカウントにおけるユーザーが管理者権限を持っていれば、定義された権限をバイパスできてしまいました。Organizations では、組織全体、組織単位(OU)ごと、もしくは、個々のアカウントごとにポリシーを構成し適用できるサービスコントロールポリシー (SCP) を提供します。このブログ投稿で Organizations の使い方の例を見ていきましょう。

 

組織の作成

たとえば、ヘルスケア業界や金融業界の規制に準拠したソフトウェアを AWS 上にデプロイし稼働させたいとしましょう。、ISOSOC などの規制によると、AWS 上で保護されたヘルスケア情報を処理し、保管し、転送するためには、指定された AWS サービスだけを使用するようにソフトウェアを制限しなければなりません。Organizations があれば、そのような規制が許可する AWS サービスだけにアクセスするようソフトウェアを制限できます。SCP は組織内の全てのアカウントに渡って AWS サービスへのアクセスを制限し、SCP が効いている AWS アカウントにおいてどんなユーザーであってもポリシーの上書きはできません。新しい組織を作る時は、マスターアカウント となるアカウントから開始する必要があります。マスターアカウントとはその組織を所有し、全ての管理者用アクションが適用されます。マスターアカウントは、SCP やアカウントグループの設定から、メンバーアカウントと呼ばれる自分以外の AWS アカウントの支払い方法まで定義できます。一括請求と同様、マスターアカウントは、メンバーアカウントの AWS 請求書を支払うアカウントでもあるので、賢明に選択してください。

この投稿では全ての例において AWS CLI を使用しますが、Organizations では AWS 管理コンソールや AWS SDK も使用可能です。

次の例では、create-organization という API を使って、Full_Control モードで新しい組織を作成します。

server:~$ aws organizations create-organization --mode FULL_CONTROL

結果は以下です。

{
    "organization": {
        "availablePolicyTypes": [
            {
                "status": "ENABLED",
                "type": "service_control_policy"
            }
        ],
        "masterAccountId": "000000000001",
        "masterAccountArn": "arn:aws:organizations::000000000001:account/o-1234567890/000000000001",
        "mode": "FULL_CONTROL",
        "masterAccountEmail": "master.account@example.corp",
        "id": "o-1234567890",
        "arn": "arn:aws:organizations::000000000001:organization/o-1234567890"
    }
}

この例では、この組織にセキュリティポリシーを設定するため、Full_Control モードで作成しました。組織の作成には Full_Control モードか Billing モードという二つの異なるモードがあります。Full_Control モードは Billing モードができる全てのことができる上に、サービスコントロールポリシーを適用する機能があります。

注意: 一括請求を現在ご利用の場合、一括請求ファミリーは AWS Organizations に自動的に Billing モードにて移行されます。一括請求と同様、メンバーアカウントで発生した全ての費用がマスターアカウントに請求されます。

 

組織にメンバーを追加

作成された組織にメンバーを追加するには、組織の中に新規 AWS アカウントを作成するか、既存アカウントを招待します。

新規 AWS アカウントの作成

Organizations は組織内に新しい AWS アカウントをプログラムで作成する API を提供します。email アドレスとアカウント名さえ指定すれば、残りの情報 (住所など) はマスターアカウントから継承します。

AWS CLI を使って新しいアカウントを作成するには、新しいアカウントに割り当てたい email アドレスとアカウント名を引数に create-account を呼びます。

server:~$ aws organizations create-account --account-name DataIngestion --email data.ingestion.prod@example.corp

AWS アカウント作成は非同期処理で、 create-accountcreateAccountStatus の応答を返します:

{
    "createAccountStatus": {
        "requestedTimestamp": 1479783743.401,
        "state": "IN_PROGRESS",
        "id": "car-12345555555555555555555555556789",
        "accountName": "DataIngestion"
    }
}

createAccountStatus id を引数にして describe-create-account-status を呼べば、その AWS アカウントがいつ使用可能になるか分かります。アカウントは一般的に数分以内で使用可能になります。

既存アカウントの招待

組織に既存 AWS アカウントを招待することもできます。組織に AWS アカウントを招待するためには、AWS アカウント ID か email アドレスが必要です。

AWS CLI でのコマンドは invite-account-to-organization です

server:~$ aws organizations invite-account-to-organization --target id=data.processing.prod@example.corp,type=EMAIL

このコマンドは、送られたリクエストに関する全ての情報を含む handshake オブジェクトを返します。この例は、 data.processing.prod@example.corp のアカウントに、 id 1234567890 の組織に参加するように送られたリクエストです。

{
    "handshake": {
        "id": "h-77888888888888888888888888888777",
        "state": "OPEN",
        "resources": [
            {
               "type": "ORGANIZATION",
               "resources": [
                  {
                     "type": "MASTER_EMAIL",
                     "value": "master.account@example.corp"
                  },
                  {
                     "type": "MASTER_NAME",
                     "value": "Example Corp"
                  },
                  {
                     "type": "ORGANIZATION_MODE",
                     "value": "FULL"
                  }
             ],
             "value": "o-1234567890"
          },
          {
             "type": "EMAIL",
             "value": "data.processing.prod@example.corp"
          }
        ],
        "parties": [
            {
              "type": "EMAIL",
              "id": "data.processing.prod@example.corp"
            },
            {
              "type": "ORGANIZATION",
              "id": "1234567890"
            }
            ],
            "action": "invite",
            "requestedTimestamp": 1479784006.008,
            "expirationTimestamp": 1481080006.008,
            "arn": "arn:aws:organizations::000000000001:handshake/o-1234567890/invite/h-77888888888888888888888888888777"
   }
}

上記のコマンドはアカウント所有者に、組織に参加するように招待された旨を通知する email が送られます。招待された AWS アカウントの所有者が、その組織へ参加する条件に同意した場合は、email 中のリンクからリクエストを承諾するか、 accept-handshake-request を呼び出します。

 

組織の参照

現時点で、この組織には DataIngestion and DataProcessing という二つのメンバーアカウントが追加されています。マスターアカウントは master.account@example.corp です。デフォルトでは、アカウントは組織のルート直下に配置されます。次の図に示されている通り、ルートとは組織構造のベースで、全ての組織単位(OU)やアカウントはそこから分岐します。

list-accounts という CLI コマンドで、組織内の全てのアカウントを参照できます。

server:~$ aws organizations list-accounts

list-accounts コマンドは、アカウント一覧とどのように組織に参加したかの詳細を返します。マスターアカウントはメンバーアカウントと一緒の組織であることに注意してください。

{
    "accounts": [
        {
           "status": "ACTIVE",
           "name": "DataIngestion",
           "joinedMethod": "CREATED",
           "joinedTimestamp": 1479784102.074,
           "id": "200000000001",
           "arn": "arn:aws:organizations::000000000001:account/o-1234567890/200000000001"
        },
        {
           "status": "ACTIVE",
           "name": " DataProcessing ",
           "joinedMethod": "INVITED",
           "joinedTimestamp": 1479784102.074,
           "id": "200000000002",
           "arn": "arn:aws:organizations::000000000001:account/o-1234567890/200000000002"
        },
        {
           "status": "ACTIVE",
           "name": "Example Corp",
           "joinedMethod": "INVITED",
           "joinedTimestamp": 1479783034.579,
           "id": "000000000001",
           "arn": "arn:aws:organizations::000000000001:account/o-1234567890/000000000001"
        }
    ]
}

サービスコントロールポリシー

サービスコントロールポリシー (SCP) によって、AWS アカウントがどの AWS サービスや API にアクセスできるかを統制できます。SCP はアカウント内の全てのエンティティ (ルートユーザー、AWS Identity and Access Management (IAM) ユーザー、IAM ロール) に適用されます。この例では、7つの AWS サービスにのみアクセスを許可する SCP を設定しようとしています。

SCP は IAM ポリシーと連携して動作することに注意してください。この SCP は一連のサービスへのアクセスを許可しますが、ユーザーに対して更に制限された IAM ポリシーを設定することも可能です。AWS は最も制限されたポリシーの組み合わせを実施します。

SCP の適用のされ方は、マスターアカウントとその他のアカウントで異なります。組織から自分自身をロックアウトしないように、組織に適用されるSCP はマスターアカウントには適用されません。

 

ポリシーの作成

この例では、与えられた一連のサービスだけにアクセスさせたいので、リストされたサービスだけにアクセス権を与える Allow ポリシーを作成します。次のポリシーは、Amazon DynamoDB, Amazon RDS, Amazon EC2, Amazon S3, Amazon EMR, Amazon Glacier, そして Elastic Load Balancing へのアクセスを許可します。

server:~$ aws organizations create-policy --name example-prod-policy --type service_control_policy --description "All services allowed by regulation policy." --content file://./Regulation-Policy.json

Regulation-Policy.json の中身は以下の通りです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                 "dynamodb:*","rds:*","ec2:*","s3:*","elasticmapreduce:*",
                 "glacier:*","elasticloadbalancing:*"
             ],
             "Effect": "Allow",
             "Resource": "*"
        }
    ]
}

SCP は IAM ポリシーと同じ構造に従います。この例は Allow ポリシーですが、SCP は特定のサービスや API へのアクセスを制限する Deny ポリシーも同様に記述できます。

CLI によって組織の SCP を作成するには、以前の SCP を Regulation-Policy.json に保存し、 create-policy を呼びます。

server:~$ aws organizations create-policy --name example-prod-policy --type service_control_policy --description "All services allowed for regulation policy." --content file://./Regulation-Policy.json

The create-policy コマンドは作成されたポリシーを返します。組織の要素に適用する時のために、policy id を保存しておいてください。

{
"policy": {
"content": "{\n\"Version\": \"2012-10-17\",\n\"Statement\": [\n {\n \"Action\": [\n \"dynamodb: *\",\"rds: *\",\"ec2: *\",\"s3: *\",\"elasticmapreduce: *\",\"glacier: *\",\"elasticloadbalancing: *\"\n],\n \"Effect\": \"Allow\",\n\"Resource\": \"*\"\n}\n ]\n}\n",
"policySummary": {
"description": "All services allowed for regulation policy.",
"type": "service_control_policy",
"id": "p-yyy12346",
"arn": "arn:aws:organizations:: 000000000001:policy/o-1234567890/service_control_policy/p-yyy12346",
"name": "example-prod-policy"
        }
    }
}

ポリシーのアタッチ

ポリシーを作成した後は、組織のエンティティにそれをアタッチします。ルートアカウントにも、組織単位(OU)にも個々のアカウントにもアタッチできます。アカウントは組織ツリーの上位にある全てのポリシーを継承します。ここでは簡単のため、 example-prod-policy に定義されている Example Corp. Prod SCP を組織全体に適用するためルートにポリシーを適用しましょう。ルートは組織ツリーの最上位要素のため、ツリーに適用されたポリシーは組織の全メンバーに適用されます。

CLI を使う場合、最初に list-roots を呼んで、ルート id を取得する必要があります。ルート id を取得したら、 attach-policy を呼んで、 ( create-policy の応答で得られた) example-prod-policy id とルート id を渡します。

server:~$ aws organizations list-roots
{
    "roots": [
        {
            "policyTypes": [
                {
                    "status": "ENABLED",
                    "type": "service_control_policy"
                }
            ],
            "id": "r-4444",
            "arn": "arn:aws:organizations::000000000001:root/o-1234567890/r-4444",
             "name": "Root"
        }
    ]
}
server:~$ aws organizations attach-policy --target-id r-4444 --policy-id p-yyy12346

それではルート上のポリシーを確認してみましょう。ルート上で list-policies-for-target を呼び出すと、組織のルートにアタッチされている全てのポリシーが表示されます。

server:~$ aws organizations list-policies-for-target --target-id r-4444 --filter service_control_policy
 
{
    "policies": [
        {
            "awsManaged": false,
            "description": "All services allowed by regulation policy.",
            "type": "service_control_policy",
            "id": " p-yyy12346",
            "arn": "arn:aws:organizations::000000000001:policy/o-1234567890/service_control_policy/p-yyy12346",
            "name": "example-prod-policy"
        },
        {
            "awsManaged": true,
            "description": "Allows access to every operation",
            "type": "service_control_policy",
            "id": "p-FullAWSAccess",
            "arn": "arn:aws:organizations::aws:policy/service_control_policy/p-FullAWSAccess",
            "name": "FullAWSAccess"
        }
    ]
}

ルート上での list-policies-for-target から、example-prod-policyFullAWSAccess という二つのポリシーが返されました。FullAWSAccess は AWS 管理ポリシーで、組織内で全ての要素にデフォルトで適用されています。組織を作ると全てのルート、組織単位(OU)、アカウントは FullAWSAccess を有していて、AWS 内の全てのリソース (*:*) にアクセスできます。

もし Example Corp. Prod SCP の特定のサービスにアクセスを制限したい場合は、 FullAWSAccess を削除しなければなりません。上記の例では、Organizations はルートアカウントに、FullAWSAccess ポリシー かつ Example Corp. Prod SCP で許可されたサービス、つまり 全てのAWS のサービスアクセスへのアクセスを許可しています。Example Corp. Prod SCP で意図した制限をかけたい場合は FullAWSAccess を削除する必要があります。CLI ではこれを以下のように行います。

aws organizations detach-policy --policy-id p-FullAWSAccess --target-id r-4444

ルートにアタッチされているのは example-prod-policy ただ一つになったことが確認できます。

aws organizations list-policies-for-target --target-id r-4444 --filter service_control_policy
 
{
    "policies": [
        {
            "awsManaged": false,
            "description": "All services allowed by regulation policy.",
            "type": "service_control_policy",
            "id": "p-yyy12346",
            "arn": "arn:aws:organizations:: 000000000001:policy/o-1234567890/service_control_policy/p-yyy12346",
            "name": "example-prod-policy"
        }
    ]
}

これで、 組織内の全てのアカウントからアクセスを Example Corp の規制に準拠したサービスに制限することで、保護を強化することできました。

The organization limiting all accounts in your organization to only those AWS services that are compliant with Example Corp’s regulations

 

より高度な構造

組織を更に細分化したなら、組織単位とポリシーを追加することもできます。たとえば、いくつかの AWS アカウントはヘルスケア情報を保護するために使用されないかもしれず、その場合、制限された SCP は必要ないことになります。

たとえば、業務上異なる AWS サービスを試す必要がある開発チームがいるとします。この場合、規制された顧客情報にアクセスできるアカウントよりも、これらのアカウントの統制を緩くすることになるでしょう。Organizations があれば、たとえば本番環境で稼働させる医療ソフトウェアを扱う組織単位(OU)を作成する一方、開発者アカウントを有する組織単位(OU)も作成することができます。そうすれば、それぞれの組織単位(OU)に異なるセキュリティの制限を適用できます。

次の図では Developer Research 組織単位(OU)に3つの開発者アカウントが示されています。規制による保護が求められる元々の2つのアカウントは Production 組織単位(OU)にいます。 Example Corp. Prod Policy をルートからデタッチし、代わりにそれをProduction 組織単位(OU)にアタッチしました。最後に、規制と無関係な制限は、新しい Company ポリシーに配置することでルートレベルで引き続き有効となっています。

上の図では、 Developer Research 組織単位(OU)にあるアカウントは依然ルート配下にあるため、Company policy が適用されています。 Production 組織単位(OU)にあるアカウントは、Company policyExample Corp. Prod Policy の両方の SCP が有効です。IAM ポリシー同様、SCPも2つのポリシーのより限定された共通部分がアカウントに適用されます。もし Company policy SCPが Glacier, EMR, S3, EC2, RDS, Dynamo, Amazon Kinesis, AWS Lambda, そして Amazon Redshift へのアクセスを許可していたら、 Production 組織単位(OU)のアカウントに適用されるポリシーは次の図で示される共通部分になるでしょう。

Production 組織単位(OU)のアカウントは、Company policy SCP と Example Corp. Prod Policy SCP の両方が適用されます。2つのポリシーの共通部分が適用されるので、これらのアカウントは DynamoDB, Glacier, EMR, RDS, EC2, そして S3 へのアクセスできます。Redshift, Lambda, 及び Kinesis は Example Corp. Prod Policy SCP には含まれていないので、Production 組織単位(OU)のアカウントはそれらサービスへのアクセスが許可されません。

ポリシーの適用について要約すると、全ての要素 (ルートアカウント、 組織単位(OU)、 アカウント) はデフォルトで FullAWSAccess (*:*) を持ちます。複数の SCP が同じ要素に適用されていたら、Organizations はそれらを結合します。組織ツリー内の複数の要素に渡ってポリシーが継承されるとき、Organizations はそれら SCP の共通項を取ります。最後に、マスターアカウントは独自の保護機能を有しており、マスターアカウントに直接アタッチされた SCP のみ、そのアクセス権を変更できます。

 

まとめ

AWS Organizations では1つのマスターアカウントから複数の AWS アカウントを簡単に管理できます。アカウントを組織単位にグループ化し、アプリケーション、環境、チーム、その他ビジネスにとって意味のあるグループ毎に、アカウントを管理できるようになります。SCP は複数のアカウントに一度にポリシーを適用できる機能を提供します。

詳細については、AWS Organizations のホームページをご覧になり、AWS Organizations のプレビューに今すぐ登録してください。 AWS re:Invent 2016に参加している場合は、11月30日水曜日、午前11時のセッション SAC323 – NEW SERVICE: Centrally Manage Multiple AWS Accounts with AWS Organizations に参加することもできます。

– Caitlyn

原文:Announcing AWS Organizations: Centrally Manage Multiple AWS Accounts (翻訳:セキュリティ ソリューション アーキテクト 桐山 隼人)

 

 

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2018年4 月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30