coiai Logo
ホーム記事コラムPodcast会社情報
お問い合わせ
Featured

AWS IAM Identity Centerとは?IAM Userを使わないAWS認証・権限管理のベストプラクティス

AWS Organizationsによるマルチアカウント環境を構築した後、次に設定したのがAWS IAM Identity Centerです。

以前はAWSへログインするためにIAM Userを作成することが一般的でしたが、現在AWSでは、人がAWSへログインする場合はIAM Identity Centerの利用を推奨しています。

今回は、IAM Identity Centerを導入した理由と、実際の設定内容についてまとめます。


IAM Identity Centerとは

IAM Identity Center(旧 AWS Single Sign-On)は、複数のAWSアカウントやAWSアプリケーションへの認証・認可を一元管理するサービスです。

従来のように各AWSアカウントへIAM Userを作成する必要はなく、

  • 一度ログインするだけで複数アカウントへアクセスできる
  • ユーザー管理を一元化できる
  • 権限管理を簡素化できる

というメリットがあります。

AWS Organizationsと組み合わせることで、マルチアカウント環境の運用が大幅に容易になります。

参考:

  • AWS IAM Identity Center ユーザーガイド

なぜIAM UserではなくIdentity Centerなのか

以前は、このような構成が一般的でした。

AWS Account
 ├── IAM User(開発者A)
 ├── IAM User(開発者B)
 ├── IAM User(管理者)
 └── IAM User(監査)

しかし、この方法では

  • アカウントごとにIAM Userを作成する必要がある
  • パスワードやMFAを個別管理する必要がある
  • 人の異動や退職時の対応が煩雑になる

といった課題があります。

Identity Centerを利用すると、ユーザー情報は一元管理され、各AWSアカウントには必要な権限だけを割り当てる運用になります。

IAM Identity Center
        │
        ├── User
        ├── Group
        └── Permission Set
               │
               ▼
AWS Account

AWS Well-Architected Frameworkでも、人によるアクセスにはフェデレーション認証を利用し、長期認証情報(IAM Userのアクセスキーなど)をできる限り利用しないことが推奨されています。

参考:

  • AWS Well-Architected Framework – Security Pillar

今回の構成

今回は次のようなシンプルな構成にしました。

グループ

Administrators
Developers
ReadOnly

Administrators

AWS環境全体を管理するメンバーです。

現在は

  • 自分
  • (今後)共同代表

を所属させる予定です。


Developers

アプリケーションやインフラ開発を行うメンバー向けです。

今回はまだ利用していませんが、開発メンバーが増えた際に使用します。

将来的には

  • PowerUserAccess
  • カスタムPermission Set

などを割り当てる予定です。


ReadOnly

閲覧専用グループです。

監査やレビュー、外部アドバイザー向けとして利用します。

今回は技術メンターにReadOnly権限を付与することを想定しています。


Permission Setとは

IAM Identity Centerでは、直接IAMポリシーをユーザーへ付与するのではなく、Permission Setという単位で権限を管理します。

Permission Setは、各AWSアカウントへ適用される権限テンプレートのようなものです。

今回はAWS管理ポリシーを利用し、次の2種類を作成しました。

AdministratorAccess
ReadOnlyAccess

AWS管理ポリシーを利用することで、AWSが提供する標準的な権限セットをそのまま利用できます。

参考:

  • AWS IAM Identity Center の Permission Sets

グループへ権限を付与する理由

IAM Identity Centerでは、ユーザーへ直接Permission Setを割り当てることもできます。

しかし今回は、

Administrators
        │
        ▼
AdministratorAccess
        │
        ▼
Dev Account

という形で、グループ単位で管理しています。

この構成には次のメリットがあります。

  • メンバー追加時はグループへ入れるだけ
  • 権限変更が容易
  • 権限管理の属人化を防げる
  • AWSの推奨運用に沿っている

将来的に人数が増えても、運用方法を変える必要がありません。


AWS Access Portal

Identity Centerを有効化すると、AWS Access Portalが作成されます。

URLは次のような形式です。

https://d-xxxxxxxxxx.awsapps.com/start

ユーザーはこのポータルへログインし、自分に割り当てられたAWSアカウントを選択して利用します。

