AWS Sign-In 完全ガイド v2.0

AWS コンソール・認証・SSO ベストプラクティス

AWS Sign-In は、AWS Management Console・サービスへのアクセスを管理する認証ポータル です。ルートユーザー・IAM ユーザー・IAM Identity Center（SSO）・フェデレーション認証の複数方式をサポートし、MFA・Passkey・セキュリティベストプラクティスを実装可能にします。本ドキュメントは、サインイン方式の選択・実装・セキュリティ・SSO 統合・企業ポータルとの連携を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

初心者向け： AWS コンソールへのログイン方式・MFA とは何かを学びたい方
開発者向け： Federation URL・STS AssumeRole によるプログラマティックアクセス
SRE/DevOps 向け： フェデレーション認証・Passkey の実装・運用
セキュリティ管理者向け： MFA 強制・IAM ユーザー → SSO への移行・監査ログ
アーキテクト向け： エンタープライズポータル統合・SSO アーキテクチャ設計
意思決定者向け： Okta / Azure Entra ID / Google Workspace との比較検討

Passkey（パスキー）対応拡大（2024年以降）： FIDO2 セキュリティキー・パスキーが MFA 標準に
AWS Builder ID（AWS アカウント不要な認証）： AWS コンソール外のコミュニティ・トレーニングで SSO
IAM Roles Anywhere（プログラマティック認証）： オンプレミス・外部環境からの認証
IAM Identity Center 統合深化（推奨）： SSO → SAML 2.0 / OIDC による企業 IdP との統合
セキュリティ要件の厳格化： ルートユーザー日常利用の廃止推奨、MFA 必須化へ

概要
Sign-In が解決する課題
4 つのサインイン方式
ルートユーザー・アカウント
IAM ユーザー・サインイン
IAM Identity Center（SSO）
フェデレーション認証
MFA・多要素認証
Passkey・セキュリティキー
アカウントエイリアス・カスタム URL
Federation エンドポイント
CLI/SDK でのプログラマティックアクセス
AWS Builder ID
IAM Roles Anywhere
企業ポータル統合
CloudTrail 監査・ログ
他の認証サービスとの比較
ベストプラクティス
トラブルシューティング
セキュリティ・コンプライアンス
料金モデル
2025-2026 最新動向
学習リソース・参考文献
セットアップチェックリスト
まとめ

概要

AWS Sign-In は、AWS Management Console へのアクセスを管理する認証・ポータル機能 です。単独のサービスというより、IAM・IAM Identity Center・STS の統合的な認証エントリーポイントです。

User → AWS Sign-In Portal
        ├── ルートユーザーログイン（非推奨）
        ├── IAM ユーザーログイン（レガシー）
        ├── IAM Identity Center（推奨）
        │   └── SAML / OIDC → 企業 IdP（Okta / Azure AD）
        └── Federation Token（プログラマティック）

1. 複数 AWS アカウントへのアクセス管理

従来の課題： 各アカウントで個別にログイン

Account A: https://123456789012.signin.aws.amazon.com
Account B: https://123456789099.signin.aws.amazon.com
Account C: https://123456789088.signin.aws.amazon.com
→ ログイン手続きが煩雑、パスワード管理が複雑

IAM Identity Center での解決：

企業ポータル → シングルサインオン → 複数アカウント一括アクセス
→ ログインが一度で済む、パスワード集中管理

2. 長期アクセスキーの廃止・セキュリティ向上

従来の課題： IAM アクセスキーが流出 → 影響が無限大

Temporary Security Credentials での解決：

Federation URL で一時認証情報を取得
→ 15分～1時間の有効期限
→ セッションキー流出しても被害が限定

3. 企業 ID 基盤との統合

従来の課題： AWS で独立した ID・パスワード管理が必要

Federation（SAML 2.0 / OIDC）での解決：

Okta / Azure AD のユーザー ← → AWS Sign-In（SAML）
→ 企業 ID でそのまま AWS コンソール利用可
→ 退職時に Okta 削除すれば AWS アクセスも自動失効

