説明
OSS のアップロードや設定変更をすべての主体に許可すると、適切なアクセス制限がない場合、信頼していない主体もデータを保存したり設定を変更したりできるおそれがあります。実際の権限は、操作、対象リソース、条件、明示的な拒否、公開アクセスのブロックによって決まります。
PutObject はオブジェクトをアップロードする操作で、ほかの Put 操作には設定を変更するものもあります。制約は操作ごとに異なります。例えば PutObjectACL は、対象オブジェクトへの読み取りと書き込み権限を持つバケット所有者だけが呼び出せるため、主体をワイルドカードにしても誰でも既存オブジェクトの ACL を変更できるわけではありません。
想定される影響
- アップロード権限が不要な主体にその権限が実際に与えられると、不要なオブジェクトが追加され、保存費用が増える可能性があります。
- 既存のオブジェクト名への書き込みが許可されると、アプリケーションが読む内容が変わる可能性があります。バージョニングが有効でも現在のバージョンは変わり得ますが、それは以前のバージョンの削除を意味しません。
- 設定変更の権限が実際に適用されると、アクセス制御などの運用設定が変わる可能性があります。操作ごとの所有権と権限の制約を確認する必要があります。
対処方法
- アップロードと設定変更に必要な主体と操作を制限し、操作に応じてバケットまたはオブジェクトのリソースのパスを指定してください。読み取りを公開するために、書き込みまで公開しないでください。
- 条件、明示的な拒否、ACL、公開アクセスのブロックを併せて確認し、各APIの所有権と権限の要件も確認してください。
privateのACLだけですべてのポリシーによるアクセスを拒否できるわけではありません。 - インラインの
policyはプロバイダー 1.220.0 以降で非推奨です。新しい構成はalicloud_oss_bucket_policyで管理し、既存ポリシーの移行後に必要なアップロードとアクセス制限を検証してください。
例
以下はプロバイダー 1.293.0 で利用できる従来のインライン形式の例です。使用可能な一意のバケット名を選び、オブジェクトのパスも合わせて変更してください。どちらもすべての主体に権限を指定しているため、そのまま本番環境に適用しないでください。
アップロードとオブジェクト ACL の権限
hcl
resource "alicloud_oss_bucket" "bucket-policy4" {
bucket = "bucket-4-policy"
acl = "private"
policy = <<POLICY
{"Statement": [
{
"Action": [
"oss:PutObjectAcl", "oss:PutObject"
],
"Effect": "Allow",
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:*:bucket-4-policy/*"
]
}
],
"Version":"1"}
POLICY
}
アップロードを必要なアカウントやロールに限定し、オブジェクトのパスも必要な範囲に絞ってください。oss:PutObjectAcl には別途所有権と権限の要件があり、アップロードが必要というだけで併せて付与すべき権限ではありません。
マルチパートアップロードの中止権限
hcl
resource "alicloud_oss_bucket" "bucket-policy1" {
bucket = "bucket-1-policy"
acl = "private"
policy = <<POLICY
{"Statement": [
{
"Action": [
"oss:AbortMultipartUpload"
],
"Effect": "Allow",
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:*:bucket-1-policy/*"
]
}
],
"Version":"1"}
POLICY
}
oss:AbortMultipartUpload は、有効なアップロード ID と必要な権限があれば、マルチパートアップロードを中止し、アップロード済みのパートを削除します。完成したオブジェクトは削除しませんが、アップロードを中断させる操作なので、必要な運用担当者やサービスだけに許可してください。