例えば、

Dev
AdministratorAccess

が表示されていれば、クリックするだけでDevアカウントへサインインできます。

これにより、アカウントごとにログインURLや認証情報を管理する必要がなくなります。


今後の予定

Identity Centerの設定が完了したら、次は開発環境の自動化を進めます。

  • AWS CLIのSSO設定
  • TerraformによるInfrastructure as Code
  • GitHub ActionsとOIDCの連携
  • IAM RoleによるCI/CD実行
  • CloudTrail・Security Hubの構築

Identity Centerを起点にすることで、人の認証とCI/CDの認証を分離した、安全で運用しやすいAWS環境を構築していく予定です。


まとめ

IAM Identity Centerは、AWS Organizationsを利用する環境では事実上の標準となる認証基盤です。

今回の構成では、

  • ユーザーはIAM Identity Centerで一元管理
  • 権限はPermission Setで管理
  • 権限付与はグループ単位で実施
  • AWS Access Portalから各AWSアカウントへサインイン

という構成を採用しました。

このような設計にすることで、開発メンバーの追加や権限変更にも柔軟に対応でき、AWSが推奨するセキュリティベストプラクティスにも沿った運用が可能になります。


参考資料

  • AWS IAM Identity Center ユーザーガイド
  • AWS IAM Identity Center – Permission Sets
  • AWS Organizations ユーザーガイド
  • AWS Well-Architected Framework – Security Pillar
  • AWS Security Reference Architecture (AWS SRA)
投稿日: 2026年7月23日
カテゴリ: AWS
タグ:
coiai

coiai

この記事もおすすめ

デフォルトサムネイル

GMKtec EVO-X2にUbuntuを入れたら有線LANが認識されなかった話

