メンバーアカウントのベストプラクティス

組織内のメンバーアカウントのセキュリティを保護するために、以下の推奨事項に従ってください。これらの推奨事項は、厳密に必要とするタスクにのみルートユーザーを使用するというベストプラクティスを遵守していることを前提としています。

アカウント名と属性を定義する

メンバーアカウントには、アカウントの使用状況を反映した命名構造とメールアドレスを使用してください。たとえば、WorkloadsFooADev に「Workloads+fooA+dev@domain.com」、WorkloadsFooBDev に「Workloads+fooB+dev@domain.com」などです。組織でカスタムタグを定義している場合は、アカウントの使用方法、コストセンター、環境、およびプロジェクトを反映したアカウントにそれらのタグを割り当てることをおすすめします。これにより、アカウントの識別、整理、検索が容易になります。

環境とアカウントの使用量を効率的にスケールする

スケールする際は、新しいアカウントを作成する前に、不必要な重複を避けるために、同じようなニーズを持つアカウントが他に存在しないことを確認してください。AWS アカウント は一般的なアクセス要件に基づいている必要があります。サンドボックスアカウントや同等のアカウントを再利用する予定がある場合は、そのアカウントの不要なリソースやワークロードをクリーンアップし、後で使用できるようにアカウントを保存しておくことをおすすめします。

アカウントを閉鎖する際には、アカウント閉鎖クォータ制限が適用されることに注意してください。詳細については、「AWS Organizations のクォータとサービス制限」を参照してください。可能であれば、アカウントを閉鎖して新しいアカウントを作成するのではなく、クリーンアッププロセスを実行してアカウントを再利用することを検討してください。これにより、リソースを実行することによるコストの発生や CloseAccount API の上限に達することを回避できます。

SCPを使用し、メンバーアカウントのルートユーザーで行えることを制限する

サービスコントロールポリシー (SCP) を組織内に作成して組織のルートにアタッチし、すべてのメンバーアカウントに適用されるようにすることをお勧めします。詳細については、「Organizations アカウントのルートユーザー認証情報を保護する」を参照してください。

メンバーアカウントで実行する必要がある特定のルート限定アクションを除いて、すべてのルートアクションを拒否できます。例えば、以下の SCP は、どのメンバーアカウントのルートユーザーでも、「誤って設定されており、すべてのプリンシパルへのアクセスを拒否する S3 バケットポリシーの更新」(ルート認証情報を必要とするアクションの 1 つ) 以外は、どの AWS サービス API コールも実行できないようにします。詳細については、「IAM ユーザーガイド」の「ルートユーザー認証情報が必要なタスク」を参照してください。

{
 "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Deny",

            "NotAction":[

            "s3:GetBucketPolicy",

            "s3:PutBucketPolicy",

            "s3:DeleteBucketPolicy"

                 ],

            "Resource": "*",

            "Condition": {
 "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" }

            }

        }

    ]
 }

多くの場合、どのような管理タスクも、関連する管理者用アクセス許可を持つメンバーアカウントの AWS Identity and Access Management (IAM) ロールで実行することが可能です。このようなロールには、アクティビティの制限、ログ、モニタリングを行えるよう、適切なコントロールが適用されている必要があります。