Nadzór nad danymi na ujednoliconej platformie danych

Ten artykuł pomaga osobom podejmującym decyzje ustanowić nadzór nad danymi w całej organizacji.

Organizacje powinny ustanowić wspólne wymagania dotyczące ładu danych, które mają zastosowanie do danych, za które odpowiadają. Spójny ład pomaga organizacji korzystać z danych z przekonaniem i zarządzać ryzykiem biznesowym lub regulacyjnym niezależnie od tego, gdzie znajdują się dane. Ten artykuł zawiera wskazówki dotyczące ustanawiania tych wymagań i spójnego stosowania ich w całej organizacji.

Architektura i drzewo decyzyjne

1. Spis danych

Jak powinniśmy zrozumieć posiadane dane? Organizacja powinna ustanowić Microsoft Purview jako wspólny system zarządzania ładem dla metadanych danych przedsiębiorstwa. Microsoft Purview Data Map zawiera spis techniczny, a Ujednolicony wykaz Microsoft Purview ułatwia użytkownikom odnajdywanie danych. Te możliwości przechowują metadane. Nie kopiują danych bazowych ani nie udzielają dostępu do nich.

Organizacja powinna ustanowić zasady spisu danych, które określają, które dane muszą być odnajdywalne za pośrednictwem Microsoft Purview oraz kolejność, w jakiej dodatkowe dane są dodawane do spisu. Pełne pokrycie techniczne nie powinno być celem początkowym, chyba że wymaga tego obowiązek prawny lub regulacyjny.

• Zakres priorytetowy: pierwsza granica inwentaryzacji powinna obejmować dane obsługujące krytyczne procesy biznesowe lub raportowanie przedsiębiorstwa. Powinna również obejmować dane używane przez rozwiązania sztucznej inteligencji, w przypadku których pochodzenie lub dozwolone użycie wpływa na ryzyko.

• Dane Microsoft 365: zawartość Microsoft 365 powinna być uwzględniana, gdy dokumenty lub komunikacja zawierają informacje należące do zakresu ładu organizacyjnego. Zapoznaj się z przewodnikami dotyczącymi konfiguracji Microsoft Purview.

• Microsoft Fabric: Zarejestruj i przeskanuj dzierżawę usługi Fabric, aby wprowadzić obsługiwane metadane usługi Fabric oraz linię pochodzenia do Microsoft Purview. Zobacz Rejestrowanie i skanowanie Microsoft Fabric.

• Dane wielochmurowe, SaaS i lokalne: skanowanie oparte na łącznikach jest wymagane do skanowania danych przechowywanych w Azure, Microsoft Dataverse, systemach lokalnych i innych chmurach (AWS, Google Cloud, Oracle). Organizacja powinna rejestrować obsługiwane źródła, jeśli centralny wgląd w metadane przynosi wyraźne korzyści w zakresie nadzoru. Ta korzyść może obejmować dowody zgodności regulacyjnej lub wykrywanie międzyplatformowe. Nieobsługiwane źródła lub źródła o niskim priorytecie powinny nadal figurować w zakresie zarządzania, z przypisanym właścicielem i zaplanowanym sposobem postępowania. Zobacz najlepsze praktyki skanowania map danych. Zobacz Ujednolicony katalog i Mapę danych w Microsoft Purview.

2. Wspólne znaczenie biznesowe

Jak zapewnić spójność definicji danych? Organizacja powinna standaryzować pojęcia biznesowe, gdy niespójność ich znaczenia mogłaby wpływać na decyzje w różnych domenach danych. Nie należy próbować tworzyć jednej definicji dla każdego pojęcia lokalnego.

• Pojęcia obowiązujące w całej organizacji: Pojęcia powinny mieć jednolitą definicję w całej organizacji, gdy wiele domen danych opiera się na tym samym znaczeniu na potrzeby raportowania lub systemów AI. Nadaj priorytet pojęciom, w których niespójne definicje mają już wpływ na decyzje biznesowe. Każda wspólna koncepcja powinna mieć zatwierdzoną definicję i odpowiedzialnego właściciela biznesowego. Definicja powinna określać dopuszczalne różnice tam, gdzie konteksty biznesowe zasadnie się różnią.

