Details zu Object Storage und Archive Storage

In diesem Thema werden Details zum Schreiben von Policys beschrieben, die den Zugriff auf Archive Storage und Object Storage kontrollieren.

Tipp

Das Feature für Objektlebenszyklus-Policys erfordert, dass Sie dem Object Storage-Service Berechtigungen zum Archivieren und Löschen von Objekten in Ihrem Namen erteilen. Weitere Informationen finden Sie unter Objektlebenszyklus-Policys verwenden.

Ressourcentypen

Individuelle Ressourcentypen

objectstorage-namespaces

buckets

objects

Aggregierter Ressourcentyp

object-family

Eine Policy, die <verb> object-family verwendet, entspricht dem Schreiben einer Policy mit einer separaten <verb> <individual resource-type>-Anweisung für die einzelnen individuellen Ressourcentypen.

Details zu den von den einzelnen Verben abgedeckten API-Vorgängen für jeden Ressourcentyp in object-family finden Sie in der Tabelle unter Details für Kombinationen aus Verb + Ressourcentyp.

Unterstützte Variablen

Object Storage unterstützt alle allgemeinen Variablen (siehe Allgemeine Variablen für alle Anforderungen) sowie die hier aufgelisteten Variablen:


Vorgänge für diesen Ressourcentyp...	Diese Variable kann verwendet werden	Variablentyp	Kommentare
`buckets` und `objects`	`target.bucket.name`	Zeichenfolge und Muster	Mit dieser Variablen können Sie den Zugriff auf einen bestimmten Bucket kontrollieren. Wichtig: Beim Bedingungsabgleich wird die Groß-/Kleinschreibung nicht beachtet. Wenn Sie einen Bucket mit dem Namen "BucketA" und einen Bucket mit dem Namen "bucketA" haben, gilt die Bedingung `where target.bucket.name="BucketA"` für beide. Um potenzielle Probleme mit Ressourcennamen in der Policy zu vermeiden, geben Sie Ihren Ressourcen eindeutige Namen.
`buckets` und `objects`	`target.bucket.tag.<TagNamespace>.<TagKeyDefinition>`	Zeichenfolge	Mit dieser Variablen können Sie den Zugriff auf die Buckets kontrollieren, die das spezifische Tag aufweisen. Siehe Schreiben von Objekten in Object Storage-Buckets durch Benutzer zulassen. Wichtig: Sie können diese Variable nicht für `CreateBucket`-Vorgänge und Vorgänge verwenden, die mehrere Buckets wie `ListBucket` umfassen.
`objects`	`target.object.name`	Zeichenfolge und Muster	Mit dieser Variablen können Sie den Zugriff auf ein bestimmtes Objekt oder Objektmuster kontrollieren.

Hinweis

Die Variablen request.ipv4.ipaddress und request.vcn.id sind veraltet. Anstatt diese Variablen zu verwenden, erstellen Sie eine Netzwerkquelle, um entweder einen IP-Adressbereich oder eine bestimmte VCN-ID anzugeben. Anschließend können Sie die Netzwerkquelle in Ihrer Policy verwenden, um den Zugriff auf diejenigen Anforderungen zu beschränken, die von den zulässigen Netzwerken stammen. Weitere Informationen finden Sie unter Netzwerkquellen - Überblick.

Details für Kombinationen aus Verb + Ressourcentyp

In den folgenden Tabellen werden die Berechtigungen und API-Vorgänge angezeigt, die von jedem Verb abgedeckt werden. Die Zugriffsebene ist kumulativ: inspect > read > use > manage. Beispiel: Eine Gruppe, die eine Ressource verwenden kann, kann diese Ressource auch prüfen und lesen. Ein Pluszeichen (+) in einer Tabellenzelle gibt einen inkrementellen Zugriff im Vergleich zur direkt darüber liegenden Zelle an, während "keine zusätzlichen" keinen inkrementellen Zugriff angibt.

Für Ressourcentypen der Familie "object-family"

