第8章: クラウドとマイクロサービスの実装パターン

クラウド IAM の3大プロバイダー — 設計哲学の違いを読む

パブリッククラウドが標準インフラとなった今、アクセス制御の実装は必然的にクラウド IAM との連携を前提とします。 AWS・Azure・GCP の3大プロバイダーは、いずれも「最小権限の原則」と「ポリシーベース認可」を掲げていますが、 設計哲学は大きく異なります。その違いを理解せずに設計すると、複雑なマルチクラウド環境でポリシーの整合性が崩れます。

一言で表すなら AWS は「柔軟性重視」、Azure は「構造重視」、GCP は「精度重視」です。 この設計哲学の違いは、ポリシー記述の単位・スコープ階層・コンプライアンス機能の分離度に明確に現れています。

AWS IAM — ポリシー JSON 1ファイルで完結する柔軟な設計

IAMポリシーの基本構造

AWS IAM の特徴は、権限（Action）とリソース（Resource）を 1 つの JSON ドキュメントに同時定義できる点です。 Effect・Action・Resource の3フィールドが権限記述の核です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnlyForTaggedBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-data-bucket",
        "arn:aws:s3:::my-data-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-1",
          "s3:ResourceTag/Environment": "production"
        }
      }
    }
  ]
}

Condition ブロックが AWS IAM の ABAC 的拡張の核心です。aws:RequestedRegion でリクエスト元リージョンを絞り込んだり、s3:ResourceTag でリソースのタグに応じた制御が可能になります。 タグベースのポリシーを活用することで、ロール爆発を防ぎながら属性駆動の認可を実現できます。

多層評価の順序と Permission Boundary

AWS IAM の評価モデルは複数のポリシー種別が重なる多層構造を持ちます。 評価順序は固定されており、いずれかの段階で明示的な Deny があれば即座に拒否となります。

1. SCP（Service Control Policy）: AWS Organizations レベルで組織全体に適用。最優先で評価され、SCP で拒否されれば他のポリシーは無意味
2. Permission Boundary: IAM エンティティに設定できる最大権限の上限。開発者が自身より強い権限をサービスに付与することを防ぐ
3. Identity Policy: ユーザー/ロールにアタッチされた通常のポリシー
4. Resource-based Policy: S3 バケットポリシー・KMS キーポリシー等のリソース側に記述するポリシー

Azure RBAC — 管理グループからリソースまでの明確な階層構造

スコープ階層とロール割り当て

Azure RBAC の設計哲学は「構造重視」です。 権限は （ロール定義）× （スコープ）× （プリンシパル） の3要素の組み合わせで決まります。 スコープは4階層の継承ツリーで構成されます。

1. 管理グループ（Management Group）— 複数サブスクリプションをまとめる組織単位
2. サブスクリプション — 課金・リソース管理の単位
3. リソースグループ — 同一ライフサイクルのリソースをまとめるコンテナ
4. リソース — VM・ストレージアカウント等の個別リソース

上位スコープで付与したロールは下位スコープに継承されます。 たとえば管理グループレベルで「Reader」を付与すると、傘下のすべてのサブスクリプション・リソースグループ・リソースを閲覧できます。

組み込みロール4種と Azure Policy との分離

Azure は 300 以上の組み込みロールを持ちますが、基本となるのは次の4種類です。

• Owner: すべての操作権限 + ロール割り当て権限。他者へ権限を委任できる唯一のロール
• Contributor: リソースの作成・変更・削除が可能。ただしロール割り当ては不可
• Reader: すべてのリソースの読み取り専用アクセス
• User Access Administrator: Azure リソースへのユーザーアクセス管理に特化

AWS と対比した際に特徴的なのは、Azure Policy（コンプライアンス強制）とRBAC（権限制御）の役割を明確に分離している点です。 「特定のリージョン以外にリソースをデプロイさせない」という制御は Azure Policy が担い、 RBAC は「誰が何をできるか」のみを管理します。 また ID 管理には Microsoft Entra ID（旧 Azure AD）が統合されており、 条件付きアクセスポリシーによる多要素認証や Privileged Identity Management（PIM）との連携が強みです。

GCP IAM — Workload Identity と IAM Conditions による精度重視

IAM Conditions と文脈依存制御

GCP IAM の設計哲学は「精度重視」です。IAM Conditions により、時間帯・リソース名前空間・リクエスト経路などの属性を条件として きめ細かな権限制御が可能です。

