上書き防止ルールは、OSS バケット内のファイルが初回アップロード後に上書きされるのを保護します。ルールは、ファイルパス、ファイル拡張子、およびユーザー ID によってスコープが設定されるため、バケット全体をロックダウンすることなく、ターゲットを絞った保護を適用できます。
動作と制限事項
ルールを設定する前に、この機能が何に対して保護し、何に対して保護しないかを理解してください。
| シナリオ | 動作 |
|---|---|
| 初回同時アップロード | 複数のクライアントが同じファイルを同時に初めてアップロードする場合、ルールが一致しても、いずれかのバージョンが正常に書き込まれます。ファイルが存在した後、その後の上書きはブロックされます。 |
| 内部 OSS 操作 | ライフサイクル トランジションとクロスリージョンレプリケーション (CRR) はブロックされません。これらのシステムが開始する操作は、コア機能を機能させるために上書き防止ルールをバイパスします。 |
| バージョン管理 | バケットのバージョン管理が有効または一時停止されている場合、ルールは効果がありません。 |
仕組み
OSS が既存のファイルに対する書き込みリクエストを受信すると、作成された順序で設定されたルールに対してリクエストを評価します。
パスの一致 — ファイルパスがルールのプレフィックスとサフィックスの条件に一致するかどうかを確認します。
ID の一致 — リクエスターが許可されるユーザー設定に一致するかどうかを確認します。
決定 — すべての条件が一致する場合、OSS は操作をブロックし、
FileAlreadyExistsエラーを返します。ルールが一致しない場合、上書きは許可されます。
ルール内のすべての条件は同時に満たされる必要があります。部分一致ではルールはトリガーされません。
特定のファイルタイプを保護する
プロダクションフォルダー内の構成ファイルとログファイルが特定のユーザーによって上書きされるのを保護します。
前提条件
開始する前に、以下があることを確認してください。
OSS バケット
バケット設定を管理するのに十分な権限を持つ OSS コンソールへのアクセス
操作手順
[バケット] ページで、対象のバケットの名前をクリックします。
左側のナビゲーションウィンドウで、Data Management > ファイルの上書き禁止 を選択します。
、[上書き書き込みを禁止する新しいルール] をクリックし、次のパラメーターを設定します。
パラメーター 説明 例 ルール ID オプション。空白のままにすると UUID が自動生成されます。または、一意の ID を入力します。 protect-configs-jsonファイル名プレフィックス 保護するフォルダーパス。 production/configs/ファイル名拡張子 保護するファイル拡張子。空白のままにすると、パス内のすべてのファイルタイプが保護されます。 .json許可されるユーザー ルールが制限する RAM ユーザー、RAM ロール、またはその他のアカウント。 *を使用してすべてのユーザーを制限します。RAM ユーザー ARN [OK] をクリックします。
ルールの検証
制限されたアカウントを使用して、
production/configs/app.jsonに同じ名前のファイルをアップロードします。FileAlreadyExistsエラーが返されることを確認します。他のユーザーがファイルを正常にアップロードできること、およびプレフィックスとサフィックスの条件外のパスへのアップロードが正常に成功することを確認します。
グローバル保護ポリシーを設定する
重要なパス内のすべてのファイルが任意のユーザーによって上書きされるのを保護します。
操作手順
[バケット] ページで、対象のバケットの名前をクリックします。
左側のナビゲーションウィンドウで、Data Management > ファイルの上書きを禁止 を選択します。
「上書き書き込みを禁止する新しいルールの追加」をクリックし、以下のパラメーターを設定します。
パラメーター 値 ルール ID オプション。空白のままにすると自動生成されます。 ファイル名プレフィックス critical-data/ファイル名拡張子 空白のままにすると、すべてのファイルタイプが保護されます。 許可されるユーザー *(すべてのユーザー)[OK] をクリックします。
ルールの検証
任意のアカウントを使用して、
critical-data/database.sqlの上書きを試行します。FileAlreadyExistsエラーが返されることを確認します。public-data/内のファイルが引き続き正常に上書きできることを確認します。
ルールの一致
| ルール | 詳細 |
|---|---|
| バケットあたりの最大ルール数 | 100 |
| プレフィックスとサフィックスの最大長 | それぞれ 1,023 文字 |
| 一致タイプ | 完全一致のみ。正規表現とワイルドカードは、プレフィックスとサフィックスのフィールドではサポートされていません。 |
| プレフィックスの一致 | logs/ は logs/app.log に一致しますが、dev-logs/app.log には一致しません。 |
| サフィックスの一致 | .txt は readme.txt に一致しますが、readme.TXT や readme.txt.bak には一致しません。 |
| 許可されるユーザー | * ワイルドカードをサポートします。詳細については、「バケットポリシーの一般的な例」をご参照ください。 |
| ルール ID | オプション。空白のままにすると UUID が自動生成されます。バケット内で一意である必要があります。 |
よくある質問
許可されるユーザーを空白のままにしたため、自分でもファイルを上書きできません。アクセスを復元するにはどうすればよいですか？
許可されるユーザーフィールドを空白のままにすると、バケット所有者と root Alibaba Cloud アカウントを含むすべてのユーザーにルールが適用されます。上書きアクセスを復元するには、次のいずれかを実行します。
コンソールでルールを削除します。
より具体的なプレフィックスまたはサフィックスを設定して、範囲を狭めます。
許可されるユーザーを特定のユーザーに設定して、制限がそれらのユーザーにのみ適用されるようにします。
logs フォルダ内のすべての .txt ファイルに一致するようにプレフィックスを logs/*.txt に設定しましたが、うまくいかないのはなぜですか？
OSS のプレフィックスの一致では、* はワイルドカードではなく、リテラル文字として扱われます。システムは、正確に logs/*.txt という名前のファイルを探します。logs/ フォルダー内のすべての .txt ファイルに一致させるには、ルールを次のように設定します。
ファイル名プレフィックス：
logs/ファイル名の拡張子：
.txt
プレフィックスとサフィックスの両方を空白のままにした場合はどうなりますか？
ルールはバケット全体に適用されます。空の許可されるユーザーフィールドと組み合わせると、バケット所有者を含むすべてのユーザーがいずれのファイルの上書きもブロックされます。許可されるユーザーが特定のユーザーを指定する場合、それらのユーザーのみが制限されます。