読み物の一覧 · 重要操作

管理者権限の付与

管理者の権限を与える操作は、一度通ると、その権限で次の操作が続きます。誰が・誰に・どの権限を与えたかを、署名の記録として残す方法をまとめます。

起きること

権限を与える操作そのものは、何も壊しません。けれども、与えた権限で次の操作がいくらでも続くので、侵入した攻撃者が最初に狙う操作の一つです⁶。

• 盗まれたセッションから、攻撃者が自分のアカウントに管理者の権限を与えます。
• 招待のリンクや承認の画面が差し替えられ、意図しない相手に権限が渡ります。
• 権限を与えたあとで、操作の記録が書き換えられたり、消されたりします。
• 監査で「この権限は誰が与えたか」を問われ、どのセッションから操作されたかしか示せません。

問われること

権限の付与は、多くの法域で「アクセスを誰に許すか」の管理として扱われます。方式を一つに定める規則は少なく、リスクに見合った措置を講じることが求められます。

争いになったときの署名の扱いは、パスキーの署名は、証拠として何になるか にまとめています。

残す記録

署名の対象（ハッシュ）に、次を含めます。

• 権限を受け取る人の識別子
• 与える権限（役割の名前）と、その範囲（組織・プロジェクトなど）
• 期限を付けるなら、その期限
• 依頼の番号

"payload": {
  "purpose": "generic.sign",
  "message_digest": "<受け取る人・役割・範囲・期限・依頼番号の SHA-256>",
  "display_hint": "管理者権限の付与"
}

権限を与える直前に、手元の内容からハッシュを計算し直し、署名のハッシュと一致することを確かめてから与えます。署名の結果は、権限の変更の記録と一緒に保管します。

二人の承認を求めたいときは、自社のサービスが二人それぞれに署名を依頼し、二つの署名がそろってから権限を与えます。そろったかどうかの判定は、自社のサービスが行います。

署名だけでは足りないこと

• 署名した人が、その権限を与えてよい立場にあるかは、自社のサービスが判定します。署名はその判定の記録を残すだけです。
• 権限を外す操作は、急いで行う必要があることがあります。外すことを先にし、記録をあとから残す設計もありえます。
• 署名は、与えた権限がその後どう使われたかを示しません。権限で行った操作の記録は、別に残します。

次の一手

• 署名の手順：依頼の登録から結果の受け取りまで
• 「ログイン済みだから本人だろう」で通してよい操作、よくない操作