🔐 IAM Roles Anywhere

AWS外部からセキュアにAWSリソースへアクセス - ホテルのカードキーで理解する

🏨 ホテルのカードキーシステムで例えると超わかりやすい!

IAM Roles Anywhere = 外部からAWSに安全にアクセスする仕組み

オンプレミスのサーバーや他のクラウドから、AWSのサービスを使いたい時...
従来は「永久に使えるマスターキー」を渡していましたが、これはセキュリティリスク大!

IAM Roles Anywhereを使えば
ホテルの宿泊客に「滞在期間だけ有効なカードキー」を渡すように、
一時的で安全な認証情報 を発行できます✨

しかも、本人確認には 公式な身分証明書(X.509証明書) を使うので超安全!

🔑
従来の方法
長期アクセスキー(危険)
🏨 ホテルのたとえ
ホテルのマスターキーを渡してしまう状態。
チェックアウト後も使えるし、紛失したら大変!
悪用されたら全ての部屋に入れてしまう...
💻 実際の問題点
• アクセスキーとシークレットキーを発行
永久に有効 (期限なし)
• ファイルに保存するため漏洩リスク大
• 定期的なローテーションが必要
• 不要になっても忘れて放置しがち
• セキュリティ管理が大変
⚠️ セキュリティリスク
• GitHubに誤ってpush
• ログファイルに記録されて流出
• 古いサーバーに残ったまま
• 無効化を忘れて放置
🎫
IAM Roles Anywhere
証明書ベース認証(安全)
🏨 ホテルのたとえ
正式な身分証明書を見せて、滞在期間だけ有効なカードキーを発行してもらう。
チェックアウトしたら自動的に無効になる。
紛失してもマスターキーじゃないから被害最小!
💻 実際のメリット
• X.509証明書で本人確認
一時的な認証情報 を発行
• 期限付き(最大12時間)
• 長期キーの保存・管理不要
• 自動的に期限切れで無効化
• IAMロールの権限管理を活用
セキュリティ向上
• PKI基盤による強固な認証
• 認証情報は短時間で失効
• 証明書失効リストで即座に無効化
• AWS CloudTrailで全アクセス記録

🏨 もっと詳しく: ホテルのカードキーシステム

📖 ストーリー形式で理解しよう

🎬 シーン1: チェックイン
あなた(オンプレミスサーバー)がホテル(AWS)にチェックインします。
フロント係員に 運転免許証(X.509証明書) を見せて本人確認。
🎬 シーン2: 信頼確認
係員は「この免許証、警察庁発行だから信頼できるね!」と確認。
これが Trust Anchor = ホテルが信頼する証明書発行機関のリスト。
🎬 シーン3: プラン選択
あなたは「ビジネスプラン」を選択。
このプランなら、部屋、会議室、ジムが使えます。
これが Profile = どのAWSリソースにアクセスできるかの設定。
🎬 シーン4: カードキー発行
係員が「3日間有効のカードキー」を発行。
これが 一時的な認証情報 = 期限付きのアクセストークン。
🎬 シーン5: 施設利用
カードキーで部屋・会議室・ジムにアクセス。
プールやレストラン(権限外)は使えません。
これが IAMロールの権限制御
🎬 シーン6: 自動失効
3日後、チェックアウト時間になったらカードキーは自動的に無効化。
持っていても使えないから安全!
これが 一時認証情報の自動失効

🔑 キーポイント

  • 身分証明書 = X.509証明書(本人確認)
  • ホテルの信頼リスト = Trust Anchor(信頼する証明書発行機関)
  • 宿泊プラン = Profile(アクセス権限の設定)
  • カードキー = 一時的な認証情報(有効期限付き)
  • 施設 = AWSリソース(S3、EC2など)

🔄 IAM Roles Anywhereの動作フロー

