LESSON 30分

ストーリー

田中VPoE
シークレット管理基盤が設計できた。次は「ID管理基盤」だ。シークレットを誰がアクセスできるかを制御するには、「誰が」を正確に識別する仕組みが必要だ
あなた
ユーザー認証とアクセス制御ですね
田中VPoE
それだけではない。現代のID管理は「人間」だけでなく「マシン(サービス、API、IoTデバイス)」のアイデンティティも含む。さらに、ゼロトラストアーキテクチャでは「すべてのアクセスを検証する」ことが求められる。ネットワーク境界を信頼しない
あなた
VPNの内側にいるから安全、という考え方をやめるということですか
田中VPoE
その通り。VPNの内側にいても、そのユーザーが本物か、そのデバイスが安全か、そのリクエストが正当か、毎回検証する。これがゼロトラストの基本だ

アイデンティティ管理の全体像

IAM(Identity and Access Management)の4つの柱

IAM の 4 つの柱:

1. Identity(識別)
   ├── 人間のID: 従業員、顧客、パートナー
   ├── マシンのID: サービス、API、Bot、IoT
   └── ワークロードID: コンテナ、Lambda、CI/CDジョブ

2. Authentication(認証)
   ├── 知識要素: パスワード、PIN
   ├── 所有要素: スマートフォン、セキュリティキー
   └── 生体要素: 指紋、顔認証

3. Authorization(認可)
   ├── RBAC: ロールベースアクセス制御
   ├── ABAC: 属性ベースアクセス制御
   ├── PBAC: ポリシーベースアクセス制御
   └── ReBAC: 関係ベースアクセス制御

4. Governance(ガバナンス)
   ├── プロビジョニング/デプロビジョニング
   ├── アクセスレビュー(定期的な権限棚卸し)
   ├── 特権アクセス管理(PAM)
   └── 監査とコンプライアンス

ゼロトラストアーキテクチャ

従来の境界型セキュリティとの比較

観点境界型セキュリティゼロトラスト
信頼の基準ネットワークの位置(内側 = 信頼)ID + コンテキスト(毎回検証)
防御の対象境界(ファイアウォール、VPN)すべてのリソースへのアクセス
内部脅威対応困難(内側は信頼済み)内部も外部と同じレベルで検証
リモートワークVPN必須(帯域がボトルネック)VPN不要(ID基盤で制御)
マイクロサービスサービス間通信の制御が困難サービスメッシュ + mTLSで制御

ゼロトラストの原則

原則内容実装例
すべてのアクセスを検証ネットワーク位置に関係なく、すべてのリクエストを認証・認可OAuth 2.0 + JWT検証
最小権限アクセス必要最小限の権限のみ付与、JITアクセスRBAC + ゼロスタンディング権限
侵害を前提とする内部ネットワークが侵害されている前提で設計マイクロセグメンテーション、暗号化
明示的な検証ユーザーID + デバイス + 場所 + 振る舞いの複合検証リスクベース認証
データ中心の保護データがどこにあっても保護が追随する暗号化、DLP、分類ラベル

アイデンティティプロバイダー(IdP)

主要なIdPの比較

IdP対象特徴コスト
Auth0(Okta)BtoB SaaS、BtoC開発者フレンドリー、豊富なSDK従量課金
Azure AD(Entra ID)Microsoft環境Microsoft 365統合、Conditional AccessMicrosoft 365に含む
Oktaエンタープライズ高い信頼性、SSO/MFA統合ユーザー単価
AWS IAM Identity CenterAWS環境AWS統合、Organizations連携無料
Google WorkspaceGoogle環境Google Cloud統合Workspaceに含む
KeycloakOSS、オンプレカスタマイズ性、オンプレ対応OSS無料

選定基準

IdP 選定フロー:

既存のクラウド環境は?
├── AWS中心 ──→ AWS IAM Identity Center + Auth0/Keycloak
├── Azure中心 ──→ Azure AD(Entra ID)
├── GCP中心 ──→ Google Workspace + Cloud Identity
└── マルチクラウド ──→ Okta / Auth0

アプリケーションの種類は?
├── BtoB SaaS ──→ Auth0 / Okta(テナント管理が充実)
├── 社内システム ──→ Azure AD / Okta
└── BtoC ──→ Auth0 / Cognito(大量ユーザー対応)

コスト感は?
├── 高予算 ──→ Okta / Auth0 Enterprise
├── 中予算 ──→ Auth0 Developer Pro / Azure AD P1
└── 低予算 ──→ Keycloak(OSS)/ AWS IAM Identity Center

ワークロードアイデンティティ

マシンのID管理

コンテキストID方式
KubernetesServiceAccount + RBACPod に ServiceAccount をアタッチ
AWS LambdaIAM RoleLambda 実行ロール
CI/CDOIDC FederationGitHub Actions → AWS OIDC
サービスメッシュSPIFFE/SPIREサービス間mTLS
コンテナVault AppRoleコンテナ→Vault認証

SPIFFE(Secure Production Identity Framework for Everyone)

SPIFFE によるワークロードID:

SPIFFE ID 形式:
  spiffe://trust-domain/path

例:
  spiffe://example.com/production/payconnect-api
  spiffe://example.com/staging/payconnect-worker

SVID(SPIFFE Verifiable Identity Document):
  - X.509 SVID: TLS証明書としてmTLSに使用
  - JWT SVID: Bearer トークンとして使用

利点:
  - プラットフォーム非依存(Kubernetes, VM, ベアメタル)
  - 自動的な証明書ローテーション
  - サービス間の強力な認証(人間の介入なし)

「人間のIDだけ管理していたのは過去の話だ。マイクロサービスのサービス間通信、CI/CDのジョブ、LambdaからS3へのアクセス — すべてにアイデンティティが必要だ」 — 田中VPoE


まとめ

ポイント内容
IAMの4つの柱識別、認証、認可、ガバナンス
ゼロトラストすべてのアクセスを検証、最小権限、侵害前提
IdP選定クラウド環境、アプリ種類、コストに応じて選定
ワークロードIDマシン/サービスにもアイデンティティを付与する

チェックリスト

  • IAMの4つの柱を説明できる
  • ゼロトラストの原則を理解した
  • 主要なIdPの特徴を比較できる
  • ワークロードアイデンティティの必要性を理解した

次のステップへ

次は「認証アーキテクチャ」を学びます。OAuth 2.0/OIDC、MFA、パスキー等の認証メカニズムを深く理解しましょう。


推定読了時間: 30分