Copilot a uprawnienia do plików: jak sprawdzić, czy nie ujawnia danych mimo braku dostępu

Na jakiej zasadzie Copilot ogranicza odpowiedzi do danych, do których użytkownik ma dostęp?

Copilot działa w granicach uprawnień aktualnie zalogowanego użytkownika. Oznacza to, że gdy wyszukuje, odczytuje lub streszcza treści z plików, wiadomości czy innych zasobów, powinien korzystać wyłącznie z tych danych, do których ten użytkownik ma już nadane prawo dostępu przez mechanizmy kontroli dostępu obowiązujące w danym środowisku.

W praktyce wygląda to tak, że model nie „omija” zabezpieczeń sam z siebie, lecz otrzymuje dane dopiero po ich przefiltrowaniu przez system źródłowy. Jeśli użytkownik nie ma prawa otworzyć dokumentu, Copilot nie powinien użyć jego treści do wygenerowania odpowiedzi. Jeżeli natomiast użytkownik ma dostęp choćby pośredni — na przykład przez członkostwo w grupie, link z uprawnieniem albo dziedziczone uprawnienia — Copilot może z tych danych skorzystać, bo z punktu widzenia systemu są one dla tego użytkownika dostępne.

Kluczowe jest rozróżnienie między brakiem wiedzy użytkownika o istnieniu pliku a faktycznym brakiem uprawnień. Copilot ogranicza się do tego drugiego. Nie ocenia, czy użytkownik „powinien” zobaczyć dany plik biznesowo, tylko czy system uprawnień rzeczywiście mu na to pozwala.

Dlatego bezpieczeństwo odpowiedzi Copilota zależy przede wszystkim od poprawnej konfiguracji uprawnień w źródłach danych. Jeśli dostęp został nadany zbyt szeroko, Copilot może legalnie uwzględnić takie treści w odpowiedzi, ponieważ dla systemu nie są to dane niedostępne.

Jakie ustawienia SharePoint i OneDrive najczęściej powodują nieświadome oversharing dokumentów?

Najczęstsze źródła nieświadomego oversharingu to ustawienia, które rozszerzają dostęp szerzej, niż zakłada właściciel pliku lub witryny. W praktyce problem zwykle nie wynika z „włamania”, tylko z legalnie nadanych uprawnień: zbyt szerokich linków udostępniania, członkostwa w grupach, dziedziczenia uprawnień oraz domyślnych konfiguracji witryn, bibliotek i zespołów.

• Linki udostępniania o zbyt szerokim zakresie – szczególnie linki typu „Każda osoba z linkiem”, „Osoby w organizacji” albo linki z prawem edycji zamiast tylko odczytu. Użytkownik często zakłada, że wysyła dokument konkretnej osobie, a faktycznie nadaje dostęp znacznie szerszej grupie.
• Domyślne ustawienia udostępniania w SharePoint i OneDrive – jeśli tenant, witryna lub OneDrive pozwalają domyślnie tworzyć szerokie linki albo nie wymagają ograniczenia do konkretnych odbiorców, użytkownicy będą częściej udostępniać pliki „za szeroko” bez pełnej świadomości skutku.
• Dziedziczenie uprawnień z witryny, biblioteki lub folderu – dokument może wyglądać na „prywatny”, ale w rzeczywistości dziedziczy dostęp od miejsca, w którym został zapisany. Jeśli folder lub biblioteka są dostępne dla szerokiej grupy, każdy nowy plik zwykle przejmuje te same uprawnienia.
• Członkostwo w grupach Microsoft 365, Teams i grupach SharePoint – dodanie użytkownika do zespołu lub grupy często otwiera dostęp do całej powiązanej witryny SharePoint, dokumentów i bibliotek. Oversharing pojawia się wtedy, gdy ktoś traktuje grupę jako roboczą lub tymczasową, a nie jako źródło realnych uprawnień do danych.