1 証明書の準備
🏨 ホテル: 公式な身分証明書(運転免許証など)を用意
💻 実際: X.509証明書と秘密鍵をサーバーに配置
• 社内のPKI基盤で発行、または
• AWS Certificate Manager Private CAで作成
⬇️
2 Trust Anchor設定
🏨 ホテル: 「このホテルは警察庁発行の免許証を信頼します」と登録
💻 実際: AWSコンソールでTrust Anchorを作成
• 信頼するCA(証明機関)の証明書を登録
• CRL(証明書失効リスト)のURLも設定可能
⬇️
3 Profile設定
🏨 ホテル: 「ビジネスプラン: 部屋+会議室+ジム利用可」を設定
💻 実際: Profileを作成し、IAMロールを紐付け
• どのIAMロールを使用するか指定
• セッション期間(最大12時間)を設定
• タグでさらに制御も可能
⬇️
4 認証リクエスト
🏨 ホテル: フロントで免許証を見せて「カードキーください」
💻 実際: aws_signing_helperツールを使って認証
• 証明書と秘密鍵で署名したリクエスト送信
• Rolesanywhere.CreateSessionを呼び出し
⬇️
5 一時認証情報の発行
🏨 ホテル: 係員が3日間有効のカードキーを発行
💻 実際: AWSが一時的な認証情報を返却
• AccessKeyId、SecretAccessKey、SessionToken
• 有効期限付き(最大12時間)
• EC2のインスタンスプロファイルと同じ形式
⬇️
6 AWSリソースへアクセス
🏨 ホテル: カードキーで部屋、会議室、ジムを利用
💻 実際: 一時認証情報でAWS APIを呼び出し
• S3からファイル取得、EC2操作など
• IAMロールの権限内で自由に操作
• CloudTrailに全アクセスが記録される

🧩 主要コンポーネントを理解しよう

📜
Trust Anchor
🏨 ホテルのたとえ:
「このホテルは警察庁・運転免許センター発行の身分証明書を信頼します」という信頼リスト
💻 技術的な説明:
• 信頼するCA証明書を登録
• このCAが発行した証明書のみ受け入れ
• CRLで失効証明書をチェック可能
• 複数のTrust Anchorを設定可能
🎫
Profile
🏨 ホテルのたとえ:
「ビジネスプラン: 部屋+会議室+ジムOK、プールNG」という宿泊プランの設定
💻 技術的な説明:
• IAMロールを1つ以上指定
• セッション期間を設定(最大12時間)
• セッションタグで更に制御
• MFA(多要素認証)要求も可能
🔐
X.509証明書
🏨 ホテルのたとえ:
運転免許証やパスポートなどの公式な身分証明書。偽造が難しく、本人確認に使える
💻 技術的な説明:
• PKI(公開鍵基盤)の証明書
• 秘密鍵でデジタル署名を作成
• 公開鍵で署名を検証
• CAが発行元として信頼性を保証
🛠️
aws_signing_helper
🏨 ホテルのたとえ:
自動でフロントに行って「免許証見せてカードキー発行してもらう」作業をしてくれるアシスタント
💻 技術的な説明:
• AWSが提供する認証ヘルパーツール
• 証明書で署名したリクエスト作成
• 一時認証情報を自動取得
• AWS SDKやCLIと連携

💼 どんな時に使う? 実践ユースケース

🖥️

オンプレミスサーバー

シナリオ:
社内データセンターのサーバーから、AWSのS3にバックアップを送りたい。

従来の問題:
長期アクセスキーをサーバーに保存。定期ローテーションが大変...

IAM Roles Anywhereで:
• サーバーにX.509証明書を配置
• 必要な時だけ一時認証情報取得
• S3へ安全にバックアップ
• キー管理の手間ゼロ!
☁️

他クラウドからAWSへ

シナリオ:
Google CloudやAzureで動いているアプリから、AWSのDynamoDBにアクセスしたい。

従来の問題:
クラウド間でアクセスキーを管理するのは危険...

IAM Roles Anywhereで:
• 他クラウドのVMに証明書配置
• 必要な時だけDynamoDBアクセス
• マルチクラウド環境でも安全
• クロスクラウド連携が簡単に!
🐳