• Pojęcia specyficzne dla domeny danych: domeny danych powinny zachować kontrolę nad pojęciami, które nie wymagają spójnego znaczenia poza domeną danych. Pojęcia te powinny stać się pojęciami ogólnoorganizacyjnymi tylko wtedy, gdy wykorzystanie w wielu domenach danych wymaga wspólnego rozumienia.

• Zarządzanie glosariuszem: zatwierdzone definicje powinny być publikowane za pośrednictwem Ujednolicony wykaz Microsoft Purview, aby użytkownicy mogli odnaleźć znaczenie skojarzone z zarządzanymi danymi. Domeny ładu mogą organizować terminy słownika i łączyć je z odpowiednimi produktami danych lub zasobami danych. Zobacz Terminy w słowniku w Unified Catalog.

3. Zgodność

Jak powinniśmy wywiązać się z naszych obowiązków w zakresie zgodności z przepisami dotyczącymi danych? Organizacja powinna przekształcić zobowiązania prawne i umowne w wymagania w zakresie danych przed wyborem technicznych zabezpieczeń. Menedżer zgodności w Microsoft Purview może pomóc ocenić mechanizmy kontroli i zorganizować pracę nad ulepszeniem.

3.1 Wymagania dotyczące zgodności

Jak należy ustanowić wymagania dotyczące zgodności? Organizacja powinna ustanowić proces tłumaczenia odpowiednich wymagań prawnych i zobowiązań umownych na wymagania dotyczące zarządzania danymi.

• Zakres odpowiedzialności: Działy prawne lub ds. zgodności powinny określić, które obowiązki mają zastosowanie. Domeny danych powinny identyfikować dane, których dotyczy problem. Zespoły ds. zabezpieczeń powinny określić, jak zatwierdzone wymagania przekładają się na mechanizmy kontroli technicznej.

• Dokumentacja: Organizacja powinna zachować te wymagania w centralnym rejestrze. Każde wymaganie powinno identyfikować organ lub osobę odpowiedzialną oraz dane, których dotyczy. Powinien on również definiować wymagane dowody i częstotliwość przeglądu.

• Narzędzia: oceny zgodności w Menedżer zgodności w Microsoft Purview powinny pomóc zidentyfikować luki w mechanizmach kontroli i zorganizować prace nad usprawnieniami. Wynik zgodności powinien służyć jako wskaźnik dla kierownictwa. Nie należy traktować go jako dowodu, że organizacja spełnia zobowiązanie prawne. Zobacz Oceny usługi Purview.

3.2 Monitorowanie zgodności danych

Jak należy monitorować zgodność danych? Organizacja powinna ustanowić wymagania dotyczące monitorowania i eskalacji zgodnie z przepisami i ryzykiem biznesowym. Wymagania o większym potencjalnym wpływie powinny podlegać bardziej rygorystycznym wymogom w zakresie monitorowania i działań naprawczych. Monitorowanie powinno dostarczyć dowodów, których zespoły odpowiedzialne mogą używać do identyfikowania istotnych luk w zgodności i śledzenia ich rozwiązania.

• Narzędzia: Menedżer zgodności w Microsoft Purview może zapewnić oceny i działania doskonalące dla obsługiwanych wymagań. Osoby podejmujące decyzje powinny używać tych informacji do monitorowania stanu zgodności i nierozwiązanych luk w kontroli. Nie powinny traktować oceny zgodności jako wyniku zgodności. Zobacz Compliance Manager i Multicloud .

• Dowody potwierdzające zgodność: Organizacja powinna zachować dowody potrzebne do wykazania, że wymagane mechanizmy kontroli działają zgodnie z oczekiwaniami. Wymagania dotyczące dowodów i okresy przechowywania powinny być zgodne z wymogiem udokumentowanym w rejestrze zgodności.

3.3. Pochodzenie danych

Jak należy śledzić historię danych? Organizacja powinna wymagać śledzenia pochodzenia danych tam, gdzie zrozumienie źródła lub transformacji danych wspiera ważne wymaganie organizacyjne. Lineage danych nie powinno stać się celem dokumentowania każdego przenoszenia danych.

