BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki

Baza wiedzy











[Artykuł] Administracja oparta o role w System Center Configuration Manager 2012

08-08-2012 06:00 | Mariusz Zarzycki
Model bezpieczeństwa oparty o klasy i instancje znany w SMS oraz SCCM 2007 uniemożliwiał przypisywanie użytkownikom odpowiednich uprawnień w sposób intuicyjny, a co najważniejsze często uprawnienia nadawane w ten sposób był zbyt obszerne w stosunku do rzeczywistych potrzeb danego użytkownika. W SCCM 2012 całkowicie zmienione podejście do ww. kwestii nadawania uprawień. Tak jak w większości produktów Microsoft od roku 2008, tak i tutaj w końcu wprowadzono zarządzanie, nadawanie uprawnień w oparciu o role tzw. RBAC (Role Based Access Control).

Kiedy zadamy pytanie administratorom SCCM 2007 co było największym niedociągnięciem SCCM 2007, wielu z nich odpowie - bezpieczeństwo, nadawania uprawnień, ograniczenia użytkowników jeżeli chodzi o uprawnienia.

Model bezpieczeństwa oparty o klasy i instancje znany w SMS oraz SCCM 2007 uniemożliwiał przypisywanie użytkownikom odpowiednich uprawnień w sposób intuicyjny, a co najważniejsze często uprawnienia nadawane w ten sposób były zbyt obszerne w stosunku do rzeczywistych potrzeb danego użytkownika.

W SCCM 2012 całkowicie zmienione podejście do ww. kwestii nadawania uprawień. Tak jak w większości produktów Microsoft od roku 2008, tak i tutaj w końcu wprowadzono zarządzanie, nadawanie uprawnień w oparciu o role tzw. RBAC (Role Based Access Control).

Charakterystyka RBAC

Model RBAC umożliwia administratorowi ConfigMgr 2012 wykorzystywanie:

  • ról bezpieczeństwa (security roles),
  • zakresów bezpieczeństwa (security scopes),
  • kolekcji (collections)

do definiowania zakresów poziomu administracji dla użytkowników, którzy biorą udział w pełnej lub częściowej administracji infrastrukturą SCCMa.

To umożliwia administratorowi nadawanie uprawnień korespondujących z wymaganiami użytkowników, z pewnością, że nie będą oni posiadali podwyższonych lub zbyt małych uprawnień tak jak to występowało w ConfigMgr 2007. Dotyczy to również oczywiście widoczności poszczególnych elementów w konsoli nowego ConfigMgr’a .

Zarządzanie z użyciem struktur płaskich

Jedną z głównych myśli przewodnich w SCCM 2012 jest spłaszczenie struktur w hierarchii organizacji ConfigMgr’a. Obecnie podczas wdrożeń SCCM 2012 wiele przedsiębiorstw może dojść do wniosku, że wystarczającym będzie posiadanie jedynie Primary Site ewentualnie skojarzonego Central Administration Site.

Jednym z głównych powodów, dlaczego w przeszłości w SMS oraz Config Mgr 2007 hierarchia SCCM składała się z wielu sitów była konieczność segregacji ról i zakresów zarządzania administracyjnego. Na przykład jeden Primary Site był dedykowany do zarządzania laptopami i desktopami, a drugi Primary Site dedykowany był dla serwerów. W ten sposób uprawnienia administratorów odpowiedzialnych za poszczególne fragmenty infrastruktury była odseparowane.

RBAC eliminuje konieczność środowiska opartego o wiele sitów. Kolejnym benefitem nowego modelu bezpieczeństwa w SCCM 2012 jest fakt, że jest on tworzony tylko raz w ramach hierarchii, a informacja o nim jest dystrybuowana, jako global replicated data, którą opisałem na itgeeks.pl

Role bezpieczeństwa bardziej szczegółowo

Role bezpieczeństwa w SCCM 2012 używane są do zdefiniowania dostępu do zasobów dla użytkowników biorących udział w częściowej administracji infrastrukturą SCCMa. Mogą być one konfigurowane w taki sposób, aby zapewniać użytkownikom odpowiednio dużo lub odpowiednio mało uprawnień do wymaganego fragmentu administracji ConfigMgr’em.