Dodatkowo ryzyko zwiększają ustawienia typu „Everyone except external users”, szerokie grupy bezpieczeństwa, brak wygasania linków, brak przeglądu starych uprawnień oraz możliwość udostępniania na poziomie folderów zamiast pojedynczych plików. W OneDrive częstym błędem jest też przechowywanie materiałów roboczych w lokalizacjach, które już wcześniej były współdzielone z zespołem lub organizacją.

Z punktu widzenia ryzyka ujawnienia danych kluczowe jest to, że SharePoint, OneDrive i narzędzia korzystające z tych uprawnień nie „zgadują intencji” właściciela pliku. Jeśli dokument jest dostępny przez szeroki link, grupę lub odziedziczone uprawnienia, system traktuje to jako prawidłowy dostęp. Dlatego najwięcej nieświadomego oversharingu powodują nie pojedyncze błędy użytkownika, lecz kombinacje: szerokie linki, dziedziczenie i zbyt pojemne grupy dostępu.

Jak sprawdzić, które treści Copilot może „widzieć” przez wyszukiwanie i indeksowanie M365?

Trzeba rozdzielić dwie rzeczy: czy dany zasób jest indeksowany przez Microsoft 365 Search oraz czy konkretny użytkownik ma do niego uprawnienia. Copilot korzysta z Microsoft Graph i mechanizmu wyszukiwania M365 tylko w granicach uprawnień użytkownika, więc sama obecność pliku w indeksie nie oznacza jeszcze, że każda osoba może go użyć w odpowiedzi Copilota.

Najprostsza weryfikacja polega na sprawdzeniu, czy treść da się odnaleźć z konta tego samego użytkownika w wyszukiwaniu Microsoft 365, SharePoint lub OneDrive. Jeśli dokument, strona, wiadomość albo element listy pojawia się w wynikach wyszukiwania dla tego użytkownika, to jest to praktyczna przesłanka, że treść jest zarówno zindeksowana, jak i dostępna w jego kontekście uprawnień. Jeśli nie pojawia się w wynikach, przyczyną może być brak indeksacji, wykluczenie z wyszukiwania, opóźnienie indeksu albo po prostu brak dostępu.

W SharePoint warto sprawdzić ustawienia biblioteki, listy lub witryny dotyczące widoczności w wynikach wyszukiwania. Jeżeli dla witryny lub biblioteki wyłączono pokazywanie zawartości w wynikach wyszukiwania, taka treść zasadniczo nie będzie dostępna przez mechanizm wyszukiwania M365. Dodatkowo znaczenie mają etykiety poufności, szyfrowanie i typ pliku, bo mogą ograniczać możliwość odczytu i indeksowania treści.

W praktyce najbardziej miarodajny test to sprawdzenie z perspektywy konkretnego użytkownika: zalogować się na konto testowe z identycznym zakresem uprawnień i wyszukać charakterystyczne fragmenty dokumentu lub nazwę zasobu. To pozwala ocenić, co Copilot może „widzieć” przez wyszukiwanie i indeksowanie w rzeczywistym kontekście dostępu, a nie tylko na poziomie konfiguracji technicznej.

Jak przygotować testy kontrolne promptami, żeby próbować wyciągnąć dane nieuprawnione?

Test kontrolny powinien symulować zachowanie użytkownika, który nie ma dostępu do określonych plików, ale próbuje skłonić asystenta do ujawnienia ich treści pośrednio. Celem nie jest „sprytne obejście” systemu, tylko sprawdzenie, czy odpowiedzi pozostają zgodne z realnymi uprawnieniami. Dlatego scenariusze należy budować wokół danych testowych o znanej zawartości i celowo rozdzielonych uprawnieniach: część materiałów musi być dostępna dla konta testowego, a część wyraźnie niedostępna.