コンテナ環境

シナリオ:
オンプレのKubernetes上のコンテナから、AWSのSecretsManagerから秘密情報を取得したい。

従来の問題:
全コンテナでアクセスキー共有? 危険すぎる...

IAM Roles Anywhereで:
• コンテナイメージに証明書注入
• または、ノードの証明書を使用
• 各コンテナが安全に認証
• シークレット管理が安全に!
🤖

CI/CDパイプライン

シナリオ:
社内のJenkins/GitLab RunnerからAWSへデプロイしたい。

従来の問題:
CI/CDツールにアクセスキーを保存。漏洩リスク大...

IAM Roles Anywhereで:
• CI/CDサーバーに証明書配置
• ビルド時のみ一時認証情報取得
• ECRにpush、ECSにデプロイ
• セキュアなデプロイフロー実現!
🏢

エンタープライズ統合

シナリオ:
既存の社内PKI基盤を活用して、全システムからAWSへ統一的にアクセスしたい。

従来の問題:
システムごとにバラバラな認証方法。管理が複雑...

IAM Roles Anywhereで:
• 既存のPKI証明書をそのまま活用
• 全システムで統一された認証
• 証明書失効で即座にアクセス停止
• エンタープライズ統制が容易!
🔄

ハイブリッドクラウド

シナリオ:
オンプレとAWSの両方でアプリ稼働。データを相互にやり取りしたい。

従来の問題:
VPNやDirect Connect必須。コストも高い...

IAM Roles Anywhereで:
• インターネット経由で安全に接続
• オンプレからS3/DynamoDBアクセス
• 証明書ベースの強固な認証
• コスト効率的なハイブリッド構成!

⚖️ メリット・デメリット完全解説

メリット
  • セキュリティ大幅向上: 長期キー不要、一時認証情報で漏洩リスク最小化
  • 管理が超楽: キーローテーション不要、自動的に期限切れ
  • PKI基盤活用: 既存の証明書インフラをそのまま使える
  • 即座に無効化: CRLで証明書を失効させれば即アクセス停止
  • 監査証跡: CloudTrailで全アクセス履歴を記録
  • IAMロール活用: 既存のIAMポリシー・権限管理がそのまま使える
  • 柔軟な権限制御: Profile単位で細かく権限設定
  • マルチクラウド対応: どこからでも統一的にアクセス
⚠️ デメリット・制約
  • 初期セットアップ: PKI基盤・証明書発行の仕組みが必要
  • 証明書管理: 証明書の有効期限管理、更新作業が必要
  • 複雑性: 従来のアクセスキーより概念的に複雑
  • セッション時間制限: 最大12時間、それ以上は再認証必要
  • ツール依存: aws_signing_helperなど専用ツールの導入が必要
  • 学習コスト: PKI、X.509証明書の知識が必要
🛠️ 基本的なセットアップ手順
# 1. Trust Anchorの作成(AWS CLI)
aws rolesanywhere create-trust-anchor \
  --name "MyCompanyCA" \
  --source sourceType=CERTIFICATE_BUNDLE,sourceData={x509CertificateData="$(cat ca-cert.pem)"}

# 2. Profileの作成
aws rolesanywhere create-profile \
  --name "S3AccessProfile" \
  --role-arns "arn:aws:iam::123456789012:role/S3AccessRole" \
  --duration-seconds 3600

# 3. aws_signing_helperのダウンロード
wget https://rolesanywhere.amazonaws.com/releases/1.0.5/X86_64/Linux/aws_signing_helper
chmod +x aws_signing_helper

# 4. 一時認証情報の取得
aws_signing_helper credential-process \
  --certificate /path/to/certificate.pem \
  --private-key /path/to/private-key.pem \
  --trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/xxx \
  --profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/xxx \
  --role-arn arn:aws:iam::123456789012:role/S3AccessRole