ConfigMgr 2012 zawiera kilka wbudowanych ról bezpieczeństwa, przygotowanych pod kątem najbardziej typowych zadań administracyjnych. Poniższy rysunek przedstawia fragment konsoli SCCM 2012 z ogólnym opisem dotyczącym każdej z ról.

Rysunek 1. Dostępne role bezpieczeństwa

Poniżej opis wbudowanych ról bezpieczeństwa bardziej szczegółowo.

  • Application Administrator - rola to scala uprawnienia opisane poniżej dla ról Application Deployment manager oraz Application Author. Dodatkowo daje możliwość wykonywania zapytań, przeglądania ustawień situ, zarządzania kolekcjami oraz edytowania ustawień związanych z podobieństwem urządzeń przypisanych do użytkownika
  • Application Author - ta rola umożliwia tworzenie, modyfikowanie, usuwanie aplikacji, zrządzanie pakietami i programami, zarządzanie alertami oraz przeglądanie wiadomości statusowych
  • Application Deployment Manager - ta rola daje możliwość dystrybuowania aplikacji, przegląd listy aplikacji oraz zarządzania innymi elementami powiązanymi z aplikacjami uwzględniając alerty, szablony, pakiety, programy. Dodatkowo członkowie tej grupy mogą przeglądać kolekcje, członkostwo w kolekcji, wiadomości statusowe, zapytanie oraz reguły dostarczania aplikacji warunkowo.
  • Asset Manager - rola ta umożliwia zarządzanie synchronizacją Asset Intelligance Pointem, jego klasami, inwentaryzacją sprzętu oraz oprogramowania oraz zasadami pomiaru wykorzystania oprogramowania w przedsiębiorstwie(Software Metering)
  • Compliance Settings Manager - rola ta umożliwia zarządzanie ustawieniami związanymi z trybem zgodności uwzględniając tworzenie, modyfikowanie, usuwanie poziomów bezpieczeństwa. Rola to umożliwia również przypisywanie opracowanych poziomów bezpieczeństwa do kolekcji, inicjalizowania ewaluacji compliance oraz sposobu zapobiegania i reakcji w stosunku do komputerów noncompliant.
  • Endpoint Protection Manager - rola ta umożliwia zarządzania i monitorowanie politykami bezpieczeństwa Endpoint Protection, dodatkowo umożliwia tworzenie, modyfikowanie, usuwanie polityk Endpoint’s wraz z przypisywaniem ich do kolekcji, tworzenie i modyfikowania alertów oraz statusów Endpoint’a.
  • Full Administrator - ta rola jak sama nazwa wskazuje nadaje uprawnienia do wszystkich obiektów Config Mgr’a 2012. Administrator instalujący SCCM 2012 automatycznie zostaje dodany do tej roli.
  • Infrastructure Administrator - ta rola umożliwia jej członkom tworzenie, usuwanie i modyfikowanie infrastruktury ConfigMgra z uwzględnieniem zadań migracyjnych.
  • Operating System Deployment Manager - jak sama nazwa wskazuje rola ta umożliwia tworzenie obrazów systemów operacyjnych od wdrażania ich do komputerów. Członkowie tej grupy zarządzać wieloma aspektami związanymi z procesem wdrażania systemów operacyjnych, uwzględniając pakiety obrazy, task sequences, sterowniki, obrazy bootowania oraz ustawienie związane z state migration
  • Operations Administrator - ta rola daje możliwość wykonywanie wszelkich operacji z ConfigMgr 2012 z wyłączeniem zrządzania bezpieczeństwem(zarządzania użytkownikami, rolami bezpieczeństwa, kolekcjami, i zakresami bezpieczeństwa)
  • Read-Only Analyst - ta rola umożliwia jedynie przeglądanie obiektów ConfigMgr 2012
  • Remote Tools Operator - jak sama nazwa wskazuje, członkowie tej roli posiadają uprawnienia do uruchamiania narzędzia zdalnego zarządzania/pomocy
  • Security Administrator - rola ta umożliwia dodawania i wykluczanie administratorów oraz przypisywania ich do odpowiednich ról bezpieczeństwa, kolekcji i zakresów.
  • Software Update Manager - rola ta umożliwia definiowanie i wdrażanie aktualizacji oprogramowania, tworzenie kolekcji, grup aktualizacji, wdrożeń, szablonów z uwzględnieniem kwestii NAP.

