ストーリー
田
田中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 Access | Microsoft 365に含む |
| Okta | エンタープライズ | 高い信頼性、SSO/MFA統合 | ユーザー単価 |
| AWS IAM Identity Center | AWS環境 | AWS統合、Organizations連携 | 無料 |
| Google Workspace | Google環境 | Google Cloud統合 | Workspaceに含む |
| Keycloak | OSS、オンプレ | カスタマイズ性、オンプレ対応 | 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方式 | 例 |
|---|
| Kubernetes | ServiceAccount + RBAC | Pod に ServiceAccount をアタッチ |
| AWS Lambda | IAM Role | Lambda 実行ロール |
| CI/CD | OIDC Federation | GitHub 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 | マシン/サービスにもアイデンティティを付与する |
チェックリスト
次のステップへ
次は「認証アーキテクチャ」を学びます。OAuth 2.0/OIDC、MFA、パスキー等の認証メカニズムを深く理解しましょう。
推定読了時間: 30分