4. MFA・パスキーによるセキュリティ向上

IAM ユーザー・Identity Center・フェデレーション認証すべてで MFA が強制可能。

4 つのサインイン方式

方式	URL 例	認証方法	推奨度	用途
ルートユーザー	https://console.aws.amazon.com	メール + パスワード + MFA	★☆☆	緊急時のみ
IAM ユーザー	https://ACCOUNT_ID.signin.aws.amazon.com	ユーザー名 + パスワード + MFA	★★☆	レガシー
IAM Identity Center	https://my-sso.awsapps.com	Enterprise SSO	★★★★	推奨
Federation	(カスタム URL)	SAML 2.0 / OIDC	★★★★	エンタープライズ

ルートユーザー・アカウント

ルートユーザーとは

AWS アカウント開設時の初期ユーザー。すべての権限を持つ。

ルートユーザー
├── アカウント削除可能 ⚠️
├── 支払い情報の変更可能
├── パスワードリセット可能（MFA をバイパス不可）
└── 制限なしのアクセス権限

セキュリティベストプラクティス

❌ ルートユーザー日常利用（非推奨）
✅ IAM Identity Center / IAM ユーザーで日常業務
✅ ルートユーザー用に MFA デバイス（ハードウェアキーを推奨）
✅ ルートユーザー用のアクセスキー作成は禁止

ルートユーザーの使用シーン：
1. AWS アカウント開設直後の初期設定
2. 支払い情報の更新
3. アカウント復旧（IAM ユーザーがすべてロックされた場合）

ルートユーザーのセキュア化

# ステップ 1: ルートユーザーで AWS Management Console にサインイン
# (アカウント作成直後)

# ステップ 2: MFA デバイスを登録（推奨：ハードウェア MFA）
# AWS Management Console → セキュリティ認証情報 → MFA デバイスを割り当てる
# → Yubikey / AWS GovCloud FID01 等を推奨

# ステップ 3: IAM ユーザーを作成
# （セッション完了後、ルートユーザーは使用しない）

IAM ユーザー・サインイン

URL 形式

https://ACCOUNT_ID.signin.aws.amazon.com/console
または
https://ACCOUNT_ALIAS.signin.aws.amazon.com/console

セットアップ

# IAM ユーザーのコンソールアクセスを有効化
aws iam create-login-profile \
  --user-name john.doe \
  --password "InitialPassword1!" \
  --password-reset-required

# アカウントエイリアスの設定
aws iam create-account-alias --account-alias mycompany

# ログイン URL
# https://mycompany.signin.aws.amazon.com/console

コンソールアクセス権限

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*"
    }
  ]
}

セキュリティベストプラクティス

# MFA を必須化
aws iam put-user-policy \
  --user-name john.doe \
  --policy-name MFARequirement \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
      }
    }]
  }'

IAM Identity Center（SSO）

推奨される最新のサインイン方式

IAM Identity Center は、AWS 推奨の ワークフォース・アイデンティティ管理（WIM） サービス。

企業 ID 基盤（Okta / Azure AD）
        ↓ SAML 2.0 / OIDC
IAM Identity Center
        ↓
複数 AWS アカウント一括アクセス

セットアップ

ステップ 1: IAM Identity Center の有効化

# AWS Organizations の管理アカウントで実行
aws ssoadmin describe-instances \
  --region us-east-1

# 有効化されていない場合
# AWS Management Console → IAM Identity Center → 有効化

ステップ 2: Identity Source の選択

1. Identity Center ネイティブ（簡易）
2. 外部 IdP（SAML 2.0）
   - Okta
   - Azure Active Directory
   - Google Workspace
   - Ping Identity
   - JumpCloud

ステップ 3: Permission Set の作成

# CLI でのセットアップ例
INSTANCE_ARN=$(aws ssoadmin list-instances --region us-east-1 \
  --query 'Instances[0].InstanceArn' --output text)

# Permission Set の作成（AdministratorAccess）
aws ssoadmin create-permission-set \
  --instance-arn "$INSTANCE_ARN" \
  --name AdminPermissionSet \
  --description "Administrator access" \
  --session-duration PT8H \
  --region us-east-1