Najlepiej przygotować prompty w kilku wariantach, które sprawdzają różne formy ujawnienia. Nie chodzi wyłącznie o pytanie wprost o treść dokumentu, ale także o próby wydobycia informacji pośrednich: streszczenia, cytatu, listy nazwisk, kwot, terminów, metadanych, porównania dwóch dokumentów, potwierdzenia czy dana informacja „występuje w pliku”, albo odpowiedzi opartych rzekomo na „wcześniej widzianych materiałach”. Jeśli system działa poprawnie, powinien odmówić, wskazać brak dostępu albo oprzeć odpowiedź wyłącznie na zasobach dostępnych użytkownikowi.

Dobre testy są powtarzalne i kontrolowane. Każdy prompt powinien mieć z góry określony oczekiwany wynik: na przykład brak odpowiedzi o dokumencie niedostępnym, brak cytatu, brak listy danych osobowych, brak potwierdzenia istnienia konkretnej informacji. Warto też rozdzielić testy na dwa typy: takie, w których pytanie dotyczy wyłącznie zasobu niedostępnego, oraz takie, w których prompt miesza dane dostępne i niedostępne, bo właśnie w takich sytuacjach łatwo przeoczyć częściowe ujawnienie.

Kluczowe jest także przygotowanie danych znacznikowych, które pozwalają jednoznacznie wykryć wyciek. W praktyce oznacza to umieszczenie w plikach testowych charakterystycznych fraz, unikalnych nazw, kontrolnych numerów lub zdań, które nie występują nigdzie indziej. Dzięki temu można łatwo stwierdzić, czy odpowiedź modelu rzeczywiście odwołała się do niedostępnego źródła, czy tylko wygenerowała ogólną, domyślną treść.

Żeby test był wiarygodny, trzeba wykonywać go z konta o dokładnie sprawdzonych uprawnieniach i dokumentować zarówno prompt, jak i pełną odpowiedź. Ocena nie powinna ograniczać się do pytania „czy pokazał cały dokument”, ale obejmować także ujawnienie fragmentu, parafrazy, wniosku wynikającego z treści pliku lub nawet potwierdzenia, że konkretny plik istnieje i zawiera określone dane. Właśnie takie pośrednie odpowiedzi najczęściej pokazują, czy kontrola dostępu działa prawidłowo także w warstwie generowanej odpowiedzi.

Jak wykorzystać Sensitivity Labels i Microsoft Purview, żeby ograniczyć ryzyko ujawnienia?

Najskuteczniej robi się to przez połączenie klasyfikacji danych z wymuszaniem ochrony. Same uprawnienia do plików nie zawsze wystarczą, bo ryzyko pojawia się także wtedy, gdy dokument jest zbyt szeroko udostępniony, skopiowany do innej lokalizacji albo zawiera dane wrażliwe, których nikt wcześniej nie oznaczył. Sensitivity Labels pozwalają oznaczać pliki i wiadomości według poziomu poufności, a Microsoft Purview dostarcza mechanizmy wykrywania danych wrażliwych, automatycznego etykietowania, zasad DLP i audytu. W praktyce chodzi o to, aby system nie tylko rozpoznawał, że treść jest wrażliwa, ale też automatycznie ograniczał sposób jej użycia.

W kontekście ograniczania ujawnienia kluczowe jest to, że etykieta poufności może wymuszać konkretne zabezpieczenia niezależnie od nazwy pliku czy miejsca przechowywania. Może na przykład szyfrować dokument, ograniczać dostęp do wskazanych użytkowników lub grup, blokować drukowanie, kopiowanie albo przekazywanie dalej. Dzięki temu nawet jeśli plik trafi do szerszego obiegu, jego zawartość pozostaje chroniona zgodnie z polityką organizacji. To ważne szczególnie przy pracy z danymi finansowymi, kadrowymi, prawnymi i informacjami objętymi tajemnicą przedsiębiorstwa.

