0
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?

@satoru_oin株式会社ジール

個人学習環境のセキュリティ強化にAWS Identity Center移行してみた

0
Last updated at Posted at 2026-03-10

はじめに

個人のAWS学習環境において、これまではIAMユーザー＋管理者権限＋アクセスキーという構成で実施していました。実案件ではこんなことはまずありえないですが、個人学習であってもこの構成はセキュリティリスクが高く、ベストプラクティスに反しています。今回、実案件でも活かしたいということでAWS Identity Center (旧AWS SSO) への移行をやってみることにしました。本記事では、実際の移行手順をまとめたものになります。

移行前の課題

  • IAMユーザーにAdministratorAccessを直接付与
  • アクセスキーをローカル環境やTerraformで使用
  • キーの漏洩リスクとローテーション管理の煩雑さ
  • すべての操作を最強権限で実行してしまう運用リスク

移行後の構成

  • AWS Identity Centerによる一時的な認証情報の発行
  • 用途別のPermission Set（権限セット）による最小権限の原則の実現
  • アクセスキー不要のセキュアな運用
  • 役割ベースのアクセス制御（RBAC）の実現

前提条件

  • AWSアカウントを所有していること
  • AWS Organizations が有効化されていること（個人アカウント1つでもOK）

Permission Setの設計思想

本記事では、以下の2つの役割を想定したPermission Setを作成します。

Administrator（管理者）

役割:

  • AWS環境全体の設定変更
  • IAM権限の管理
  • セキュリティ設定の変更
  • 緊急時の対応

使用場面:

  • 初期環境構築
  • Permission Setの追加・変更
  • セキュリティ設定の見直し
  • トラブルシューティング

権限: AdministratorAccess（AWS管理ポリシー）

運用方針: 本当に必要な時のみ使用し、普段の作業では使わない

Developer（開発者）

役割:

  • AWS環境の確認・モニタリング
  • AI開発環境での作業

使用場面:

  • リソース状態の確認
  • ログやメトリクスの参照
  • Claude CodeなどのAI開発ツール利用
  • 開発中のアプリケーションの動作確認

権限:

  • ReadOnlyAccess（AWS管理ポリシー）
  • Bedrock呼び出し権限（カスタムポリシー）

運用方針:

  • 日常的な開発作業はこちらを使用
  • リソースの変更はCI/CDパイプライン経由で実施する想定
  • ローカル環境からの直接的なリソース操作は行わない

この設計により、「変更は慎重に、確認は自由に」という原則を実現できます。

実装手順

1. AWS Identity Centerの有効化

AWS Identity Centerは既にアカウント作成時に有効化されている場合があります。確認方法：

  1. AWSマネジメントコンソールで「IAM Identity Center」を検索
  2. 既に有効な場合は設定画面が表示される
  3. 未設定の場合は「有効にする」ボタンをクリック
  4. ホームリージョン（通常はap-northeast-1）を選択

2. Permission Setの作成

用途に応じたPermission Setを作成します。

管理用Permission Set

最初から作成されているAdministratorAccessをそのまま使用可能です。

開発用Permission Set（ReadOnly + Bedrock）

  1. Permission sets → Create permission set
  2. Custom permission set を選択
  3. 名前: DeveloperReadOnlyWithBedrock
  4. 説明（推奨）: Read-only access with Bedrock invoke permissions for AI development
  5. AWS managed policies セクションで Attach policies
  6. ReadOnlyAccessを検索して選択
  7. Inline policy セクションで Create inline policy
  8. JSON形式で以下を入力：
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListFoundationModels",
        "bedrock:GetFoundationModel"
      ],
      "Resource": "*"
    }
  ]
}
  1. ポリシー名: BedrockInvokeAccess
  2. Create policy → Create permission set

ポイント:

  • ReadOnlyAccessにより、すべてのAWSリソースの参照が可能
  • BedrockのInvoke*アクションのみ許可し、モデル管理や設定変更は不可
  • この構成により、AI開発ツールは使えるが環境変更はできない状態を実現