# AWS managed policy をアタッチ
aws ssoadmin attach-managed-policy-to-permission-set \
  --instance-arn "$INSTANCE_ARN" \
  --permission-set-arn arn:aws:sso:::permissionSet/xxx \
  --managed-policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
  --region us-east-1

ステップ 4: Account Assignment（アカウント割り当て）

# ユーザー John Doe に dev アカウントでの AdminPermissionSet を割り当て
aws ssoadmin create-account-assignment \
  --instance-arn "$INSTANCE_ARN" \
  --target-id 123456789099 \
  --target-type AWS_ACCOUNT \
  --principal-type USER \
  --principal-id USER-123 \
  --permission-set-arn arn:aws:sso:::permissionSet/xxx \
  --region us-east-1

ログイン画面

https://my-organization.awsapps.com/start
        ↓
Okta / Azure AD でログイン
        ↓
複数アカウントのクイックアクセスが表示
        ↓
目的のアカウント・Permission Set をクリック
        ↓
AWS Management Console に自動ログイン

フェデレーション認証

AssumeRole with SAML（従来の方式）

古い方式だが、Identity Center 以前に構築された環境で使用。

import boto3
from botocore.exceptions import ClientError

def get_federation_token_with_saml(saml_assertion, role_arn, duration=3600):
    """SAML assertion から一時認証情報を取得"""
    sts = boto3.client('sts')
    
    try:
        response = sts.assume_role_with_saml(
            RoleArn=role_arn,
            PrincipalArn='arn:aws:iam::123456789012:saml-provider/MyProvider',
            SAMLAssertion=saml_assertion,
            DurationSeconds=duration
        )
        
        credentials = response['Credentials']
        
        return {
            'AccessKeyId': credentials['AccessKeyId'],
            'SecretAccessKey': credentials['SecretAccessKey'],
            'SessionToken': credentials['SessionToken'],
            'Expiration': credentials['Expiration']
        }
        
    except ClientError as e:
        print(f"Error: {e}")
        return None

Federation Endpoint（Console へのリダイレクト）

社内ポータルから AWS Console に直接リダイレクト。

import boto3
import json
import urllib.parse
import urllib.request

def create_federated_console_url(role_arn, session_name, issuer, duration=3600):
    """Federation Endpoint で Console URL を生成"""
    sts = boto3.client('sts')
    
    # ロールを引き受けて一時認証情報を取得
    assumed_role = sts.assume_role(
        RoleArn=role_arn,
        RoleSessionName=session_name,
        DurationSeconds=duration
    )
    
    credentials = assumed_role['Credentials']
    
    # セッション JSON を作成
    session_json = json.dumps({
        'sessionId': credentials['AccessKeyId'],
        'sessionKey': credentials['SecretAccessKey'],
        'sessionToken': credentials['SessionToken']
    })
    
    # Federation Endpoint で SignIn Token を取得
    request_url = (
        'https://signin.aws.amazon.com/federation'
        '?Action=getSigninToken'
        '&SessionDuration=' + str(duration) +
        '&Session=' + urllib.parse.quote(session_json)
    )
    
    response = urllib.request.urlopen(request_url)
    signin_token = json.loads(response.read())['SigninToken']
    
    # Console URL を生成
    console_url = (
        'https://signin.aws.amazon.com/federation'
        '?Action=login'
        '&Issuer=' + urllib.parse.quote(issuer) +
        '&Destination=' + urllib.parse.quote('https://console.aws.amazon.com/') +
        '&SigninToken=' + signin_token
    )
    
    return console_url

# 使用例（社内ポータルから呼び出し）
console_url = create_federated_console_url(
    role_arn='arn:aws:iam::123456789012:role/DevOpsRole',
    session_name='john-doe-session',
    issuer='https://mycompany.example.com',
    duration=3600
)

# Portal 側でリダイレクト
print(f"Redirect: {console_url}")

MFA・多要素認証

MFA デバイスの種類