オンプレミスAIサーバー(ローカルLLM + 社内文書RAG)の構築を始めました。機材はGMKtec EVO-X2、AMD Ryzen AI Max+ 395搭載のミニPCです。128GBのユニファイドメモリをGPUに大きく割り当てられるので、ローカルLLM用途では今いちばん面白いマシンだと思っています。 この記事は初日の作業ログです。結論から言うと「インストールUSBが起動しない」「有線LANが認識されない」という2つの罠を踏んだので、同じ構成を組む方のために記録しておきます。 OSはLinuxかWindowsか 最初に迷うのがここですが、サーバー用途ならUbuntu Server一択でした。 日常操作はすべてブラウザ(Open WebUI)経由なので、サーバーOSにGUIは不要です。管理画面が欲しければCockpitを入れれば、Webブラウザからメトリクス確認・サービス再起動・ターミナルまで使えます。「CUIのサーバー + Web管理画面」が現代の標準形だと思います。 BIOS設定 ― EVO-X2で一番大事なのはVRAM割り当て 電源ON直後にDel連打でBIOS(AMI)へ入ります。設定したのは3つです。 罠その1: インストールUSBが起動しない Ubuntu Server 24.04のISOをMacから dd でUSBメモリに書き込み、いざブート……しません。Boot Overrideに出てくる「UEFI OS」を選んでもWindowsが立ち上がってしまいます。 切り分けの過程が学びでした。 原因はおそらく、dd の書き込みが完全に終わる前に抜いてしまったことです。dd は進捗表示が止まってからもバッファの書き出しが続くので、完了統計が表示されるまで待たなければいけません。パーティションテーブルはディスク先頭に書かれるため、途中で切れていても一見正常に見えるのが厄介なところです。 教訓: インストールUSB作成はbalenaEtcherを使いましょう。 書き込み後に自動でベリファイ(照合)まで走るので、「書けたつもり」が原理的に起きません。Etcherで書き直したら一発で起動しました。 インストール時の選択 罠その2: 有線LANが認識されない インストール完了、ログイン成功。しかし ip a を見ると有線LANにIPがありません。それどころか、よく見ると有線のインターフェース自体が存在しません。 カーネルログを見て原因が確定しました。 EVO-X2の2.5GbEチップ(Realtek RTL8125D)が新しすぎて、Ubuntu 24.04の標準カーネル6.8のドライバが知らないチップだったのです。インストール中にネットに繋がらなかったのもこれが原因でした。ケーブルを何度挿し直しても無駄だったわけです。 教訓: 「繋がらない」時はケーブルを疑う前に dmesg を読みましょう。 カーネルログには大抵、答えがそのまま書いてあります。 解決: HWEカーネル 新しいチップに対応するには、新しいカーネルを入れれば解決します。Ubuntuには**HWE(Hardware […]

FSD v2.1 Feature-Sliced Design を導入する

FSD v2.1 Feature-Sliced Design を導入する

この記事は何? 公式のドキュメントやチュートリアル、exsample を読んで理解するのが一番いいですが、備忘録として残しておきます。特に後述の Skills, Steiger については開発する際にあった方が便利なので、それについても記事にします。 FSDとは? FSD (Feature-Sliced Design) はフロントエンドのアーキテクチャの一つです。 FSDとは責務で分けていくアーキテクチャと違い、ページやエンティティで分けていくアーキテクチャというとわかりやすいと思います。 コードの分離の仕方について話す前に、FSDで前提となる この3つについて理解する必要があります。 レイヤー より細かく分けていく方法がありますが、この記事では導入だけ触れたいので、3つのレイヤーのみ説明します。 です。この流れは上(app)に向かえば向かうほどアプリケーション固有、下(shared)に向かうほど汎用的になります。 原則として上位レイヤーは下位レイヤーを利用できるが、下位レイヤーから上位レイヤーへ依存できません。 始め方としては小さく初めて、必要になったらレイヤーを増やしてくようです。 スライス ブログアプリであればレイヤーの pages には といったページに分けられるため、このような構成になります。このblog-list, blog-detail, user がスライスです。これらはページやエンティティによって分けられます。 セグメント これらのmodel, ui といった部分がエンティティです。これらは責務にあたります。sharedに関しては直下にスライスではなくセグメントが入ります。 FSD 2.1 で重要なのは Pages First です。とにかくPagesから作って、細分化の必要ができたら、下位レイヤーに抽出します。 Steiger Steiger とはアーキテクチャリンターです。以下でインストールできます。 AIコーディングのために Claude Skills https://github.com/feature-sliced/skills?utm_source=chatgpt.com このリポジトリが公式に公開されています。 これで Skills を追加できるので、claude にFSDの設計知識を共有できます。

フロントエンドのアーキテクチャについて最初から考える

フロントエンドのアーキテクチャについて最初から考える

これは何? この記事は基本に立ち戻りアーキテクチャの選定を試みた際の備忘録です。Feature-Sliced Design(FSD)や Vertical Slice Architecture など、モダンなアーキテクチャがありますが、どのような判断をもとに選定するのかを考え直します。 アーキテクチャの地図 アーキテクチャを理解するために、以下のような学習のための地図を作りました。設計原則、アーキテクチャ、個別の設計パターンへと詳細になっていきます。 そもそも、、、 このコードは何を担当しているのかを考えるのが最初の問です。 商品一覧画面を作るときに といったタスクを書き出します。 これら全てを一つの巨大なコンポーネントとして作ることもできますが、管理が大変になるのは皆さんもお分かりだと思います。参考:https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html?utm_source=chatgpt.com ここからどこまでを同じモジュールとして管理するのか?という設計の問題が始まります。 Cohesion と Coupling CohesionとCouplingはそれぞれ、凝集度、結合度というようです。https://qiita.com/dsudo/items/ee3fee1f558c7f1b359f Cohesionは関係するコードがまとまっているか? Couplingは別のコードにどれだけ依存しているか? です。 例えば以下のようなコードがあります。 技術的な種類ごとに整理されていますが、商品一覧のコーディングをするのにそれぞれ別のディレクトリを行き来する必要があります。一方で、以下のように書いた場合はどうでしょうか? この書き方なら、商品に依存するコードがまとまっています。 この書き方が Feature-based Architecture, Vertical Slice Architecture に繋がっていきます。 コロケーションについて colocation Place code as close to where it’s relevant as possible 同じ種類のコードを集めることではなく、一緒に変更されるコードを近くに置くことです。 https://kentcdodds.com/blog/colocation?utm_source=chatgpt.com Layered Architecture について ここからアーキテクチャの話です。 Layered Architectureでは、技術的責務でアプリケーションを分離します。 これのメリットは責務がわかりやすいところです。 しかし、この方法では前述までとは変わり、機能を変更するときに、横断して変更する可能性があります。 つまり、技術的には分かれている一方で、機能は複数に分散するわけです。 […]

デフォルトサムネイル

【WSL入門】Ubuntu on WSL2 に開発ツールを一式そろえる — Git / nvm / pnpm / AWS CLI / Terraform

前回の記事では、Windows に WSL2 を導入して Ubuntu が動くところまでを扱いました。ただ、素の Ubuntu はあくまで「まっさらな Linux」です。ここから実際に開発を始めるには、バージョン管理・ランタイム・クラウド操作のツールを自分で入れていく必要があります。 この記事では、すべて公式ドキュメントに載っている手順だけを使って、次のツールを順番にセットアップします。 各セクションの末尾に出典 URL を置いてあるので、手順が古くなったと感じたらそこを見に行ってください。記事末尾には出典一覧もまとめています。 検証環境Windows 11 / WSL2 / Ubuntu 24.04 LTS(x86_64)確認日:2026年7月28日 バージョン番号は執筆時点のものです。インストールコマンド自体は基本的に「常に最新を取ってくる」形になっているので、そのまま実行して問題ありません。 はじめに:WSL開発の大原則 コマンドに入る前に、ひとつだけ。Microsoft の公式ドキュメントが繰り返し書いている重要な原則があります。 使う予定のツールと同じ OS 側にファイルを置く。Linux ツールで Linux コマンドラインから作業しているなら、最速のパフォーマンスを出すためにファイルは WSL ファイルシステムに格納します。 具体的には、プロジェクトは次の場所に置きます。 /mnt/c/ 配下はファイルシステムをまたぐため、npm install や git status が体感でわかるほど遅くなります。第2弾でこれから入れるツールも、すべて Linux 側のホームディレクトリを前提に使ってください。 出典:WSL 開発環境を設定する — Microsoft Learn 1. まずは基本ツール Ubuntu を起動したら、最初にやることはパッケージの更新です。Microsoft の公式ドキュメントにもこう書かれています。 ディストリビューションの優先パッケージ マネージャーを使用して、パッケージを定期的に更新およびアップグレードすることをお勧めします。Windows […]

この記事を書いた会社

株式会社coiaiは、「想像できることを美しく実現」を掲げ、XR・Web・アプリ・システム開発およびDX支援を行う会社です。 創業2022年、東京都練馬区に本社を置き、要件のヒアリングからPoC(概念実証)、本番運用まで一貫して伴走します。 まずはお気軽にご相談ください。

商号株式会社 coiai創業2022年1月設立2025年1月23日資本金1,500,000円(設立時点)本社所在地東京都練馬区関町北 3-6-9代表者代表取締役 竹村 啓佑 / 代表取締役 服部 陽良

主なご相談内容

  • Webサイト・Webアプリの設計・開発
  • スマートフォンアプリ(iOS / Android)の開発
  • XR・AR・VRを活用した体験設計・開発
  • DX推進・業務システムの企画・開発
  • PoC(概念実証)から本番運用までの伴走支援
  • マーケティング・コンサルティング
会社概要・役員紹介を見る

詳しい会社情報は会社概要ページでご覧いただけます。

資料請求・無料相談

導入要件のヒアリングからPoC、本番運用まで伴走します。まずはお気軽にご相談ください。

フォームで問い合わせメールで相談

お問い合わせの前に 個人情報保護方針 をご確認ください。

株式会社coiai株式会社coiai

XR, Web, システム開発, DX — 想像できることを美しく実現

メールでお問い合わせ

サービス

on-premise AI

基幹システム Anchor

XR開発

会社情報

会社概要

ブログ

お問い合わせ

法務

プライバシーポリシー


所在地

〒177-0051 東京都練馬区関町北3-6-9

営業時間

平日 10:00-18:00

土日祝 休み

info@coiai.net

© 2023–2026 株式会社coiai. All rights reserved.