wtorek, 15 listopada 2011

Clariion - Unisphere Security Features

Tytuł po angielsku (brakło weny do stworzenia jakiegoś w miarę dobrego tłumaczenia) ale sama treść już w języku ojczystym ;)
Tym razem będzie o czymś na co w praktyce (przynajmniej mojej osobistej) raczej nie zwracałem uwagi. Temat przewodni to bezpieczeństwo a konkretnie sposoby na jakie Clariion (a w zasadzie Unisphere) pilnuje, aby dostępu do niego miały tylko uprawnione osoby i tylko w tym zakresie jaki został im udostępniony.
Ponieważ operacje zakładania i dawania dostępu nowym użytkownikom do macierzy to nie jest coś, co się przeprowadza regularnie i często, tak więc zwykle nie pamięta się wszyskich możliwości i niuansów jakie są z tym związane.
Podejrzewam jednak, że udane podejście do egzaminu na Clariion Specialist wymaga odświeżenia i uporządkowania sobie wiedzy w tym zakresie.

Do rzeczy.

Macierzą można zarządzać przez dwa główne interfejsy. Unisphere - czyli GUI dostępne poprzez przeglądarkę sieciową lub za pomocą linii komend.

Unisphere:

Aby dostać się do Unisphere należy w przeglądarce wpisać adres http://<clariion_ip> - powoduje to uruchomienie apletu Javy. Aplet ten zestawia bezpieczne, szyfrowane połączenie ( SSL/TLS na porcie 443) z storage management serwerem na macierzy. Dzięki temu, mimo iż nie jest bezpośrednio używany https, połączenie jest zabezpieczone.
Szyfrowana jest także cała komunikacja pomiędzy storage management serwerami na różnych macierzach.

Podczas logowania się do macierzy za pomocą Unisphere użytkownik autentyfikuje się podając login, hasło oraz tzw zakres (scope)

SecureCLI:

Podczas używania linii poleceń komunikacja z macierzą jest zabezpieczona w ten sam sposób, co przy łączeniu poprzez Unisphere (szyfrowanie połączenia).
Jeżeli chodzi o autoryzację, to administrator przy wpisywaniu komend, każdorazowo powinien podać login,hasło oraz zakres. Ponieważ takie rozwiązanie nie jest zbyt wygodne mamy możliwość stworzenia tzw "Security File". "Security File" jest przypisany do danego użytkownika na systemie operacyjnym, z którego wydaje się polecenia do clariiona i zawiera w sobie zaszyfrowany login,hasło i scope. Dzięki temu dany użytkownik nie musi ich podawać razem z każdą wysłaną komendą.
Komenda tworząca "Security File" to addusersecurity i ma następującą składnię:
naviseccli -addusersecurity -user <username> -password <pw> -scope<0|1|2>


Sam "Security file" to tak naprawdę dwa pliki które umiejscawiają się na home folderze użytkownika:
SecuredCLISecurityFile.xml i SecuredCLIXMLEncrypted.key

Usunięcie "Security Pliku" wykonuje się poleceniem:
naviseccli -removeusersecurity

Zakres (scope):

Każde konto do zarządzania Clariionami ma jeden z trzech zakresów:

  • Local - konto zdefiniowane na jednej macierzy
  • Global - konto umożliwiające administrowanie każdą z macierzy w domenie
  • LDAP - konto zdefiniowane na serwerze LDAP (np: w domenie AD) i umożliwiające zalogowanie się do każdej macierzy używającej LDAPu do autentyfikacji



Autentyfikacja przez serwer LDAP:

Metoda wykorzystania do zarządzania Clariionami konta z domeny jest najbardziej wygodna. Dzięki temu nie musimy wyodrębniać zarządzania użytkownikami macierzą do innego miejsca i możemy utrzymać centralny punkt (domena np: AD) do zarządzania uprawnieniami.
Macierz musi być najpierw odpowiednio skonfigurowana aby móc na niej korzystać z użytkowników domenowych. Z poziomu Unisphere ustawienia dotyczące LDAPa można znaleźć w menu:

All Systems > Domains > Configure LDAP for CLARiiON Systems

W tym miejscu można przede wszystkim dodać(i zmienić) adresy naszych kontrolerów domeny.
Tutaj także ustawia się interwał synchronizacji. Storage server przechowuje (cache-uje) informacje o kontach i ich uprawnieniach pobrane z domeny tak, żeby każde wydane polecenie nie musiało być autentyfikowane z kontrolerem. Standardowo ten cache jest czyszczony co 24h, ale jeżeli chcemy aby czas ten uległ skróceniu i macierz częściej odświeżała/synchronizowała informacje z domeny możemy zmienić.


Role użytkowników:


Ostatni temat jaki zostanie omówiony w tym wpisie, to role czyli rodzaje kont jakie można założyć na macierzy. Różnią się one, oczywiście, rodzajem uprawnień, a przez to działaniami jakie dany użytkownik może wykonywać.
Dostępne są następujące role:

  • Monitor - użytkownik z uprawnieniami read-only
  • Manager - użytkownik mogący zarządzać macierzą ale nie mający uprawnień do tworzenia i zarządzania kontami użytkowników na niej.
  • Administratror - użytkownik posiadający maksymalne uprawnienia zarówno jeżeli chodzi o zarządzanie macierzą (tworzenie, wystawianie LUNów, definiowanie RAID grup itd..) jak i o zarządzanie użytkownikami
  • Security Administrator - użytkownik mogący tworzyć i zarządzać innymi użytkownikami, ale nie mogący konfigurować macierzy.
Od FLARE29 dostępne są także 3 role do działań związanych z replikacją:
  • Local Replication - użytkownik może wykonywać operacje związane z replikacją lokalną SnapView
  • Replication  - użytkownik może wykonać operacje związane z replikcją zdalną - MirrorView, oraz lokalną.
  • Replication/Recovery - rola podobna jak Replication ale dodatkowo użytkownik może wykonywać operacje "odzyskania" np: roll-back z kopii migawkowej.

Co istotne żadna z tych 3 ról "replikacyjnych" nie zezwala na tworzenie nowych bytów związanych z replikacją (jak klony, kopie migawkowe itd...). Możliwe jest jedynie zarządzanie już istniejącymi obiektami.




Brak komentarzy:

Prześlij komentarz