objectstorage-namespaces


Verben	Berechtigungen	Vollständig abgedeckte APIs	Teilweise abgedeckte APIs
read	OBJECTSTORAGE_NAMESPACE_READ	`GetNamespace`	kein Wert
use	OBJECTSTORAGE_NAMESPACE_READ	`GetNamespace`	kein Wert
manage	OBJECTSTORAGE_NAMESPACE_READ OBJECTSTORAGE_NAMESPACE_UPDATE	`GetNamespace` mit optionalem Parameter `compartmentId` `GetNamespaceMetadata` `UpdateNamespaceMetadata`	kein Wert

buckets


Verben	Berechtigungen	Vollständig abgedeckte APIs	Teilweise abgedeckte APIs
inspect	BUCKET_INSPECT	`HeadBucket` `ListBuckets`	kein Wert
read	INSPECT + BUCKET_READ	INSPECT + `GetBucket` `ListMultipartUploads` `GetObjectLifecyclePolicy` `GetRetentionRule` `ListRetentionRules` `GetReplicationPolicy` `ListReplicationPolicies` `ListReplicationSources`	kein Wert
use	READ + BUCKET_UPDATE	READ + `UpdateBucket` `DeleteObjectLifecyclePolicy` `ReencryptBucket`	`PutObjectLifecyclePolicy`
manage	USE + BUCKET_CREATE BUCKET_DELETE PAR_MANAGE RETENTION_RULE_MANAGE RETENTION_RULE_LOCK (wenn optionale Regelsperre verwendet wird)	USE + `CreateBucket` `DeleteBucket` `CreatePreauthenticatedRequest` `GetPreauthenticatedRequest` `ListPreauthenticatedRequest` `DeletePreauthenticatedRequest` `CreateRetentionRule` `UpdateRetentionRule` `DeleteRetentionRule`	`CreateReplicationPolicy`, `DeleteReplicationPolicy`, `MakeBucketWritable` (diese Vorgänge benötigen auch `manage objects`)

objects


Verben	Berechtigungen	Vollständig abgedeckte APIs	Teilweise abgedeckte APIs
inspect	OBJECT_INSPECT	`HeadObject` `ListObjects` `ListMultipartUploadParts`	kein Wert
read	INSPECT + OBJECT_READ	INSPECT + `GetObject`	kein Wert
use	READ + OBJECT_OVERWRITE	READ + `ReencryptObject`	READ + `PutObject` (mit USE kann `PutObject` vorhandene Objekte überschreiben, für das Erstellen eines neuen Objekts ist jedoch auch OBJECT_CREATE erforderlich) `CreateMultipartUpload`, `UploadPart`, `CommitMultipartUpload` (diese Vorgänge benötigen auch `manage objects`)
manage	USE + OBJECT_CREATE OBJECT_DELETE OBJECT_VERSION_DELETE OBJECT_RESTORE OBJECT_UPDATE_TIER	USE + `CreateObject` `RenameObject` `RestoreObject` `DeleteObject` `DeleteObjectVersion` `UpdateObjectStorageTier` `CreateMultipartUpload` `UploadPart` `CommitMultipartUpload` `AbortMultipartUpload`	`PutObjectLifecyclePolicy` (benötigt auch `manage objects`) `CreateReplicationPolicy`, `DeleteReplicationPolicy`, `MakeBucketWritable` (diese Vorgänge benötigen auch `manage buckets`)

Für jeden API-Vorgang erforderliche Berechtigungen

In der folgenden Tabelle werden die API-Vorgänge in einer logischen Reihenfolge nach Ressourcentyp gruppiert aufgeführt.

Informationen zu Berechtigungen finden Sie unter Berechtigungen.