# 5. AWS CLIで使用(~/.aws/configに設定)
[profile onpremise]
credential_process = /path/to/aws_signing_helper credential-process \
  --certificate /path/to/cert.pem \
  --private-key /path/to/key.pem \
  --trust-anchor-arn arn:aws:rolesanywhere:...  \
  --profile-arn arn:aws:rolesanywhere:... \
  --role-arn arn:aws:iam::...

# 6. 実際のAWS操作
aws s3 ls --profile onpremise
aws ec2 describe-instances --profile onpremise

🏗️ AWS Private CAとの完璧な連携

🏢 Private CA = 社内の身分証明書発行センター

🎭 ホテルチェーンの例で理解しよう

🏨 シナリオ:
あなたは全国展開するホテルチェーンのIT責任者。
各地の従業員やシステムに「社員証」を発行して、本社システム(AWS)にアクセスさせたい。
❌ 外部の身分証明書を使う場合:
従業員に「運転免許証を持ってきて」と言う状態。
• 発行元(警察庁)が社外なので管理できない
• 退職時に即座に無効化できない
• 会社のポリシーに合わせた有効期限設定ができない
• コストも発行元に依存
✅ Private CA(社内発行センター)を使う場合:
会社が独自の「社員証発行センター」を持つ状態。
完全な管理権限: いつでも発行・無効化できる
社内ポリシーに準拠: 有効期限や使用範囲を自由に設定
即座に無効化: 退職・異動時にすぐ停止
コスト管理: 社内で費用をコントロール
統合管理: 全従業員の証明書を一元管理

🔑 技術的な説明

AWS Private CA は、AWSが提供するプライベート認証局(CA)サービス。
自社専用のX.509証明書を発行・管理できる、マネージドなPKI基盤です。

IAM Roles Anywhereと組み合わせると:
• Private CAで証明書を発行
• その証明書でIAM Roles Anywhereに認証
• AWSリソースへ安全にアクセス
→ 完全にAWS内で完結する、セキュアな認証システムが完成!

✨ Private CA連携の強力なメリット

🎯
完全な統合管理
メリット:
• 証明書発行からアクセス管理まで全てAWS内で完結
• AWSコンソールから一元管理
• CloudTrailで証明書発行・使用を全記録
• 他のAWSサービスとシームレスに連携
簡単・高速セットアップ
メリット:
• 数クリックでCA構築完了
• 複雑なPKI基盤の構築不要
• AWS CLIで証明書を即座に発行
• インフラ管理の手間ゼロ
🔒
即座の失効・制御
メリット:
• コンソールから即座に証明書失効
• CRL(失効リスト)を自動生成
• 緊急時の対応が迅速
• きめ細かい有効期限設定
💰
コスト効率的
メリット:
• 従量課金で無駄なし
• サーバー維持費不要
• 証明書発行コストが低い
• スケールに応じた課金
🛡️
エンタープライズグレード
メリット:
• AWSのセキュリティ基準
• 高可用性・耐障害性
• 自動バックアップ
• コンプライアンス準拠
🔄
自動化・API連携
メリット:
• AWS APIで証明書発行を自動化
• CI/CDパイプラインに組み込み
• Lambda等で発行処理自動化
• Infrastructure as Code対応

🏗️ Private CA + IAM Roles Anywhere アーキテクチャ

🖥️
オンプレミスサーバー
またはk他クラウド
⬇️ ① 証明書リクエスト
🏢
AWS Private CA
証明書発行センター
⬇️ ② 証明書発行
🖥️
証明書をサーバーに配置
⬇️ ③ 証明書で認証リクエスト
🎫
IAM Roles Anywhere
Trust Anchor + Profile
⬇️ ④ 一時認証情報発行
☁️
AWSリソース
S3, DynamoDB, EC2など

🎯 ポイント: 全てAWS内で完結!
証明書発行から認証、リソースアクセスまで、
セキュアで統合されたエコシステムが実現します

📝 Private CA + IAM Roles Anywhere 完全セットアップ