タイプ	例	セットアップ	セキュリティ
Virtual MFA	Google Authenticator、Authy	スマートフォン	★★☆
Hardware MFA	Yubikey、AWS GovCloud FID01	物理デバイス購入	★★★
SMS/Email	SMS 受信	キャリア依存	★☆☆（非推奨）

MFA の有効化

# ステップ 1: IAM ユーザー用の仮想 MFA デバイスを作成
aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name john-doe-mfa \
  --outfile /tmp/mfa-qr.png \
  --bootstrap-method QRCodePNG

# ステップ 2: QR コードをスキャン
# Google Authenticator または Authy で QR コードを読み取り

# ステップ 3: MFA デバイスを有効化
# Authenticator に表示される 6 桁のコード × 2 回を入力
aws iam enable-mfa-device \
  --user-name john.doe \
  --serial-number arn:aws:iam::123456789012:mfa/john-doe-mfa \
  --authentication-code1 123456 \
  --authentication-code2 789012

# ステップ 4: MFA 必須化（IAM ポリシー）
aws iam put-user-policy \
  --user-name john.doe \
  --policy-name EnforceMFA \
  --policy-document file://enforce-mfa-policy.json

MFA 必須ポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListingOnlyIfMFAIsEnabled",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    },
    {
      "Sid": "DenyAllOutsideOfWorkingHours",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "0.0.0.0/0"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Passkey・セキュリティキー

Passkey（2024年以降）

Passkey は、パスワード不要の認証。生体認証（指紋・顔）または PIN で認証。

従来：ユーザー名 + パスワード + MFA アプリ
      ↓
Passkey: 指紋・顔認証のみ
      ↓
セキュリティ向上、利便性向上

セットアップ

# AWS Management Console → セキュリティ認証情報 → Passkey を追加
# 1. デバイス名を入力（例: "iPhone 15 Pro"）
# 2. 生体認証（Face ID / Touch ID）で確認
# 3. Passkey 登録完了

FIDO2 セキュリティキー

物理的なハードウェアキー（Yubikey など）。

# セキュリティキーを USB ポートに挿入
# → AWS Management Console → セキュリティ認証情報 → デバイスを登録
# → セキュリティキーのボタンを押す
# → 登録完了

アカウントエイリアス・カスタム URL

アカウントエイリアスの設定

# デフォルト URL
https://123456789012.signin.aws.amazon.com/console

# カスタム URL に変更
aws iam create-account-alias --account-alias mycompany

# 新しい URL
https://mycompany.signin.aws.amazon.com/console

利点

ブランディング（企業ドメイン）
記憶しやすい
フィッシング対策（社員が正規 URL を認識）

Federation エンドポイント

Console リダイレクト用の Federation Endpoint

https://signin.aws.amazon.com/federation

パラメータ：

Action=getSigninToken: SignIn Token を取得
Action=login: Token でコンソールにログイン
SessionDuration: セッション持続時間（秒）
Session: セッション JSON（Base64 エンコード）
Issuer: 発行者（企業ポータル URL）
Destination: リダイレクト先 URL

CLI/SDK でのプログラマティックアクセス

AWS CLI with SSO

# IAM Identity Center SSO ユーザーでログイン
aws configure sso

# AWS SSO プロファイルを作成
aws configure sso-session --profile dev-account

# CLI での操作
aws s3 ls --profile dev-account

# 自動的に临時認証情報を取得・使用

AWS SDK with Assume Role

import boto3

# STS クライアント
sts = boto3.client('sts')

# ロールを引き受ける
assumed_role = sts.assume_role(
    RoleArn='arn:aws:iam::123456789099:role/CrossAccountRole',
    RoleSessionName='john-doe-session',
    DurationSeconds=3600
)

# 一時認証情報でクライアントを作成
creds = assumed_role['Credentials']

s3_client = boto3.client(
    's3',
    aws_access_key_id=creds['AccessKeyId'],
    aws_secret_access_key=creds['SecretAccessKey'],
    aws_session_token=creds['SessionToken']
)

# S3 操作を実行
response = s3_client.list_buckets()
print(response)

AWS Builder ID

AWS コミュニティ・トレーニング用 ID

AWS コンソール以外のリソースへのアクセス用（AWS Skill Builder など）。

AWS Builder ID
├── AWS Skill Builder（トレーニング）
├── AWS re:Post（Q&A コミュニティ）
├── AWS Console（オプション）
└── サードパーティ統合

セットアップ

AWS Skill Builder → "Log in" → "Create with Amazon" / "Create with Google"
        ↓
AWS Builder ID を作成
        ↓
AWS Skill Builder コースにアクセス

IAM Roles Anywhere

オンプレミス・外部環境からの AWS アクセス

IAM Roles Anywhere により、AWS の外側（オンプレミス、コンテナなど）から IAM ロールを引き受け可能。

オンプレミス EC2
    ↓ X.509 証明書
IAM Roles Anywhere
    ↓
AWS IAM Role assume
    ↓
AWS リソースアクセス

セットアップ

# ステップ 1: Trust Anchor を作成（ACM Private CA）
aws acm-pca describe-certificate-authority \
  --certificate-authority-arn arn:aws:acm-pca:us-east-1:123456789012:certificate-authority/xxx

# ステップ 2: IAM Roles Anywhere の Role を作成
aws iam create-role \
  --role-name OnPremiseWorkloadRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }]
  }'