• Zakres pochodzenia danych: domeny danych powinny obejmować wystarczający zakres informacji o pochodzeniu danych, aby wspierać wymagane decyzje dotyczące ładu w odniesieniu do ważnych produktów danych.

• Śledzenie pochodzenia danych systemu źródłowego powinno być wymagane, gdy organizacja musi wykazać, skąd pochodzą ważne dane lub prześledzić problemy do źródła autorytatywnego.

• Lineage warstwy zużycia, takie jak Fabric, może stanowić scentralizowaną granicę lineage, gdy systemy nadrzędne już dostarczają wystarczające dowody. Zobacz: Scan Fabric.

• Zarówno warstwy źródłowe, jak i warstwy konsumpcji powinny być uwzględniane, gdy transformacja może istotnie zmienić znaczenie danych lub dozwolone użycie.

• Oprzyrządowanie: Ujednolicony wykaz Microsoft Purview powinien zapewniać scentralizowany widok pochodzenia zarządzanych zasobów danych. Szczegóły zasobu danych mogą przedstawiać linie pochodzenia w górę i w dół wraz z kontekstem biznesowym, takim jak opis zasobu i właściciel. Zobacz Wyszukaj produkty data w Unified Catalog.

• Zbieranie lineage: Organizacja powinna automatyzować zbieranie lineage za pomocą obsługiwanych integracji źródłowych, jeśli to możliwe. Domeny danych powinny identyfikować istotne luki, gdy automatyczne śledzenie pochodzenia danych nie dostarcza dowodów wymaganych do podejmowania decyzji dotyczących ładu. Zobacz Metadane i linia pochodzenia z Fabric do Microsoft Purview i Ręczna konfiguracja linii pochodzenia.

3.4 Przechowywanie danych

Jak długo powinniśmy przechowywać nasze dane? Organizacja powinna ustanowić wymagania dotyczące przechowywania na podstawie zobowiązań prawnych i potrzeb biznesowych przed skonfigurowaniem poszczególnych platform. Każda główna klasyfikacja danych lub typ rekordu powinna mieć zatwierdzony okres przechowywania i wymaganie dotyczące usuwania. Zasady powinny również identyfikować okoliczności, które uniemożliwiają normalne usunięcie, takie jak blokada prawna.

Domeny danych powinny stosować te wymagania organizacyjne w odniesieniu do danych, których są właścicielami. Zespoły platformy powinny zapewnić zatwierdzone wzorce implementacji dla usług, którymi zarządzają.

3.4.1 przechowywanie danych Microsoft 365

Zasady przechowywania i etykiety przechowywania w Microsoft 365 powinny spełniać organizacyjne wymagania dotyczące przechowywania dla obsługiwanej zawartości Microsoft 365. Organizacje powinny używać zarządzanie cyklem życia danych Microsoft Purview i funkcji zarządzania rekordami, które spełniają wymagania dotyczące przechowywania i usuwania. Przechowywanie danych w usłudze Microsoft 365.

3.4.2 Azure przechowywanie danych

Standardy platformy Azure powinny definiować sposób, w jaki wymagania organizacji dotyczące przechowywania przekładają się na ustawienia tworzenia kopii zapasowych i cyklu życia specyficzne dla usługi. Organizacja powinna odróżnić przechowywanie danych biznesowych lub regulacyjnych od kopii zapasowej wymaganej do odzyskiwania operacyjnego. Te cele mogą wymagać różnych kontrolek. Zobacz Azure Storage, SQL Database, Cosmos DB i MySQL.

3.4.3 Lokalne i wielochmurowe przechowywanie danych

Wymagania dotyczące przechowywania organizacyjnego powinny mieć zastosowanie niezależnie od tego, gdzie znajdują się dane. Domeny danych powinny identyfikować platformy, które nie spełniają wymaganych zasad przechowywania lub usuwania. Jeśli platforma nie może spełnić wymagania, organizacja powinna ustanowić zatwierdzony mechanizm kontrolny kompensujący lub przenieść zarządzaną dokumentację na platformę, która może spełnić wymaganie.