1 Private CAの作成
🏨 ホテル: 社内に「社員証発行センター」を新設
💻 実際: AWS Private CAでルートCAを作成
• AWSコンソールのACM Private CAへ移動
• 「プライベートCAの作成」をクリック
• CAタイプを選択(ルートCA推奨)
• 組織情報・有効期限を設定
• 作成後、CAを有効化(アクティベート)
⬇️
2 Trust Anchorの作成
🏨 ホテル: 「このホテルは自社発行の社員証を信頼する」と登録
💻 実際: Private CAの証明書をTrust Anchorに登録
• IAM Roles Anywhereコンソールへ移動
• Trust Anchorを作成
• ソースタイプで「AWS Private CA」を選択
• 作成したPrivate CAのARNを指定
⬇️
3 IAMロールの作成
🏨 ホテル: 「部屋+会議室アクセス」などの権限プランを定義
💻 実際: Roles Anywhereで使用するIAMロールを作成
• IAMコンソールでロール作成
• 信頼関係でRoles Anywhereを許可
• 必要な権限ポリシーをアタッチ
• 最小権限の原則に従う
⬇️
4 Profileの作成
🏨 ホテル: 証明書とプランを紐付け
💻 実際: IAM Roles Anywhere Profileを作成
• Roles Anywhereコンソールでプロファイル作成
• 作成したIAMロールを紐付け
• セッション期間を設定(最大12時間)
• 必要に応じてタグでさらに制御
⬇️
5 証明書の発行
🏨 ホテル: 従業員に社員証を発行
💻 実際: Private CAからX.509証明書を発行
• CSR(証明書署名要求)を作成
• Private CAに証明書発行リクエスト
• 発行された証明書をダウンロード
• サーバーに証明書と秘密鍵を配置
⬇️
6 クライアント設定とテスト
🏨 ホテル: 社員証でホテル施設にアクセステスト
💻 実際: aws_signing_helperで認証テスト
• aws_signing_helperをインストール
• 認証情報取得をテスト
• AWS CLIでリソースアクセス確認
• CloudTrailでアクセスログ確認
🔧 Private CA + IAM Roles Anywhere 完全コマンド例
# ========================================
# STEP 1: Private CAの作成
# ========================================

# 1-1. Private CAを作成
aws acm-pca create-certificate-authority \
  --certificate-authority-configuration '{
    "KeyAlgorithm": "RSA_2048",
    "SigningAlgorithm": "SHA256WITHRSA",
    "Subject": {
      "Country": "JP",
      "Organization": "MyCompany",
      "OrganizationalUnit": "IT",
      "State": "Tokyo",
      "CommonName": "MyCompany Root CA"
    }
  }' \
  --certificate-authority-type "ROOT" \
  --idempotency-token "12345"

# 出力されたCA ARNを保存
export CA_ARN="arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/xxxxx"

# 1-2. CA証明書を取得(自己署名)
aws acm-pca get-certificate-authority-csr \
  --certificate-authority-arn $CA_ARN \
  --output text > ca.csr

# 1-3. CA証明書を発行(自己署名ルートCA)
aws acm-pca issue-certificate \
  --certificate-authority-arn $CA_ARN \
  --csr fileb://ca.csr \
  --signing-algorithm "SHA256WITHRSA" \
  --template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \
  --validity Value=10,Type="YEARS"

# 証明書ARNを保存
export CERT_ARN="arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/xxxxx/certificate/yyyyy"

# 1-4. CA証明書を取得
aws acm-pca get-certificate \
  --certificate-authority-arn $CA_ARN \
  --certificate-arn $CERT_ARN \
  --output text > ca-certificate.pem

# 1-5. CAをインポートして有効化
aws acm-pca import-certificate-authority-certificate \
  --certificate-authority-arn $CA_ARN \
  --certificate fileb://ca-certificate.pem

# ========================================
# STEP 2: Trust Anchorの作成
# ========================================

# Private CAをソースとしてTrust Anchorを作成
aws rolesanywhere create-trust-anchor \
  --name "MyCompany-Private-CA-Trust" \
  --source '{
    "sourceType": "AWS_ACM_PCA",
    "sourceData": {
      "acmPcaArn": "'$CA_ARN'"
    }
  }' \
  --enabled

