Sytuacja
Kolegium w Kownie na Litwie korzysta z Microsoft 365 od ponad dziesięciu lat: poczta, Teams, OneDrive i SharePoint dla wykładowców, administracji i studentów. Użytkowników z kadry jest około 400, do tego kilka tysięcy kont studenckich, a każdego roku przybywa kolejnych. Administracją zajmował się jeden pracownik IT, obok wszystkich pozostałych obowiązków: komputerów, sprzętu w salach, sieci.
Z biegiem lat zgromadziło się to, co gromadzi się wszędzie tam, gdzie konta zakłada się ręcznie, a wyłącza „gdy ktoś sobie przypomni”. Byli studenci mieli działające konta z pocztą i dostępem do kanałów Teams z materiałami do nauki. Podobnie wykładowcy, którzy odeszli z pracy, a niektórzy z nich mieli dostęp do wspólnych bibliotek SharePoint. Uwierzytelnianie wieloskładnikowe było włączone tylko u tych, którzy sami tego chcieli, czyli u mniejszości. Licencje kupiono na najwyższą liczbę użytkowników, jaka kiedykolwiek wystąpiła, i od tamtej pory nie były przeglądane.
Zgłosili się do nas po dwóch zdarzeniach: uwagach z przeglądu cyberbezpieczeństwa dotyczących MFA oraz incydencie phishingowym, w którym wiadomości do wykładowców zostały wysłane z konta byłego studenta. Kierownictwo kolegium chciało, aby administracja działała według procesu, a nie z pamięci, i aby pracownik IT mógł wrócić do swoich pozostałych zadań.
Czego potrzebowano
- Cyklu życia konta powiązanego z systemami studenckim i kadrowym: przyjęcie na studia tworzy konto, odejście je wyłącza, bez pracy ręcznej.
- Obowiązkowego MFA dla wszystkich kont, z listą wyjątków wyłącznie dla wspólnych kont w salach i laboratoriach.
- Dostępu warunkowego: dostęp do systemów administracyjnych tylko z zarządzanych urządzeń i tylko z Litwy.
- Przeglądu licencji i jasnej zasady, która licencja jest przypisana do której roli.
- Przejścia bez przerw w trakcie semestru i bez lawiny zgłoszeń do IT.
Co zrobiliśmy
Tygodnie 1–3: audyt i ścieżka konta
Po przejęciu administracji Microsoft 365 zaczęliśmy od audytu tenanta: ile jest kont, kiedy każde z nich logowało się po raz ostatni, jakie są licencje, kto ma uprawnienia administratora i jakie są ustawienia udostępniania. Obraz był taki, jakiego się spodziewaliśmy: około jedna trzecia kont nie logowała się od ponad roku, część z nich z płatnymi licencjami, a administratorów globalnych było ośmiu, z czego dwóch już tam nie pracowało.
Razem z dziekanatem i działem kadr opisaliśmy ścieżkę konta od decyzji o przyjęciu na studia do wykreślenia z rejestru. Ustaliliśmy, który system jest źródłem prawdy dla każdej roli, kiedy konto trzeba wyłączyć, a kiedy usunąć.
Tygodnie 4–7: cykl życia w Entra ID
Skonfigurowaliśmy Microsoft Entra ID tak, aby konta były tworzone i wyłączane na podstawie danych z systemów studenckiego i kadrowego: nowy rekord tworzy konto z licencją i grupami przypisanymi do roli, zmiana statusu wyłącza logowanie w ciągu doby, a po uzgodnionym okresie konto jest archiwizowane i licencja zostaje zwolniona. Stare konta wyłączaliśmy falami, powiadamiając wydziały na tydzień przed każdą falą, aby ci, którzy nadal potrzebowali dostępu, mieli czas zareagować. Zareagowały nieliczne osoby.
Tygodnie 8–10: MFA i dostęp warunkowy
MFA włączaliśmy etapami: najpierw administracja i wykładowcy, potem studenci wydział po wydziale. Na każdy etap przygotowywaliśmy krótkie instrukcje po litewsku i angielsku oraz okno rejestracji, w którym użytkownicy mogli skonfigurować aplikację we własnym tempie. Reguły dostępu warunkowego: systemy studenckie i kadrowe tylko z zarządzanych urządzeń, konta administratorów tylko z MFA odpornym na phishing, a logowania z nietypowych krajów blokowane. Najtrudniejsze okazały się wspólne konta w salach, dla których utworzyliśmy osobną regułę ograniczającą dostęp do sieci kolegium.
Tygodnie 11–12: licencje i przekazanie
Licencje rozdzieliliśmy według ról: plany edukacyjne dla studentów i wykładowców, administracja według faktycznej potrzeby, a dla kont wspólnych żadnych płatnych licencji. Zostało trzech administratorów, każdy z osobnym kontem administracyjnym. Pracownikowi IT przekazaliśmy szablon miesięcznego raportu i dostęp do naszego helpdesku.
Wynik
Wszystkie aktywne konta, 100%, mają obowiązkowe MFA; lista wyjątków jest krótka, udokumentowana i przeglądana co kwartał. Od czasu zmiany nie odnotowano żadnych wiadomości phishingowych wysłanych z kont kolegium.
Liczba płatnych licencji spadła o około 28%: część zwolniono przez wyłączenie nieużywanych kont, część przez zmianę planów na dopasowane do ról. Oszczędności zostały w budżecie kolegium na kolejne lata.
Dostęp jest wyłączany w ciągu 24 godzin od zmiany w systemie studenckim lub kadrowym, bez udziału pracownika IT. Mierzymy to na podstawie dzienników Entra ID: czasu od zmiany statusu do wyłączenia konta.
„Co roku we wrześniu mieliśmy tydzień zakładania kont. W tym roku po prostu się pojawiły i było to dziwne uczucie.”
Co doradzilibyśmy w podobnej sytuacji
- Zacznij od źródła prawdy: dopóki konta nie są powiązane z systemami kadrowym i studenckim, każde porządkowanie będzie tymczasowe.
- Wyłączaj stare konta falami z wcześniejszym powiadomieniem, a nie wszystkie naraz, ale nie odkładaj tego tylko dlatego, że „ktoś może z niego korzystać”.
- Wprowadzaj MFA etapami, z instrukcjami i oknem rejestracji; większość oporu znika, gdy ludzie mogą zrobić to sami.
- Przeglądaj licencje razem z kontami, a nie osobno: w większości przypadków to ta sama lista.