4. Bezpieczeństwo danych

Jak należy klasyfikować i chronić dane? Organizacja powinna ustanowić spójny model zabezpieczeń danych, który chroni dane zgodnie z ich wrażliwością i ryzykiem biznesowym. Model powinien definiować wymagania dotyczące całej organizacji dotyczące identyfikowania poufnych danych i zapobiegania niewłaściwemu użyciu lub ujawnieniu. Każda platforma powinna implementować te wymagania za pośrednictwem obsługiwanych mechanizmów kontroli zabezpieczeń.

4.1 Klasyfikacja danych

Jak należy klasyfikować nasze dane? Organizacja powinna ustanowić jeden model klasyfikacji informacji we wszystkich obsługiwanych platformach. Każda klasyfikacja powinna definiować znaczenie biznesowe i wymagany poziom ochrony. Platformy powinny implementować ten model za pomocą obsługiwanych mechanizmów, w tym etykiet poufności, jeśli ma to zastosowanie.

• Taksonomia organizacyjna: taksonomia powinna używać terminów, które mają już zaakceptowane znaczenie organizacyjne. Model może używać klasyfikacji, takich jak Public, General, Confidential i Highly Confidential. Organizacja powinna tworzyć etykiety poufności tylko wtedy, gdy reprezentują odrębną ochronę lub sposób postępowania. Zbyt wiele etykiet sprawia, że klasyfikacja jest trudna do zrozumienia i spójnego stosowania. Przeczytaj Wprowadzenie do etykiet poufności.

• Klasyfikacja domyślna: Organizacja powinna ustanowić bezpieczną wartość domyślną dla platform, na których dane nieoznaczone spowodują ryzyko materialne. Domyślna klasyfikacja zapewnia punkt wyjścia. Nie zastępuje klasyfikacji przez odpowiedzialną domenę danych. Zobacz Domyślne etykiety poufności i zasady.

• Organ uprawniony do udzielania wyjątków: Organizacja powinna określić, kto może obniżyć klasyfikację i jakie dowody są wymagane. Klasyfikacje o wysokim stopniu wrażliwości powinny wymagać zatwierdzenia przez odpowiedzialnego właściciela biznesowego lub wyznaczoną osobę odpowiedzialną za bezpieczeństwo.

• Microsoft 365: etykiety poufności Microsoft Purview mogą klasyfikować zawartość w usłudze Microsoft 365 i stosować skonfigurowane zabezpieczenia, w tym szyfrowanie i ograniczenia użytkowania. Zobacz Microsoft 365.

• Microsoft Fabric: Fabric używa etykiet poufności Microsoft Purview do klasyfikacji. Etykieta poufności elementu Fabric sama nie wymusza równoważnych ograniczeń dostępu dla elementu Fabric. Uprawnienia w usłudze Fabric nadal kontrolują dostęp. Jeśli klasyfikacja wymaga ograniczonego dostępu, użyj mechanizmów kontroli dostępu Fabric lub obsługiwanych zasad ochrony, aby wyegzekwować ten wymóg. Zobacz Chronione etykiety poufności i domyślne zasady etykiet w usłudze Fabric.

• Weryfikacja ochrony: Organizacja powinna sprawdzić, czy wymagana ochrona zostanie zachowana podczas istotnych przejść między platformami. Testowanie powinno obejmować ścieżki, w których dane mogą opuścić środowisko o wyższym poziomie kontroli, na przykład podczas eksportu z Fabric do Microsoft 365.

4.2 Dane wrażliwe

Jak należy chronić poufne dane? Organizacja powinna zdefiniować, które informacje tworzą istotne ryzyko biznesowe lub związane ze zgodnością, i ustanowić spójne metody ich wykrywania. Obszary danych powinny identyfikować poufne informacje w kontekście biznesowym. Zespoły ds. bezpieczeństwa i zgodności powinny przełożyć te definicje na klasyfikatory nadające się do ponownego użycia oraz mechanizmy ochrony.

