Koncepcja uslug wspolnych dla jednostek edukacyjnych w jednostkach samorzadowych

Koncepcja usług wspólnych
dla jednostek edukacyjnych
w Jednostkach Samorządowych
Microsoft dla Edukacji
Opracowanie: Microsoft Sp. z o.o.

Spis treści
1. Geneza projektu .................................................................................................................................................................... 2
2. Beneficjenci projektu .......................................................................................................................................................... 3
3. Cele projektu ........................................................................................................................................................................... 4
4. Metody realizacji projektu ............................................................................................................................................... 5
4.1. Etapy projektu .......................................................................................................................................................................... 5
5. Główne funkcjonalności projektu ................................................................................................................................ 6
5.1. Zdefiniowane potrzeby szczegółowe .............................................................................................................................. 6
6. Podstawowe metryki sukcesu ........................................................................................................................................ 7
7. Wizja architektury usług wspólnych ........................................................................................................................... 8
7.1. Funkcje komponentów usług wspólnych ....................................................................................................................... 8
7.2. Wymagania dodatkowe ........................................................................................................................................................ 9
7.3. Wymagania w zakresie niezbędnych komponentów ................................................................................................ 9
7.3.1. Usługa mechanizmów komunikacji .................................................................................................................................. 9
7.3.2. Mechanizmy wirtualizacji środowisk serwerowych
i wykorzystania hostowanych środowisk wirtualnych ............................................................................................ 10
7.3.3. Usługi katalogowe ............................................................................................................................................................... 10
7.3.4. Zarządzanie stacjami roboczymi i AV ........................................................................................................................... 12
7.3.5. Poczta elektroniczna ........................................................................................................................................................... 14
7.3.6. Portal wielofunkcyjny pracy grupowej ......................................................................................................................... 16
7.3.7. Komunikacja wielokanałowa ............................................................................................................................................ 16
7.3.8. Wstępne wymiarowanie serwerów ................................................................................................................................ 18
8. Wymagania techniczne dla standardowych komponentów systemu .................................................... 20
8.1. System zarządzania i monitorowania podstawowej infrastruktury .................................................................. 20
8.2. System zarządzania stacjami roboczymi ..................................................................................................................... 37
8.3. System poczty elektronicznej .......................................................................................................................................... 38
8.4. Serwery portali wielofunkcyjnych .................................................................................................................................. 41
8.5. Serwery komunikacji wielokanałowej ........................................................................................................................... 45
8.6. Serwery relacyjnej bazy danych ...................................................................................................................................... 48
8.7. Pakiet biurowy ....................................................................................................................................................................... 56

1. Geneza projektu
Proces i efektywność edukacji stopnia podstawowe-
go i średniego są jednymi z krytycznych elementów
oceny działania jednostek samorządu terytorialnego
przez obywateli. Ocena ta jest zwykle bardzo kry-
tyczna i wskazuje na wiele niedostatków działania
szkół publicznych. Równie krytycznie oceniany jest
poziom kandydatów na uczelnie wyższe, a często
spotkać się można z opinią o spadającym pozio-
mie ich przygotowania. Ponadto, wzrasta oczeki-
wanie społeczne unowocześnienia procesu eduka-
cji w sposób adekwatny do otacząjącego obywateli
środowiska życia i pracy.
Jednocześnie rozproszony z konieczności i nakiero-
wany na wyodrębnione procesy sposób dotychcza-
sowej informatyzacji szkół, generuje wysokie koszty
zarządzania oświatą dla samorządów lokalnych oraz
wymaga niepotrzebnego zaangażowania szczupłych
zasobów kadry administracyjnej systemów IT.
Pamiętać należy, że zarówno na terenie Polski, jak
i Unii Europejskiej, podniesienie poziomu nauczania,
a pośrednio wzrost konkurencyjności tych państw
na arenie światowej staje się jednym z głównych
priorytetów.
Czynnikiem, który mógłby stać się wzorcowym przy-
kładem zmian w sposobie nauczania, może być
wdrożenie przemyślanego systemu wsparcia telein-
formatycznego w szkołach szczebla podstawowego
i średniego podległych jednostkom samorządu te-
rytorialnego. Taki wzorzec, mógłby być propagowa-
ny na terenie całego kraju, a jednocześnie stać się
podstawą do kreowania przyszłej polityki Minister-
stwa Edukacji Narodowej.

2. Beneficjenci
projektu
Beneficjentami projektu są uczniowie szkół podsta-
wowych i średnich, nauczyciele oraz rodzice uczniów,
a po poszerzeniu projektu objęte by nim zostały
przedszkola. Pośrednio korzyści odniesie całe społe-
czeństwo oraz Jednostki Samorządu Terytorialnego.

Koncepcja usług wspólnych dla jednostek edukacyjnych w Jednostkach Samorządowych
4
3. Cele projektu
Głównymi celami projektu Innowacyjna Edukacja
jest zaadresowanie oczekiwań mieszkańców w za-
kresie polepszenia warunków i sposobu nauczania,
a z drugiej strony podniesienie efektywności realiza-
cji zadań statutowych i docelowo – obniżenie kosz-
tów zarządzania oświatą.
Głównymi wytycznymi projektu są:
• Wprowadzenie nowoczesnych metod wspoma-
gania procesu edukacyjnego odpowiadających
swoim zaawansowaniem rozwojowi otaczające-
go uczniów i rodziców środowiska życia i pracy,
• Promocja kreatywności uczniów i pracy zespo-
łowej,
• Wyrównanie szans różnych grup uczniów po-
przez standaryzację dostępu do nowoczesnych
technologii i form działania w otaczającym świe-
cie,
• Optymalizacja i standaryzacja kosztów wsparcia
procesów edukacyjnych,
• Zapewnienie bezpieczeństwa danych, w tym da-
nych osobowych beneficjentów projektu,
• Wskazanie referencyjnych rozwiązań innym jed-
nostkom samorządu terytorialnego.
• Zwiększenie dostępności usług elektronicznych
dla mieszkańców.

5
4. Metody realizacji
projektu
Założeniem projektu jest realizacja jego celów po-
przez wdrożenie rozwiązań IT, przy minimalizacji
ryzyka niepowodzenia oraz minimalizacji kosztów
związanych z wdrożeniem i utrzymaniem trwałości
działania narzędzi wspierających edukację. Z uwagi
na to przyjęto następujące założenia:
• Zatwierdzenie celów, sposobu realizacji i finan-
sowania projektu,
• Przystąpienie do wyboru Inżyniera Kontraktu ko-
ordynującego projekt,
• Uczestnictwo w trakcie planowania projektu
aktywnych przedstawicieli nauczycieli oraz firm
komercyjnych posiadających doświadczenie
w budowie rozwiązań teleinformatycznych dla
edukacji,
• Oparcie się na znanych, powszechnie dostępnych
narzędziach, gwarantujących intuicyjną obsługę
i minimalizację ryzyka niepowodzenia projektu,
• Wykorzystanie gotowych platform usługowych
w celu ograniczenia ryzyk projektowych oraz
znacznego obniżenia kosztów wdrożenia i utrzy-
mania,
• Przyjęcie zasady iteracyjnego rozwoju projektu
metodą iteracyjnych korekt po podsumowaniu
każdego etapu, a za tym idzie ścisłe dopaso-
wanie do wymagań wszystkich jego beneficjen-
tów przy uzyskaniu efektu szybkiego wdrożenia
pierwszej wersji,
• Umocowanie komitetu sterującego z udziałem
władz jednostki samorządowej monitorującego
projekt,
• Zapewnienie partycypacji w wykorzystaniu efek-
tów projektu maksymalnej liczbie uczestników
procesu edukacyjnego poprzez ich dostępność
oraz zapewnienie niezbędnego transferu wiedzy,
• Szeroką promocję wyników projektu.
• Opracowanie i wdrożenie architektury systemu
zgodnejznajlepszymikomercyjnymistandardami.
4.1. Etapy projektu
W obecnej chwili projekt przewiduje następujące
etapy:
1. Budowę infrastruktury usług wspólnych i bez-
pieczeństwa,
2. Udostępnienie inicjalnych usług komunikacy-
jnych,
3. Opracowanie standardów interoperacyjności dla
wszystkich dostawców komponentów do sys-
temów dla jednostek edukacyjnych,

6
5. Główne
funkcjonalności
projektu
Aby zrealizować założenia i cele projektu z sukce-
sem, należ przyjąć, że jego wdrażanie będzie nastę-
powało etapowo i rozpocznie się od prostych, acz
użytecznych funkcji, takich jak:
• Zapewnienie podstaw jednolitej tożsamości
wszystkich użytkowników w systemie , służących
jako podstawa infrastrukturalna wszystkim kom-
ponentom różnych dostawców,
• Wypracowanie standaryzacji i określenia danych
źródłowych dla wszystkich dostawców oprogra-
mowania dla edukacji,
• Zapewnienie bezpiecznej komunikacji elektro-
nicznej pomiędzy nauczycielem, uczniem i jego
opiekunami,
• Zapewnienie monitoringu pracy ucznia i jego
wyników z możliwością interakcji między na-
uczycielem i opiekunami ucznia,
• Przeniesienie do spójnej i wymieniającej dane
domeny cyfrowej dzienników, dzienniczków
ucznia, planów lekcyjnych i rocznych planów na-
uczania,
• Zapewnienie uczniom i nauczycielom repozyto-
riów dokumentów elektronicznych z możliwo-
ścią udzielania uprawnionego dostępu,
• Wdrożenie platformy zdalnego nauczania typu
e-learning,
• Umożliwienie drogą cyfrowej partycypacji w za-
jęciach szkolnych uczniów chorych lub niepeł-
nosprawnych,
• Stworzenie dla nauczycieli elektronicznej plat-
formy dziedzinowych warsztatów/spotkań pod-
noszących ich kwalifikację i promujących dobre
praktyki,
• Wdrożenie platformy umożliwiającej nauczanie
programowania i tworzenia aplikacji.
• Zbudowanie komponentowego i interoperacyj-
nego systemu zarządzania placówkami oświa-
towymi powiązanego z systemem zarządzania
jednostki samorządu terytorialnego.
5.1. Zdefiniowane potrzeby
szczegółowe
1. Obsługa IT w Jednostkach Oświatowych
2. Obsługa rekrutacji
3. Obsługa Arkusza Organizacyjnego
4. Obsługa Dziennika elektronicznego
5. Przygotowanie standardów interoperacyjności
dla wyżej wymienionych i przyszłych kompo-
nentów systemu w zakresie:
a. Jednolitego systemu nadawania tożsamości
użytkowników i uwierzytelniania
b. Określenie zbioru metadanych
c. Wymiany danych pomiędzy komponentami,
a co za tym idzie brak konieczności wpisy-
wania tych samych danych do różnych pod-
systemów obsługujących sektor edukacyjny
d. Określenia źródłowych danych dla kompo-
nentów systemu.
6. Przygotowanie materiałów i mechanizmów sz-
koleń dla kadry administratorskiej i użytkown-
ików.

7
6. Podstawowe
metryki sukcesu
• Wzrost liczby uczniów posługujących się codzien-
nie narzędziami teleinformatycznymi w nauce,
• Wzrost liczby szkół wykorzystujących dzienniki
i dzienniczki elektroniczne,
• Wzrost liczby interakcji w formie cyfrowej po-
między nauczycielem i opiekunami ucznia,
• Wzrost udziału dokumentów elektronicznych
w stosunku do papierowych przy kreowaniu prac
domowych oraz dostarczaniu uczniowi materia-
łów edukacyjnych,
• Wzrost liczby materiałów multimedialnych wy-
korzystywanych w procesie nauczania,
• Wzrost liczby dobrych praktyk nauczania popu-
laryzowanych w szkołach,
• Wzrost liczby szkoleń (dla uczniów, nauczycieli
i rodziców) prowadzonych drogą elektroniczną,
• Spadek kosztów utrzymania systemów teleinfor-
matycznych w szkołach.
• Wolumen usług teleinformatycznych świadczo-
nych mieszkańcom.