Microsoft Purview warto wykorzystać do automatycznego wykrywania treści, które powinny być objęte wyższą ochroną. Jeśli dokument zawiera numery identyfikacyjne, dane osobowe, dane płatnicze albo zdefiniowane wzorce biznesowe, Purview może nadać odpowiednią etykietę automatycznie lub zasugerować ją użytkownikowi. To ogranicza zależność od ręcznego oznaczania, które w praktyce bywa pomijane albo wykonywane błędnie. Dodatkowo zasady Data Loss Prevention mogą blokować lub ostrzegać przy próbie udostępnienia takich danych w niewłaściwy sposób, na przykład poza organizację lub do niezatwierdzonej lokalizacji.

Żeby to działało skutecznie, etykiety powinny odpowiadać realnym scenariuszom ryzyka, a nie być wyłącznie formalnym podziałem na poziomy typu „niska”, „średnia” i „wysoka”. Dobra konfiguracja oznacza przypisanie każdej kategorii danych konkretnych skutków technicznych: kto może otworzyć plik, czy wolno go pobrać, czy można go wysłać poza organizację i czy jego użycie jest rejestrowane. Purview uzupełnia to przez możliwość monitorowania zdarzeń i sprawdzenia, gdzie dane wrażliwe występują oraz jak są wykorzystywane. Dzięki temu można wykryć miejsca, w których ochrona jest zbyt słaba, zanim dojdzie do niezamierzonego ujawnienia.

Najważniejsze jest więc nie samo „oznaczenie” dokumentów, ale powiązanie etykiet z egzekwowalną ochroną i politykami Purview. Sensitivity Labels klasyfikują i wymuszają zabezpieczenia na poziomie pliku lub wiadomości, a Microsoft Purview automatyzuje wykrywanie, zapobiega nieprawidłowemu udostępnianiu i daje wgląd w to, gdzie ryzyko nadal istnieje. Tylko takie połączenie realnie zmniejsza prawdopodobieństwo, że wrażliwe informacje zostaną ujawnione mimo błędów użytkownika lub zbyt szerokiego dostępu.

Gdzie sprawdzać logi i audyt, żeby wykrywać podejrzane użycie Copilot?

Najważniejsze są trzy miejsca: logi aktywności użytkowników, dzienniki dostępu do plików oraz audyt zmian uprawnień. Samo sprawdzanie odpowiedzi generowanych przez Copilot zwykle nie wystarcza, bo sygnał o nadużyciu częściej widać wcześniej: w nietypowych otwarciach dokumentów, nagłych wzrostach odczytów, seryjnym wyszukiwaniu treści albo zmianach członkostwa w grupach i uprawnieniach, które rozszerzają zakres danych widocznych dla użytkownika.

W praktyce należy analizować audyt usług, w których znajdują się dane używane przez Copilot, czyli przede wszystkim repozytoria plików, pocztę, czaty, dokumenty współdzielone i wyszukiwarkę organizacyjną. Trzeba szukać zdarzeń takich jak odczyt pliku, podgląd, pobranie, udostępnienie, nadanie dostępu, zmiana linku udostępniania, dołączenie do zespołu lub grupy oraz masowe zapytania do treści. Podejrzane są szczególnie wzorce odbiegające od roli użytkownika: dostęp do dokumentów spoza jego obszaru, aktywność poza typowymi godzinami, nagły wzrost liczby otwieranych plików albo sekwencje działań sugerujące „sondowanie” danych przed zadaniem pytań do Copilot.

Osobno warto sprawdzać logi administracyjne i tożsamościowe, bo nadużycie nie zawsze wynika z samego użycia Copilot, lecz z wcześniejszego uzyskania szerszych uprawnień. Jeśli użytkownik nagle trafia do grupy dającej dostęp do wrażliwych zasobów albo ktoś zmienia polityki udostępniania, to właśnie tam pojawia się pierwszy twardy ślad. W takim dochodzeniu kluczowe jest korelowanie czasu: czy tuż po zmianie uprawnień pojawiły się odczyty dokumentów, wyszukiwania i aktywność, której wcześniej nie było.

