0Pricing
Security+ Academy · レッスン

クラウドID：IAMロールとサービスアカウント

クラウドプラットフォームで最小権限のIAMロールとサービスアカウントを設定し、ワイルドカード権限や長期間有効な鍵などのよくある誤りを避けます。

「クラウドID：IAMロールとサービスアカウント」はCoddyKit上の無料Security+ Academyレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはSecurity+ Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Security+ Academyコースには全4レッスンが含まれています。

クラウドIDの基礎

クラウド環境では、アイデンティティが新たな境界となります。VMの起動、データベースの読み取り、APIの呼び出しなど、すべてのアクションは呼び出し元のアイデンティティに基づいて認可されます。クラウドIAM（Identity and Access Management）システムは、誰が、何を、どのリソースに対して実行できるかを定義します。ネットワーク上の場所が暗黙の信頼をもたらしていたオンプレミス環境とは異なり、クラウドIAMでは、どこから発信されたリクエストであっても、すべてのリクエストに明示的な認可が必要だと考えます。

AWS IAMにおけるユーザー、グループ、ロール

AWS IAMには、主に3種類のアイデンティティがあります。IAM Usersは、長期的な認証情報（アクセスキーとシークレットキー）を持つ個々の人間またはアプリケーションを表します。IAM Groupsはユーザーをまとめ、共通の権限を割り当てます。IAM Rolesは、一時的な認証情報を持つアイデンティティであり、ユーザー、AWSサービス（EC2、Lambda）、または別のアカウントが引き受けることができます。認証情報が自動的に期限切れになるため、認証情報が漏えいするリスクを減らせるロールは、長期的なアクセスキーよりも推奨されます。

# IAM role trust policy — allows EC2 to assume this role
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': { 'Service': 'ec2.amazonaws.com' },
    'Action': 'sts:AssumeRole'
  }]
}

# EC2 instance with this role attached can call AWS APIs
# using temporary credentials from the instance metadata service

IAMポリシーにおける最小権限

IAMポリシーは、アイデンティティがどのリソースに対してどのアクションを実行できるかを定義します。最小権限の原則では、タスクに必要な具体的なアクションだけをポリシーで許可することを求めます。よくある違反には、アクションに*のワイルドカードを使用すること（サービス内のすべてのアクションを許可します）、リソースに*を使用すること（すべてのリソースへのアクセスを許可します）、サービスアカウントにAdministratorAccessのような過度に広範な管理ポリシーをアタッチすることがあります。すべてのワイルドカードは使用理由を明確にし、定期的に見直す必要があります。

# Overly permissive policy (AVOID)
{
  'Effect': 'Allow',
  'Action': 's3:*',      # all S3 actions
  'Resource': '*'         # all buckets
}

# Least-privilege policy (PREFERRED)
{
  'Effect': 'Allow',
  'Action': ['s3:GetObject', 's3:ListBucket'],
  'Resource': [
    'arn:aws:s3:::my-specific-bucket',
    'arn:aws:s3:::my-specific-bucket/*'
  ]
}

GCP のサービスアカウント

Google Cloud Platform (GCP)では、人間以外のワークロードは、JSON キーファイルまたは Workload Identity Federation を使用する管理対象の ID エンティティであるサービスアカウントを使って認証します。各サービスアカウントには最小権限の原則を適用し、呼び出す必要がある GCP サービスにのみ権限を付与してください。サービスアカウントキー（コンソールからダウンロードする JSON ファイル）は有効期限の長い認証情報であり、パスワードと同様に扱う必要があります。定期的にローテーションし、ソースコードにコミットしたり、公開リポジトリにアップロードしたりしないでください。

# Check service account permissions (gcloud)
gcloud projects get-iam-policy my-project \
  --flatten='bindings[].members' \
  --format='table(bindings.role, bindings.members)' \
  --filter='bindings.members:serviceAccount'

# Prefer Workload Identity over service account keys
# (no downloadable key files — uses workload federation tokens)

Azure Managed Identities

Azure のManaged Identities（旧称 MSI）は、サービス向けの AWS IAM ロールに相当します。VM、App Services、Functions などの Azure リソースが、認証情報を保存せずに Azure API へ認証できるようにします。種類は 2 つあります。System-assigned managed identities は特定のリソースに紐づき、そのリソースが削除されると削除されます。User-assigned managed identities は独立したオブジェクトで、複数のリソース間で共有できます。Managed identities を使用すると、保存されたキーやシークレットが不要になります。

# Azure CLI — assign managed identity to a VM
az vm identity assign \
  --name myVM \
  --resource-group myRG \
  --identities /subscriptions/.../userAssignedIdentities/myIdentity

# The VM can now call Azure Key Vault without any stored credentials:
# Token is fetched automatically from the Instance Metadata Service

有効期限の長い認証情報のリスク

有効期限の長い認証情報、つまり期限切れにならない静的アクセスキー、API トークン、サービスアカウントキーファイルは、クラウド環境における最も高リスクな要素の一つです。GitHub、S3 バケット、ログ、または侵害された開発者のノートパソコンなどから漏えいすると、手動で無効化するまで、これらの認証情報によって即座にアクセスされてしまいます。組織は、有効期限の長い認証情報をすべて監査し、スケジュールに従ってローテーションし、短期トークンを発行するロールベースまたはフェデレーションアクセスを優先し、公開リポジトリに認証情報が現れた場合は直ちにアラートを出す必要があります。

# Find IAM access keys older than 90 days (AWS)
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | \
  base64 -d | grep -v 'N/A' | \
  awk -F',' '$10 > 90 {print $1, $10}'