8
7. Wizja architektury
usług wspólnych
7.1. Funkcje komponentów usług
wspólnych
Projektowana architektura usług wspólnych będzie
udostępniać następujące funkcjonalności:
• Usługa mechanizmów komunikacji rozległej
zawierająca wymaganą infrastrukturę sieciową,
łącza do poziomu urządzeń dostępowych w jed-
nostkach , zarządzanie i SLA na całość usługi,
• Mechanizmy wirtualizacji środowisk serwero-
wych i wykorzystania hostowanych środowisk
wirtualnych,
• Mechanizmy tożsamości użytkowników bazują-
ce na usłudze katalogowej,
• System zarządzania i monitorowania podstawo-
wej infrastruktury,
• system zarządzania stacjami roboczymi ,
• oprogramowaniem antywirusowym i antymal-
ware,
• Platformę pracy grupowej i poczty elektronicz-
nej w oparciu o serwery poczty elektronicznej,
• Platformę wymiany informacji, pracy grupowej –
opartej o funkcje portali wielofunkcyjnych,
• Komunikację błyskawiczną, głosową i wideokon-
ferencje oparte o system komunikacji wieloka-
nałowej
• Oprogramowanie klienckie bazujące na standar-
dowym pakiecie biurowym.
Realizacja powyższego, wymaga wprowadzenia me-
chanizmów uwierzytelniania użytkowników i ich sta-
cji roboczych, a także mechanizmów kontroli dostę-
pu. W związku z tym, konieczne jest wprowadzenie
spójnej usługi uwierzytelniania w oparciu o usługę
katalogową. Umożliwi to jednocześnie w mechani-
zmów pojedynczego logowania (SSO) w dostępie
do poszczególnych elementów usług składowych.
Wprowadzenie takiej wizji usług zakłada również,
aby każdy użytkownik w placówkach oświatowych
posiadał dostęp do wewnętrznych zasobów jedno-
stek z zaufanej stacji roboczej i/lub urządzenia mo-
bilnego. Oznacza to, iż konieczne jest zestawienie
bezpiecznych tuneli sieci prywatnej pomiędzy lo-
kalizacją, w które zlokalizowane będą systemy cen-
tralne, a poszczególnymi placówkami oświatowymi.
Szczególnie polecanym scenariuszem jest oparcie
usług o gotową platformę usługową – na przykład
MS Azure, realizującą wszystkie wymagane funkcje
i zapewniającą wysoki poziom bezpieczeństwa sys-
temu oraz niskie i przewidywalne koszty eksploatacji.
Lokacja/centrum
przetwarzania
Tunel VPNTunel VPN
Placówka oświatowa Placówka oświatowa

9
Tunele prywatnych sieci będą realizowane przez kilka
metod, w zależności od możliwości danej placówki:
• Router sieciowy realizujący połączenie Site-To-
-Site VPN za pomocą
• L2TP
• IPSec
• Przezroczysty VPN realizowany za pomocą funk-
cjonalności Direct Access lub Auto VPN,
• Dedykowane łącze WAN do lokacji centralnej
• Dedykowany połączenie VPN na wybranych kom-
puterach w jednostkach oświatowych (w przy-
padku braku możliwości realizacji powyższych)
W skład lokalizacji centralnej, wchodzić będą składo-
we wszystkich komponentów świadczonych usług:
Usługa
katalogowa
Platforma
bazodanowa
System
aktualizacji
Zarządzanie
i monitorowanie
stacji
Serwery poczty
elektronicznej
Serwery portali
wielofunkcyjnych
wraz z analizą
danych
Serwery
komunikacji
wielokanałowej
Azure i Office 365
7.2. Wymagania dodatkowe
Niezbędnym wymaganiem dla wprowadzenia jed-
nolitej platform usług wspólnych jest
• Wprowadzenie sieci WAN / połączeń Site-To-
-Site VPN
• Dystrybucja i instalacja stacji klienckich – z syste-
mem wspierającym usługę Branch Cache
• Dodanie wszystkich stacji roboczych do central-
nej usługi katalogowej
• W przypadku większych lokalizacji wprowadze-
nie lokalnego punktu dystrybucyjnego dla opro-
gramowania i aktualizacji
• Wśród świadczonych usług, platforma wymia-
ny informacji i poczty elektronicznej będzie
świadczona także w sieci Internet (poza siecią
LAN/WAN).
7.3. Wymagania w zakresie niezbęd-
nych komponentów
Wymagane dla działania systemu komponenty mu-
szą być komponentami standardowymi opartymi
o oprogramowanie i usługi standardowe, powszech-
nie dostępne na rynku.
7.3.1. Usługa mechanizmów komunikacji
Usługa mechanizmów komunikacji może być nieza-
leżnym postępowaniem i projektem, spełniającym
jednak wymagania stawiane przez całość systemów
edukacji.

10
Musi ona zapewniać dla wszystkich jednostek oświa-
towych podlegających jednostce samorządu teryto-
rialnego:
• Wszystkie urządzenia, usługi telekomunikacyjne
i wsparcie techniczne konieczne do wytworzenia
i utrzymania komunikacji w okresie ostatniego
roku wdrożenia i 5 lat od uruchomienia produk-
cyjnego.
• Łączność pomiędzy wszystkimi jednostkami
oświatowymi i samorządu terytorialnego włą-
czonymi w projekt.
• Wymaganą infrastrukturę sieciową, łącza do po-
ziomu urządzeń dostępowych w jednostkach ,
zarządzanie i SLA na całość usługi.
7.3.2. Mechanizmy wirtualizacji środowisk
serwerowych i wykorzystania hosto-
wanych środowisk wirtualnych
Niezwykle dynamiczny rozwój technologii wirtuali-
zacyjnych spowodował, że w obecnej chwili wyko-
rzystują je praktycznie wszystkie duże centra prze-
twarzania. Trudno sobie też wyobrazić inny model
dla tych największych Data Center, obsługujących
miliony użytkowników.
Wykorzystywana usługa centrum przetwarzania da-
nych powinna w zgodzie z wymogami bezpieczeń-
stwa i i prawa umożliwiać uruchamianie maszyn
wirtualnych Windows Server i Linux, przestrzeni dy-
skowych i komunikacji o określonych wymaganiami
projektowymi parametrach.
7.3.3. Usługi katalogowe
Wdrożenie wspólnej usługi katalogowej umożliwi
zrealizowanie wymagań organizacyjnych i technicz-
nych stojących przed centralnym środowiskiem in-
formatycznych, takich jak:
• Utworzenie jednolitej struktury usług katalogo-
wych, zapewniającej mechanizmy uwierzytelnie-
nia i autoryzacji wszystkim podmiotom.
• Zapewnienie jednolitej infrastruktury zarządza-
nia środowiskiem użytkownika oraz usługami
w ramach sieci organizacji.
• Planowana infrastruktura musi umożliwiać do-
stosowanie struktury do dynamicznych zmian
w zakresie sukcesywnego dołączania kolejnych
placówek oświatowych.
• Ponadto planowane rozwiązanie stanowi pod-
stawę do wdrożenia nowoczesnych usług wspo-
magania procesu edukacyjnego, platformy prze-
pływów pracy, systemów kadrowo-księgowych,
czy usług poczty elektronicznej.
Serwery usługi katalogowej zostaną zlokalizowane
w środowisku hostowanego centrum przetwarza-
nia. Na potrzeby synchronizacji usługi katalogowej
z usługami dostępnymi w centrum przetwarzania
zostaną zainstalowane serwery Windows z funkcjo-
nalnością Active Directory Dirsync oraz Active Direc-
tory Federation Sevices, których zadaniem będzie
umożliwienie (poprzez sewery proxy w sieci zdemili-
taryzowanej) federacja uwierzytelniania z serwerami
i usługami w chmurze publicznej. Wysokopoziomo-
wą architekturę tego rozwiązania przedstawia po-
niższa ilustracja:

11
Rysunek 1: Architektura usługi katalogowej
ADFS
Proxy
Server
DMZ 1
Usługa katalogowa
ADFS
Proxy
Server
DMZ 1
Domena: np. oswiata.xxx.gov.pl
Datacenter 1
Dirsync
ADFS
Dirsync
ADFS
Datacenter 2
Domain
controllers
Domain
controllers

12
7.3.4. Zarządzanie stacjami roboczymi i AV
W ramach przedsięwzięcia stworzony zostanie sys-
tem kompleksowego zarządzania stacjami roboczy-
mi, w tym inwentaryzacji sprzętu i oprogramowania,
automatyzacji instalacji stacji i dystrybucji oprogra-
mowania (w tym poprawek bezpieczeństwa i aktu-
alizacji bibliotek antywirusowych). System zarządza-
nia stacjami roboczymi będzie zbudowany w oparciu
o komponenty systemu zarządzania stacjami..
Wdrożenie podstawowej funkcjonalności systemu
zarządzającego będzie polegało na uruchomieniu
następujących usług:
• Inwentaryzacja sprzętu,
• Inwentaryzacja oprogramowania,
• Dystrybucja oraz instalacja oprogramowania
(z wykorzystaniem mechanizmów Branch Cache),
• Dystrybucja oprogramowania antywirusowego
• Dystrybucja oraz instalacja aktualizacji systemo-
wych
• Dystrybucja i aktualizacja definicji antywirusowych
• Zdalna administracja (Remote Tools, Remote As-
sistance, Remote Desktop),
• Mechanizm raportowania,
• Mechanizm weryfikacji zgodności stacji roboczej
ze wzorcem (Desired Configuration Management)
• Katalog aplikacji
W tej skali środowiska najlepszym rozwiązaniem bę-
dzie jednopoziomowa struktura systemu zarządza-
jącego – siedziba typu Primary (pracująca w serwe-
rowni centralnej).
Stanowi on centralne repozytorium wszystkich in-
formacji gromadzonych przez system zarządzający.
Siedziba będzie stanowiła centralny punkt admini-
stracji, do którego (zdalnie) za pomocą konsol admi-
nistracyjnych systemu zarządzającego będą łączyć
się operatorzy systemu. Siedziba systemu zarządza-
jącego składa się z jednego serwera typu Primary,
dodatkowego serwera pełniącego rolę punktu dys-
trybucyjnego oraz zewnętrznej bazy danych zain-
stalowanej na klastrze serwerów bazodanoiwych
(współdzielonym również dla pozostałych kompo-
nentów usługowych)
Na podstawowym serwerze zostaną zainstalowane
również funkcjonalności dotyczące zarządzania po-
prawkami (Software Update Point), a także zarzą-
dzania antywirusem (Protection Point), dzięki czemu
możliwa będzie wymuszona dystrybucja oprogra-
mowania i antywirusa
W wybranych lokalizacjach oświatowych (w przy-
padku wolnych łączy i/lub dużej ilości stacji robo-
czych), zostaną utworzone punkty dystrybucyjne
obsługujące klientów w sieci rozległej.
Poniższa ilustracja przedstawia przyjętą architekturę
systemu:

13
Rysunek 2: Architektura zarządzania stacjami
Admin Console
Centralna serwerownia
Wybrane stacje klienckie Wybrane lokalizacje oświatowe
Distribution
Point
Primary
Server
Distribution
Point
Distribution
Point
Database
Server

14
7.3.5. Poczta elektroniczna
W nowej usłudze katalogowej zostanie wdrożony
system poczty elektronicznej, a dotychczasowe sys-
temy poczty elektronicznej będą podlegać migracji
do centralnego systemu.
Po przeprowadzeniu migracji, usługa poczty opartej
o serwer poczty elektronicznej będzie głównym sys-
temem pocztowym pracowników oświaty.
Użytkownicy będą mieli dostęp do swoich skrzynek
pocztowych zarówno z sieci wewnętrznej jak i z In-
ternetu za pomocą protokołów:
• Outlook Anywhere
• Outlook Web App
• ActiveSync
Skrzynki pocztowe zostaną umieszczone na ser-
werach z rolą „Mailbox”. Natomiast dostęp do nich
odbywał się będzie za pośrednictwem roli „Client
Access (CAS)”. Serwery będą zainstalowane w trybie
multirole, co oznacza, iż również rola „Hub Trans-
port” znajdzie się na tych serwerach. Mechanizmy
równoważenia obciążenia (sprzętowe lub progra-
mowe) będą rozkładać równomiernie sesje użytkow-
ników pomiędzy serwery.
Poczta przychodząca z Internetu będzie wstępnie
filtrowana przez urządzenia sprzętowe znajdujące
się w dwóch lokalizacjach centralnych, gdzie będzie
poddana skanowaniu przez oprogramowanie an-
tyspamowe i antywirusowe.
Dostęp usług ActiveSync oraz Outlook Web Access
będzie realizowany poprzez połączenie SSL z wyko-
rzystaniem obecnej infrastruktury IT. Umożliwi to:
• Dostęp do poczty przy użyciu telefonów komór-
kowych (Windows Mobile Device lub innych te-
lefonów obsługujących komunikację z wykorzy-
staniem ActiveSync).
• Możliwe jest również wykorzystanie oprogramo-
wania firm trzecich pod warunkiem, że będzie
ono umożliwiało nawiązanie szyfrowanego po-
łączenia opartego na certyfikatach
• Dostęp do poczty przy użyciu przeglądarki in-
ternetowej.
• Zdalny dostęp do poczty przy użyciu skonfigu-
rowanego konta pocztowego w oprogramowa-
niu Microsoft Outlook.
Na etapie projektowania musi zostać podjęta decy-
zja o wymaganiach dotyczących wysokiej dostępno-
ści, a także rozwiązań podsystemu dyskowego.
Jedno z możliwych rozwiązań umożliwia wykorzy-
stanie tanich półek dyskowych (JBOD), kosztem
zwiększenia ilości kopii skrzynek pocztowych do 4,
a także rezygnacji z dodatkowych rozwiązań kopii
zapasowych na rzecz mechanizmu serwerów poczty
umożliwiający przechowywanie zawartości usunię-
tych elementów i skrzynek pocztowych przez okre-
ślony czas.
Poniższy diagram przedstawia referencyjną architek-
turę systemu pocztowego:

15
Rysunek 3: Architektura Poczty elektronicznej
Windows
Android
Zewnętrzny
użytkownik
Outlook
Anywhere
ActiveSync
Apple
Wewnętrzny użytkownik Inne wewnętrzne systemy pocztowe
Windows
Android
Apple
DMZ
Datacenter 1
DMZ
Datacenter 2
Outlook Web
App ActiveSync
Outlook Anywhere
Outlook Web
App ActiveSync
Outlook Anywhere
Web Services
SMTP
Outlook Web
App ActiveSync
Outlook Anywhere
Web Services
SMTP
Hardware Load BalancingDatacenter 1
DAG 1
Active/Active
LAN/WAN
Datacenter 2

16
7.3.6. Portal wielofunkcyjny pracy
grupowej
Portal pracy grupowej oparty o platformę portalu
wielofunkcyjnego będzie podstawowym rozwiąza-
niem dla kluczowych aplikacji pracy grupowej. De-
dykowane witryny będą umożliwiać zaadresowanie
następujących obszarów współpracy:
• Obsługa wprowadzania danych tożsamości
elektronicznej ucznia,
• Repozytoria wzorów dokumentów i dokumentów,
• Obsługa Arkusza Organizacyjnego
• Obsługa Dziennika elektronicznego
Sama platforma pracy grupowej zostanie zbudowana
na bazie farmy 4 serwerów zlokalizowanych w dwóch
serwerowniach. W każdej z lokalizacji będzie znajdo-
wał się serwer typu front end oraz back end.
Datacenter 1 Datacenter 1
FrontEnd Servers
BackEnd Servers
Rysunek 4: Architektura platformy portalu
Farma ta będzie jednocześnie korzystać z współ-
dzielonego klastra bazy danych.
7.3.7. Komunikacja wielokanałowa
Najważniejszym komponentem zunifikowanej ko-
munikacji będzie serwer komunikacji wielokanało-
wej współpracujący z systemami poczty elektronicz-
nej i portali wielofunkcyjnych
System wspomagający wewnętrzną komunikację
w organizacji ma zapewnić pracownikom prostą,
efektywną kosztowo, niezawodną i bezpieczną ko-
munikację głosową, video oraz przesyłanie wiado-
mości tekstowych z użyciem posiadanych kompute-
rów PC oraz urządzeń mobilnych.
Ideą implementacji platformy jednolitej komunikacji
(PJK) jest współpraca różnych komponentów, wyko-
rzystująca integrację poczty email, kalendarzy, wia-
domości błyskawicznych, konferencji w sieci Web,
audio i wideokonferencji. PJK powinna być zinte-
growana z komponentami portalu wielofunkcyjnego
i poczty elektronicznej. Ponadto PJK musi wykorzy-
stywać mechanizm pojedynczego logowania (single
sign-on), uprawnień użytkowników i ich grup, bazu-
jąc na komponencie usług katalogowych.

17
Wynikiem takiej integracji mają być następujące ce-
chy systemu:
• Ujednolicenie komunikacji
• Dostęp z dowolnego miejsca do komunikacji
w czasie rzeczywistym i asynchronicznej.
• Ujednolicona poczta głosowa, e-mail, kontakty,
kalendarz, wiadomości błyskawiczne (IM) i dane
o obecności w jednym interfejsie klienckim.
• Integracja z aplikacjami pakietu biurowego
z kontekstową komunikacją i z funkcjami obec-
ności.
• Wbudowane mechanizmy dostępu mobilnego
i bezprzewodowego.
• Rozszerzalna platforma integracji narzędzi
współpracy z aplikacjami biznesowymi.
• Usługi bezpieczeństwa umożliwiające chronioną
komunikację wewnątrz organizacji.
• Aplikacje biznesowe dostępne bezpośrednio
na urządzeniach mobilnych.
• Mobilny dostęp do ludzi i danych firmowych.
• Obniżone koszty dzięki zdalnej administracji
i zarządzaniu urządzeniami.
• Niskie koszty usług telefonicznych i komunikacji
między odległymi lokalizacjami.
• Wsparcie dla użytkowników niepełnosprawnych.
Zwiększenie efektywności pracy zespołów poprzez
obszary robocze
• Możliwość tworzenia ad-hoc witryn współpracy
czy obszarów roboczych dla zespołów z pozio-
mu interfejsu klienta portalu wielofunkcyjnego
lub z poziomu pakietu biurowego.
• Zdecentralizowane tworzenie dokumentów
dzięki obszarom roboczym zespołów, blogom
i witrynom wiki.
• Strukturalne tworzenie dokumentów ze scentra-
lizowanym przepływem pracy i kontrolą proce-
sów.
• Funkcje sygnalizacji obecności, wiadomości bły-
skawicznych i konferencji bezpośrednio wbudo-
wane w portale i obszary robocze zespołów i do-
stępne z poziomu klienta poczty elektronicznej.
• Możliwość wspólnej pracy zespołów z różnych
lokalizacji, wewnątrz i spoza ram organizacyj-
nych.
• Integracja zarządzania rekordami i dokumenta-
mi z aplikacjami biurowymi i bazodanowymi.
• Możliwość prostego, dostępnego dla użytkow-
ników konfigurowania mechanizmów śledzenia
i monitorowania kluczowych wskaźników wydaj-
ności,
W związku z tak postawionymi założeniami PJK ma
zapewnić:
• Efektywną wymianę informacji z możliwością
wyboru formy komunikacji i niezależnie od loka-
lizacji pracowników.
• Ulepszoną komunikacja poprzez wykorzystanie
statusu obecności i konferencje w czasie rzeczy-
wistym.
• Zarządzanie, sortowanie i praca z różnymi typa-
mi wiadomości, bez konieczności przełączania
się pomiędzy aplikacjami czy systemami.
• Dostęp z dowolnego miejsca poprzez dostęp
do usług komunikacyjnych z poziomu pulpitu,
przeglądarki sieci Web i urządzeń mobilnych.
Planując założenia do systemu warto przewidzieć
obsługę następujących funkcjonalności:
1. Status obecności – informacja o statusie
dostępności użytkowników (dostępny, zajęty,
z dala od komputera), prezentowana w formie
graficznej, zintegrowana z usługą katalogową
i kalendarzem, a dostępna w interfejsach poczty
elektronicznej, komunikatora i portalu wielo-
funkcyjnego.
2. Krótkie wiadomości tekstowe – Możliwość
komunikacji typu chat. Możliwość grupowania
kontaktów, możliwość konwersacji typu jeden-
do-jednego, jeden-do-wielu, możliwość rozszer-
zenia komunikacji o dodatkowe media (głos,
wideo) w trakcie trwania sesji chat. Możliwość
komunikacji z darmowymi komunikatorami in-
ternetowymi (AOL, Skype, Yahoo). Możliwość
administracyjnego zarządzania treściami prz-
esyłanymi w formie komunikatów tekstowych.
3. Obsługę komunikacji głosowej – Możli-
wość realizowania połączeń głosowych między
użytkownikami lokalnymi, możliwość realizac-
ji połączeń głosowych do i z sieci PSTN (pub-
licznej sieci telefonicznej). Możliwość realizac-
ji funkcjonalności RCC (Remote Call Controll)
tj. zarządzania telefonem stacjonarnym firm
trzecich z poziomu komunikatora. Obsługa stac-
jonarnych telefonów IP.
4. Obsługę komunikacji wideo – Możliwość zest-
awiania połączeń wideo-telefonicznych
5. Obsługę konferencji wirtualnych – Możliwość
realizacji konferencji wirtualnych z wykorzysta-
niem głosu i wideo. Możliwość współdzielenia
aplikacji jak również całego pulpitu. Możliwość
nagrywania konferencji na centralnym serwer-
ze jak również lokalnie przez uczestników. Zapis

18
nagrania konferencji do formatu umożliwiające-
go odtwarzanie z poziomu serwera WWW. Au-
tomatyzacja planowania konferencji - zaprosze-
nia rozsyłane są automatycznie w postaci poczty
elektronicznej.
6. Wsparcie dla funkcjonalności single sign-on
– po zalogowaniu w systemie operacyjnym użyt-
kownik nie musi ponownie podawać ponownie
nazwy użytkownika i hasła..
7.3.8. Wstępne wymiarowanie serwerów
4x AD (2 da EX)
2x adfs/dirsync
2x adfs proxy
2 x EX (sprzet do wyliczenia)
2xSQL – klaster
2 x SCCM ( w tym wsus)
4 x SharePoint (inicjalna farma )
3 x Skype for Business
Rysunek 5: Architektura zunifikowanej komunikacji (UC)
Skype
Yahoo
Windows Live
Chmura
publicznych
usług IM
PSTN
Użytkownicy
zdalni
Organizacje
stowarzyszone
DMZ
Dostęp do UC
Serwery
brzegowe
Serwery
Front-End
Funkcje:
• IM/Obecność
• Konferencje
• Głos
• Udostępnianie Aplikacji
Audio Video
SIP
Baza SQL
Wdzwanianie
konferencji
Serwer Mediacji
Media GW
Exchange UM
Poczta Głosowa
Serwer
monitorujący
Udostępnianie
plików
Active
Directory
Serwer
archiwizacji

19

20
8. Wymagania techniczne dla standardowych
komponentów systemu
8.1. System zarządzania i monitorowania podstawowej infrastruktury
Oprogramowanie do zarządzania i monitorowania podstawowej infrastruktury musi posiadać następujące
cechy
Zarządzanie serwerem musi obejmować wszystkie funkcje zawarte w opisanych poniżej modułach:
• System zarządzania infrastrukturą i oprogramowaniem
• System zarządzania komponentami
• System zarządzania środowiskami wirtualnym
• System tworzenia kopii zapasowych
• System automatyzacji zarządzania środowisk IT
• System zarządzania incydentami i problemami
• Ochrona antymalware
System zarządzania infrastrukturą i oprogramowaniem
System zarządzania infrastrukturą i oprogramowaniem musi spełniać następujące wymagania poprzez wbu-
dowane mechanizmy, bez użycia dodatkowych aplikacji.
1. Inwentaryzacja i zarządzanie zasobami:
a. Inwentaryzacja zasobów serwera powinna się odbywać w określonych przez administratora syste-
mu interwałach czasowych. System powinien mieć możliwość odrębnego planowania inwentaryzacji
sprzętu i oprogramowania
b. Inwentaryzacja sprzętu powinna się odbywać przez pobieranie informacji z interfejsu WMI, kompo-
nent inwentaryzacyjny powinien mieć możliwość konfiguracji w celu ustalenia informacji, o jakich
podzespołach będą przekazywane do systemu
c. Inwentaryzacja oprogramowania powinna skanować zasoby dyskowe przekazując dane o znalezio-
nych plikach do systemu w celu identyfikacji oprogramowania oraz celów wyszukiwania i gromadze-
nia informacji o szczególnych typach plików (np. pliki multimedialne: wav, mp3, avi, xvid, itp…)
d. System powinien posiadać własną bazę dostępnego na rynku komercyjnego oprogramo-
wania, pozwalającą na identyfikację zainstalowanego i użytkowanego oprogramowania.
System powinien dawać możliwość aktualizacji tej bazy przy pomocy konsoli administratora oraz
automatycznie przez aktualizacje ze stron producenta
e. Informacje inwentaryzacyjne powinny być przesyłane przy pomocy plików różnicowych w celu ogra-
niczenia ruchu z agenta do serwera
2. Użytkowane oprogramowanie – pomiar wykorzystania
a. System powinien mieć możliwość zliczania uruchomionego oprogramowania w celu śledzenia wyko-
rzystania
b. Reguły dotyczące monitorowanego oprogramowania powinny być tworzone automatycznie przez
skanowanie oprogramowania uruchamianego.
3. System powinien dostarczać funkcje dystrybucji oprogramowania, dystrybucja i zarządzania aktualizacja-
mi, instalacja/aktualizacja systemów operacyjnych.
a. System powinien umożliwiać dystrybucją oprogramowania w trybie wymaganym, opcjonalnym lub
na prośbę użytkownika