# ステップ 3: オンプレミス環境で証明書を配置
# X.509 証明書、秘密鍵を配置

# ステップ 4: AWS CLI / SDK で Assume Role
aws sts assume-role-with-web-identity \
  --role-arn arn:aws:iam::123456789012:role/OnPremiseWorkloadRole \
  --role-session-name onprem-session \
  --web-identity-token <jwt-token>

企業ポータル統合

Okta Portal 統合例

1. Okta にユーザーログイン
2. Okta Tiles で "AWS" タイルをクリック
3. Okta が SAML Assertion を AWS に送信
4. AWS が Temporary Credentials を返却
5. Okta Tiles から AWS Console に直接ジャンプ

Azure AD 統合例

1. Microsoft 365 にログイン
2. Azure AD で AWS Application を登録
3. SAML / OIDC で IAM Identity Center と連携
4. ユーザーが Azure AD で AWS アカウント + Permission Set を選択
5. AWS Console に自動ログイン

CloudTrail 監査・ログ

サインイン操作の記録

# CloudTrail を有効化
aws cloudtrail create-trail \
  --name sign-in-audit-trail \
  --s3-bucket-name audit-bucket

# ConsoleLogin イベントを検索
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \
  --max-results 10

ログイン失敗の検出

# 不正ログイン試行を検出
aws logs create-metric-filter \
  --log-group-name /aws/cloudtrail/console-logins \
  --filter-name FailedLoginAttempts \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorCode != "Success") }' \
  --metric-transformations metricName=FailedLogins,metricValue=1

他の認証サービスとの比較

サービス	強み	弱み	AWS 統合
AWS IAM Identity Center	AWS ネイティブ、無料、統合完全	AWS 専用	★★★★★
Okta Workforce Identity	マルチクラウド、エンタープライズ	高コスト	★★★★
Microsoft Entra ID	Microsoft 統合	Azure 主体	★★★☆
Google Workspace SSO	Google 統合	Google 主体	★★★☆
Auth0	開発者向け、柔軟	複雑	★★★☆
JumpCloud	クロスプラットフォーム	中規模向け	★★☆☆
OneLogin	エンタープライズ	高コスト	★★☆☆

ベストプラクティス

1. ルートユーザーの保護

✅ ルートユーザー用にハードウェア MFA（Yubikey）を使用
✅ ルートユーザー用アクセスキーは作成しない
✅ ルートユーザーは緊急時のみ使用
✅ CloudTrail でルートユーザー操作をログ記録

2. IAM ユーザーからの移行（SSO へ）

Step 1: IAM Identity Center を有効化
Step 2: Identity Source を外部 IdP に接続（Okta / Azure AD）
Step 3: Permission Set を定義
Step 4: Account Assignment でユーザーを割り当て
Step 5: IAM ユーザーのコンソールアクセス権を削除