# Trust Anchor ARNを保存
export TRUST_ANCHOR_ARN="arn:aws:rolesanywhere:ap-northeast-1:123456789012:trust-anchor/zzzzz"

# ========================================
# STEP 3: IAMロールの作成
# ========================================

# 3-1. 信頼ポリシーを作成
cat > trust-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "rolesanywhere.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession",
        "sts:SetSourceIdentity"
      ]
    }
  ]
}
EOF

# 3-2. IAMロールを作成
aws iam create-role \
  --role-name RolesAnywhereS3Access \
  --assume-role-policy-document file://trust-policy.json

# 3-3. 権限ポリシーをアタッチ(例: S3読み取り専用)
aws iam attach-role-policy \
  --role-name RolesAnywhereS3Access \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Role ARNを保存
export ROLE_ARN="arn:aws:iam::123456789012:role/RolesAnywhereS3Access"

# ========================================
# STEP 4: Profileの作成
# ========================================

aws rolesanywhere create-profile \
  --name "OnPremise-S3-Access-Profile" \
  --role-arns "$ROLE_ARN" \
  --duration-seconds 3600 \
  --enabled

# Profile ARNを保存
export PROFILE_ARN="arn:aws:rolesanywhere:ap-northeast-1:123456789012:profile/aaaaa"

# ========================================
# STEP 5: 証明書の発行(クライアント用)
# ========================================

# 5-1. 秘密鍵を生成
openssl genrsa -out client-private-key.pem 2048

# 5-2. CSR(証明書署名要求)を作成
openssl req -new -key client-private-key.pem -out client.csr \
  -subj "/C=JP/ST=Tokyo/O=MyCompany/OU=IT/CN=onpremise-server-01"

# 5-3. Private CAで証明書を発行
aws acm-pca issue-certificate \
  --certificate-authority-arn $CA_ARN \
  --csr fileb://client.csr \
  --signing-algorithm "SHA256WITHRSA" \
  --validity Value=365,Type="DAYS" \
  --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1

# 証明書ARNを保存
export CLIENT_CERT_ARN="arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/xxxxx/certificate/bbbbb"

# 5-4. 発行された証明書を取得
aws acm-pca get-certificate \
  --certificate-authority-arn $CA_ARN \
  --certificate-arn $CLIENT_CERT_ARN \
  --output text > client-certificate.pem

# ========================================
# STEP 6: クライアント設定
# ========================================

# 6-1. aws_signing_helperをダウンロード
wget https://rolesanywhere.amazonaws.com/releases/1.0.5/X86_64/Linux/aws_signing_helper
chmod +x aws_signing_helper
sudo mv aws_signing_helper /usr/local/bin/

# 6-2. 証明書と秘密鍵を安全な場所に配置
sudo mkdir -p /etc/aws-rolesanywhere/
sudo mv client-certificate.pem /etc/aws-rolesanywhere/
sudo mv client-private-key.pem /etc/aws-rolesanywhere/
sudo chmod 600 /etc/aws-rolesanywhere/client-private-key.pem

# 6-3. AWS CLIの設定(~/.aws/config)
cat >> ~/.aws/config << EOF

[profile onpremise]
credential_process = /usr/local/bin/aws_signing_helper credential-process \
  --certificate /etc/aws-rolesanywhere/client-certificate.pem \
  --private-key /etc/aws-rolesanywhere/client-private-key.pem \
  --trust-anchor-arn $TRUST_ANCHOR_ARN \
  --profile-arn $PROFILE_ARN \
  --role-arn $ROLE_ARN
EOF

# ========================================
# STEP 7: テスト
# ========================================

# S3バケットのリストを取得
aws s3 ls --profile onpremise

# 特定のバケットの内容を確認
aws s3 ls s3://my-bucket/ --profile onpremise