21
b. System powinien dawać możliwość integracji dostępnych zadań dystrybucji (pakietów instalacyjnych)
z obsługą oprogramowania systemów Windows (dostępne do instalacji pakiety powinny się pojawiać
w Panelu Sterowania w sekcji Dodaj/Usuń Programy, w części Dodaj Nowe Programy)
c. System powinien posiadać narzędzia pozwalające na przeskanowanie serwerów pod kątem zain-
stalowanych poprawek dla systemów operacyjnych Windows oraz dostarczać narzędzia dla innych
producentów oprogramowania (ISVs) w celu przygotowania reguł skanujących i zestawów poprawek
d. System powinien posiadać możliwość instalacji wielu poprawek jednocześnie bez konieczności re-
startu komputera w trakcie instalacji kolejnych poprawek
e. System powinien udostępniać informacje o aktualizacjach systemów operacyjnych Windows dostęp-
nych na stronach producenta (Windows Update) oraz informacje o postępie instalacji tych aktualizacji
na serwerach (również w postaci raportów). System powinien również umożliwiać skanowanie i inwen-
taryzację poprawek, które były już instalowane wcześniej niezależnie od źródła dystrybucji
f. System powinien umożliwiać instalację lub aktualizację systemu operacyjnego ze zdefiniowanego
wcześniej obrazu, wraz z przeniesieniem danych użytkownika (profil)
g. Przy przenoszeniu danych użytkownika, powinny one na czas migracji być składowane w specjalnym,
chronionym (zaszyfrowanym) zasobie
h. System powinien zawierać wszystkie narzędzia do sporządzenia, modyfikacji i dystrybucji obrazów
na dowolny komputer, również taki, na którym nie ma żadnego systemu operacyjnego (bare metal)
i. System powinien być zintegrowany z oprogramowaniem antywirusowym i być zarządzany przy po-
mocy jednej wspólnej konsoli do zarządzania.
4. Definiowanie i sprawdzanie standardu serwera:
a. System powinien posiadać komponenty umożliwiające zdefiniowanie i okresowe sprawdzanie stan-
dardu serwera, standard ten powinien być określony zestawem reguł sprawdzających definiowanych
z poziomu konsoli administracyjnej,
b. Reguły powinny sprawdzać następujące elementy systemy komputerowego:
◦◦ stan usługi (Windows Service)
◦◦ obecność poprawek (Hotfix)
◦◦ WMI
◦◦ rejestr systemowy
◦◦ system plików
◦◦ Active Directory
◦◦ SQL (query)
◦◦ IIS Metabase
c. Dla reguł sprawdzających system powinien dawać możliwość wprowadzenia wartości poprawnej, któ-
ra byłaby wymuszana w przypadku odstępstwa lub wygenerowania alertu administracyjnego w sytu-
acji, kiedy naprawa nie jest możliwa.
5. Raportowanie, prezentacja danych:
a. System powinien posiadać komponent raportujący oparty o technologie webową (wydzielony portal
z raportami) i/lub
b. Wykorzystujący mechanizmy raportujące dostarczane wraz z silnikami bazodanowymi, np. SQL Re-
porting Services
c. System powinien posiadać predefiniowane raport w następujących kategoriach:
◦◦ Sprzęt (inwentaryzacja)
◦◦ Oprogramowanie (inwentaryzacja)
◦◦ Oprogramowanie (wykorzystanie)
◦◦ Oprogramowanie (aktualizacje, w tym system operacyjny)

22
d. System powinien umożliwiać budowanie stron z raportami w postaci tablic (dashboard), na których
może znajdować się więcej niż jeden raport
e. System powinien posiadać konsolę administratora, w postaci programu do zainstalowania na stacjach
roboczych, obsługującą wszystkie funkcje systemu
f. Konsola powinna zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu (poza opcjami do-
stępnymi w procesie instalacji i wstępnej konfiguracji), w tym:
◦◦ konfigurację granic systemu zarządzania
◦◦ konfigurację komponentów systemu zarządzania
◦◦ konfigurację metod wykrywania serwerów, użytkowników i grup
◦◦ konfigurację metod instalacji klienta
◦◦ konfiguracje komponentów klienta
◦◦ grupowanie serwerów (statyczne, dynamiczne na podstawie zinwentaryzowanych parametrów)
◦◦ konfiguracje zadań dystrybucji, pakietów instalacyjnych, itp…
◦◦ konfigurację reguł wykorzystania oprogramowania
◦◦ konfigurację zapytań (query) do bazy danych systemu
◦◦ konfiguracje raportów
◦◦ podgląd zdarzeń oraz zdrowia komponentów systemu.
6. Analiza działania systemu, logi, komponenty
a. Konsola systemu powinna dawać dostęp do podstawowych logów obrazujących pracę poszczegól-
nych komponentów, wraz z oznaczaniem stanu (OK, Warning, Error) w przypadku znalezienia zdarzeń
wskazujących na problemy
b. Konsola systemu powinna umożliwiać podgląd na stan poszczególnych usług wraz z podstawowymi
informacjami o stanie usługi, np. ilość wykorzystywanego miejsca na dysku twardym.
System zarządzania komponentami
System zarządzania komponentami musi udostępniać funkcje pozwalające na budowę bezpiecznych i skalo-
walnych mechanizmów zarządzania komponentami IT spełniając następujące wymagania:
1. Architektura
a. System zarządzania komponentami powinien składać się z:
◦◦ Serwera Zarządzającego,
◦◦ Serwer zarządzania jest punktem centralnym do zarządzanie grupą (pulą) serwerów i komuni-
kowania się z bazą danych. Po otwarciu konsoli serwera możliwe jest podłączenie się do grupy
zarządzającej, W zależności od wielkości środowiska komputerowego, grupa zarządzania może
zawierać jeden lub wiele serwerów połączonych w pule zasobów.
◦◦ Bazy Operacyjnej przechowującej informacje o zarządzanych elementach,
◦◦ baza operacyjna jest relacyjną bazą danych, która zawiera wszystkie dane konfiguracyjne dla za-
rządzanej grupy serwerów i przechowuje wszystkie dane związane z monitorowaniem. Baza Ope-
racyjna zachowuje dane krótkoterminowe, domyślnie 7 dni.
◦◦ Baza Hurtowej przechowującej dane do analiz historycznych, definiuje granicę czasową do retencji
danych historycznych.
b. System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster typu fail-over).
c. System musi pozwalać na zarządzanie platformami wirtualizacyjnymi, co najmniej trzech różnych
dostawców.
d. Serwery zarządzające muszą mieć możliwość publikowania informacji o uruchomionych komponen-
tach w usługach katalogowych, informacje te powinny być odstępne dla klientów systemu w celu

23
automatycznej konfiguracji.
e. Możliwość budowania struktury wielopoziomowej (tiers) w celu separacji pewnych grup kompute-
rów/usług.
f. System uprawnień musi być oparty o role (role based security), użytkownicy i grupy użytkowników
w poszczególnych rolach powinny być pobierane z usług katalogowych.
g. Możliwość definiowania użytkowników do wykonywania poszczególnych zadań na klientach i serwe-
rze zarządzającym, w tym zdefiniowany użytkownik domyślny.
h. Uwierzytelnianie klientów na serwerze zarządzającym przy pomocy certyfikatów w standardzie X.509,
z możliwością odrzucania połączeń od klientów niezaakceptowanych.
i. Kanał komunikacyjny pomiędzy klientami a serwerem zarządzającym powinien być szyfrowany.
j. Możliwość budowania systemu w oparciu o łącza publiczne - Internet (bez konieczności wydzielania
kanałów VPN).
k. Wsparcie dla protokołu IPv6.
l. System powinien udostępniać funkcje autodiagnostyczne, w tym: monitorowanie stanu klientów,
możliwość automatycznego lub administracyjnego restartu klienta, możliwość reinstalacji klienta.
2. Audyt zdarzeń bezpieczeństwa
System musi udostępniać komponenty i funkcje pozwalające na zbudowanie systemu zbierającego zdarzenia
związane z bezpieczeństwem monitorowanych systemów i gwarantować:
a. Przekazywanie zdarzeń z podległych klientów w czasie „prawie” rzeczywistym (dopuszczalne opóź-
nienia mogą pochodzić z medium transportowego – sieć, oraz komponentów zapisujących i odczy-
tujących).
b. Niskie obciążenie sieci poprzez schematyzację parametrów zdarzeń przed wysłaniem, definicja sche-
matu powinna być definiowana w pliku XML z możliwością dodawania i modyfikacji.
c. Obsługę co najmniej 2500 zdarzeń/sek w trybie ciągłym i 100000 zdarzeń/sek w trybie „burst” – chwi-
lowy wzrost ilości zdarzeń, jeden kolektor zdarzeń powinien obsługiwać, co najmniej 100 kontrolerów
domen (lub innych systemów autentykacji i usług katalogowych) lub 1000 serwerów.
3. Konfiguracja i monitorowanie
System musi umożliwiać zbudowanie jednorodnego środowiska monitorującego, korzystając z takich samych
zasad do monitorowania różnych komponentów, a w tym:
a. Monitorowane obiekty powinny być grupowane (klasy) w oparciu o atrybuty, które można wykryć
na klientach systemu w celu autokonfiguracji systemu. Powinny być wykrywane - co najmniej, atry-
buty pobierane z:
◦◦ rejestru
◦◦ WMI
◦◦ OLEDB
◦◦ LDAP
◦◦ skrypty (uruchamiane w celu wykrycia atrybutów obiektu),
W definicjach klas powinny być również odzwierciedlone zależności pomiędzy nimi.
b. Na podstawie wykrytych atrybutów system powinien dokonywać autokonfiguracji klientów, przez
wysłanie odpowiadającego wykrytym obiektom zestawu monitorów, reguł, skryptów, zadań, itp…
c. Wszystkie klasy obiektów, monitory, reguły, skrypty, zadania, itp... elementy służące konfiguracji sys-
temu muszą być grupowane i dostarczane w postaci zestawów monitorujących, system powinien
posiadać w standardzie zestawy monitorujące, co najmniej dla:

24
◦◦ Windows Server 2003 SP2
◦◦ Windows 2008 Server SP2
◦◦ Windows 2008 Server R2
◦◦ Windows 2008 Server R2 SP1
◦◦ Windows Server 2012
◦◦ Windows Server 2012 R2
◦◦ Windows Client OS:
-- Windows XP Pro x64 SP2
-- Windows XP Pro SP32
-- Windows Vista SP2
-- Windows XP Embedded Standard
-- Windows XP Embedded Enterprise
-- Windows XP Embedded POSReady
-- Windows 7 Professional for Embedded Systems
-- Windows 7 Ultimate for Embedded Systems
-- Windows 7
-- Windows 8
-- Windows 8.1
◦◦ Active Directory 2003/2008
◦◦ Exchange 2003/2007/2010
◦◦ Microsoft SharePoint 2003/2007/2010
◦◦ Microsoft SharePoint Services 3.0
◦◦ Microsoft SharePoint Foundation 2010
◦◦ SQL 2005/2008/2008R2 (x86/x64/ia64)
◦◦ Information Worker (Office, IExplorer, Outlook, itp…)
◦◦ IIS 6.0/7.0/7.5
◦◦ Linux/Unix
-- HP-UX 11i V2 (PA-RISC and Itanium)
-- HP-UX 11i V3 (PA-RISC and Itanium)
-- Oracle Solaris 9 (SPARC)
-- Oracle Solaris 10 (SPARC and x86)
-- Oracle Solaris 11 (SPARC and x86)
-- Red Hat Enterprises Linux 4 (x86/x64)
-- SUSE Linux Enterprise Server 9 (x86)
-- SUSE Linux Enterprise Server 10 (x86/x64)
-- SUSE Linux Enterprise Server 11 (x86/x64)
-- IBM AIX 5.3 (POWER)
-- Cent OS 5 (x86/x64)
-- Cent OS 6 (x86/x64)
-- Debian 5 (x86/x64)
-- Debian 6 (x86/x64)
-- Ubuntu Server 10.04 (x86/x64)
-- Ubuntu Server 12.04 (x86/x64)
◦◦ Usług i zasobów infrastruktury zlokalizowanej w Chmurze Publicznej np. Azure/AWS/Google

25
d. System powinien posiadać możliwość monitorowania za pomocą agenta lub bez niego.
e. System musi pozwalać na wykrycie oraz monitorowanie urządzeń sieciowych (routery, przełączniki
sieciowe, itp.) za pomocą SNMP v1, v2c oraz v3. System monitorowania w szczególności powinien
mieć możliwość zbierania następujących informacji:
◦◦ interfejsy sieciowe
◦◦ porty
◦◦ sieci wirtualne (VLAN)
◦◦ grupy Hot Standby Router Protocol (HSRP)
f. System zarządzania musi mieć możliwość czerpania informacji z następujących źródeł danych:
◦◦ SNMP (trap, probe)
◦◦ WMI Performance Counters
◦◦ Log Files (text, text CSV)
◦◦ Windows Events (logi systemowe)
◦◦ Windows Services
◦◦ Windows Performance Counters (perflib)
◦◦ WMI Events
◦◦ Scripts (wyniki skryptów, np.: WSH, JSH)
◦◦ Unix/Linux Service
◦◦ Unix/Linux Log
g. Na podstawie uzyskanych informacji monitor powinien aktualizować status komponentu, powinna
być możliwość łączenia i agregowania statusu wielu monitorów
4. Tworzenie reguł
a. W systemie zarządzania powinna mieć możliwość czerpania informacji z następujących źródeł da-
nych:
◦◦ Event based (text, text CSV, NT Event Log, SNMP Event, SNMP Trap, syslog, WMI Event)
◦◦ Performance based (SNMP performance, WMI performance, Windows performance)
◦◦ Probe based (scripts: event, performance)
b. System musi umożliwiać przekazywanie zebranych przez reguły informacji do bazy danych w celu
ich późniejszego wykorzystania w systemie, np. raporty dotyczące wydajności komponentów, alarmy
mówiące o przekroczeniu wartości progowych czy wystąpieniu niepożądanego zdarzenia.
c. Reguły zbierające dane wydajnościowe muszą mieć możliwość ustawiania tolerancji na zmiany, w celu
ograniczenia ilości nieistotnych danych przechowywanych w systemie bazodanowym. Tolerancja po-
winna mieć, co najmniej dwie możliwości:
d. na ilość takich samych próbek o takiej samej wartości
e. na procentową zmianę od ostatniej wartości próbki.
f. Monitory sprawdzające dane wydajnościowe w celu wyszukiwania wartości progowych muszą mieć
możliwość – oprócz ustawiania progów statycznych, „uczenia” się monitorowanego parametru w za-
kresie przebiegu bazowego „baseline” w zadanym okresie czasu.
g. System musi umożliwiać blokowanie modyfikacji zestawów monitorujących, oraz definiowanie wyjąt-
ków na grupy komponentów lub konkretne komponenty w celu ich odmiennej konfiguracji.
h. System powinien posiadać narzędzia do konfiguracji monitorów dla aplikacji i usług, w tym:
◦◦ ASP .Net Application
◦◦ ASP .Net Web Service
◦◦ OLE DB