3. MFA・Passkey の標準化

✅ すべてのコンソールユーザーに MFA を必須化
✅ Passkey / セキュリティキーを推奨
✅ SMS ベースの MFA は避ける
✅ Hardware MFA を管理者用に推奨

4. Federation Endpoint の安全な運用

✅ Issuer URL をブランド化（企業ドメイン）
✅ SessionDuration を短く設定（1～8時間）
✅ HTTPS のみを使用（HTTP は禁止）
✅ Federation Token をログ記録しない（機密情報）

トラブルシューティング

1. “Invalid MFA” エラー

症状： MFA コード入力後もログインできない

原因と対策：

# ① 端末の時刻がズレている
# → スマートフォン / コンピュータの時刻を同期

# ② MFA デバイスが無効化されている
aws iam list-mfa-devices --user-name john.doe

# ③ デバイスの登録直後で同期に時間がかかっている
# → 数分待機して再試行

# ④ Authenticator App のコードが期限切れ
# → 新しいコード（6桁）を入力

2. SSO ログイン失敗

症状： Identity Center のポータルで “Authentication failed” エラー

原因と対策：

# ① SAML metadata が正しくない
aws ssoadmin describe-instances --region us-east-1

# ② IdP 側（Okta / Azure AD）の設定ズレ
# → IdP の SAML Configuration を確認

# ③ ユーザーに Permission Set が割り当てられていない
aws ssoadmin list-account-assignments \
  --instance-arn $INSTANCE_ARN \
  --account-id 123456789012 \
  --region us-east-1

# ④ Assertion Expiration Time が短すぎる
# → IdP の設定で 60～300 秒に延長

3. Federation URL がリダイレクトされない

症状： create_federated_console_url が 403 エラーを返す

原因と対策：

# ① Credentials の有効期限切れ
aws sts get-caller-identity

# ② Role ARN が正しくない
aws iam get-role --role-name DevOpsRole

# ③ Session Duration が長すぎる（max 1 時間）
# → DurationSeconds を 3600 以下に設定

# ④ Session JSON の JSON フォーマットエラー
# → json.dumps() で正しくエンコード

セキュリティ・コンプライアンス

IAM ポリシー（最小権限）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowConsoleLogin",
      "Effect": "Allow",
      "Action": [
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:GetLoginProfile"
      ],
      "Resource": "arn:aws:iam::123456789012:user/${aws:username}"
    },
    {
      "Sid": "AllowChangeSelfPassword",
      "Effect": "Allow",
      "Action": [
        "iam:ChangePassword"
      ],
      "Resource": "arn:aws:iam::123456789012:user/${aws:username}"
    }
  ]
}

PCI-DSS / HIPAA コンプライアンス

✅ MFA 必須化
✅ CloudTrail ログを 7 年保持
✅ パスワードポリシー（14文字以上、大文字・小文字・数字・記号混在）
✅ 90 日ごとのパスワード変更
✅ 5 回の失敗後 24 時間ロック

料金モデル

項目	費用
AWS Sign-In（Console）	無料
IAM Identity Center	無料（Organizations 統合）
IAM ユーザー	無料
MFA デバイス	無料（Hardware MFA は購入）

2025-2026 最新動向

1. Passkey が標準に

パスワード廃止、Passkey / セキュリティキーへ完全移行。

2. AWS Builder ID の拡大

AWS Skill Builder 以外のサービスでも AWS Builder ID での認証が拡大。

3. IAM Roles Anywhere の普及

ハイブリッドクラウド・Kubernetes 環境での IAM 統合が標準化。

4. Zero Trust Architecture

MFA・Passkey・CloudTrail ログにより、全アクセスを可視化・制御。

学習リソース・参考文献

AWS 公式ドキュメント

ベストプラクティス

AWS Security Best Practices

セットアップチェックリスト

