Tożsamość usługowa

Najpoważniejsze okazały się jednak kłopoty z komunikacją w bardzo specyficznej topologii połączeń. Ze względów bezpieczeństwa, ruch między podsieciami został zablokowany, sieci wykorzystywały różne adresacje. Stosowana podwójna zmiana adresu byłaby problemem, gdyby komunikacja wymagała dynamicznie otwieranych portów. Na szczęście wystarczy otwarcie konkretnych portów, agent nie używa portów zwrotnych.

Ważnym problemem było szybkie i niezawodne blokowanie konta we wszystkich systemach na podstawie zgłoszenia z TIM. W domyślnej konfiguracji serwer TIM łączył się z zarządzanym systemem i blokował konto, ale była to komunikacja jednorazowa. Zmianą wprowadzoną przy wdrożeniu systemu była pętla, która powodowała kilkukrotne komunikowanie się. Skutkiem wykonania pętli jest skuteczne i potwierdzone zablokowanie dostępu albo zgłoszony alert o problemach z komunikacją.

Bezpieczeństwo przede wszystkim

System zarządzania tożsamością jest najważniejszym elementem systemu, odpowiedzialnym za bezpieczeństwo wszystkich zarządzanych zasobów. Dlatego firma zastosowała ponadstandardowe środki bezpieczeństwa. Serwery Tivoli Identity Management zostały zainstalowane w oddzielonej podsieci. Wybrano platformę Red Hat Linux eksploatowaną w wirtualizowanym środowisku VMware, zapewniającym wysoką dostępność dzięki mechanizmowi klastrowania VMotion.

Do każdego ze środowisk klienckich zrealizowano wirtualną sieć prywatną IPSec. Połączenie jest zrealizowane w taki sposób, że reguły zapór sieciowych blokują każdy ruch z wyjątkiem połączenia pomiędzy agentami TIM a współpracującym z nimi serwerem. Przy tym projekt topologii połączeń wyklucza całkowicie inną komunikację, nie jest możliwe żadne połączenie pomiędzy sieciami poszczególnych klientów. Agent TIM komunikuje się z serwerem przy pomocy szyfrowanego połączenia SSL, nasłuchuje wyłącznie jednego adresu IP, pod którym jest widoczny serwer. Komunikacja jest zabezpieczona certyfikatami, zatem podszywanie się jest praktycznie niemożliwe.

Do serwera Tivoli Identity Management, w celach administracyjnych lub przy zmianie hasła, można się zalogować wyłącznie z dedykowanej podsieci, z użyciem dwuskładnikowego uwierzytelnienia tokenami RSA SecurID. Centralizowany dostęp umożliwił zrealizowanie mocnej polityki haseł, znacznie lepszej niż najmocniejsza używana przez klientów. Dzięki temu administratorzy nie muszą pilnować zmian hasła w każdym z systemów, logując się w każdym z nich za pomocą swojego, aktualnego, mocnego i dobrze pilnowanego hasła.


TOP 200