# IAM Conditions の例: 平日9〜18時のみアクセス許可
resource "google_project_iam_member" "time_limited" {
  project = var.project_id
  role    = "roles/storage.objectViewer"
  member  = "serviceAccount:sa@project.iam.gserviceaccount.com"

  condition {
    title       = "business-hours-only"
    description = "平日業務時間帯のみ有効"
    expression  = <<-EOT
      request.time.getDayOfWeek("Asia/Tokyo") >= 1 &&
      request.time.getDayOfWeek("Asia/Tokyo") <= 5 &&
      request.time.getHours("Asia/Tokyo") >= 9  &&
      request.time.getHours("Asia/Tokyo") < 18
    EOT
  }
}

Workload Identity Federation — 静的キー不要化

GCP の大きな差別化要因が Workload Identity Federation です。 従来のサービスアカウントキー（JSON ファイル）は漏洩リスクが高く、ローテーションも煩雑でした。 Workload Identity Federation を使うと、GitHub Actions・AWS EC2・オンプレ Kubernetes などの 外部 IdP が発行するトークンを直接 GCP サービスアカウントにマッピングでき、長期間有効な静的キーが不要になります。

2022 年に追加された IAM Deny Policy と Policy Analyzer も注目機能です。 Deny Policy は「Allow ポリシーが何を許可していても、この操作だけは常に拒否する」という明示的拒否ルールを記述でき、 Policy Analyzer はシミュレーションで権限の実効範囲を事前確認できます。

3大クラウド IAM の設計比較

マイクロサービスのアクセス制御アーキテクチャ

北南・東西トラフィックの区別

マイクロサービス環境のアクセス制御を設計する際、まずトラフィックの方向を区別することが重要です。北南トラフィック（North-South）とは外部クライアント（ブラウザ・モバイルアプリ・サードパーティ）から システムへの流入トラフィックです。API ゲートウェイで処理します。東西トラフィック（East-West）とはマイクロサービス間の内部通信です。 サービスメッシュで処理します。

この2種類のトラフィックは性質が異なるため、認可の粒度と実装手段も異なります。 北南は「このユーザー（人間）がこのエンドポイントを呼べるか」という粗粒度の認可が中心ですが、 東西は「このサービスアカウントが別のサービスの内部 API を呼べるか」というワークロード間認証・認可が中心です。

graph TB
  Client([クライアント])
  GW[API Gateway]
  Mesh[サービスメッシュ: Istio]
  SvcA[サービスA]
  SvcB[サービスB]
  SvcC[サービスC]
  Client -->|HTTPS + JWT| GW
  GW -->|粗粒度認可 ロールベース| GW
  GW -->|JWT伝播| Mesh
  Mesh -->|mTLS + AuthorizationPolicy| SvcA
  Mesh -->|mTLS + AuthorizationPolicy| SvcB
  SvcA -->|東西 mTLS| SvcB
  SvcA -->|東西 mTLS| SvcC
  SvcA -->|細粒度認可 リソースレベル| SvcA
  style GW fill:#f97316,stroke:#ea580c,color:#fff
  style Mesh fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style SvcA fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style SvcB fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style SvcC fill:#3b82f6,stroke:#1d4ed8,color:#fff

集中型 vs 分散型 vs ハイブリッド

マイクロサービスの認可方式には主に3つのアプローチがあります。

• 集中型（Centralized）: 専用の認可サービス（例: OPA サーバー・Open Policy Agent）が すべての認可判定を処理。ポリシーの一元管理と一貫性が強みですが、単一障害点になりやすく、 レイテンシが増加します。
• 分散型（Distributed）: 各サービスが自身でポリシーを保持・評価。 依存なく独立して動作できますが、ポリシーの更新伝播が困難でドリフト（乖離）が発生しやすい欠点があります。
• ハイブリッド（推奨）: ポリシーは中央で管理・配信し（OPA Bundle Server 等）、 評価は各サービスのサイドカーでローカルに行う。一元管理と低レイテンシを両立できるため プロダクション環境での推奨アーキテクチャです。

Istio AuthorizationPolicy — サービスメッシュでの Zero Trust 実現

デフォルト拒否ポリシー — Zero Trust の基本

Istio を使ったサービスメッシュでのアクセス制御は、まずすべてを拒否するポリシーを作成することから始めます。 これが Zero Trust の基本原則「明示的に許可されたもの以外はすべて拒否」を実現する第一歩です。

# デフォルト拒否ポリシー（production 名前空間全体）
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  {}
  # spec が空 = すべてのリクエストを拒否
  # action フィールドを省略すると ALLOW として機能するが
  # rules が空の場合は誰も許可されない → 実質 deny-all

明示的許可ポリシーの記述

デフォルト拒否の上に、必要な通信のみを許可するポリシーを追加します。 ServiceAccount（ワークロード ID）と JWT クレームの両方で条件を指定できます。

