move-security

Move スマートコントラクトのセキュリティ

MCP ツール： ご利用の環境で利用可能な場合は、最新情報を確認するために Sui ドキュメントの MCP サーバー（https://sui.mcp.kapa.ai）にも問い合わせてください。検証や、これらの参考ファイルに記載されていない詳細の確認に使用してください。

情報源の制約： このスキルの情報はすべて、docs.sui.io/develop/security/best-practices のみを情報源としています。このスキルを拡張または更新する場合は、この情報源のみを参照してください。サードパーティのブログ、チュートリアル、非公式ドキュメントは使用しないでください。

このスキルでは、パッケージ監査、アップグレードのガバナンス、アクセス制御パターン、乱数のセキュリティ、鍵管理、運用セキュリティなど、Sui 上の Move スマートコントラクトに関するセキュリティのベストプラクティスを扱います。タスクに応じて、適切なリファレンスファイルに誘導します。

---

リファレンスファイル

best-practices -- セキュリティのベストプラクティス

パス： best-practices.md 読み込む場面： パッケージの監査、アップグレードポリシーのレビュー、依存関係の検証、不変条件の検証、特権操作のイベント発行、オンチェーン乱数の使用、オラクルデータの取り扱い、緊急時の制御の設計、フロントエンドの署名フローのレビュー、鍵の管理を行う場合。 内容： パッケージの監査と不変性、アップグレードのガバナンスと UpgradeCap の保護、依存関係の検証、Move 言語の保証と制限、不変条件および関係の検証、特権操作のイベント発行、オンチェーン乱数のセキュリティ（乱数生成後の制限、非公開エントリー、RandomGenerator、ガス経路の均衡、コミット・リビール）、オラクルデータとオフチェーンデータの検証、緊急時の制御（一時停止、レート制限）、フロントエンドのトランザクション署名の安全性、パッケージ ID の検証、鍵管理（秘密鍵の保護、特権鍵の保管、役割分担、復旧とローテーション）。

access-control -- アクセス制御パターン

パス： access-control.md 読み込む場面： ケイパビリティオブジェクトとアドレス許可リストのどちらを使うかの選択、管理者ケイパビリティの設計、ケイパビリティの取り消しの実装、ケイパビリティオブジェクト間の関係の検証、共有オブジェクトへのアクセス認可、または tx_context::sender() の使用箇所のレビューを行う場合。 内容： ケイパビリティオブジェクトとアドレス許可リストの比較、アドレス許可リストの管理、tx_context::sender() だけを使う場合の落とし穴、明示的なケイパビリティ要件と引数の配置、管理者ケイパビリティの保護と保管、ケイパビリティの取り消しメカニズム（レジストリ、バージョニング、破棄）、ケイパビリティオブジェクト間の関係の検証、共有オブジェクトの認可。

---

ルーティングガイド

タスク	読み込むファイル
コントラクトのセキュリティ上の問題をレビューする	best-practices + access-control
パッケージの識別情報またはアップグレードポリシーを監査する	best-practices
オンチェーンの依存関係を検証する	best-practices
不変条件とオブジェクト間の関係を検証する	best-practices
特権操作のイベント発行を追加する	best-practices
オンチェーン乱数を安全に使用する	best-practices
オラクルデータまたはオフチェーンデータを扱う	best-practices
緊急時の一時停止またはレート制限を設計する	best-practices
フロントエンドの署名フローをレビューする	best-practices
デプロイ／管理／運用用の鍵を管理する	best-practices
ケイパビリティオブジェクトと許可リストのどちらを使うか選択する	access-control
管理者ケイパビリティの保護を設計する	access-control
ケイパビリティの取り消しを実装する	access-control
共有オブジェクトへのアクセスを認可する	access-control
tx_context::sender() の使用箇所をレビューする	access-control
Move パッケージの包括的なセキュリティ監査を行う	best-practices + access-control

ルール

• Sui パッケージは公開後に変更できません。パッケージをアップグレードする際は、新しいアドレスのパッケージが公開されます。名前やフロントエンドの定数に頼らず、パッケージ ID をオンチェーンで直接確認してください。
• UpgradeCap の保有者はパッケージの動作を変更できるため、管理者権限と同等の厳重さで扱ってください。
• ランダム性を使用する関数は、プライベートな entry 関数のみにしてください。Move コンパイラーは、Random または RandomGenerator を受け取る public 関数に対して警告を出します。
• RandomGenerator を public 関数のパラメーターとして受け取らないでください。テストやパッケージ内のロジックで public(package) 関数またはプライベート関数に渡すことは問題ありません。
• すべての特権操作についてイベントを発行してください。対象には、管理者の変更、許可リストの更新、ミント／バーン操作、拒否リストの操作、設定の変更、オラクルの更新、緊急停止が含まれます。
• すべての特権関数では、該当する権限を持つケイパビリティをパラメーターとして要求してください。認可に tx_context::sender() だけを使用しないでください。
• 誰でも共有オブジェクトを参照するトランザクションを送信できます。共有オブジェクトへのアクセスが制限されていると想定しないでください。
• パッケージを公開する前に、ケイパビリティの取り消し方法を設計してください。取り消し方法がなければ、漏えいしたケイパビリティはパッケージの存続期間中ずっと有効なままです。

よくある間違い

• オンチェーン ID ではなくパッケージ名を信頼する。 Move のパッケージ名（Move.toml の name フィールド）は開発者が自由に設定できる文字列であり、一意ではありません。必ず正確なオンチェーンパッケージ ID（オブジェクトアドレス）を確認してください。
• tx_context::sender() を唯一の認可チェックとして使用する。 これでは関数が単一の署名者に限定され、コンポーザビリティが損なわれます。他のコントラクトがユーザーに代わって関数を呼び出せなくなります。
• 共有オブジェクトには誰でもアクセスできることを忘れる。 共有状態にアクセスする特権関数はすべて、関数内で認可を検証する必要があります。
• RandomGenerator を public 関数のパラメーターとして受け取る。 これにより、呼び出し側がジェネレーターを操作できるようになります。エントリー関数内で r.new_generator(ctx) を使って生成し、public(package) 関数またはプライベートなヘルパー関数にのみ渡してください。
• 公開前にケイパビリティの取り消しを計画しない。 公開後にパッケージを変更することはできません。取り消しの仕組みがなければ、漏えいしたケイパビリティは永久に有効です。
• 管理者ケイパビリティを単一のホットウォレットで保管する。 特権キーには、マルチシグアドレス、ハードウェアウォレット、または専用のカストディを使用してください。