1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@blinkgroup_jp(ブリンクグループ)

AWS Organizationsによるマルチアカウント運用の基本設計とSCP・Terraformによる管理手法

1
Posted at

AWS Organizationsを利用したマルチアカウント管理は、セキュリティ境界の分離やコスト管理の観点から、現在のAWS運用における標準的なアプローチとなっています。しかし、初期の設計を誤ると、アカウントの乱立やセキュリティ統制の形骸化を招くリスクがあります。

この記事では、実務でAWS Organizationsを導入・運用するエンジニア向けに、推奨されるOU（Organizational Unit）設計、SCP（サービスコントロールポリシー）の具体例、Terraformによるコード管理手法、および導入時のチェックリストを解説します。

対象読者と前提条件

  • AWS Organizationsを用いたマルチアカウント運用の設計・構築を担当するインフラエンジニア、SRE
  • Terraformを用いたInfrastructure as Code (IaC) の実務経験がある方
  • AWSの基本的なサービス（IAM、S3、CloudTrailなど）の知識を有している方

1. 推奨されるOU（組織単位）の基本構成

AWS Organizationsでは、アカウントを「OU」と呼ばれるグループに分類し、階層構造で管理します。AWS公式のベストプラクティスに基づき、実務で拡張性とセキュリティを両立しやすい基本構成を以下に示します。

Root (ルート)
├── Security OU (セキュリティ用)
│   ├── Log Archive Account (ログ集約)
│   └── Security Tooling Account (セキュリティ監視/検出)
├── Infrastructure OU (共通インフラ用)
│   ├── Network Account (Transit Gateway/DNS等)
│   └── Shared Services Account (CI/CD、共通AD等)
├── Workloads OU (本番・開発ワークロード用)
│   ├── Production Account (本番環境)
│   └── Non-Production Account (ステージング・開発環境)
└── Sandbox OU (検証・個人実験用)
    └── Sandbox Accounts (個別検証環境、インターネット制限あり)

各OUの役割

  • Security OU: ログの集約やセキュリティスキャンツール（GuardDuty、Security Hubなど）をホストするアカウントを配置します。一般の開発者はアクセスできないように厳しく制限します。
  • Infrastructure OU: ネットワークのハブや、共有のCI/CDランナーなど、複数システムで共有するリソースを配置します。
  • Workloads OU: 実際のビジネスアプリケーションを稼働させるアカウント群です。本番（Production）と開発（Non-Production）でアカウントを分離し、セキュリティレベルやアクセス権限に差をつけます。
  • Sandbox OU: 開発者が自由にAWSサービスを試せる環境です。本番データへのアクセスを禁止し、コスト上限や利用可能サービスを制限します。

2. SCP（サービスコントロールポリシー）の実装例

SCPは、組織またはOU内のアカウントに対して、利用可能なAPIアクションの最大権限を制限する機能です。ルートユーザーに対しても適用されるため、強力な統制手段となります。

例1：特定リージョン以外のアクションを制限するSCP

日本国内のプロジェクトなどで、東京（ap-northeast-1）とグローバルサービス（us-east-1など）以外のリージョンでのリソース作成を禁止する設定例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideRequestedRegions",
      "Effect": "Deny",
      "NotAction": [
        "cloudfront:*",
        "iam:*",
        "route53:*",
        "support:*",
        "waf:*",
        "organizations:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

例2：メンバーアカウントでのCloudTrail削除・停止を禁止するSCP

監査ログの改ざんを防ぐため、各メンバーアカウントでのCloudTrailの削除や設定変更を禁止します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventCloudTrailDisabling",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    }
  ]
}

3. TerraformによるAWS Organizationsのコード管理

Organizationsの構成をコード化（IaC）することで、アカウントの追加やOUの変更履歴をGitで管理できます。以下は、Terraformを使用して組織、OU、およびメンバーアカウントを作成するコード例です。

※実行前に、管理アカウント（Management Account）の認証情報が設定されていることを確認してください。

# 組織の有効化
resource "aws_organizations_organization" "org" {
  aws_service_access_principals = [
    "cloudtrail.amazonaws.com",
    "config.amazonaws.com",
    "securityhub.amazonaws.com"
  ]
  feature_set = "ALL"
}

# Workloads OUの作成
resource "aws_organizations_organizational_unit" "workloads" {
  name      = "Workloads"
  parent_id = aws_organizations_organization.org.roots[0].id
}

# Production OUの作成（Workloadsの下位）
resource "aws_organizations_organizational_unit" "production" {
  name      = "Production"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

# 本番環境用メンバーアカウントの作成
resource "aws_organizations_account" "prod_app_01" {
  name      = "prod-app-01"
  email     = "aws-prod-app-01@example.com"
  parent_id = aws_organizations_organizational_unit.production.id

  # 管理アカウントからスイッチロールするためのロール名
  role_name = "OrganizationAccountAccessRole"

  # アカウント削除時の挙動（Terraform管理から外すのみ。AWSアカウント自体は即時削除されません）
  lifecycle {
    ignore_changes = [role_name]
  }
}

4. 導入・運用時の注意点とよくある失敗

① 管理アカウント（Management Account）で日常的なワークロードを動かさない

管理アカウントは、組織の管理や請求（Billing）のみに特化させるべきです。ここにアプリケーションリソースを構築すると、SCPによる制御が及ばず、セキュリティリスクが高まります。また、請求データの漏洩リスクも増加します。

② SCPによる「セルフロックアウト」の防止

SCPは強力なため、設定を誤ると管理アカウントや必要な管理者ロールの操作まで拒否（Deny）してしまう可能性があります。SCPを適用する際は、影響範囲を特定のOUに限定し、テスト用OUで動作確認を行ってから本番OUへ適用するプロセスを徹底してください。

③ アカウント削除プロセスの理解

TerraformなどのIaCツールで aws_organizations_account リソースを削除（destroy）しても、AWSアカウント自体が即座に完全削除されるわけではありません。組織から「離脱」するか、手動でAWSコンソールから解約手続きを行う必要があります。運用のライフサイクル設計にこの仕様を組み込んでおいてください。

5. 実務用導入チェックリスト

マルチアカウント環境を本番運用する前に、以下の項目が満たされているか確認してください。

チェック項目 確認内容 対応状況
ルートメールアドレスの管理 各アカウントのルートメールアドレスは、個人のアドレスではなく、メーリングリストや共有エイリアスで作成されているか [ ]
MFAの有効化 管理アカウントおよび各メンバーアカウントのルートユーザーにMFA（多要素認証）が設定されているか [ ]
CloudTrailの組織集約 組織全体でCloudTrailを有効化し、ログがSecurity OUのS3バケットに集約されているか [ ]
AWS IAM Identity Centerの導入 メンバーアカウントへのアクセスは、個別のIAMユーザーではなく、IAM Identity Center（旧SSO）によるフェデレーションが設定されているか [ ]
サポートプランの確認 ビジネスプラン以上のサポートが組織全体、または必要なアカウントに適用されているか [ ]

まとめ

AWS Organizationsは、統制の取れたクラウド環境を構築するための基盤です。初期段階で適切なOU設計とSCPの適用ルールを定めておくことで、将来的なアカウント増加にも柔軟に対応できます。本記事の設定例やチェックリストを参考に、安全で管理しやすいマルチアカウント環境の構築を進めてください。

※AWSの仕様やTerraformのプロバイダー仕様は変更される可能性があるため、実装の際は常に最新の公式ドキュメントを参照してください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?