26
◦◦ TCP Port
◦◦ Web Application
◦◦ Windows Service
◦◦ Unix/Linux Service
◦◦ Process Monitoring
Narzędzia te powinny pozwalać na zbudowanie zestawu predefiniowanych monitorów dla wybranej aplikacji
i przyporządkowanie ich do wykrytej/działającej aplikacji
i. System musi posiadać narzędzia do budowania modeli aplikacji rozproszonych (składających się
z wielu wykrytych obiektów), pozwalając na agregację stanu aplikacji oraz zagnieżdżanie aplikacji.
j. Z każdym elementem monitorującym (monitor, reguła, alarm, itp…) powinna być skojarzona baza
wiedzy, zawierająca informacje o potencjalnych przyczynach problemów oraz możliwościach jego
rozwiązania (w tym możliwość uruchamiania zadań diagnostycznych z poziomu).
k. System musi zbierać informacje udostępniane przez systemy operacyjne Windows o przyczynach
krytycznych błędów (crash) udostępnianych potem do celów analitycznych.
l. System musi umożliwiać budowanie obiektów SLO (Service Level Object) służących przedstawianiu
informacji dotyczących zdefiniowanych poziomów SLA (Service Level Agreement) przynajmniej dla
monitora (dostępność) i licznika wydajności (z agregacją dla wartości – min, max, avg).
5. Przechowywanie i dostęp do informacji
a. Wszystkie informacje operacyjne (zdarzenia, liczniki wydajności, informacje o obiektach, alarmy, itp…)
powinny być przechowywane w bazie danych operacyjnych.
b. System musi mieć co najmniej jedną bazę danych z przeznaczeniem na hurtownię danych do celów
historycznych i raportowych. Zdarzenia powinny być umieszczane w obu bazach jednocześnie, aby
raporty mogłyby być generowane w oparciu o najświeższe dane.
c. System musi mieć osobną bazę danych, do której będą zbierane informacje na temat zdarzeń security
z możliwością ustawienia innych uprawnień dostępu do danych tam zawartych (tylko audytorzy).
d. System powinien mieć zintegrowany silnik raportujący niewymagający do tworzenia raportów uży-
wania produktów firm trzecich. Produkty takie mogą być wykorzystanie w celu rozszerzenia tej funk-
cjonalności.
e. System powinien mieć możliwość generowania raportów na życzenie oraz tworzenie zadań zaplano-
wanych.
f. System powinien umożliwiać eksport stworzonych raportów przynajmniej do następujących formatów:
◦◦ XML
◦◦ CSV
◦◦ TIFF
◦◦ PDF
◦◦ XLS
◦◦ Web archive
6. Konsola systemu zarządzania
a. Konsola systemu musi umożliwiać pełny zdalny dostęp do serwerów zarządzających dając dostęp
do zasobów zgodnych z rolą użytkownika korzystającego z konsoli.
b. System powinien udostępniać dwa rodzaje konsoli:
◦◦ w postaci programu do zainstalowania na stacjach roboczych, obsługującą wszystkie funkcje sys-
temu (konsola zdalna)
◦◦ w postaci web’owej dla dostępu do podstawowych komponentów monitorujących z dowolnej
stacji roboczej (konsola webowa).

27
c. Konsola zdalna powinna umożliwiać definiowanie każdemu użytkownikowi własnych widoków,
co najmniej w kategoriach:
◦◦ Alerts
◦◦ Events
◦◦ State
◦◦ Performance
◦◦ Diagram
◦◦ Task Status
◦◦ Web Page (dla użytkowników, którzy potrzebują podglądu tylko wybranych elementów systemu).
d. Konsola musi umożliwiać budowanie widoków tablicowych (dashboard) w celu prezentacji różnych
widoków na tym samym ekranie.
e. Widoki powinny mieć możliwość filtrowania informacji, jakie się na nich znajdą (po typie, ważności,
typach obiektów, itp…), sortowania oraz grupowania podobnych informacji, wraz z możliwością defi-
niowania kolumn, jakie mają się znaleźć na widokach „kolumnowych”.
f. Z każdym widokiem (obiektem w tym widoku) powinno być skojarzone menu kontekstowe, z naj-
częstszymi operacjami dla danego typu widoku/obiektu.
g. Konsola musi zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu (poza opcjami dostęp-
nymi w procesie instalacji i wstępnej konfiguracji), w tym:
◦◦ opcji definiowania ról użytkowników
◦◦ opcji definiowania widoków
◦◦ opcji definiowania i generowania raportów
◦◦ opcji definiowania powiadomień
◦◦ opcji tworzenia, konfiguracji i modyfikacji zestawów monitorujących
◦◦ opcji instalacji/deinstalacji klienta
h. Konsola musi pozwalać na pokazywanie obiektów SLO (Service Level Object) i raportów SLA (Service
Level Agreement) bez potrzeby posiadania konsoli i dostepu do samego systemu monitorującego,
na potrzeby użytkowników biznesowych (właścicieli procesu biznesowego).
7. Wymagania dodatkowe
System musi dostarczać API lub inny system (web service, connector) z publicznie dostępną dokumentacją
pozwalający m.in. na:
a. Budowanie konektorów do innych systemów, np. help-desk w celu przekazywania zdarzeń czy alar-
mów (dwukierunkowo),
b. Wykonywanie operacji w systemie z poziomu linii poleceń,
c. Podłączenie rozwiązań firm trzecich pozwalających na monitorowanie w jednolity sposób systemów
informatycznych niewspieranych natywnie przez system zarządzania,
d. Podłączenie do aplikacji biurowych pozwalające na integrację statycznych modeli (np. diagramów
Visio) z monitorowanymi obiektami, pozwalające na wyświetlanie ich stanu na diagramie,
System zarządzania środowiskami wirtualnym
System zarządzania środowiskami wirtualnymi musi posiadać następujące cechy:
1. Architektura
a. System zarządzania środowiskiem wirtualnym powinien składać się z:

28
◦◦ serwera zarządzającego,
◦◦ relacyjnej bazy danych przechowującej informacje o zarządzanych elementach,
◦◦ konsoli, instalowanej na komputerach operatorów,
◦◦ portalu self-service (konsoli webowej) dla operatorów „departamentowych”,
◦◦ biblioteki, przechowującej komponenty niezbędne do budowy maszyn wirtualnych,
◦◦ agenta instalowanego na zarządzanych hostach wirtualizacyjnych,
◦◦ „konektora” do systemu monitorującego pracę hostów i maszyn wirtualnych.
b. System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster typu fail-over).
c. System musi pozwalać na zarządzanie platformami wirtualizacyjnymi co najmniej trzech różnych do-
stawców.
2. Interfejs użytkownika
a. Konsola musi umożliwiać wykonywanie codziennych zadań związanych z zarządzaniem maszynami
wirtualnymi w sposób jak najbardziej intuicyjny.
b. Konsola musi umożliwiać grupowanie hostów i nadawanie uprawnień poszczególnym operatorom
do grup hostów.
c. Widoki hostów i maszyn wirtualnych powinny mieć możliwość zakładania filtrów, pokazując tylko
odfiltrowane elementy, np. maszyny wyłączone, maszyny z systemem operacyjnym X, itp...
d. Widok szczegółowy elementu w przypadku maszyny wirtualnej musi pokazywać stan, ilość alokowa-
nej pamięci i dysku twardego, system operacyjny, platformę wirtualizacyjną, stan ostatniego zadania,
oraz wykres utylizacji procesora i podgląd na pulpit.
e. Konsola musi posiadać odrębny widok z historią wszystkich zadań oraz statusem zakończenia po-
szczególnych etapów i całych zadań.
3. Scenariusze i zadania
a. Tworzenie maszyn wirtualnych – system musi umożliwiać stworzenie maszyny wirtualnej w co naj-
mniej dwóch trybach:
◦◦ Ad hoc – gdzie wszystkie elementy są wybierane przez operatora podczas tworzenia maszyny,
◦◦ Nadzorowany – gdzie operator tworzy maszynę korzystając z gotowego wzorca (template), a wzo-
rzec składa się z przynajmniej 3-ech elementów składowych:
-- profilu sprzętowego
-- profilu systemu operacyjnego,
-- przygotowanych dysków twardych,
b. Predefiniowane elementy muszą być przechowywane w bibliotece systemu zarządzania.
c. System musi umożliwiać przenoszenie maszyny wirtualnej pomiędzy zarządzanymi hostami:
d. w trybie migracji „on-line” – bez przerywania pracy,
e. w trybie migracji „off-line – z zapisem stanu maszyny
f. System musi umożliwiać automatyczne, równomierne rozłożenie obciążenia pomiędzy zarządzanymi
hostami.
g. System musi umożliwiać wyłączenie hosta, gdy jego zasoby nie są konieczne do pracy, w celu oszczęd-
ności energii. System powinien również umożliwiać ponowne włączenie takiego hosta.
h. System musi umożliwiać przełączenie wybranego hosta w tryb „maintenance” w przypadku wystą-
pienia awarii lub w celu przeprowadzenia planowanych prac serwisowych. Uruchomienie tego trybu
musi skutkować migracją maszyn na inne hosty lub zapisaniem ich stanu.
i. System musi posiadać możliwość konwersji maszyny fizycznej do wirtualnej.
j. System misi posiadać (bez potrzeby instalowania dodatkowego oprogramowania) - możliwość wykry-
cia maszyny fizycznej w sieci i instalacje na niej systemu operacyjnego wraz z platformą do wirtualizacji.

29
4. Wymagania dodatkowe
a. System musi informować operatora o potrzebie migracji maszyn, jeśli wystąpią nieprawidłowe zda-
rzenia na hoście lub w innych maszynach wirtualnych mające wpływ na ich pracę, np. awarie sprzętu,
nadmierna utylizacja współdzielonych zasobów przez jedną maszynę.
b. System musi dawać operatorowi możliwość implementacji w/w migracji w sposób automatyczne bez
potrzeby każdorazowego potwierdzania.
c. System musi kreować raporty z działania zarządzanego środowiska, w tym:
◦◦ utylizacja poszczególnych hostów,
◦◦ trend w utylizacji hostów,
◦◦ alokacja zasobów na centra kosztów,
◦◦ utylizacja poszczególnych maszyn wirtualnych,
◦◦ komputery-kandydaci do wirtualizacji
d. System musi umożliwiać skorzystanie z szablonów:
◦◦ wirtualnych maszyn
◦◦ usług
oraz profili dla:
◦◦ aplikacji
◦◦ serwera SQL
◦◦ hosta
◦◦ sprzętu
◦◦ systemu operacyjnego gościa
e. System musi umożliwiać tworzenie chmur prywatnych na podstawie dostępnych zasobów (hosty,
sieci, przestrzeń dyskowa, biblioteki zasobów).
f. System musi posiadać możliwość przygotowania i instalacji zwirtualizowanej aplikacji serwerowej.
g. System musi pozwalać na skalowalność wirtualnego środowiska aplikacji (poprzez automatyczne do-
danie wirtualnej maszyny z aplikacją)
System tworzenia kopii zapasowych
System tworzenia i odtwarzania kopii zapasowych danych (backup) musi spełniać następujące wymagania:
1. Architektura:
a. System musi składać się z serwera zarządzającego kopiami zapasowymi i agentami kopii zapasowych
b. System musi posiadać agentów kopii zapasowych instalowanych na komputerach zdalnych
c. System musi posiadać konsolę administracyjną instalowaną lokalnie na komputerach użytkowników
zarządzających systemem
d. System musi posiadać własną bazę danych (niewymagającą dodatkowych zakupów)
2. Wykonywanie kopii zapasowych:
a. System kopii zapasowych musi wykorzystywać mechanizm migawkowych kopii – VSS (Volume Sha-
dowCopy Service)
b. System kopii zapasowych musi posiadać możliwości zapisu danych na:
◦◦ na puli magazynowej złożonej z dysków twardych
◦◦ na napędach I bibliotekach taśmowych
◦◦ podłączonych zdalnie zasobach chmurowych

