SSO, FERPA i zgodność: czego uniwersytety potrzebują od badawczego SaaS
Lista kontrolna dla działów IT i zakupów służąca do oceny platform badawczych SaaS. Obejmuje SSO/SAML, FERPA, SOC 2, rezydencję danych, HECVAT, dostępność oraz sposób przeprowadzenia przeglądu bezpieczeństwa.
Uniwersyteckie zespoły IT potrzebują badawczego SaaS, który spełnia wymagania dotyczące SSO, FERPA, SOC 2 i dostępności. Ten przewodnik zawiera praktyczną listę kontrolną oceny i wyjaśnia kwestie zgodności specyficzne dla szkolnictwa wyższego.
Jeśli pracujesz w uniwersyteckim IT, bezpieczeństwie informacji lub dziale zakupów, wiesz, że wdrożenie nowego oprogramowania nigdy nie jest tak proste, jak znalezienie narzędzia, które spodoba się badaczom. Każda platforma SaaS, która ma styczność z danymi instytucjonalnymi, musi przejść przez gąszcz przeglądów bezpieczeństwa, kontroli zgodności i negocjacji umownych. W przypadku narzędzi ukierunkowanych na badania — które mogą przetwarzać prace studentów, nieopublikowane dane oraz wyniki projektów finansowanych ze środków federalnych — wymagania są szczególnie rygorystyczne.
Ten przewodnik zawiera praktyczną listę kontrolną do oceny platform badawczych SaaS, ze szczególnym uwzględnieniem wymagań specyficznych dla szkolnictwa wyższego.
Single sign-on nie jest opcjonalne w przypadku oprogramowania instytucjonalnego. Uniwersytety korzystają ze scentralizowanych systemów tożsamości, a każde narzędzie wymagające osobnej nazwy użytkownika i hasła stwarza ryzyko bezpieczeństwa, zwiększa obciążenie help desku i utrudnia korzystanie użytkownikom.
Czego wymagać Obsługa SAML 2.0 — standardowy protokół dla korporacyjnego SSO w szkolnictwie wyższym Zgodność z Shibboleth — wiele uniwersytetów używa Shibboleth jako dostawcy tożsamości SAML, szczególnie tych należących do federacji InCommon Integracja z Azure AD / Entra ID — coraz powszechniejsza wraz z przechodzeniem uniwersytetów na Microsoft 365 Obsługa Okta — używana przez rosnącą liczbę instytucji, zwłaszcza w USA Provisioning SCIM — automatyczne tworzenie i dezaktywacja użytkowników na podstawie zmian w katalogu (kluczowe przy zarządzaniu kontami, gdy studenci kończą studia lub pracownicy odchodzą) Wymuszanie MFA — platforma powinna respektować polityki MFA instytucji, a nie je omijać
Read next
- Explore more on sso
- Explore more on ferpa
- Explore more on zgodność
- Explore more on uniwersytet
- Explore more on zakupy
- Explore more on bezpieczeństwo
Related articles
Explore PapersFlow
Frequently Asked Questions
- Czy FERPA ma zastosowanie do narzędzi badawczych używanych wyłącznie przez kadrę akademicką?
- To zależy. FERPA chroni dokumentację edukacyjną studentów, więc jeśli narzędzie jest używane wyłącznie przez kadrę akademicką do własnych badań (bez danych studentów), FERPA zazwyczaj nie ma zastosowania. Jednak jeśli studenci korzystają z platformy w ramach kursu albo jeśli w systemie przechowywane są nazwiska studentów, oceny lub identyfikatory, FERPA ma zastosowanie. Wiele uniwersytetów stosuje wymagania FERPA szeroko wobec całego SaaS jako strategię zarządzania ryzykiem, nawet gdy ścisła możliwość zastosowania jest niepewna.
- Czym jest HECVAT i dlaczego dostawcy muszą go wypełnić?
- HECVAT (Higher Education Community Vendor Assessment Toolkit) to ustandaryzowany kwestionariusz bezpieczeństwa opracowany przez EDUCAUSE i Internet2. Eliminuje potrzebę tworzenia przez każdy uniwersytet własnego kwestionariusza, oszczędzając czas zarówno dostawcom, jak i instytucjom. Istnieją dwie wersje: HECVAT Lite (dla narzędzi o niższym ryzyku) oraz HECVAT Full (dla narzędzi obsługujących dane wrażliwe). Większość uniwersyteckich działów zakupów nie będzie kontynuować procesu bez wypełnionego HECVAT.
- Czy dostawca bez certyfikacji SOC 2 nadal może zostać zatwierdzony?
- Technicznie tak, ale powoduje to istotne utrudnienia. Bez SOC 2 zespół bezpieczeństwa uniwersytetu zazwyczaj będzie wymagał bardziej rozbudowanego przeglądu — w tym szczegółowej dokumentacji architektury, wyników testów penetracyjnych, a być może także audytu na miejscu. Wiele uniwersytetów ma politykę wymagającą SOC 2 Type II dla każdego narzędzia, które przetwarza dane instytucjonalne. Mniejsi dostawcy mogą czasem wykorzystać alternatywne dowody (ISO 27001, wypełniony CAIQ lub raporty z niezależnych audytów bezpieczeństwa), ale należy się spodziewać, że proces zakupowy potrwa dłużej.