API-Vorgang	Erforderliche Berechtigungen für den Vorgang
`GetNamespace`	Die API erfordert keine Berechtigungen und gibt den Namespace des Aufrufers zurück. Mit der API können Sie Ihre Zugangsdaten validieren. Wenn Sie den optionalen Parameter `compartmentId` verwenden, ist die Berechtigung "OBJECTSTORAGE_NAMESPACE_READ" erforderlich. Verwenden Sie den Parameter `compartmentId`, um den Namespace für einen Drittanbietermandanten zu suchen.
`GetNamespaceMetadata`	OBJECTSTORAGE_NAMESPACE_READ
`UpdateNamespaceMetadata`	OBJECTSTORAGE_NAMESPACE_UPDATE
`CreateBucket`	BUCKET_CREATE Wenn die KMS-Schlüssel-ID für den Vorgang angegeben wird, sind die folgenden zusätzlichen Berechtigungen erforderlich: KEY_ASSOCIATE Das Objektspeicher-<location>-Betreff muss außerdem Folgendes enthalten: KEY_ENCRYPT, KEY_DECRYPT, KEY_READ.
`UpdateBucket`	BUCKET_UPDATE Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt auch KEY_ENCRYPT und KEY_DECRYPT aufweisen.
`GetBucket`	BUCKET_READ Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt KEY_DECRYPT aufweisen.
`HeadBucket`	BUCKET_INSPECT Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt KEY_DECRYPT aufweisen.
`ListBuckets`	BUCKET_INSPECT
`DeleteBucket`	BUCKET_DELETE
`ReencryptBucket`	BUCKET_UPDATE Das Objektspeicher-<location>-Betreff muss außerdem Folgendes enthalten: KEY_ENCRYPT und KEY_DECRYPT.
`PutObject`	Die erforderliche Berechtigung hängt davon ab, ob das Objekt bereits im Bucket vorhanden ist: OBJECT_CREATE ist erforderlich, wenn ein Objekt mit diesem Namen noch nicht im Bucket vorhanden ist. "OBJECT_OVERWRITE" ist erforderlich, wenn ein Objekt mit diesem Namen bereits im Bucket vorhanden ist. Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt KEY_ENCRYPT aufweisen.
`RenameObject`	OBJECT_CREATE und OBJECT_OVERWRITE
`GetObject`	OBJECT_READ Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt KEY_DECRYPT aufweisen.
`HeadObject`	OBJECT_READ oder OBJECT_INSPECT Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt KEY_DECRYPT aufweisen.
`DeleteObject`	OBJECT_DELETE
`DeleteObjectVersion`	OBJECT_VERSION_DELETE
`ListObjects`	OBJECT_INSPECT
`ListObjectVersions`	OBJECT_INSPECT
`ReencryptObject`	OBJECT_READ, OBJECT_OVERWRITE Für einen vom Kunden verwalteten verschlüsselten Schlüssel-Bucket sind die folgenden Berechtigungen erforderlich: KEY_ASSOCIATE Darüber hinaus muss das Objektspeicher-<location>-Subjekt KEY_ENCRYPT, KEY_DECRYPT und KEY_READ enthalten.
`RestoreObjects`	OBJECT_RESTORE
`UpdateObjectStorageTier`	OBJECT_UPDATE_TIER
`CreateMultipartUpload`	OBJECT_CREATE und OBJECT_OVERWRITE Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt KEY_ENCRYPT aufweisen.
`UploadPart`	OBJECT_CREATE und OBJECT_OVERWRITE Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt KEY_ENCRYPT aufweisen.
`CommitMultipartUpload`	BUCKET_READ, OBJECT_CREATE, OBJECT_READ und OBJECT_OVERWRITE
`ListMultipartUploadParts`	OBJECT_INSPECT
`ListMultipartUploads`	BUCKET_READ
`AbortMultipartUpload`	OBJECT_DELETE
`CreatePreauthenticatedRequest`	PAR_MANAGE
`GetPreauthenticatedRequest`	PAR_MANAGE oder BUCKET_READ
`ListPreauthenticatedRequests`	PAR_MANAGE oder BUCKET_READ
`DeletePreauthenticatedRequest`	PAR_MANAGE
`PutObjectLifecyclePolicy`	BUCKET_UPDATE, OBJECT_CREATE und OBJECT_DELETE Darüber hinaus muss das Objektspeicher-<location>-Thema auch Folgendes enthalten: BUCKET_INSPECT, BUCKET_READ, OBJECT_INSPECT. Wenn es sich bei dem Bucket, für den die Lebenszyklus-Policy gilt, um einen vom Kunden verwalteten verschlüsselten Schlüssel-Bucket handelt, muss das Objektspeicher-<location>-Subjekt auch Folgendes aufweisen: KEY_ENCRYPT und KEY_DECRYPT. Wenn der Vorgang `PutObjectLifeCyclePolicy` auch die Objektebene aktualisiert, z.B. von standardmäßig auf INFREQUENT_ACCESS, müssen dem Benutzer und dem Objektspeicher-<location>-Subjekt die Berechtigung OBJECT_UPDATE_TIER erteilt werden.
`GetObjectLifecyclePolicy`	BUCKET_READ Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt KEY_DECRYPT aufweisen.
`DeleteObjectLifecyclePolicy`	BUCKET_UPDATE Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt auch KEY_ENCRYPT und KEY_DECRYPT aufweisen.
`CreateRetentionRule`	BUCKET_UPDATE und RETENTION_RULE_MANAGE (und RETENTION_RULE_LOCK) Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt auch KEY_ENCRYPT und KEY_DECRYPT aufweisen.
`GetRetentionRule`	BUCKET_READ
`ListRetentionRule`	BUCKET_READ
`UpdateRetentionRule`	BUCKET_UPDATE und RETENTION_RULE_MANAGE (und RETENTION_RULE_LOCK) Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt auch KEY_ENCRYPT und KEY_DECRYPT aufweisen.
`DeleteRetentionRule`	BUCKET_UPDATE und RETENTION_RULE_MANAGE Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt auch KEY_ENCRYPT und KEY_DECRYPT aufweisen.
`CopyObjectRequest`	Die erforderliche Berechtigung OBJECT_READ und der zweite Benutzer hängt davon ab, ob das Objekt bereits im Bucket vorhanden ist: OBJECT_CREATE ist erforderlich, wenn ein Objekt mit diesem Namen nicht bereits im Bucket vorhanden ist. "OBJECT_OVERWRITE" ist erforderlich, wenn ein Objekt mit diesem Namen bereits im Bucket vorhanden ist. Zusätzlich benötigt das Objektspeicher-<location>-Betreff OBJECT_READ. Bei einem vom Kunden verwalteten verschlüsselten Schlüssel-Bucket muss das objectstorage-<location>-Subjekt auch KEY_ENCRYPT, KEY_DECRYPT aufweisen.
`GetWorkRequest`	OBJECT_READ
`ListWorkRequests`	OBJECT_INSPECT
`CancelWorkRequest`	OBJECT_DELETE
`CreateReplicationPolicy`	OBJECT_READ, OBJECT_CREATE, OBJECT_OVERWRITE, OBJECT_INSPECT, OBJECT_DELETE, OBJECT_RESTORE, BUCKET_READ und BUCKET_UPDATE Das Objektspeicher-<location>-Betreff muss dieselben Berechtigungen wie der Benutzer haben.
`GetReplicationPolicy`	BUCKET_READ
`DeleteReplicationPolicy`	OBJECT_READ, OBJECT_CREATE, OBJECT_OVERWRITE, OBJECT_INSPECT, OBJECT_DELETE, OBJECT_RESTORE, BUCKET_READ und BUCKET_UPDATE
`ListReplicationPolicies`	BUCKET_READ
`ListReplicationSources`	BUCKET_READ
`MakeBucketWritable`	OBJECT_READ, OBJECT_CREATE, OBJECT_OVERWRITE, OBJECT_INSPECT, OBJECT_DELETE, BUCKET_READ und BUCKET_UPDATE

Oracle Cloud Infrastructure - Dokumentation