30
c. System kopii zapasowych musi umożliwiać zdefiniowanie ochrony zasobów krótkoterminowej, dłu-
goterminowej i online (chmura). Oznacza to, iż krótkookresowe kopie mogą być tworzone w puli
magazynowej, a długookresowe na napędach i bibliotekach taśmowych
d. System kopii zapasowych powinien wykonywać zapis na napędach dyskowych i zasobach chmuro-
wych w postaci repliki danych produkcyjnych (pierwszy backup) a następnie odkładanie tylko zmie-
nionych partii danych
e. System kopii zapasowych powinien wykonywać zapis na napędach i bibliotekach taśmowych w posta-
ci pełnego backupu na chwilę wykonywania zadania.
f. System kopii zapasowych musi umożliwiać synchronizację przechowywanych kopii zapasowych (ko-
pie różnicowe) z produkcyjnymi transakcyjnymi bazami danych na poziomie poniżej 30 minut. Kopie
te muszą być tworzone w ciągu godzin pracy, w niezauważalny dla użytkowników końcowych sposób.
g. System kopii zapasowych musi umożliwiać odtworzenie dowolnego 30 minutowego kwantu czasu
dla krytycznych systemów, takich jak bazy danych.
h. System kopii zapasowych musi umożliwiać rozwiązanie automatycznego przenoszenia chronionych
danych do zdalnej lokalizacji (nadrzędny serwer kopii zapasowych), wykorzystując przy tym mecha-
nizm regulacji przepustowości.
i. System powinien umożliwiać skonfigurowanie okresu przechowywania danych (retention) dla po-
szczególnych typów ochrony:
◦◦ Krótkoterminowe: Pule dyskowe – do 448 dni
◦◦ Online: Zasoby chmurowe – do 3360 dni
◦◦ Krótkoterminowe: Taśmy – do 12 tygodni
◦◦ Długoterminowe: Taśmy – do 99 lat
3. Odzyskiwanie danych:
a. System kopii zapasowych musi umożliwiać odzyskanie chronionych zasobów plikowych użytkownika
na jego komputerze z poziomu zakładki „Poprzednie wersje”
b. System kopii zapasowych musi umożliwiać odtworzenie danych do:
◦◦ lokalizacji oryginalnej
◦◦ lokalizacji alternatywnej
◦◦ w przypadku nadrzędnego serwera kopii zapasowych (w centrum zapasowym) do podrzędnego
serwera kopii zapasowych
4. Agent kopii zapasowej
a. Agent powinien posiadać możliwość współpracy z komponentami VSC.
b. Agent powinien posiadać możliwość sterowania pasmem a w szczególności określenia godzin „biz-
nesowych” oraz wykorzystywanego pasma w i poza godzinami „biznesowymi”
c. Agent powinien rozpoznawać podstawowe aplikacje i systemy wykorzystywane w środowisku zama-
wiającego i automatycznie dodawać wszystkie wymagane pliki do puli chronionej, w tym:
◦◦ System operacyjny Windows (w tym pliki, system state i BMR)
◦◦ Maszyny wirtualne na platformie Hyper-V
◦◦ Bazy danych MS SQL
◦◦ Sharepoint
◦◦ Exchange
5. Konsola administracyjna:
a. Konsola powinna umożliwiać tworzenie określonych harmonogramów wykonywania kopii zapaso-
wych na chronionych agentach

31
b. Konsola powinna umożliwiać grupowanie chronionych zasobów ze względu na typy chronionych
zasobów
c. Zarządzanie agentami i zadaniami kopii zapasowych powinno być możliwe również za pomocą linii
poleceń
d. Konsola powinna posiadać mechanizm kontrolowania wykonywanych zadań kopii zapasowych
e. Konsola powinna posiadać mechanizm notyfikacji administratorów odnośnie zdarzeń w systemie ko-
pii zapasowych
f. Konsola powinna posiadać wbudowany system raportujący (m.in. raporty dotyczące zużycia puli ma-
gazynowej, wykonania kopii zapasowych, itp.).
System automatyzacji zarządzania środowisk IT
System automatyzacji zarządzania środowisk IT musi udostępniać środowisko standaryzujące i automatyzu-
jące zarządzanie procesami w systemach IT na bazie najlepszych praktyk.
1. Architektura:
a. System musi posiadać graficzną konsolę dla administratorów (autorów) pozwalającą w łatwy sposób
(bez znajomości języków programowania) tworzenie przebiegów procesów (runbooks) przy pomocy
gotowych elementów aktywności.
b. System musi posiadać tester przebiegów pozwalający na sprawdzenie poprawności wykonywania
stworzonego przez administratora (autora) pokazując informacje o wykonaniu poszczególnych kro-
ków, informacje wchodzące i wychodzące z poszczególnych kroków, możliwość ustawiania pułapek
(breakpoints) oraz wykonywania krok po kroku.
c. System musi posiadać serwer zarządzający i własną bazę danych, w której przechowywane są infor-
macje o stworzonych przebiegach procesów oraz ich stanie.
d. System musi posiadać serwery wykonawcze, które realizują przebiegi procesów zdefiniowane przez
administratorów (autorów).
e. System powinien posiadać konsolę webową pozwalającą na podgląd zdefiniowanych przebiegów
procesów, ich stanu, informacji historycznych o wykonanych przebiegach oraz pozwalająca na uru-
chamianie przebiegów procesów na żądanie.
f. System powinien posiadać własną bazę danych (niewymagającą dodatkowych zakupów).
2. Tworzenie przebiegów:
a. Do tworzenia przebiegów procesów powinny być gotowe zestawy aktywności, które przy pomocy
graficznego środowiska pracy (konsola administratora) autor może łączyć w gotowe przebiegi.
b. Zestawy aktywności powinny być dostarczane do systemu w postaci pakietów, zawierających gotowe
przygotowane aktywności dla zadanego obszaru.
c. System powinien posiadać podstawowy (wbudowany) zestaw aktywności w następujących obszarach:
◦◦ System:
-- Run Program
-- Run .Net Script
-- End Process
-- Start/Stop Service
-- Restart System
-- Save Event Log
-- Query WMI
-- Run SSH Command
-- Get SNMP Variable
-- Monitor SNMP Trap

32
-- Send SNMP Trap
-- Set SNMP Variable
◦◦ Planowanie:
-- Monitor Date/Time
-- Check Schedule
◦◦ Monitorowanie:
-- Monitor Event Log
-- Monitor Service
-- Get Service Status
-- Monitor Process
-- Get Process Status
-- Monitor Computer/IP Status
-- Monitor Disk Space
-- Get Disk Space Status
-- Monitor Internet Application
-- Get Internet Application Status
-- Monitor WMI
◦◦ Zarządzanie plikami:
-- Compress File
-- Copy File
-- Create Folder
-- Decompress File
-- Delete File
-- Delete Folder
-- Get File Status
-- Monitor File
-- Monitor Folder
-- Move File
-- Move Folder
-- PGP Decrypt File
-- PGP Encrypt File
-- Print File
-- Rename File
◦◦ E-mail:
-- Send E-mail
◦◦ Powiadomienia:
-- Send Event Log Message
-- Send Syslog Message
-- Send Platform Event
◦◦ Narzędzia:
-- Apply XSLT
-- Query XML

33
-- Map Published Data
-- Compare Values
-- Write Web Page
-- Read Text Log
-- Write to Database
-- Query Database
-- Monitor Counter
-- Get Counter Value
-- Modify Counter
-- Invoke Web Services
-- Format Date/Time
-- Generate Random Text
-- Map Network Path
-- Disconnect Network Path
-- Get Dial-up Status
-- Connect/Disconnect Dial-up
◦◦ Zarządzanie plikami tekstowymi:
-- Append Line
-- Delete Line
-- Find Text
-- Get Lines
-- Insert Line
-- Read Line
-- Search and Replace Text
◦◦ Kontrola przepływów (runbooks):
-- Invoke Runbook
-- Initialize Data
-- Junction
-- Return Data
d. System powinien posiadać również inne zestawy aktywności, które mogą być zaimportowane na ży-
czenie administratora (autora) w celu zarządzania procesami na innych systemach posiadanych przez
zamawiającego, w tym:
◦◦ Active Directory
◦◦ Exchange Admin
◦◦ Exchange Users
◦◦ FTP Integration
◦◦ HP iLO and OA
◦◦ HP Operations Manager
◦◦ HP Service Manager
◦◦ IBM Tivoli Netcool/OMNIbus
◦◦ Representational State Transfer (REST)
◦◦ Sharepoint
◦◦ Microsoft Azure
◦◦ VMware vSphere
◦◦ System Center

34
3. Serwer zarządzający i baza danych:
a. Serwer zarządzający powinien organizować jednoczesny dostęp konsoli graficznych administratorów
i zapewniać funkcje Check-In/Check-Out dla poszczególnych przebiegów uniemożliwiając jednocze-
sne zmiany tego samego przebiegu przez dwóch użytkowników.
b. Serwer zarządzający powinien zapewniać dostęp - na zdefiniowanym przez autora poziomie, dla po-
szczególnych przebiegów oraz zestawów przebiegów (całe katalogi).
c. Baza danych systemu powinna przechowywać:
◦◦ Definicje przebiegów procesów
◦◦ Stan uruchomionych przebiegów
◦◦ Informacje statusowe (logs)
◦◦ Dane konfiguracyjne systemu
System zarządzania incydentami i problemami
System zarządzania incydentami i problemami musi zapewniać zintegrowane środowisko pozwalające na uru-
chomienie usług wsparcia (service-desk) u zamawiającego.
1. Architektura:
a. System musi posiadać serwer zarządzający odpowiedzialny za wykonywanie wszystkich zadań zwią-
zanych z obsługą incydentów, problemów, zmian, zleceń, użytkowników, itp… zapewniając jednocze-
śnie wymuszenie odpowiednich uprawnień.
b. System musi posiadać zintegrowany komponent CMDB (Configuration Management Database)
c. System musi posiadać zintegrowany moduł bazy wiedzy (Knowledge Management)
d. System musi posiadać graficzną konsolę użytkownika instalowana lokalnie na komputerach pracow-
ników wsparcia.
e. System musi posiadać komponent hurtowni danych, odpowiedzialny za agregację i przechowywanie
danych historycznych i przygotowywanie raportów.
f. System musi posiadać własną bazę danych (niewymagającą dodatkowych zakupów)
g. System musi posiadać konsolę webową umożliwiającą pracownikom zgłaszanie incydentów/proble-
mów technicznych oraz zapotrzebowania na zasoby IT.
2. Procesy wsparcia:
a. System musi posiadać przygotowanie i dostępne po instalacji następujące procesy:
◦◦ Zarządzanie incydentami
◦◦ Zarządzanie problemami
◦◦ Zarządzanie zmianą
◦◦ Zarządzanie
b. W zakresie zarządzania incydentami i problemami system powinien posiadać:
◦◦ Przygotowane formatki do wprowadzania incydentów przez pracowników wsparcia, formatka po-
winna umożliwiać wprowadzenie, co najmniej następujących danych:
-- Narażony użytkownik,
-- Alternatywna metoda kontaktu,
-- Tytuł,
-- Opis,
-- Kategoria,

35
-- Pilność,
-- Wpływ,
-- Źródło,
-- Grupa pomocy technicznej,
-- Przypisany,
-- Podstawowy właściciel,
-- Uwzględnione usługi,
-- Narażone elementy,
-- Dziennik akcji (komentarz).
3. Komponent CMDB:
a. Baza danych CMDB powinna mieć domyślnie skonfigurowane podstawowe klasy obiektów wraz
z atrybutami i relacje pomiędzy nimi, w tym:
◦◦ Użytkownik:
-- Imię
-- Nazwisko
-- Inicjały
-- Tytuł,
-- Firma,
-- Dział,
-- Biuro,
-- Telefon służbowy,
-- Ulica i numer,
-- Miejscowość,
-- Województwo,
-- Kod pocztowy,
-- Kraj,
-- Strefa czasowa,
-- Ustawienia regionalne,
-- Komputery użytkownika
-- Urządzenia użytkownika
-- Elementy pokrewne (incydenty, problemy, zmiany, itp…)
◦◦ Komputer:
b. System musi posiadać gotowe konektory do innych skojarzonych systemów pozwalające na automa-
tyczną i planowana aktualizację odpowiednich rekordów w CMDB, a w szczególności:
◦◦ Konektor do systemu zarządzania infrastrukturą i oprogramowaniem
◦◦ Konektor do systemu zarządzania komponentami
◦◦ Konektor do systemu zarządzania środowiskami wirtualnym
◦◦ Konektor do systemu automatyzacji zarządzania środowisk IT
◦◦ Konektor do usługi katalogowej Active Directory
4. System musi mieć postać zintegrowanej platformy pozwalającej poprzez wbudowane i definiowane
mechanizmy w ramach przyjętej metodyki (np. MOF czy ITIL) na zarządzanie incydentami i problemami
oraz zarządzanie zmianą.
5. System powinien posiadać bazę wiedzy (CMDB) automatycznie zasilaną z takich systemów jak: usługa
katalogowa, system monitorujący, system do zarządzania desktopami.