Jak można zauważyć każda z wyżej wymienionych ról nadaje uprawnienia do różnego rodzaju obiektów. Aby dokładniej zobaczyć te informacje w konsoli ConfigMgra 2012, na przykład dla roli Application Administrator, należy:

  • W konsoli SCCM 2012 należy wybrać Administration -> Security -> Security Roles
  • Należy wybrać interesującą nas rolę, w naszym przypadku Application Administrator
  • Ze menu/wstążki wybrać Properties, a następnie zakładkę Permissions

Rysunek 2. Właściwości roli

Ważną informacją jest fakt, że uprawnienia zaszyte do poszczególnych obiektów w rolach predefiniowanych nie mogą być zmieniane. Dodatkowo role te nie mogę być eksportowane oraz usuwane. Jeżeli istnieje konieczność wykonania kastomizacji roli wbudowanej, to należy ją skopiować co skutkuje się pojawianiem się nowej roli, którą już można modyfikować wedle potrzeb.

Zalecenia Microsoft co do zarządzania użytkownikami zgodnie z opisywanym w tym artykule RBAC mówią, że jeżeli użytkownicy współdzielą różne role administracyjne to ich konta powinny znajdować się w odpowiednich grupach predefiniowanych, a nie w specjalnie tworzonych, nowych grupach, które będą posiadały uprawnienia będące sumą uprawnień z ról predefiniowanych.

Zakresy bezpieczeństwa bardziej szczegółowo

ConfigMgr 2012 używa zakresów bezpieczeństwa do zapewnienia użytkownikom administracyjnym określonego rodzaju dostępu do chronionych obiektów. Wszystkie obiekty chronione muszą być przypisane do przynajmniej jednego z zakresów bezpieczeństwa. Asocjacja pomiędzy obiektem a zakresem bezpieczeństwa jest zarządzana poprzez obiekt a nie zakres.

Rysunek 3. Dostepne zakresy bezpieczenstwa

Powyższy rysunek zawiera dwa wbudowane zakresy bezpieczeństwa:

  1. ALL – ten zakres umożliwia nadaje uprawnienia do wszystkich pozostałych zakresów. Obiekty nie mogą być do niego przypisywane
  2. Default – zakres zawierający wszelkie nowe obiekty dodawane po instalacji ConfigMgr 2012

Tworzenie Security Scope

Tworzenie zkastomizowanego zakresu bezpieczeństwa nie jest rzeczą skomplikowaną. W tym celu należy:

  1. Z konsoli ConfigMgra 2012 należy wybrać obszar roboczy Administration, następnie zakładkę Security Scopes
  2. Z wstążki należy wybrać Create Security Scope
  3. Należy podać odpowiednio nazwę dla nowo tworzonego zakresu bezpieczeństwa, opis jest polem opcjonalnym, następnie zatwierdzić przyciskiem OK.

Po tych trzech banalnych krokach nowy zakres bezpieczeństwa powinien pojawić się w oknie konsoli(patrz powyższy rysunek).

Zakresy bezpieczeństwa (ang. Security Scopes) mogą zwierać jeden lub więcej obiektów, do których zaliczyć można:

  • Aplikacje
  • Pakiety
  • Obrazy bootowalne
  • Sity
  • Zkastomizowane ustawienia klienta
  • Distribution Points oraz Distribution Points Groups

Poniższe obiekty nie mogą należeć do zakresu bezpieczeństwa i mogą być członkami jedynie ról bezpieczeństwa opisywanych wcześniej w artykule. Do tych obiektów należą:

  • Użytkownicy administracyjni
  • Role bezpieczeństwa
  • Zakresy bezpieczeństwa
  • Domyślne ustawienia klienckie
  • Granice (ang. Bounderies)
  • Konektory Exchange
  • Adresy sitów
  • Lasy Active Directory
  • Role Sitów Systemowych