• Wykrywanie standardowe: Typy informacji wrażliwych lub dokładne dopasowanie danych należy stosować, gdy dane wrażliwe mają wiarygodny wzorzec lub wiarygodny zestaw referencyjny. Przykłady obejmują identyfikatory państwowe lub istniejące rekordy klientów.

• Wykrywanie kontekstowe: klasyfikatory, które można trenować, powinny być używane, gdy czułość zależy od znaczenia treści, a nie od przewidywalnego wzorca. Przykłady obejmują poufne dokumenty strategiczne lub zastrzeżone wyniki badań.

Microsoft Purview udostępnia typy informacji poufnych i klasyfikatory do trenowania, które mogą obsługiwać te definicje organizacyjne. Zobacz Omówienie klasyfikatorów Microsoft Purview.

4.3 Zapobieganie utracie danych

Jak skonfigurować zapobieganie utracie danych (DLP)? Organizacja powinna ustanowić polityki DLP dla określonych scenariuszy utraty danych, w których zapobieganie takim działaniom lub ich wykrywanie zmniejsza istotne ryzyko dla działalności. Nie stosuj najbardziej rygorystycznej dostępnej kontroli w każdej lokalizacji. DLP powinna być jednym mechanizmem kontrolnym w szerszym modelu ochrony danych, ponieważ zakres ochrony różni się w zależności od platformy i aktywności.

• Scenariusze ryzyka: Każda zasada DLP powinna definiować poufne dane i ryzykowne działania, których dotyczy. Należy również zdefiniować populację lub usługę objęte zakresem. Na przykład zasada może dotyczyć zewnętrznego udostępniania danych osobowych klienta z Microsoft 365.

• Faza monitorowania: Nowe zasady powinny zwykle rozpoczynać się w trybie inspekcji/audytu lub symulacji. Zespół odpowiedzialny powinien przejrzeć dopasowania pod kątem reprezentatywnej działalności biznesowej i zdefiniować zatwierdzone wyjątki przed włączeniem ograniczeń. Zobacz Tryb symulacji DLP.

• Faza egzekwowania: Blokowanie powinno mieć zastosowanie, gdy oczekiwany efekt ujawnienia danych przekracza efekt biznesowy przerwania legalnej pracy. Organizacja powinna wyznaczyć uprawnienia do obsługi wyjątków przed włączeniem blokowania.

• Przegląd zasad: powtarzające się przesłonięcia lub wyniki fałszywie dodatnie powinny wyzwolić przegląd zasad. Te wzorce mogą wskazywać na niedokładne wykrywanie lub uzasadniony proces biznesowy, który powoduje konflikt z zasadami.

Zobacz informacje o DLP dla Ochrona przed utratą danych w Microsoft Purview oraz szczegółowe wskazówki dotyczące Microsoft Fabric i Microsoft Copilot.

4.4 Zabezpieczenia danych platformy Azure

Jak zabezpieczyć dane w systemach Azure? Organizacja powinna ustanowić standardy ochrony danych Azure, które przekształcają klasyfikację danych w minimalne wymagania dotyczące zabezpieczeń. Klasyfikacja Microsoft Purview może identyfikować wrażliwość danych i ich znaczenie biznesowe. Usługi platformy Azure powinny wymuszać wynikające z nich wymagania za pośrednictwem obsługiwanych mechanizmów kontroli zabezpieczeń.

• Poziom bazowy ochrony: zespoły platformy powinny udostępniać zatwierdzone wzorce Azure spełniające te wymagania, aby poszczególne zespoły obciążeń nie projektowały niezależnie modelu zabezpieczeń organizacji.

• Implementacja usługi: usługi Azure powinny wymuszać bazowy standard organizacyjny za pomocą swoich wbudowanych mechanizmów. Klasyfikacja danych powinna informować, które zabezpieczenia są wymagane, a nie dyktować określoną implementację techniczną dla każdej usługi.

• Weryfikacja kontroli: zespoły ds. zabezpieczeń powinny okresowo weryfikować, czy usługi zawierające poufne dane spełniają bazowy poziom organizacji i identyfikować wyjątki, które wymagają korygowania lub formalnej akceptacji ryzyka.