36
6. System musi udostępniać narzędzia efektywnego zarządzania dostępnością usług, umożliwiających do-
starczenie użytkownikom systemów SLA na wymaganym poziomie.
7. System, poprzez integrację z systemami zarządzania i monitorowania musi zapewniać:
a. Optymalizację procesów i ich prawidłową realizację poprzez predefiniowane scenariusze, zgodne
z najlepszymi praktykami i założoną metodyką,
b. Redukcję czasu rozwiązywania problemów z działaniem systemów poprzez zapewnienie dotarcia wła-
ściwej, zagregowanej informacji do odpowiedniego poziomu linii wsparcia,
c. Automatyczne generowanie opisu problemów na bazie alarmów i kojarzenie zdarzeń w różnych kom-
ponentach systemu,
d. Wspomaganie procesów podejmowania decyzji poprzez integrację informacji i logikę ich powiązania,
e. Planowanie działań prewencyjnych poprzez kolekcjonowanie informacji o zachowaniach systemu
w przypadku incydentów,
f. Raportowanie pozwalające na analizy w zakresie usprawnień systemu oraz usprawnień procesów
ich opieki serwisowej,
g. Tworzenie baz wiedzy na temat rozwiązywania problemów,
h. Automatyzację działań w przypadku znanych i opisanych problemów,
i. Wykrywanie odchyleń od założonych standardów ustalonych dla systemu.
Ochrona antymalware
Oprogramowanie antymalware musi spełniać następujące wymagania:
1. Ochrona przed zagrożeniami typu wirusy, robaki, Trojany, rootkity, ataki typu phishing czy exploity ze-
ro-day.
2. Centralne zarządzanie ochroną serwerów poprzez konsolę System zarządzania infrastrukturą i opro-
gramowaniem
3. Centralne zarządzanie politykami ochrony.
4. Automatyzacja wdrożenia i wymiany dotychczasowych agentów ochrony.
5. Mechanizmy wspomagające masową instalację.
6. Pakiet ma wykorzystywać platformę skanowania, dzięki której dostawcy zabezpieczeń stosować mogą
technologię „minifiltrów”, skanujących w czasie rzeczywistym w poszukiwaniu złośliwego oprogramowa-
nia. Dzięki użyciu technologii minifiltrów, system ma wykrywać wirusy, oprogramowanie szpiegowskie
i inne pliki przed ich uruchomieniem, dając dzięki temu wydajną ochronę przed wieloma zagrożeniami,
a jednocześnie minimalizując zaangażowanie użytkownika końcowego.
7. Aparat ochrony przed złośliwym oprogramowaniem ma używać zaawansowanych technologii wykrywa-
nia, takich jak analiza statyczna, emulacja, heurystyka i tunelowanie w celu identyfikacji złośliwego opro-
gramowania i ochrony systemu. Ponieważ zagrożenia stają się coraz bardziej złożone, ważne jest, aby
zapewnić nie tylko oczyszczenie systemu, ale również poprawne jego funkcjonowanie po usunięciu złoś-
liwego oprogramowania. Aparat ochrony przed złośliwym oprogramowaniem w systemie ma zawierać
zaawansowane technologie oczyszczania, pomagające przywrócić poprawny stan systemu po usunięciu
złośliwego oprogramowania.
8. Generowanie alertów dla ważnych zdarzeń, takich jak atak złośliwego oprogramowania czy niepowodze-
nie próby usunięcia zagrożenia.
9. Tworzenie szczegółowych raportów zabezpieczeń systemów IT o określonych priorytetach, dzięki którym
użytkownik może wykrywać i kontrolować zagrożenia lub słabe punkty zabezpieczeń. Raporty mają obe-
jmować nie tylko takie informacje, jak ilość ataków wirusów, ale wszystkie aspekty infrastruktury IT, które
mogą wpłynąć na bezpieczeństwo firmy (np. ilość komputerów z wygasającymi hasłami, ilość maszyn,
na których jest zainstalowane konto „gościa”, itd.).
10. Pakiet ma umożliwiać zdefiniowanie jednej zasady konfigurującej technologie antyszpiegowskie, anty-
wirusowe i technologie monitorowania stanu jednego lub wielu chronionych komputerów. Zasady obe-
jmują również ustawienia poziomów alertów, które można konfigurować, aby określić rodzaje alertów
i zdarzeń generowanych przez różne grupy chronionych komputerów oraz warunki ich zgłaszania.

37
11. System ochrony musi być zoptymalizowany pod kątem konfiguracji ustawień agenta zabezpieczeń przy
użyciu Zasad Grupy usługi katalogowej oraz dystrybucji aktualizacji definicji.
8.2. System zarządzania stacjami roboczymi
System zarządzania stacjami roboczymi musi spełniać następujące wymagania:
1. Architektura Systemu UDM
Dostępna poprzez Internet na zasadzie subskrypcji usługa pozwalająca na budowę bezpiecznego i skalowal-
nego środowiska, a w szczególności:
a. Integrację z systemem SCCM 2012 R2 w oparciu o natywne interfejsy komunikacyjne
b. Wykorzystanie bazy użytkowników znajdujących się w Active Directory
c. Porozumiewania się z użytkownikiem końcowym w języku polskim.
2. Inwentaryzacja sprzętu i zarządzanie zasobami:
a. Inwentaryzacja zasobów urządzenia mobilnego odbywa się w interwałach czasowych.
b. Inwentaryzacja sprzętu pozwala na zbieranie następujących informacji
◦◦ Nazwa urządzenia
◦◦ Identyfikator urządzenia
◦◦ Nazwa platformy systemu operacyjnego
◦◦ Wersja oprogramowania układowego
◦◦ Typ procesora
◦◦ Model urządzenia
◦◦ Producent urządzenia
◦◦ Architektura procesora
◦◦ Język urządzenia
◦◦ Lista aplikacji zainstalowanych w ramach przedsiębiorstwa
3. Zdalna blokada i wymazanie:
a. W celu zapewnienia bezpieczeństwa danych usługa musi umożliwiać funkcjonalność zdalnej blokady,
wymazania urządzenia (przywrócenia urządzenia do ustawień fabrycznych) oraz selektywnego wy-
mazania danych i aplikacji.
b. Usługi te mają być możliwe do zrealizowania z poziomu SCCM (dla operatorów systemu) lub poprzez
dedykowany interfejs webowy lub aplikację (dla użytkownika urządzenia mobilnego).
4. Dystrybucja oprogramowania:
a. Pakiety instalacyjne dla aplikacji mobilnych mogą być przechowywany na specjalnie wydzielonych
zasobach sieciowych – punktach dystrybucyjnych (tak jak ma to miejsce dla dystrybucji aplikacji).
Punkty te mogą być zasobami sieciowymi lub wydzielonymi witrynami WWW lub punktami dystry-
bucyjnymi w usłudze.
b. Systemu UDM umożliwia dystrybucję oprogramowania na prośbę użytkownika, realizowaną poprzez
wybór oprogramowania w ramach dostępnego katalogu aplikacji
c. Katalog aplikacji jest zrealizowany w oparciu o dedykowaną witrynę webową lub dedykowaną aplika-
cję (dostępną dla poszczególnych platform w dedykowanych sklepach mobilnych).
d. Katalog aplikacji wspiera następujące formaty aplikacji mobilnych:
◦◦ *.appx (Windows RT)

38
◦◦ *.xap (Windows Phone 8)
◦◦ *.ipa (iOS)
◦◦ *.apk (Android)
e. Katalog aplikacji musi mieć możliwość publikowania aplikacji znajdujących się w następujących skle-
pach mobilnych aplikacji:
◦◦ Windows Store
◦◦ Windows Phone Store
◦◦ Android Google Play Store
◦◦ iOS App Store
5. Definiowanie polityk urządzenia mobilnego:
a. Komponenty umożliwiające zdefiniowanie standardu polityk urządzenia mobilnego. W obszarze po-
lityki haseł system zapewni:
◦◦ Zdefiniowanie wymuszenia hasła
◦◦ Określenia minimalnej długości hasła
◦◦ Określenia czasu wygasania hasła
◦◦ Określenia ilości pamiętanych haseł
◦◦ Określenia ilości prób nieudanego wprowadzenia hasła przed wyczyszczeniem urządzenia
◦◦ Określenia czasu bezczynności urządzenia, po jakim będzie wymagane podanie hasła
6. Raportowanie, prezentacja danych:
Usługa ma umożliwiać skorzystanie z szeregu predefiniowane raportów dedykowanych dla klas urządzeń
mobilnych. W szczególności w obszarze raportowania zainstalowanego oprogramowania jest możliwość ze-
brania informacji o zainstalowanym oprogramowaniu na urządzeniu firmowym lub urządzeniu użytkownika.
8.3. System poczty elektronicznej
Serwery systemu poczty elektronicznej muszą charakteryzować się następującymi cechami, bez konieczności
użycia rozwiązań firm trzecich:
1. Funkcjonalność podstawowa:
a. Odbieranie i wysyłanie poczty elektronicznej do adresatów wewnętrznych oraz zewnętrznych.
b. Mechanizmy powiadomień o dostarczeniu i przeczytaniu wiadomości przez adresata.
c. Tworzenie i zarządzanie osobistymi kalendarzami, listami kontaktów, zadaniami, notatkami.
d. Zarządzanie strukturą i zawartością skrzynki pocztowej samodzielnie przez użytkownika końcowego,
w tym: kategoryzacja treści, nadawanie ważności, flagowanie elementów do wykonania wraz z przy-
pisaniem terminu i przypomnienia.
e. Wsparcie dla zastosowania podpisu cyfrowego i szyfrowania wiadomości.
f. Pełne wsparcie dla klienta poczty elektronicznej MS Outlook 2013 i nowszych wersji.
2. Funkcjonalność wspierająca pracę grupową:
a. Możliwość przypisania różnych akcji dla adresata wysyłanej wiadomości, np. do wykonania czy do prze-
czytania w określonym terminie.
b. Możliwość określenia terminu wygaśnięcia wiadomości.
c. Udostępnianie kalendarzy osobistych do wglądu i edycji innym użytkownikom, z możliwością definio-
wania poziomów dostępu.

39
d. Podgląd stanu dostępności innych użytkowników w oparciu o ich kalendarze.
e. Mechanizm planowania spotkań z możliwością zapraszania wymaganych i opcjonalnych uczestników
oraz zasobów (np. sala, rzutnik), wraz z podglądem ich dostępności, raportowaniem akceptacji bądź
odrzucenia zaproszeń, możliwością proponowania alternatywnych terminów spotkania przez osoby
zaproszone.
f. Mechanizm prostego delegowania zadań do innych pracowników, wraz ze śledzeniem statusu ich wy-
konania.
g. Tworzenie i zarządzanie współdzielonymi repozytoriami kontaktów, kalendarzy, zadań.
h. Mechanizm udostępniania współdzielonych skrzynek pocztowych.
i. Obsługa list i grup dystrybucyjnych.
j. Dostęp ze skrzynki do poczty elektronicznej, poczty głosowej, wiadomości błyskawicznych i SMS-ów.
k. Możliwość informowania zewnętrznych użytkowników poczty elektronicznej o dostępności lub nie-
dostępności.
l. Możliwość wyboru poziomu szczegółowości udostępnianych informacji o dostępności.
m. Widok rozmowy, automatycznie organizujący wątki wiadomości w oparciu o przebieg wymiany wia-
domości między stronami.
n. Konfigurowalna funkcja informująca użytkowników przed kliknięciem przycisku wysyłania o szczegó-
łach wiadomości, które mogą spowodować jej niedostarczenie lub wysłanie pod niewłaściwy adres,
obejmująca przypadkowe wysłanie poufnych informacji do odbiorców zewnętrznych, wysyłanie wia-
domości do dużych grup dystrybucyjnych lub odbiorców, którzy pozostawili informacje o nieobec-
ności.
o. Transkrypcja tekstowa wiadomości głosowej, pozwalająca użytkownikom na szybkie priorytetyzowa-
nie wiadomości bez potrzeby odsłuchiwania pliku dźwiękowego.
p. Możliwość uruchomienia osobistego automatycznego asystenta poczty głosowej.
q. Telefoniczny dostęp do całej skrzynki odbiorczej – w tym poczty elektronicznej, kalendarza i listy
kontaktów.
r. Udostępnienie użytkownikom możliwości aktualizacji danych kontaktowych i śledzenia odbierania
wiadomości e-mail bez potrzeby wsparcia ze strony informatyków.
s. Mechanizm automatycznego dostosowywania się funkcji wyszukiwania kontaktów do najczęstszych
działań użytkownika skutkujący priorytetyzacją wyników wyszukiwania.
t. Możliwość wyszukiwania i łączenia danych (zgodnie z nadanycmi uprawnieniami) z systemu poczty
elektronicznej oraz innych systemów w organizacji (portali wielofunkcyjnych, komunikacji wielokana-
łowej i serwerów plików).
u. Mozliwość dostępu do poczty elektronicznej i dokumentów przechowywanych w portalu wielofunk-
cyjnym z poziomu jednego interfejsu zarządzanego przez serwer poczty elektronicznej.
3. Funkcjonalność wspierająca zarządzanie systemem poczty:
a. Oparcie się o profile użytkowników usługi katalogowej Active Directory.
b. Wielofunkcyjna konsola administracyjna umożliwiająca zarządzanie systemem poczty oraz dostęp
do statystyk i logów uzytkowników.
c. Definiowanie kwot na rozmiar skrzynek pocztowych użytkowników, z możliwością ustawiania progu
ostrzegawczego poniżej górnego limitu.
d. Możliwość definiowania różnych limitów pojemności skrzynek dla różnych grup użytkowników.
e. Możliwość przeniesienia lokalnych archiwów skrzynki pocztowej z komputera na serwer.
f. Możliwość korzystania interfejsu internetowego w celu wykonywania często spotykanych zadań zwią-
zanych z pomocą techniczną.
g. Narzędzia kreowania, wdrażania i zarządzania politykami nazewnictwa grup dystrybucyjnych.
4. Utrzymanie bezpieczeństwa informacji
a. Centralne zarządzanie cyklem życia informacji przechowywanych w systemie pocztowym, w tym: śledze-
nie i rejestrowanie ich przepływu, wygaszanie po zdefiniowanym okresie czasu, oraz archiwizacja danych.