[ ] ルートユーザーに MFA デバイスを割り当て
[ ] IAM Identity Center を有効化
[ ] Identity Source を外部 IdP に接続（推奨）
[ ] Permission Set を定義
[ ] Account Assignment でユーザーを割り当て
[ ] すべてのコンソールユーザーに MFA を必須化
[ ] CloudTrail ロギングを有効化
[ ] IAM パスワードポリシーを設定
[ ] Passkey / セキュリティキーの導入計画
[ ] Federation Endpoint の設定（必要に応じて）
[ ] 企業ポータル統合の検証
[ ] セキュリティ監査を実施

まとめ

AWS Sign-In は、AWS Management Console へのセキュアで柔軟なアクセスを提供する認証ポータル です。

主要なポイント：

4 つのサインイン方式： ルートユーザー（避けるべき）/ IAM ユーザー（レガシー）/ IAM Identity Center（推奨）/ Federation（エンタープライズ）
MFA・Passkey は必須： セキュリティベストプラクティス
IAM Identity Center への移行を推奨： SSO・SAML・OIDC 統合
Federation Endpoint で社内ポータル統合： シームレスなアクセス
CloudTrail で全操作をログ記録： 監査・コンプライアンス対応

推奨フロー：

ルートユーザー（初期設定のみ）
        ↓
IAM Identity Center 有効化
        ↓
Okta / Azure AD と SAML 統合
        ↓
Passkey / MFA で保護
        ↓
複数アカウント SSO アクセス

最終更新：2026-04-26 バージョン：v2.0

目次

AWS Sign-In 完全ガイド v2.0

AWS コンソール・認証・SSO ベストプラクティス

ドキュメントの目的

2025-2026 年の AWS Sign-In エコシステム

目次

概要

Sign-In が解決する課題

1. 複数 AWS アカウントへのアクセス管理

2. 長期アクセスキーの廃止・セキュリティ向上

3. 企業 ID 基盤との統合

4. MFA・パスキーによるセキュリティ向上

4 つのサインイン方式

ルートユーザー・アカウント

ルートユーザーとは

セキュリティベストプラクティス

ルートユーザーのセキュア化

IAM ユーザー・サインイン

URL 形式

セットアップ

コンソールアクセス権限

セキュリティベストプラクティス

IAM Identity Center（SSO）

推奨される最新のサインイン方式

セットアップ

ステップ 1: IAM Identity Center の有効化

ステップ 2: Identity Source の選択

ステップ 3: Permission Set の作成

ステップ 4: Account Assignment（アカウント割り当て）

ログイン画面

フェデレーション認証

AssumeRole with SAML（従来の方式）

Federation Endpoint（Console へのリダイレクト）

MFA・多要素認証

MFA デバイスの種類

MFA の有効化

MFA 必須ポリシー

Passkey・セキュリティキー

Passkey（2024年以降）

セットアップ

FIDO2 セキュリティキー

アカウントエイリアス・カスタム URL

アカウントエイリアスの設定

利点

Federation エンドポイント

Console リダイレクト用の Federation Endpoint

CLI/SDK でのプログラマティックアクセス

AWS CLI with SSO

AWS SDK with Assume Role

AWS Builder ID

AWS コミュニティ・トレーニング用 ID

セットアップ

IAM Roles Anywhere

オンプレミス・外部環境からの AWS アクセス

セットアップ

企業ポータル統合

Okta Portal 統合例

Azure AD 統合例

CloudTrail 監査・ログ

サインイン操作の記録

ログイン失敗の検出

他の認証サービスとの比較

ベストプラクティス

1. ルートユーザーの保護

2. IAM ユーザーからの移行（SSO へ）

3. MFA・Passkey の標準化

4. Federation Endpoint の安全な運用

トラブルシューティング

1. “Invalid MFA” エラー

2. SSO ログイン失敗

3. Federation URL がリダイレクトされない

セキュリティ・コンプライアンス

IAM ポリシー（最小権限）

PCI-DSS / HIPAA コンプライアンス

料金モデル

2025-2026 最新動向

1. Passkey が標準に

2. AWS Builder ID の拡大

3. IAM Roles Anywhere の普及

4. Zero Trust Architecture