IOSOR ガイド

送信権限と API キーローテーションの運用設計

人のロールが送信権限を決定します。API キーのローテーションとサンドボックスの切り替えは Developers の管轄に維持し、シート権限の付与とシークレットのライフサイクルを混同しないでください。

人の権限管理と API キーの衛生管理はチケット上では隣り合って見えますが、解決すべき問題は全く異なります。誰が送信できるかという問題はロールの割り当てであり、どのシートが本番 SMS を送信し、キャンペーンを承認し、データエクスポートを実行できるかを定義します。

IOSOR はこの境界を厳密に分離します。コンソールロールを付与しても Webhook 署名キーはローテーションされません。また、キーをローテーションしても送信権限が自動的に付与されることはありません。

シート権限の付与とシークレットのライフサイクルを分離する

シート権限の付与は、誰が送信・承認・エクスポートのボタンを押せるかを決定します。これらは明確な所有者と最小権限マトリクスを備えた roles-access の審査領域に属します。

ロールチケットにはシートと実行可能な操作が記載されます。Developers チケットにはシークレットの所有者、ローテーション期間、切替の証明が記載されます。

誰が送信できるかはロールの領域である

本番環境で SMS を送信すると前払いホールドが消費され、ライブパスに監査ログが残ります。送信権限を持つシートは明示的でなければなりません。キャンペーン運用担当、オンコールメッセージング担当、または文書化された所有者を持つ自動化アイデンティティがこれに該当します。閲覧専用の財務担当者や KYC 審査員、エクスポート担当者が共有管理者ロールから送信権限を継承してはなりません。

退職者が発生した場合は、端末のローテーションを行う前に送信権限を取り消してください。キーのローテーションはシートの失効の代わりにはなりません。有効なロールが残っている場合、退職したエンジニアが新しいキーを発行できてしまうためです。ホワイトレーベル画面を利用するパートナー管理者にも同様の明確さが必要です。ポータルロールは人のマップであり、本番キーを貼り付けるための近道ではありません。

ローテーションと切替は Developers パスに維持する

ダウンタイムなしでの Webhook 署名キーのローテーション、サンドボックスから本番キーへの切り替え、キーのローンチ衛生管理は Developers の役割です。これらにはデュアルラン期間、新シークレットでのスモークテスト、誰がエクスポート権限を持っているかに依存しない切替チェックリストが必要です。ロール変更に'APIキーのローテーションも行う'と含まれている場合は、ローテーション処理を Developers へルーティングしてください。

ロールチケットにキーを貼り付けるハイブリッドな権限付与を拒否する

'管理者 — 本番キーを保持'といったスプレッドシートの運用は、シートをキー保管庫として扱う悪習を生みます。ロールマトリクス(人 → 操作)と Developers のキーレジスタ(シークレット → 所有者 → 最終ローテーション日)の2つの成果物を発行してください。パートナーから送信可能なログインと本番キーを1つのメールで請求された場合は、roles-access と Developers の2つのリンクで答えてください。

IOSORで始める

本日のコンソール座席権限の監査を実施し、ユーザーのメッセージ送信権限とAPI資格情報の管理を明確に分離してください。人間の役割はチームのアクセス権マトリクスに基づいて厳格に割り当て、鍵のローテーションスケジュールは開発者の作業ストリームに組み込みます。座席プロビジョニングのチケットや運用ログ内に、生の資格情報やウェブフックのシークレットが保存されていないことを必ず確認してください。

IOSORの要点

人間の座席権限の付与はメッセージの送信やレポートの閲覧者を決定するものであり、APIキーの衛生管理はサービス資格情報のライフサイクルを管理するものです。ユーザーの座席プロビジョニングとシークレット管理を混同すると、深刻なセキュリティリスクが生じ、運用の責任体制が損なわれます。

ユーザーアクセス権のマトリクスと、責任者および切り替えウィンドウが文書化された開発者用キー台帳との間には、厳格な分離を維持してください。本番環境のシークレットを人間の役割承認とともに貼り付けるような、ハイブリッドな付与やスプレッドシートの運用は許可しないでください。

このガイドは役に立ちましたか？