OSS バケットに上書き禁止ルールを設定することで、ファイルの初回アップロード後の偶発的または悪意のある変更からファイルを保護できます。このルールにより、パス、タイプ、またはユーザー ID に基づいて、どのファイルを上書きできないかを正確に制御できます。
初回の同時アップロード：複数のクライアントが同じファイルを同時にアップロードした場合、システムはいずれか 1 つのバージョンの書き込みを成功させます。これは、ファイルが上書き禁止ルールに一致する場合でも発生します。このプロセスにより、高同時実行シナリオでの書き込み成功率が保証されます。ファイルが作成された後、ルールは後続のすべての上書き操作をブロックします。
内部システムの動作：上書き禁止機能は、`PutObject` や `AppendObject` など、クライアント起因の操作にのみ適用されます。このルールは、ライフサイクルトランジションやクロスリージョンレプリケーション (CRR) など、OSS システムが開始するバックグラウンド操作をブロックしません。これにより、コア機能が中断なく機能し続けることが保証されます。
バージョン管理との非互換性：バケットでバージョン管理が有効または一時停止されている場合、上書き禁止ルールは有効になりません。
仕組み
OSS がファイルの上書きリクエストを受信すると、システムは次のように保護ルールに照らしてリクエストを評価します。
ルールの一致：システムは、作成された順序でルールをチェックします。リクエストされたファイルパスがルールのプレフィックスおよびサフィックス条件に一致するか、またユーザーの ID が認可ユーザー設定に一致するかを検証します。
決定の実行：上書き禁止ルールは、プレフィックス、サフィックス、ユーザー ID などのすべてのフィルター条件が一致した場合にのみトリガーされます。その後、システムは `FileAlreadyExists` を返します。
デフォルトの動作：一致する保護ルールがない場合、ファイルの上書き操作は続行が許可されます。
特定のファイルタイプの保護
本番環境の設定ファイルやログファイルを保護できます。これにより、特定のユーザーが誤ってそれらを上書きするのを防ぎます。
[バケット] ページで、対象のバケット名をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
新たに上書き禁止ルールを追加 をクリックし、次のパラメーターを設定します。
ルール ID：ID を入力するか、システムに生成させます。
ファイル名のプレフィックス：保護するフォルダのパスを入力します。例：
production/configs/。ファイル名のサフィックス：ファイル名拡張子を入力します。例：
.json。認可ユーザー：上書きを制限する RAM ユーザー、ロール、またはその他のアカウントを指定します。
[OK] をクリックしてルールを作成します。
ルールの検証：
制限されたアカウントを使用して、同じ名前のファイルを
production/configs/app.jsonにアップロードしてみます。`FileAlreadyExists` が返されることを確認します。
他のユーザーによるアップロードや、プレフィックスおよびサフィックス条件に一致しないパスへのアップロードは通常どおり続行されます。
グローバル保護ポリシーの設定
重大なビジネスデータがどのユーザーによっても誤って処理されるのを防ぐことができます。
[バケット] ページで、対象のバケット名をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
新たに上書き禁止ルールを追加 をクリックし、次のパラメーターを設定します。
ルール ID：ID を入力するか、システムに生成させます。
ファイル名のプレフィックス：
critical-data/ファイル名のサフィックス：パス内のすべてのファイルを保護するために、このフィールドは空のままにします。
認可ユーザー：すべてのアカウント (*)
[OK] をクリックしてルールを作成します。
グローバル保護の検証：
任意のアカウントを使用して
critical-data/database.sqlを上書きしてみます。`FileAlreadyExists` が返されることを確認します。これは、グローバル保護が有効であることを示します。
public-data/パスにアップロードされたファイルは通常どおり上書きできます。
マッチングルール
ルール数：1 つのバケットでサポートされるルールの最大数は 100 です。
文字長：プレフィックスとサフィックスの両方の最大長は 1,023 文字です。
プレフィックスとサフィックスの一致：完全な文字列一致のみがサポートされています。正規表現とワイルドカード文字はサポートされていません。
logs/のような入力はリテラル文字列として扱われます。プレフィックス一致：
logs/はlogs/app.logに一致しますが、dev-logs/app.logには一致しません。サフィックス一致：
.txtはreadme.txtに一致しますが、readme.TXTやreadme.txt.bakには一致しません。認可ユーザーの一致：アスタリスク (*) ワイルドカード文字がサポートされています。詳細については、「バケットポリシーの例」のプリンシパル設定をご参照ください。
条件の組み合わせ：上書き禁止ルールは、プレフィックス、サフィックス、認可ユーザーなど、ルール内のすべての条件が満たされた場合にのみトリガーされます。
ルール ID：このパラメーターはオプションです。空のままにすると、汎用一意識別子 (UUID) が自動的に生成されます。ID を指定する場合、その ID はバケット内で一意である必要があります。
よくある質問
[認可ユーザー] を空に設定した後、バケットの所有者である私でさえファイルを上書きできなくなりました。どうすればよいですか？
これは想定される動作です。[認可ユーザー] フィールドを空のままにすると、ルールがバケット作成者や Alibaba Cloud アカウントを含むすべてのユーザーに適用されることを意味します。上書き権限を復元するには、次のいずれかの操作を実行できます。
コンソールでルールを削除します。
ルールのプレフィックスまたはサフィックス条件を変更して、保護範囲を狭めます。
[認可ユーザー] フィールドに特定のユーザーを設定して、それらのユーザーのみの上書き操作を制限します。
`logs` フォルダ内のすべての `.txt` ファイルに一致させるためにプレフィックスを logs/*.txt に設定しましたが、機能しません。なぜですか？
OSS のプレフィックスおよびサフィックス一致では、ワイルドカード文字はサポートされていません。* 文字はリテラル文字として扱われます。システムは、logs/*.txt という正確な名前のファイルと一致させようとします。これを正しく設定する方法は次のとおりです。
プレフィックスを
logs/に設定します。サフィックスを
.txtに設定します。
この設定は、logs/ フォルダ内の .txt で終わるすべてのファイルに一致します。
プレフィックスとサフィックスの両方を空にした場合はどうなりますか？
プレフィックスとサフィックスの両方を空のままにすると、ルールはバケット全体に適用されます。これは次のことを意味します。
[認可ユーザー] フィールドも空のままにすると、すべてのユーザーがバケット内のどのファイルも上書きすることが禁止されます。
[認可ユーザー] フィールドに特定のユーザーが指定されている場合、それらのユーザーのみがバケット内のファイルを上書きすることが禁止されます。