# 注文サービスへのアクセスを制御するポリシー
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: order-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: order-service
  action: ALLOW
  rules:
    # API Gateway からの呼び出しを許可（サービスアカウントで識別）
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/api-gateway"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/v1/orders*"]
    # 在庫サービスからの在庫確認コールバックを許可
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/inventory-service"
      to:
        - operation:
            methods: ["GET"]
            paths: ["/internal/stock-check*"]
      when:
        # JWT クレームで追加制御: 内部サービス呼び出しのみ
        - key: request.auth.claims[caller-type]
          values: ["internal-service"]

JWT 二段階認可パターン

JWT クレームによる権限伝播

JWT（JSON Web Token）は、認証後に発行されるアクセストークンとしてマイクロサービス全体に権限情報を伝播する役割を担います。 ペイロードにロール・権限・スコープをクレームとして埋め込むことで、 各サービスがトークンをローカル検証するだけで認可判定ができます。

// JWT ペイロードの例（デコード後）
{
  "sub": "user_a1b2c3",
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1750000000,
  "exp": 1750003600,   // 有効期間: 1時間
  "roles": ["order:read", "order:write"],
  "permissions": ["order:create", "order:view", "product:view"],
  "org_id": "org_xyz",
  "tier": "premium"     // ビジネスルール属性（ABACへの拡張）
}

二段階認可の実装フロー

JWT を使った二段階認可では、API ゲートウェイとマイクロサービス内で異なる粒度の認可を行います。

1. API Gateway（粗粒度認可）: JWT の署名検証・有効期限チェック・ エンドポイント単位のロールチェックを行います。 「order:read ロールを持つユーザーだけが GET /orders を呼べる」という粗粒度のルールです。 認可サービスへの同期呼び出しなしにローカル検証できるため低レイテンシです。
2. マイクロサービス内（細粒度認可）: JWT クレームの org_id や sub を使って 「このユーザーがこの特定の注文リソースを閲覧できるか」というリソースレベルの判定を行います。 ReBAC や ABAC と組み合わせることで「同一組織のリソースのみアクセス可」といったルールを実現します。

OSSツールによるポリシー統一

OPA サイドカーパターン

第5章で解説した OPA（Open Policy Agent）は、マイクロサービス環境での認可エンジンとしても広く使われます。 各サービスに OPA をサイドカーとして配置し、Rego ポリシーをローカルで評価することで 低レイテンシを維持しながら外部サービスへの依存を排除します。

# OPA をサイドカーとして Kubernetes Pod に配置する例
spec:
  containers:
    - name: order-service
      image: order-service:v1.2.0
      env:
        - name: OPA_URL
          value: "http://localhost:8181"  # ローカルサイドカーを参照

    - name: opa
      image: openpolicyagent/opa:latest
      args:
        - "run"
        - "--server"
        - "--addr=0.0.0.0:8181"
        - "--bundle"
        - "https://policy-bundle-server.internal/bundles/order-service"
      # バンドルサーバーからポリシーを定期取得（デフォルト60秒ごと）

OPA バンドルサーバーパターンでは、ポリシーの Rego ファイルを中央サーバーにまとめて配置し、 各 OPA サイドカーが定期的に最新ポリシーをダウンロードします。 ポリシー変更が即座に全サービスに伝播し、一元管理と分散評価を両立できます。 さらに OPA Conftest を CICD パイプラインに組み込むことで、 Terraform・Kubernetes マニフェスト・Dockerfile のポリシー違反をデプロイ前に検出できます。

Casbin 組み込みパターン

既存のアプリケーションにアクセス制御を後付けする場合、Casbin は有力な選択肢です。 Go・Java・Python・Node.js など多言語の SDK を提供しており、 ミドルウェアとして組み込むだけで RBAC・ABAC・ACL 等複数モデルを切り替えられます。

// Go での Casbin 組み込み例
package middleware

import (
    "github.com/casbin/casbin/v2"
    "net/http"
)

func AuthzMiddleware(e *casbin.Enforcer) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            // JWT クレームから sub・ロールを取得（省略）
            user   := getUserFromContext(r.Context())
            path   := r.URL.Path
            method := r.Method

            // Casbin でポリシー評価
            ok, err := e.Enforce(user, path, method)
            if err != nil || !ok {
                http.Error(w, "Forbidden", http.StatusForbidden)
                return
            }
            next.ServeHTTP(w, r)
        })
    }
}

実装チェックリスト

クラウド + マイクロサービス環境でアクセス制御を設計・実装する際の確認項目をまとめます。