認証・IAM・セキュリティ

CRISIS API の認証方式、IAM（Identity and Access Management）の仕組み、セキュリティのベストプラクティスを解説します。

概要

CRISIS のアクセス制御は、以下の概念で構成されています。

Bearer トークン認証

すべての API リクエストには Authorization ヘッダに Bearer トークンを付与する必要があります。

Authorization: Bearer {access_token}

トークンが無効な場合は 401 Unauthorized（AUT-002, AUT-003, AUT-004）が返されます。 権限が不足している場合は 403 Forbidden（IAM-001）が返されます。

サービスアカウント

サービスアカウントは、お客様のシステムがプログラムから CRISIS API にアクセスするための専用アカウントです。 人間のユーザーアカウント（user_account）とは別の種別（service_account）として管理されます。

ライフサイクル

役割分離の設計

サービスアカウントは用途ごとに分離し、それぞれに最小限の権限を付与してください。

Workload Identity Federation

Workload Identity Federation（WIF）を使うと、GitHub Actions・Google Cloud・Azure AD・AWS などの外部 OIDC IdP が発行する 短命 JWT を CRISIS アクセストークンと交換できます。 静的なアクセストークンをリポジトリや環境変数に保存する必要がなくなります。

WIF の詳細なセットアップ手順・使用例は Workload Identity Federation ガイド を参照してください。

CRN（CrisisResourceName）

CRN は CRISIS プラットフォーム上のリソースを一意に識別するリソース名です。 すべてのリソースは CRN を持ち、IAM でアクセス制御の対象を指定する際に使用します。

形式

crn:crisis:{scope}:{organizationId}:{resourceType}/{resourceId}

例

// 特定の組織
crn:crisis:organizations:org-abc123

// 特定のインシデント
crn:crisis:organizations:org-abc123:incidents/inc-def456

// 特定のインシデントとそのサブリソースすべて（ワイルドカード）
crn:crisis:organizations:org-abc123:incidents/inc-def456<(/.*)?$>

// 組織内のすべてのインシデント
crn:crisis:organizations:org-abc123:incidents<(/.*)?$>

末尾の <(/.*)?$> は正規表現パターンで、指定リソースとそのサブリソース（イベント、フォーム、レポートなど）をすべて含みます。

パーミッション

パーミッションは サービス.リソース:アクション 形式で表現されます。 ロールに複数のパーミッションを含め、IAM でリソースにバインドすることで権限を付与します。

// パーミッション形式
^[a-z][a-z0-9_]*(?:\.[a-z0-9_]+)*:(?:list|get|update|delete|create|publish|fullaccess)$

// 例
organization.incident:create          // インシデントの作成
organization.incident:get             // インシデントの取得
organization.incident:list            // インシデント一覧の取得
organization.incident:update          // インシデントの更新
organization.incident:delete          // インシデントの削除
organization.workflow_topic:publish   // ワークフロートピックへのパブリッシュ
organization.user:list                // ユーザー一覧の取得
organization.service_account.access_token:create  // トークンの発行

アクションの種類

fullaccess を持たない場合は、メンバーとして割り当てられたインシデントのみ参照でき、フォーム回答も自身が回答したものに限定されます。

ロール

ロールは、パーミッションをまとめたものです。CRISIS には 2 種類のロールがあります。

カスタムロールの作成例:

// カスタムロール: ワークフローパブリッシュのみ
POST /organizations/{orgId}/iam/roles

{
  "name": "Workflow Publisher",
  "description": "ワークフロートピックへのパブリッシュのみ許可",
  "policies": [
    {
      "permission_id": "organization.workflow_topic:get",
      "effect": "allow",
      "description": "ワークフロートピックの参照を許可"
    },
    {
      "permission_id": "organization.workflow_topic:publish",
      "effect": "allow",
      "description": "ワークフロートピックへのパブリッシュを許可"
    }
  ]
}

IAM バインディング

IAM バインディングは、「誰が」「どのリソースに」「どのロールで」アクセスできるかを定義します。 ユーザー、グループ、サービスアカウントのそれぞれに対して設定します。

// サービスアカウント IAM の設定例
PUT /organizations/{orgId}/service_accounts/{saId}/iam

{
  "bindings": [
    {
      "resource": "crn:crisis:organizations:org-123:workflow_topics<(/.*)?$>",
      "role_id": "role-workflow-publisher"
    }
  ]
}

対象別の IAM エンドポイント

インシデント単位の IAM

インシデントごとに IAM を設定し、特定のインシデントに対するアクセス権を個別に制御できます。 これにより、対策本部のメンバーだけが特定のインシデント内のリソース（イベント、フォーム、レポートなど）にアクセスできるようになります。

PUT /organizations/{orgId}/incidents/{incidentId}/iam

{
  "bindings": [
    {
      "role_id": "role-incident-responder",
      "user_ids": ["user-001", "user-002"],
      "group_ids": ["group-hq"]
    }
  ]
}

認証ポリシー

組織の認証ポリシーを GET/PUT /organizations/{orgId}/iam/authentication_policy で管理できます。 ログイン方式や多要素認証の要件を制御します。

セキュリティプラクティス

次のステップ