# CloudTrailでアクセスログを確認
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=onpremise-server-01 \
  --max-results 10

# ========================================
# オプション: 証明書の失効
# ========================================

# 証明書を失効させる(緊急時)
aws acm-pca revoke-certificate \
  --certificate-authority-arn $CA_ARN \
  --certificate-serial "証明書のシリアル番号" \
  --revocation-reason "KEY_COMPROMISE"
🤖 証明書発行の自動化スクリプト例
#!/bin/bash
# 新しいサーバー用の証明書を自動発行するスクリプト

set -e

# パラメータ
SERVER_NAME="$1"
CA_ARN="$2"

if [ -z "$SERVER_NAME" ] || [ -z "$CA_ARN" ]; then
  echo "Usage: $0  "
  exit 1
fi

echo "🔐 Generating certificate for: $SERVER_NAME"

# 1. 秘密鍵生成
echo "📝 Step 1: Generating private key..."
openssl genrsa -out "${SERVER_NAME}-key.pem" 2048

# 2. CSR作成
echo "📝 Step 2: Creating CSR..."
openssl req -new \
  -key "${SERVER_NAME}-key.pem" \
  -out "${SERVER_NAME}.csr" \
  -subj "/C=JP/ST=Tokyo/O=MyCompany/OU=IT/CN=${SERVER_NAME}"

# 3. 証明書発行
echo "📝 Step 3: Issuing certificate from Private CA..."
CERT_ARN=$(aws acm-pca issue-certificate \
  --certificate-authority-arn "$CA_ARN" \
  --csr fileb://"${SERVER_NAME}.csr" \
  --signing-algorithm "SHA256WITHRSA" \
  --validity Value=365,Type="DAYS" \
  --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
  --query "CertificateArn" \
  --output text)

echo "⏳ Waiting for certificate issuance..."
sleep 3

# 4. 証明書取得
echo "📝 Step 4: Retrieving certificate..."
aws acm-pca get-certificate \
  --certificate-authority-arn "$CA_ARN" \
  --certificate-arn "$CERT_ARN" \
  --output text > "${SERVER_NAME}-cert.pem"

# 5. 証明書情報表示
echo "✅ Certificate issued successfully!"
echo "📄 Certificate: ${SERVER_NAME}-cert.pem"
echo "🔑 Private Key: ${SERVER_NAME}-key.pem"
echo ""
echo "📊 Certificate Details:"
openssl x509 -in "${SERVER_NAME}-cert.pem" -noout -subject -dates

# 6. セキュリティ推奨
echo ""
echo "🔒 Security Recommendations:"
echo "  1. Store private key in a secure location"
echo "  2. Set appropriate file permissions (600)"
echo "  3. Never commit to version control"
echo "  4. Rotate certificate before expiration"

# CSRを削除(不要)
rm "${SERVER_NAME}.csr"

⚖️ Private CA vs 外部CA - どちらを選ぶ?

項目 AWS Private CA 外部CA(社内PKIなど)
セットアップ ✅ 超簡単
数クリックで完了
❌ 複雑
サーバー構築・設定が必要
運用管理 ✅ マネージド
AWSが自動管理
❌ 手動
自社で運用・保守
AWS統合 ✅ 完璧
シームレス連携
⚠️ 手動
Trust Anchor設定が必要
コスト ✅ 従量課金
使った分だけ
⚠️ 固定費
サーバー・人件費
証明書発行 ✅ API経由
自動化が容易
⚠️ 手動
プロセスによる
監査証跡 ✅ CloudTrail
自動記録
⚠️ 個別
独自の監査ログ
可用性 ✅ 高
AWS SLA保証
⚠️ 自社次第
冗長化が必要
既存システム ⚠️ 新規
既存PKIは別途
✅ 統合
既存インフラ活用
推奨ケース • AWSメイン環境
• 新規構築
• 管理を簡素化したい
• 素早く始めたい
• 既存PKI基盤あり
• 社内全体で統一
• 完全な制御が必要
• オンプレミス中心
💡 成功のための重要ポイント
1. Private CAの活用が最適解:
• 🎯 まず考えるべきはPrivate CA - AWS環境なら第一選択
• AWSコンソールから簡単にCA構築完了
• Trust Anchorとの統合がシームレス
• 証明書発行からアクセスまで全てAWS内で完結
• 既存のPKI基盤がない場合は特に推奨