# Keys older than 90 days should be rotated or deleted

IAM ロールチェーンと権限昇格

IAM の権限昇格は、ID が複数の権限を組み合わせて、自身に追加の権限を付与するときに発生します。典型的な昇格経路には、自分自身のユーザーにより許可範囲の広いポリシーをアタッチする、新たに高い権限を持つ IAM ユーザーを作成する、サービスにロール（iam:PassRole）を渡す、Lambda 関数の実行ロールを更新する、といったものがあります。AWS の IAM Access Analyzer はこうしたパターンを検出でき、IAM の権限境界によって、ID に付与可能な最大権限を厳格に制限できます。

# Dangerous permission combination (enables privilege escalation):
# iam:CreatePolicyVersion + iam:SetDefaultPolicyVersion
# Attacker can create a new policy version with AdministratorAccess

# Or: iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction
# Attacker creates Lambda with a privileged role, invokes it

# Defense: permission boundaries limit maximum grantable permissions

クロスアカウントロールの引き受け

クラウド組織では、影響範囲を限定するために、複数のアカウント（dev、staging、prod、security）を使用することがよくあります。クロスアカウントロールの引き受けを使うと、一方のアカウントの ID が別のアカウントのロールを引き受けられるため、集中管理されたツールでアカウント間の操作を行えます。セキュリティ対策としては、混乱した代理人攻撃を防ぐために信頼ポリシーでExternal IDを必須にすること、Principal ARN によってロールを引き受けられるアカウントを制限すること、監査のためにすべてのクロスアカウントロール引き受けを CloudTrail に記録することなどがあります。

# Trust policy with External ID (confused deputy protection)
{
  'Effect': 'Allow',
  'Principal': { 'AWS': 'arn:aws:iam::PARTNER-ACCOUNT-ID:root' },
  'Action': 'sts:AssumeRole',
  'Condition': {
    'StringEquals': {
      'sts:ExternalId': 'unique-shared-secret-12345'
    }
  }
}

IMDS とメタデータサービスのセキュリティ

AWS EC2 インスタンスは、Instance Metadata Service (IMDS)（http://169.254.169.254）から IAM ロールの認証情報を取得できます。ここでは SSRF 脆弱性が特に危険です。アプリケーションに SSRF の脆弱性があると、攻撃者はサーバーに IMDS の URL へアクセスさせることで、インスタンスの IAM ロール認証情報を窃取できます。IMDSv2（セッショントークンが必要）は、SSRF に基づく認証情報の窃取を緩和するため、すべての EC2 インスタンスで適用する必要があります。

# Enforce IMDSv2 on a new EC2 instance (requires token for IMDS)
aws ec2 run-instances \
  --metadata-options 'HttpTokens=required,HttpEndpoint=enabled' \
  ...

# IMDSv1 (insecure) just needs a GET request:
# curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# IMDSv2 requires a PUT to get a session token first

IAM Access Analyzer とポリシーレビュー

IAM Access Analyzer（AWS）は、外部プリンシパルと共有されているリソースや、意図した範囲を超える権限を付与する IAM ポリシーを自動的に特定します。バケットポリシー、ロールの信頼ポリシー、KMS キーポリシーを分析し、明示的に意図していない外部アクセスにフラグを付けます。IAM ポリシーを定期的に手動でレビューするか、Cloudsplaining、PMapper、Permissions Boundary Analyzer などのツールでレビューすることは、攻撃者に発見される前に権限昇格経路を特定するうえで不可欠です。

Workload Identity Federation

Workload Identity Federationを使用すると、外部ワークロード（GitHub Actions、オンプレミスシステム、他のクラウドプロバイダー）は、有効期限の長いサービスアカウントキーではなく、短期の OIDC トークンを使ってクラウド IAM に認証できます。GitHub Actions のワークフローは、ジョブの実行中だけ OIDC トークンを使って AWS IAM ロールを引き受け、その後トークンは期限切れになります。この方法により、CI/CD パイプラインにおける有効期限の長い認証情報の漏えいという問題全体をなくせます。

クイックチェック

このレッスンで扱った CompTIA Security+ (SY0-701) の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、IAM ロールは一時的な認証情報を提供し、クラウドワークロードでは有効期限の長いアクセスキーよりも優先されること、最小権限ポリシーではワイルドカードを避け、特定のリソースに対して特定のアクションだけを許可すべきこと、そしてIMDSv2、権限境界、ワークロード ID フェデレーションによって、一般的な認証情報の露出経路をなくせることを学びました。次は Cloud Security Posture Management (CSPM) について学びます。

よくある質問

「クラウドID：IAMロールとサービスアカウント」レッスンは無料ですか？

はい。「クラウドID：IAMロールとサービスアカウント」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Security+ Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Security+ Academyコースには全4レッスンが含まれています。

「クラウドID：IAMロールとサービスアカウント」で何を学びますか？

クラウドプラットフォームで最小権限のIAMロールとサービスアカウントを設定し、ワイルドカード権限や長期間有効な鍵などのよくある誤りを避けます。 ブラウザで直接実行するハンズオンコードでSecurity+ Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Security+ Academyを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSecurity+ Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。

「クラウドID：IAMロールとサービスアカウント」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSecurity+ Academyレッスンでコードを書いて実行できますか？

はい。すべてのSecurity+ Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 責任共有モデル：IaaS、PaaS、SaaS
  2. クラウドストレージのセキュリティとデータ漏えいリスク
  3. クラウドID：IAMロールとサービスアカウント
  4. クラウドセキュリティポスチャ管理（CSPM）
← Security+ Academyに戻る