Zagadnienia dotyczące zabezpieczeń warunków przypisywania ról platformy Azure w usłudze Azure Blob Storage
Aby w pełni zabezpieczyć zasoby przy użyciu kontroli dostępu opartej na atrybutach platformy Azure (Azure ABAC), należy również chronić atrybuty używane w warunkach przypisywania ról platformy Azure. Jeśli na przykład warunek jest oparty na ścieżce pliku, należy pamiętać, że dostęp może zostać naruszony, jeśli podmiot zabezpieczeń ma nieograniczone uprawnienia do zmiany nazwy ścieżki pliku.
W tym artykule opisano zagadnienia dotyczące zabezpieczeń, które należy uwzględnić w warunkach przypisywania ról.
Ważne
Kontrola dostępu oparta na atrybutach platformy Azure (Azure ABAC) jest ogólnie dostępna do kontrolowania dostępu do usług Azure Blob Storage, Azure Data Lake Storage Gen2 i Azure Queues przy użyciu requestatrybutów , resource, environmenti principal zarówno w warstwach wydajności konta magazynu w warstwie Standardowa, jak i Premium Storage. Obecnie atrybut zasobu metadanych kontenera i lista obiektów blob dołączania atrybutu żądania są dostępne w wersji zapoznawczej. Aby uzyskać pełne informacje o stanie funkcji ABAC dla usługi Azure Storage, zobacz Stan funkcji warunku w usłudze Azure Storage.
Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.
Korzystanie z innych mechanizmów autoryzacji
Warunki przypisywania ról są oceniane tylko w przypadku używania kontroli dostępu opartej na rolach platformy Azure na potrzeby autoryzacji. Te warunki można pominąć, jeśli zezwolisz na dostęp przy użyciu alternatywnych metod autoryzacji:
- Autoryzacja klucza współdzielonego
- Sygnatura dostępu współdzielonego konta (SAS)
- Sygnatura dostępu współdzielonego usługi.
Podobnie warunki nie są oceniane, gdy dostęp jest udzielany przy użyciu list kontroli dostępu (ACL) na kontach magazynu z hierarchiczną przestrzenią nazw (HNS).
Możesz zapobiec autoryzacji sygnatury dostępu współdzielonego, sygnatury dostępu współdzielonego na poziomie konta i sygnatury dostępu współdzielonego, wyłączając autoryzację klucza współużytkowanego dla konta magazynu. Ponieważ sygnatura dostępu współdzielonego delegowania użytkowników zależy od kontroli dostępu opartej na rolach platformy Azure, warunki przypisywania ról są oceniane podczas korzystania z tej metody autoryzacji.
Zabezpieczanie atrybutów magazynu używanych w warunkach
Ścieżka obiektu blob
W przypadku używania ścieżki obiektu blob jako atrybutu @Resource warunku należy również uniemożliwić użytkownikom zmianę nazwy obiektu blob w celu uzyskania dostępu do pliku podczas korzystania z kont, które mają hierarchiczną przestrzeń nazw. Jeśli na przykład chcesz utworzyć warunek na podstawie ścieżki obiektu blob, należy również ograniczyć dostęp użytkownika do następujących akcji:
| Akcja | opis |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action |
Ta akcja umożliwia klientom zmianę nazwy pliku przy użyciu interfejsu API tworzenia ścieżki. |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action |
Ta akcja umożliwia dostęp do różnych operacji systemu plików i ścieżek. |
Tagi indeksu obiektów blob
Tagi indeksu obiektów blob są używane jako atrybuty wolnego formularza dla warunków w magazynie. Jeśli tworzysz jakiekolwiek warunki dostępu przy użyciu tych tagów, musisz również chronić same tagi. W szczególności funkcja Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction umożliwia użytkownikom modyfikowanie tagów w obiekcie magazynu. Możesz ograniczyć tę akcję, aby uniemożliwić użytkownikom manipulowanie kluczem tagu lub wartością w celu uzyskania dostępu do nieautoryzowanych obiektów.
Ponadto jeśli tagi indeksu obiektów blob są używane w warunkach, dane mogą być podatne na zagrożenia, jeśli dane i skojarzone tagi indeksu są aktualizowane w oddzielnych operacjach. Można użyć @Request warunków w operacjach zapisu obiektów blob, aby wymagać ustawienia tagów indeksu w tej samej operacji aktualizacji. Takie podejście może pomóc zabezpieczyć dane od chwili ich zapisu w magazynie.
Tagi skopiowanych obiektów blob
Domyślnie tagi indeksu obiektów blob nie są kopiowane ze źródłowego obiektu blob do miejsca docelowego, gdy używasz interfejsu API kopiowania obiektów blob ani żadnego z jego wariantów. Aby zachować zakres dostępu do obiektu blob podczas kopiowania, należy również skopiować tagi.
Tagi dotyczące migawek
Nie można modyfikować tagów migawek obiektów blob. W związku z tym przed wykonaniem migawki należy zaktualizować tagi w obiekcie blob. Jeśli zmodyfikujesz tagi w podstawowym obiekcie blob, tagi w jego migawki będą nadal miały poprzednią wartość.
Jeśli tag w podstawowym obiekcie blob zostanie zmodyfikowany po utworzeniu migawki, zakres dostępu może być inny dla podstawowego obiektu blob i migawki.
Tagi w wersjach obiektów blob
Tagi indeksu obiektów blob nie są kopiowane po utworzeniu wersji obiektu blob za pomocą interfejsów API Put Blob, Put Block List lub Copy Blob . Tagi można określić za pomocą nagłówka dla tych interfejsów API.
Tagi można ustawiać indywidualnie w bieżącym podstawowym obiekcie blob i w każdej wersji obiektu blob. Podczas modyfikowania tagów w podstawowym obiekcie blob tagi w poprzednich wersjach nie są aktualizowane. Jeśli chcesz zmienić zakres dostępu dla obiektu blob i wszystkich jego wersji przy użyciu tagów, musisz zaktualizować tagi w każdej wersji.
Wykonywanie zapytań i filtrowanie ograniczeń dla wersji i migawek
Jeśli używasz tagów do wykonywania zapytań o obiekty blob i filtrowania ich w kontenerze, w odpowiedzi są uwzględniane tylko podstawowe obiekty blob. Wersje obiektów blob lub migawki z żądanymi kluczami i wartościami nie są uwzględniane.
Uprawnienia i role
Jeśli używasz warunków przypisywania ról dla ról wbudowanych platformy Azure, należy dokładnie przejrzeć wszystkie uprawnienia, które rola przyznaje podmiotowi zabezpieczeń.
Dziedziczone przypisania ról
Przypisania ról można skonfigurować dla grupy zarządzania, subskrypcji, grupy zasobów, konta magazynu lub kontenera i są dziedziczone na każdym poziomie w podanej kolejności. Kontrola dostępu oparta na rolach platformy Azure ma model addytywne, więc skuteczne uprawnienia są sumą przypisań ról na każdym poziomie. Jeśli podmiot zabezpieczeń ma takie same uprawnienia przypisane do nich za pośrednictwem wielu przypisań ról, dostęp do operacji przy użyciu tego uprawnienia jest oceniany oddzielnie dla każdego przypisania na każdym poziomie.
Ponieważ warunki są implementowane jako warunki przypisania ról, każde bezwarunkowe przypisanie roli może umożliwić użytkownikom obejście warunku. Załóżmy, że przypiszesz użytkownikowi rolę Współautor danych obiektu blob usługi Storage dla konta magazynu i subskrypcji, ale dodasz warunek tylko do przypisania konta magazynu. W rezultacie użytkownik ma nieograniczony dostęp do konta magazynu za pośrednictwem przypisania roli na poziomie subskrypcji.
W związku z tym należy konsekwentnie stosować warunki dla wszystkich przypisań ról w hierarchii zasobów.
Inne uwagi
Operacje warunku zapisujące obiekty blob
Wiele operacji, które zapisują obiekty blob, wymaga Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write uprawnienia lub Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action . Wbudowane role, takie jak Właściciel danych obiektu blob usługi Storage i Współautor danych obiektu blob usługi Storage, udzielają obu uprawnień podmiotowi zabezpieczeń.
Podczas definiowania warunku przypisania roli dla tych ról należy użyć identycznych warunków dla obu tych uprawnień, aby zapewnić spójne ograniczenia dostępu dla operacji zapisu.
Zachowanie kopiowania obiektu blob i kopiowania obiektu blob z adresu URL
W przypadku operacji @Request kopiowania obiektów blob i kopiowania obiektu blob z adresu URL warunki używające ścieżki obiektu blob jako atrybutu Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write akcji i jego podoperacji są oceniane tylko dla docelowego obiektu blob.
W przypadku warunków w źródłowym obiekcie blob @Resource są oceniane warunki Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read akcji.