3つの観点

1. 誰がアクセスできるか（人間・サービスアカウント）
2. 何にアクセスできるか（データ・機能・環境）
3. 誰がいつ何をしたかを記録する（監査ログ）

最小権限の原則

すべての権限は必要最小限から始め、必要に応じて拡張します。「念のため広めに」は事故の元です。

RBAC（ロールベースアクセス制御）

個人にではなくロールに権限を付与し、ロールを個人に割り当てる方式が管理しやすいです。

ロール例：
・Admin       … 全権限（極少数）
・Operator    … 本番ツール経由の読み書き
・Support     … 顧客データの読み取りのみ
・Developer   … 開発・ステージングのみ
・Auditor     … 監査ログの読み取りのみ

シークレット・トークンのアクセス

• レシートローラーのクライアントシークレット → 本番サービスアカウントのみ
• 顧客のアクセストークン → アプリ実行ユーザーのみ、人間からは隠す
• Webhookシークレット → 受信サーバーのみ

監査ログ

誰が何をしたかを記録することは、不正検知・事故調査・コンプライアンス対応に必須です。

記録すべきイベント

• 本番環境へのログイン・ログアウト
• シークレット・トークンの取得
• 顧客データの閲覧（特に大量取得）
• データ削除・エクスポート
• アプリ設定の変更
• 権限の付与・剥奪

各レコードに含めるべき項目

• タイムスタンプ（UTC）
• 実行者（user_id / service_account_id）
• アクション（read, write, delete 等）
• 対象（resource_type + resource_id）
• 結果（success / failure）
• クライアントIP・User-Agent
• 関連リクエストID

保管

• 監査ログ専用のストレージ（書込のみ・改ざん不可）
• 最低1年（業界によっては3〜7年）
• アプリログとは別に保管

定期レビュー

• 四半期：付与済み権限の棚卸し、不要な権限を剥奪
• 月次：監査ログの異常パターン確認
• 退職時：即時アカウント無効化、関連シークレットローテーション
• 年次：アクセス制御ポリシー全体の見直し

多要素認証（MFA）

本番環境にアクセスできる全ユーザーは MFA 必須にしてください。SMS よりも TOTP（Google Authenticator 等）または FIDO2 を推奨します。

関連ガイド

• データ保護の考え方
• 本番運用のベストプラクティス
• シークレットのローテーション
• 開発者ヘルプトップへ戻る