Po stworzeniu zakresu bezpieczeństwa kolejnym krokiem, jaki należy wykonać jest przypisanie do niego określonych zasobów. W tym celu należy:

  1. W konsoli ConfigMgra 2012 wybierz interesujący Cię zasób, który ma zostać dodany do zakresu bezpieczeństwa. W naszym przypadku wykorzystamy aplikacje MDT, która została wcześniej skonfigurowana.
  2. Wybierając Software Library z konsoli ConfigMgr 2012, następnie Application Management Applications widzimy aplikację, o której mowa w punkcie 1. Zaznaczamy ją.
  3. Z wstążki wybieramy Classify a następnie Set Security Scopes. W tym miejscu wybieramy zakresy bezpieczeństwa, jeden lub wiele dla tego obiektu.

Rysunek 4. Przypisanie do obiektow

W wyniku przypisania obiektu do zakresu bezpieczeństwa, stan Security Scope zmienia się na Yes w kolumnie In Use.

Rysunek 5. Stan Security Scope

W celu uzyskania informacji na temat obiektów, które zostały przypisane do zakresu bezpieczeństwa, można posłużyć się wbudowanymi raportami, które dostarczają to, czego szukamy. Jednym z nich jest raport „Objects Secured by a Single Security Scope”. Ponieważ raportowanie nie jest tematem tego artykuł poprzestanę jedynie na tej małej wzmiance.

Kilka słów o kolekcjach

Omówiliśmy powyżej jak używane są role bezpieczeństwa i zakresy w modelu RBAC zaprezentowanym w ConfigMgr 2012. W celu umożliwienia użytkownikowi administracyjnemu wykonywania określonych funkcji, np. wdrażania aplikacji użytkownik musi posiadać uprawnienia do kolekcji, która zawiera określony zasoby, na które chcemy przeprowadzić wdrożenie.

Kolekcje obok zakresów i ról bezpieczeństwa umożliwiają w szczegółowy sposób kontrolować, które dostępne są dla użytkownika administracyjnego w konsoli ConfigMgr 2012.

Oczywiście kolekcje nie są elementem nowym i dla weteranów SMSa czy SCCM 2007 ich zasadność oraz mechanizm funkcjonowania jest znany. Jednakże ConfgiMgr 2012 wprowadza kilka zmian, które to wynikają z modelu User-Centric, który został przedstawiony w najnowszej wersji Config Mgra. W tym miejscu nie będę opisywał dokładnie zagadnień związanych z kolekcjami, ale jedynie podkreślę niektóre różnice oraz zmiany z nimi związane.

Używanie kolekcji

Definicja kolekcji jest dość prosta – jest to obiekt, który umożliwia logiczne grupowanie zasobów, takich jak urządzenia czy użytkownicy.

Występują cztery reguły określające członkostwo w danej kolekcji, która po stworzeniu może zostać przypisana do określonego użytkownika administracyjnego w ConfigMgr.

Do tych reguł zaliczamy:

  • Direct Rule – ta reguła umożliwia administratorowi jawnie określenie użytkowników lub komputerów, którzy mają być członkami kolekcji. Reguła tak występowała w CM2007
  • Query rule – reguła określającą członkostwo poprze określone zapytanie wykonujące w trybie zaplanowanym, co oznacza, że po pojawieniu się nowych obiektów w CongfigMgr, spełniających warunku zapytania, obiekty te automatycznie będą w danej kolekcji. Reguła ta występowała w CM2007
  • Include Collections Rule – nowy rodzaj reguły, który umożliwia administratorowi określenie członkostwa w danej kolekcji bazując na członkach innej kolekcji.
  • Exclude Collections Rule – kolejna nowa reguła, która umożliwia administratorowi określenie członkostwa w danej kolekcji poprzez wykluczenie członków należących do innej kolekcji.