3. グループとユーザーの作成

グループの作成

  1. Groups → Create group
  2. 管理用グループ名: Admins
    • 説明: Administrators with full access for infrastructure management
  3. 開発用グループ名: Developers
    • 説明: Developers with read-only access and Bedrock invoke permissions

ユーザーの作成

セキュリティのベストプラクティスとして、用途別にユーザーを分けることを推奨します。

  1. Users → Add user
  2. 管理用ユーザー作成
    • メールアドレス: 管理用メールアドレス
    • 用途: インフラ管理、セキュリティ設定変更
  3. 開発用ユーザー作成
    • メールアドレス: 開発用メールアドレス
    • 用途: 日常的な開発作業、リソース確認
  4. それぞれ該当のグループに追加

ユーザー分離のメリット:

  • 認証情報の漏洩時の影響範囲を限定
  • 操作ログでの追跡性向上
  • 意図しない高権限操作の防止

4. Permission SetとAWSアカウントへの割り当て

  1. AWS accounts → 自分のアカウントを選択
  2. Assign users or groups
  3. グループを選択（Admins, Developers）
  4. Permission Setを選択
    • Admins → AdministratorAccess
    • Developers → DeveloperReadOnlyWithBedrock
  5. Submit

プロビジョニングが完了すると、ステータスが「プロビジョン済み」になります。

5. アクセスポータルの確認

  1. アクセスポータルURL（https://your-org.awsapps.com/start）にアクセス
  2. 各ユーザーでログインして、割り当てられたPermission Setが表示されることを確認

確認ポイント:

  • 管理用ユーザーでログイン → AdministratorAccessが表示される
  • 開発用ユーザーでログイン → DeveloperReadOnlyWithBedrockが表示される

Tips: 同じブラウザで別ユーザーをテストする場合は、シークレット/プライベートウィンドウを使用すると便利です。

6. AWS CLIの設定

SSOプロファイルの作成

開発用プロファイル（日常使い用）:

aws configure sso --profile dev

対話式入力：

SSO session name (Recommended): dev-session
SSO start URL [None]: https://your-org.awsapps.com/start
SSO region [None]: ap-northeast-1
SSO registration scopes [sso:account:access]: (Enter)

# ブラウザで開発用ユーザーとして認証
# 表示されるPermission Setから DeveloperReadOnlyWithBedrock を選択

CLI default client Region [None]: ap-northeast-1
CLI default output format [None]: json
CLI profile name: dev

管理用プロファイル（必要時のみ使用）:

aws configure sso --profile admin

対話式入力：

SSO session name (Recommended): admin-session
SSO start URL [None]: https://your-org.awsapps.com/start
SSO region [None]: ap-northeast-1
SSO registration scopes [sso:account:access]: (Enter)

# ブラウザで管理用ユーザーとして認証
# 表示されるPermission Setから AdministratorAccess を選択

CLI default client Region [None]: ap-northeast-1
CLI default output format [None]: json
CLI profile name: admin

設定ファイルの確認

~/.aws/config に以下のような設定が追加されます：

[profile dev]
sso_session = dev-session
sso_account_id = 123456789012
sso_role_name = DeveloperReadOnlyWithBedrock
region = ap-northeast-1

[profile admin]
sso_session = admin-session
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = ap-northeast-1

[sso-session dev-session]
sso_start_url = https://your-org.awsapps.com/start
sso_region = ap-northeast-1

[sso-session admin-session]
sso_start_url = https://your-org.awsapps.com/start
sso_region = ap-northeast-1

7. 動作確認

開発用プロファイルの確認

# ログイン
aws sso login --profile dev

# 認証情報の確認
aws sts get-caller-identity --profile dev

# S3リスト取得（ReadOnlyで成功するはず）
aws s3 ls --profile dev

# Bedrock確認（us-east-1リージョンで実施）
aws bedrock list-foundation-models --region us-east-1 --profile dev