40
b. Możliwość wprowadzenia modelu kontroli dostępu, który umożliwia nadanie specjalistom upraw-
nień do wykonywania określonych zadań – na przykład pracownikom odpowiedzialnym za zgodność
z uregulowaniami uprawnień do przeszukiwania wielu skrzynek pocztowych – bez przyznawania peł-
nych uprawnień administracyjnych.
c. Mechanizm zapobiegania wycieku danych ograniaczający możliwość wysyłania danych poufnych
do nieuprawnionych osób poprzez konfigurowalne funkcje monitoringu i analizy treści, bazujący
na ustalonych politykach bezpieczeństwa.
d. Możliwość łatwiejszej klasyfikacji wiadomości e-mail dzięki definiowanym centralnie zasadom zacho-
wywania, które można zastosować do poszczególnych wiadomości.
e. Możliwość wyszukiwania w wielu skrzynkach pocztowych poprzez interfejs przeglądarkowy i funkcja
kontroli dostępu w oparciu o role, która umożliwia przeprowadzanie ukierunkowanych wyszukiwań
przez pracowników działu HR lub osoby odpowiedzialne za zgodność z uregulowaniami.
f. Integracja z usługami zarządzania dostępem do treści pozwalająca na automatyczne stosowanie
ochrony za pomocą zarządzania prawami do informacji (IRM) w celu ograniczenia dostępu do in-
formacji zawartych w wiadomości i możliwości ich wykorzystania, niezależnie od miejsca nadania.
Wymagana jest możliwość użycia 2048-bitowych kluczy RSA, 256-bitowych kluczy SHA-1 oraz algo-
rytmu SHA-2.
g. Odbieranie wiadomości zabezpieczonych funkcją IRM przez zewnętrznych użytkowników oraz odpo-
wiadanie na nie – nawet, jeśli nie dysponują oni usługami ADRMS.
h. Przeglądanie wiadomości wysyłanych na grupy dystrybucyjne przez osoby nimi zarządzające i bloko-
wanie lub dopuszczanie transmisji.
i. Wbudowane filtrowanie oprogramowania złośliwego, wirusów i oprogramowania szpiegującego za-
wartego w wiadomościach wraz z konfigurowalnymi mechanizmami powiadamiania o wykryciu i usu-
nięciu takiego oprogramowania.
j. Mechanizm audytu dostępu do skrzynek pocztowych z kreowaniem raportów audytowych.
5. Wsparcie dla użytkowników mobilnych:
a. Możliwość pracy off-line przy słabej łączności z serwerem lub jej całkowitym braku, z pełnym dostę-
pem do danych przechowywanych w skrzynce pocztowej oraz z zachowaniem podstawowej funkcjo-
nalności systemu. Automatyczne przełączanie się aplikacji klienckiej pomiędzy trybem on-line i off-li-
ne w zależności od stanu połączenia z serwerem
b. Możliwość „lekkiej” synchronizacji aplikacji klienckiej z serwerem w przypadku słabego łącza (tylko
nagłówki wiadomości, tylko wiadomości poniżej określonego rozmiaru itp.)
c. Możliwość korzystania z usług systemu pocztowego w podstawowym zakresie przy pomocy urzą-
dzeń mobilnych typu PDA, SmartPhone.
d. Możliwość dostępu do systemu pocztowego spoza sieci wewnętrznej poprzez publiczną sieć Internet
– z dowolnego komputera poprzez interfejs przeglądarkowy, z własnego komputera przenośnego
z poziomu standardowej aplikacji klienckiej poczty bez potrzeby zestawiania połączenia RAS czy VPN
do firmowej sieci wewnętrznej.
e. Umożliwienie – w przypadku korzystania z systemu pocztowego przez interfejs przeglądarkowy –
podglądu typowych załączników (dokumenty PDF, MS Office) w postaci stron HTML, bez potrzeby
posiadania na stacji użytkownika odpowiedniej aplikacji klienckiej.
f. Obsługa interfejsu dostępu do poczty w takich przeglądarkach, jak Internet Explorer, Apple Safari
i Mozilla Firefox.
6. Funkcje związane z niezawodnością systemu:
a. Zapewnienie pełnej redundancji serwerów poczty elektronicznej bez konieczności wdrażania klastrów
oraz niezależnych produktów do replikacji danych.
b. Automatyzacja replikacji bazy danych i przełączania awaryjnego już dla dwóch serwerów poczty,
a także w wypadku centrów danych rozproszonych geograficznie.

41
c. Utrzymanie dostępności i uzyskanie możliwości szybkiego odzyskiwania po awarii dzięki możliwości
konfiguracji wielu replik każdej bazy danych skrzynki pocztowej.
d. Automatyczne odtwarzanie redundancji poprzez tworzenie kopii zapasowych w miejsce kopii
na uszkodzonych dyskach według zadanego schematu.
e. Ograniczenie zakłócenia pracy użytkowników podczas przenoszenia skrzynek pocztowych między
serwerami, pozwalające na przeprowadzanie migracji i konserwacji w dowolnym czasie – nawet w go-
dzinach pracy biurowej.
f. Zapewnienie ochrony przed utratą e-maili spowodowaną uaktualnianiem lub awarią roli serwera
transportu poprzez zapewnienie redundancji i inteligentne przekierowywanie poczty na inną dostęp-
ną ścieżkę.
g. Obsługa ponad pięciu baz danych skrzynek pocztowych.
8.4. Serwery portali wielofunkcyjnych
Serwery portali wielofunkcyjnych muszą spełniać następujące wymagania:
1. Publikacji dokumentów, treści i materiałów multimedialnych na witrynach wewnętrznych i zewnętrznych
dostępnych przez przeglądarkę internetową
2. Tworzenia witryn www,
3. Tworzenia repozytoriów – bibliotek przechowywania treści i plików,
4. Publikowania forów dyskusyjnych z oceną treści i publikacją własnych treści,
5. Publikowania ankiet,
6. Udostępniania formularzy elektronicznych,
7. Tworzenia repozytoriów wzorów dokumentów,
8. Tworzenia repozytoriów dokumentów,
9. Zarządzania strukturą portalu, witrynami, treściami www, repozytoriami plików i uprawnieniami użytkow-
ników,
10. Zakładania przez użytkowników własnych struktur – witryn, repozytoriów
11. Tworzenia spersonalizowanych witryn i przestrzeni roboczych dla poszczególnych ról i grup ról użytkow-
ników wraz z określaniem praw dostępu na bazie usługi katalogowej,
12. Wspólnej, bazującej na niezaprzeczalnych uprawnieniach pracy nad dokumentami,
13. Wersjonowania dokumentów,
14. Zarządzania mechanizmami ewidencjonowania i wyewidencjonowania dokumentów (blokowania doku-
mentu do wyłącznych praw edycji lub odblokowywania wyłącznych praw edycji),
15. Możliwość pracy z dokumentami w formacie XML w oparciu schematy XML przechowywane w repozy-
toriach portalu,
16. Organizacji pracy grupowej, poprzez udostępnianie użytkownikom wymienionych mechanizmów funkc-
jonalnych do których dana grupa ma uprawnienia,
17. Wyszukiwania treści zarówno poprzez wyszukiwanie fraz jak i metadanych dokumentów z możliwością
ich filtrowania,
18. Dostępu do danych w relacyjnych bazach danych z zachowaniem uprawnień użytkownika do konkretne-
go zakresu danych,
19. Możliwości analizy danych wraz z graficzną prezentacją danych,
20. Możliwości wykorzystanie mechanizmów portalu do budowy systemu zarządzania eszkoleniami (e-learn-
ing).
21. Budowy struktury portalu tak, by mogła stanowić zbiór wielu niezależnych portali (podportali), które
w zależności od nadanych uprawnień mogą być zarządzane niezależnie i prezentować wspólne lub różne
treści,
22. Nadawania uprawnień użytkownikom lub ich grupom wspólnie dla całej struktury portalu (z prawa-
mi dziedziczenia w strukturze), lub też niezależnie dla każdego podportalu, witryny czy repozytorium
w zakresie zarządzania strukturą i treściami i nadawania dalszych uprawnień.
23. Nadawania gotowych typów uprawnień (administrator, zapisywanie i odczyt, tylko odczyt) i definiowanie
własnych zakresów uprawnień dla użytkowników lub grup użytkowników.

42
24. Wsparcia pracy zespołowej poprzez definiowalne mechanizmy przepływów pracy (workflow) pozwa-
lających na tworzenie obiegów dokumentów i spraw wraz z funkcjonalnością integracji przepływów
z web-services, wywoływania web-services z poziomu workflow,
25. Mechanizmy wspierające przepływy pracy (workflow) bez konieczności kodowania przy wykorzystaniu
prostych w obsłudze narzędzi portalu.
26. Możliwość instalacji serwera na maszynach fizycznych i maszynach wirtualnych w środowiskach własnych
i hostowanych.
Serwery portali muszą posiadać następujące cechy dostępne bezpośrednio, jako wbudowane właściwości
produktu:
1. Interfejs użytkownika:
a. Dostęp za pomocą standardowej przeglądarki internetowej (Microsoft Explorer, Microsoft Edge, Ope-
ra, Safari),
b. Praca bezpośrednio z aplikacji pakietu biurowego z portalowymi rejestrami informacji typu repozyto-
ria dokumentów, kalendarze oraz bazy kontaktów,
c. Tworzenie witryn w ramach portalu bezpośrednio z aplikacji pakietu biurowego, np. edytora tekstu,
d. Możliwość pracy off-line z plikami przechowywanymi w repozytoriach portalu, poprzez mechanizmy
replikacji aktualnego stanu repozytorium i dokumentów na zasób lokalny przy każdym uzyskaniu
połączenia z portalem,
e. Wbudowane zasady pozwalające na konfigurację zgodną z WCAG 2.0,
f. Umożliwienie uruchomienia prezentacji stron w wersji pełnej oraz w wersji dedykowanej i zoptymali-
zowanej dla użytkowników urządzeń mobilnych PDA, telefon komórkowy).
2. Bezpieczeństwo
a. Szyfrowanie połączeń TLS 1.1 i 1.2,
b. Mechanizm jednokrotnej identyfikacji (single sign-on) pozwalający na autoryzację użytkowników
portalu i dostęp do danych w innych systemach biznesowych, niezintegrowanych z systemem LDAP,
c. Uwierzytelnianie użytkowników na bazie oświadczeń (claim-based authentication) z wykorzystaniem:
d. SAML (Security Assertion Markup Language)
e. Windows claims
f. Na bazie formularzy – Forms based claims,
g. Uwierzytelniania aplikacji i stowarzyszonego użytkownika na bazie tokenów,
h. Uwierzytelniania z poziomu serwera na bazie Open Authorization 2.0,
i. Uwierzytelnianie za pomocą pojedynczego logowania domenowego użytkowników zdefiniowanych
w zaimplementowanej usłudze katalogowej (single-sign on),
j. Możliwość uruchomienia mechanizmu wyszukiwania danych wrażliwych w zasobach portalu (takich
jak numery kart kredytowych, PESEL, numery dowodów osobistych czy paszportów) z powiadamia-
niem właścicieli zasobów lub/i administratorów portalu,
k. Narzędzia zabezpieczania i monitorowania udostępnionych innym użytkownikom zasobów:
l. Monitorowanie udostępnionych folderów i plików
m. Definicja przypomnień przy zapomnieniu hasła
n. Wskazanie użytkownika udostępniającego folder
o. Wysyłanie wiadomości pocztą elektroniczną do użytkowników zapraszanych do korzystania z folderu,
p. Mechanizm wnioskowania o dostęp do udziału i mechanizm akceptacji/odrzucenia wniosku dla ad-
ministrującego zasobem.
q. Możliwość wykorzystania różnych portów SMTP poza standardowym 25.
3. Projektowanie stron
a. Wbudowane intuicyjne narzędzia projektowania wyglądu stron,

Koncepcja uslug wspolnych dla jednostek edukacyjnych w jednostkach samorzadowych

Koncepcja uslug wspolnych dla jednostek edukacyjnych w jednostkach samorzadowych

Recommended

Recommended

More Related Content

Similar to Koncepcja uslug wspolnych dla jednostek edukacyjnych w jednostkach samorzadowych

Similar to Koncepcja uslug wspolnych dla jednostek edukacyjnych w jednostkach samorzadowych (20)

More from HIPERSYSTEM LTD ™

More from HIPERSYSTEM LTD ™ (20)

Koncepcja uslug wspolnych dla jednostek edukacyjnych w jednostkach samorzadowych