ConfigMgr 2012 zawiera kilka predefiniowanych kolekcji. Niektóre z nich mogą być modyfikowane wedle potrzeb, jednakże żadna z nich nie może być usunięta. Do kolekcji domyślnych zaliczamy:

  • All Users Groups - zawiera grupy użytkowników odnalezionych podczas Active Directory Security Group Discovery
  • All Users - zawiera użytkowników odnalezionych podczas Active Directory User Discovery
  • All Users and User groups - suma powyższych kolekcji tzn. All Users Groups oraz All Users. Kolekcja ta nie może być modyfikowana i zawiera największy zakres zasobów użytkowników
  • All Desktop and Server Clients - zawiera urządzenia serwerowe oraz desktopowe, które posiadają zainstalowanego klienta ConfigMgra 2012. Członkostwo jest określone poprzez HeartBeat Discovery
  • All Mobile Devices - zawiera urządzanie mobilne, które są zarządzanie przez ConfigMgra 2012. Członkostwo jest ograniczone jednie do urządzań mobilnych, które poprawnie zostały przypisane do Situ SCCMa oraz odkryte przez Exchange Server Connector.
  • All Systems - suma All Desktop and Server Clients oraz All Mobile Devices i All Unknown Computers. Kolekcja ta nie może zostać usunięta i zawiera największy zakres zasobów urządzeń
  • All Unknown Computers – zawiera ogólne rekordy komputerów bez szczegółów. Najczęściej ta kolekcja jest wykorzystywana jest podczas wdrożeń systemów operacyjnych z użyciem PXE

Użytkownicy Administracyjni

Ostatnim elementem tego artykułu jest opis użytkowników administracyjnych, których pojęcie pojawiło się a nie zostało opisanie wcześniej w artykule.

Użytkownik administracyjny jest indywidualnym użytkownikiem lub grupa, która będzie posiadała uprawnienia do zarządzania obiektami w ConfigMgr 2012. Użytkownik administracyjny może mieć bardzo ograniczone uprawnienia do zasobów, lub posiadając bardzo szerokie uprawnienia do wszystkich obiektów w środowisku SCCM.

Użytkownik administracyjny oprócz faktu, że musi posiadać przypisanego użytkownika AD lub grupę, dodatkowo składa się również z przypisanej roli bezpieczeństwa i zakresu bezpieczeństwa. Kolekcja, która umożliwia dalsze ograniczenia wobec użytkownika administracyjnego jest elementem opcjonalnym. Powyższe elementy mogą być konfigurowane podczas tworzenia użytkownika administracyjnego lub zmieniane w późniejszym terminie wedle potrzeb.

Rysunek 6. Formatka Add User or Group

Mam nadzieję, że powyższy tekst wyjaśnia model RBAC zaprezentowany w ConfigMgr 2012 i jest argumentem potwierdzającym tezę "Manualne nadawanie uprawnień obecnych w SCCM 2007 to przeszłość".

Komentarze 5

Piotr Pawlik Redaktor
Piotr Pawlik
3486 pkt.
Guru
MVP
08-08-2012
oceń pozytywnie 0
Bardzo ciekawa tematyka! Przyjemnie się czytało.
kajetan_
kajetan_
1519 pkt.
Guru
11-08-2012
oceń pozytywnie 0
RBAC najczęściej się tłumaczy jako Role Based Access Control, ewentualnie (i raczej sporadycznie) Role Based Administration Control, natomiast Role Based Administrator Control jest IMHO niepoprawne.
Mariusz  Zarzycki
Mariusz Zarzycki
1084 pkt.
Senior
11-08-2012
oceń pozytywnie 0
Dziekuje za komentarze. RBAC - Kajetan_21 masz oczywiscie racje, szczerze mowic sam nie wiem czemu to tak przetlumaczylem, juz poprosilem redakcje o naniesienie korekty.
Dariusz Porowski Microsoft
Dariusz Porowski
Uczestnik projektów
12-08-2012
oceń pozytywnie 0
Poprawione :)
kajetan_
kajetan_
1519 pkt.
Guru
13-08-2012
oceń pozytywnie 0
:)
pkt.

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.