# 書き込み操作は失敗することを確認（ReadOnlyのため）
aws s3 mb s3://test-bucket --profile dev
# → Access Deniedエラーが返ることを確認

管理用プロファイルの確認

# ログイン
aws sso login --profile admin

# IAM操作（管理者権限でのみ可能）
aws iam list-users --profile admin

8. デフォルトプロファイルの設定

日常的には開発用プロファイルを使うため、デフォルトに設定します：

~/.bashrc または ~/.zshrc:

# 開発作業用をデフォルトに
export AWS_PROFILE=dev

# 設定を反映
source ~/.bashrc

これにより、--profileオプションなしでコマンドを実行できます：

# devプロファイルが自動的に使用される
aws sts get-caller-identity
aws s3 ls

管理作業が必要な時のみ、明示的に管理用プロファイルを指定：

aws iam create-role --role-name MyRole --profile admin

9. 既存IAMユーザーの整理

新しい構成が正常に動作することを確認後：

  1. IAMコンソール → Users → 該当ユーザー
  2. Security credentials タブ
  3. Access keys セクションで Deactivate
  4. 数日様子を見て問題なければ Delete

注意: 緊急時用のbreak-glassアカウント（IAMユーザー）は残しておくことを推奨します。

Terraformでの使用

Terraformのprovider設定でSSOプロファイルを指定：

provider "aws" {
  region  = "ap-northeast-1"
  profile = "dev"  # 確認用
}

# または管理操作が必要な場合
provider "aws" {
  region  = "ap-northeast-1"
  profile = "admin"
}

または環境変数を使用：

# 開発用（デフォルト）
export AWS_PROFILE=dev
terraform plan

# 管理用（必要時のみ）
export AWS_PROFILE=admin
terraform apply

devcontainerでの利用

.devcontainer/devcontainer.jsonで設定をマウント：

{
  "mounts": [
    "source=${localEnv:HOME}/.aws,target=/home/vscode/.aws,type=bind,consistency=cached"
  ],
  "remoteEnv": {
    "AWS_PROFILE": "dev"
  }
}

devcontainer起動後、以下を実行：

aws sso login

注意: 認証トークンは一定時間（デフォルト8時間）で期限切れとなるため、定期的に再ログインが必要です。

セッション管理のTips

アクティブセッションの確認と削除

Identity Centerコンソールで：

  1. Users → 該当ユーザー
  2. Active sessions タブ
  3. Delete all sessions で強制サインアウト

これにより、即座にすべてのアクティブセッションが失効します。セキュリティインシデントが疑われる場合や、認証情報の切り替えを確実に行いたい場合に有効です。

ブラウザプロファイルの分離

Chrome/Edgeでブラウザプロファイルを分けると運用が楽になります：

  • プロファイル1: 管理用（adminユーザー専用）
  • プロファイル2: 開発用（devユーザー専用）

これにより、誤って異なる権限でログインしてしまうミスを防げます。

まとめ

AWS Identity Centerへの移行により、以下のメリットが得られます：

セキュリティ面

  • アクセスキー不要: 一時的な認証情報の使用により漏洩リスクを低減
  • 最小権限の原則: 用途別のPermission Setによる適切な権限管理
  • 監査性向上: CloudTrailでのアクセスログ記録とユーザー識別

運用面

  • 役割の明確化: 管理作業と開発作業の分離
  • 誤操作防止: 日常作業では読み取り専用権限を使用
  • 一元管理: SSOによる認証管理の簡素化

開発効率

  • 柔軟なアクセス制御: 必要な時だけ高権限を使用
  • 環境の一貫性: ローカル、CI/CD、本番で同じ認証方式
  • スケーラビリティ: 今後チーム開発に移行する際も対応可能

個人学習環境であっても、本番環境と同じセキュリティベストプラクティスを適用することで、実践的なスキルが身につきます。

参考リンク

0
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
0
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?