2. Private CAの料金体系を理解:
• CA作成: 月額$400/CA(削除しても30日分課金)
• 証明書発行: $0.75/証明書(初月1000枚は無料)
• CRL: S3ストレージ料金のみ
• 💡 少数のサーバーなら十分コスト効率的!

3. 証明書のライフサイクル自動化:
• EventBridgeで有効期限30日前に通知
• Lambdaで証明書の自動再発行スクリプト作成
• Systems Manager Automation で配布自動化
• CloudWatch Logsで証明書使用状況を監視

4. セキュリティのベストプラクティス:
• 秘密鍵は暗号化して保管(KMS活用)
• 証明書の有効期間は最長1年(短いほど安全)
• CRLを有効化して失効チェック実施
• Profileで最小権限のIAMロールのみ許可
• セッション期間も必要最小限に(1-4時間推奨)

5. 監視とコンプライアンス:
• CloudTrailで全てのCA操作・証明書発行を記録
• 証明書発行時にタグ付けして管理
• Config Rulesで証明書の有効期限チェック
• Security Hubで統合的なセキュリティ監視
• 定期的な権限レビューとアクセス監査

6. 段階的な導入戦略:
Phase 1: 開発環境で概念実証(PoC)
Phase 2: 非本番環境で詳細テスト
Phase 3: 重要度の低いシステムで本番試験
Phase 4: 段階的に全システムへ展開
• 各フェーズでトラブルシューティング手順を更新

7. トラブルシューティング準備:
• 証明書検証エラーの対処法を文書化
• ネットワーク切断時のリトライロジック実装
• バックアップ認証方法の準備(緊急時用)
• チーム内でナレッジ共有(Wiki/Confluence)
• エスカレーションフローを明確化

8. コスト最適化:
• 使用しないCAは削除(30日後に課金停止)
• 証明書は必要な時だけ発行
• 複数用途で同じCAを活用
• CloudWatch Insightsでコスト分析

🎓 まとめ

🏨 ホテルのカードキー = IAM Roles Anywhere

オンプレミスや他クラウドからAWSへ安全にアクセスする仕組み
長期的なアクセスキーの代わりに、
証明書ベースの一時認証 でセキュリティ大幅向上✨

🏢 + AWS Private CAで完璧!
証明書発行からアクセス管理まで、
全てAWS内で完結する統合ソリューション

🔐
セキュリティ

証明書ベース認証で
長期キー不要。
一時認証で安全性UP
シンプル

キーローテーション不要。
自動的に期限切れ。
管理の手間が激減
🌐
柔軟性

どこからでもアクセス。
マルチクラウド対応。
既存PKI活用可能
🏢
統合管理

Private CAで
証明書発行も
AWS内で完結

🎯 こんな時に使おう:

✅ オンプレミスからAWSへアクセスしたい
✅ 他のクラウドからAWSを使いたい
✅ 長期アクセスキーの管理が大変
✅ セキュリティを強化したい
PKI基盤がない → Private CAで構築!
全てAWS内で完結させたい → Private CA連携!
✅ エンタープライズ要件を満たしたい

IAM Roles Anywhere は、
ホテルのカードキーのように 「安全で一時的なアクセス」 を実現🎉

🏢 AWS Private CAと組み合わせれば、
証明書発行からアクセス管理まで 全てAWS内で統合管理
複雑なPKI基盤の構築は不要、数クリックで完了します✨

初期セットアップは少し手間ですが、
一度構築すれば 長期的なセキュリティと管理の楽さ を享受できます!

まずはPrivate CAで開発環境から試してみよう! 🚀

Created by SSuzuki1063

AWS SAP Learning Resources