Żeby taki audyt miał wartość, trzeba ustawić alerty na anomalie, a nie tylko przeglądać logi ręcznie. Najbardziej użyteczne są reguły wykrywające nietypowy wolumen odczytów, dostęp do danych o wysokiej wrażliwości, seryjne otwieranie wielu plików przez jednego użytkownika oraz zmiany uprawnień wykonane tuż przed zwiększoną aktywnością. Jeżeli organizacja ma klasyfikację informacji, warto filtrować zdarzenia właśnie po etykietach poufności i lokalizacjach, w których przechowywane są najwrażliwsze materiały.

Najkrócej: podejrzanego użycia Copilot nie szuka się w jednym „logu Copilot”, tylko w połączonym audycie dostępu do danych, wyszukiwania treści, aktywności użytkownika i zmian uprawnień. Dopiero taki pełny obraz pozwala odróżnić zwykłą pracę od prób wydobywania informacji, do których użytkownik formalnie nie powinien mieć praktycznego wglądu.

Jakie szybkie zasady governance najbardziej zmniejszają ryzyko wycieku przez Copilot?

Najszybciej działają te zasady, które ograniczają nadmiarowy dostęp do danych u źródła i zmniejszają ryzyko, że Copilot zinterpretuje jako dostępne treści, które w praktyce nie powinny być szeroko widoczne. Copilot nie „omija” uprawnień, ale potrafi ujawnić informacje z plików, miejsc i konwersacji, do których użytkownik ma już dostęp — także wtedy, gdy ten dostęp został przyznany zbyt szeroko, przypadkowo albo historycznie.

• Zasada najmniejszych uprawnień: ograniczaj dostęp do plików, bibliotek, zespołów i grup tylko do osób, które realnie go potrzebują. Największe ryzyko wynika zwykle nie z samego Copilota, lecz z dziedziczonych, starych lub zbyt szerokich uprawnień.
• Porządek w udostępnianiu: ogranicz linki „każdy z linkiem”, dostęp dla wszystkich w organizacji i masowe udostępnienia bez właściciela. Preferuj dostęp nadawany konkretnym osobom lub grupom o jasno określonym składzie.
• Separacja danych wrażliwych: dokumenty zawierające dane poufne, kadrowe, finansowe lub prawne trzymaj w osobnych lokalizacjach z ostrzejszymi zasadami dostępu. Nie mieszaj ich z obszarami roboczymi o szerokiej współpracy.
• Minimalne, ale obowiązkowe etykiety i reguły ochrony: oznaczaj treści wrażliwe i powiąż je z automatycznymi ograniczeniami, np. blokadą zbyt szerokiego udostępniania. Nawet prosta klasyfikacja jest lepsza niż brak rozróżnienia między dokumentem roboczym a poufnym.

W praktyce warto też wprowadzić krótką zasadę operacyjną: najpierw porządek w uprawnieniach i udostępnieniach, dopiero potem szerokie użycie Copilota. To najszybszy sposób obniżenia ryzyka ujawnienia treści, które formalnie są dostępne, ale nie powinny być łatwo odnajdywane i streszczane przez narzędzie generatywne.

Jeśli organizacja chce osiągnąć efekt szybko, powinna zacząć od przeglądu lokalizacji o najwyższym ryzyku: wspólnych bibliotek, zespołów z otwartym członkostwem, folderów z linkami publicznymi lub organizacyjnymi oraz starszych zasobów bez aktywnego właściciela. To zwykle daje większą redukcję ryzyka niż rozbudowane polityki opisowe bez zmian w realnym modelu dostępu.

Testy z Claude Code: jak przyspieszyć QA bez obniżania jakości 27 maja 2026

Claude Code w praktyce: jak AI zmienia tworzenie oprogramowania od zera do wdrożenia 25 maja 2026