Postępowanie z danymi

1Security czyta o Twoim tenancie sporo, więc pytanie „co się z tym dzieje?" jest w pełni uzasadnione - i zwykle pada jako pierwsze w przeglądzie bezpieczeństwa. Ta strona odpowiada na nie w kolejności, w jakiej takie przeglądy zwykle idą.

Co jest czytane, a co przechowywane

To rozróżnienie znaczy więcej niż sama objętość. Większość tego, czego 1Security dotyka, jest czytana, oceniana i odrzucana; zostaje mapa, nie materiał.

Jak skanowanie wrażliwości analizuje treść

Silnik wrażliwości działa we własnym procesie Twojego wdrożenia:

• Detektory są deterministyczne - ponad 300 detektorów opartych na wyrażeniach regularnych i słowach kluczowych, plus reguły walidacji, np. sumy kontrolne formatów kart i identyfikatorów.
• OCR działa lokalnie - obrazy i skany przetwarzane są offline w tym samym procesie, nie są nigdzie wysyłane.
• Żaden zewnętrzny dostawca AI nie widzi treści plików w konfiguracji domyślnej. Opcjonalna analiza wspierana modelem językowym istnieje dla trudniejszych przypadków, jest włączana per tenant i wraca do detektorów deterministycznych zawsze, gdy AI dla tenanta jest wyłączone.

Gdzie żyją dane

Szczegóły wdrożeń, wymiarowanie i szacunki kosztów są w Instalacji.

Izolacja tenantów

Każdy podłączony tenant domyślnie dostaje własną, dedykowaną bazę danych, a nie wspólną tabelę z kolumną tenanta. Zapytanie wykonane dla jednego tenanta fizycznie nie może sięgnąć wierszy innego. Do tego każda tabela związana z tenantem nosi jego identyfikator, a każde zapytanie po nim filtruje - izolacja jest wymuszona dwukrotnie: na poziomie infrastruktury i na poziomie zapytań.

Jedynym celowym wyjątkiem jest grupa tenantów: tenanci, których administrator jawnie połączył w jeden panel, współdzielą jedną bazę danych. To decyzja Twojego własnego administratora w momencie podłączania, może objąć wyłącznie tenantów Twojej organizacji, a ograniczenie zapytań do tenanta nadal obowiązuje przy każdym odczycie i zapisie. Dwóch różnych klientów nigdy nie współdzieli bazy danych.

To także sprawia, że scenariusze wielotenantowe są bezpieczne dla MSP i grup kapitałowych: podłączenie drugiego tenanta dokłada bazę danych (chyba że celowo go łączysz), nie poszerza promienia rażenia pierwszego.

Dostęp wewnątrz 1Security

Czytanie Twojego tenanta to jedno pytanie o uprawnienia; kto w Twojej organizacji może to czytać w 1Security - to drugie. Przy zapraszaniu użytkownika dostępne są trzy poziomy:

• Synchronizacja z Microsoft 365 - status administratora wynika z istniejących ról Entra danej osoby.
• Administrator - pełny dostęp do wszystkich zasobów, ustawień i podłączonych tenantów.
• Użytkownik (ograniczony dostęp) - widzi wyłącznie własne zasoby: pliki, e-maile, grupy i witryny, które posiada lub z którymi pracuje, plus trendy jawnie mu udostępnione.

Przed wysłaniem zaproszenia użytkownikowi ograniczonemu możesz podejrzeć dokładnie to, co zobaczy. Szczegóły w Pierwszych krokach.

Uprawnienia zapisu

Instalacja bazowa nie może niczego zmienić w Twoim tenancie. Zapis istnieje w dokładnie dwóch opcjonalnych modułach - Automatyzacje i Zarządzanie skrzynkami - a nawet po ich włączeniu:

• Działania czekają w kolejce przeglądu z okresem karencji, zanim cokolwiek się wykona.
• Każde działanie trafia do rejestru, który można odtworzyć - co zaproponowano, kto zatwierdził, co faktycznie się zmieniło.
• Działania na skrzynkach izolują lub oznaczają wiadomości; nie usuwają trwale.

Dokładne uprawnienia każdego modułu wypisuje strona Wymagania.

Retencja

• Historia aktywności jest przechowywana tak długo, jak aktywna jest subskrypcja, maksymalnie trzy lata. Trzy lata ciągłej subskrypcji to trzy lata historii dostępnej do śledztwa - znacznie ponad domyślną retencję audytu w Microsofcie.
• Ustalenia dotyczące wrażliwości i graf uprawnień odzwierciedlają bieżący stan tenanta i są odświeżane przez skanowania; punkty historyczne trendów zostają, żeby było widać kierunek zmian.

Odłączenie i usunięcie danych

Tenanta odłączasz w Ustawienia → Tenanci → Odłącz. Wszystkie dane związane z tym tenantem znikają z 1Security w ciągu 7 dni.

Odłączenie usuwa dane tenanta w całości: dedykowana baza samodzielnego tenanta jest usuwana jako całość, a dane tenanta połączonego są kasowane z bazy współdzielonej przez jego własną grupę. W obu przypadkach nie zostaje żaden osad w zbiorze innego klienta - baza jest współdzielona wyłącznie wewnątrz jednej organizacji, z jej własnego wyboru.

Cofnięcie zgody w Microsoft Entra również natychmiast odcina dostęp, niezależnie od tego, co zrobisz w 1Security: tokeny aplikacji przestają działać w chwili wycofania zgody.

Zgłoszenia do katalogu AI

1Security klasyfikuje aplikacje według możliwości AI (oparte na Copilot, własny model dostawcy, hybrydowe) i pozwala administratorom poprawiać lub uzupełniać tę klasyfikację. Takie zgłoszenia mogą być przekazywane do katalogu AI 1Security, dzięki czemu klasyfikacja poprawia się u wszystkich klientów.

Jak dokładnie działa ten kanał:

• Co jest wysyłane: globalne identyfikatory aplikacji (identyfikator aplikacji Microsoft, nazwa, wydawca), zaproponowana klasyfikacja, opcjonalna notatka administratora i pseudonimowy identyfikator wdrożenia. Jedna paczka dziennie.
• Czego nigdy nie wysyłamy: tożsamości tenanta ani użytkowników, nazw i treści plików, instrukcji agentów, danych aktywności ani zgłoszeń oznaczonych "nie udostępniaj poza moją organizację".
• Kontrola: udostępnianie jest domyślnie włączone i można je wyłączyć per tenant w Ustawienia → Integracje, gdzie opcja Zobacz przykładowy pakiet danych pokazuje dokładny JSON najbliższej wysyłki. Operatorzy wdrożeń self-hosted wyłączają kanał całkowicie przez AI_TELEMETRY_ENDPOINT=''; instalacje air-gap nie są objęte (wysyłka po cichu nic nie robi).
• Audyt: każda zmiana zgody i każda transmisja są zapisywane w dzienniku audytu, a każda wysyłka pojawia się w dzienniku aktywności tenanta jako wpis 1Security ("Agentic feedback has been sent").

Zgłoszenia geolokalizacji

1Security klasyfikuje sieci, z których pochodzą logowania i aktywność (centrum danych, VPN, Tor, zwykły dostawca internetu) i je geolokalizuje. Dostawcy chmury przenoszą zakresy IP szybciej, niż nadążają publiczne bazy, więc administratorzy mogą zgłaszać korekty ("ten zakres to centrum danych Azure", "błędny kraj") - a takie zgłoszenia faktów o sieci mogą być przekazywane dalej, aby geolokalizacja poprawiała się u wszystkich klientów. Zweryfikowane korekty trafiają do wszystkich wdrożeń jako kuratorowany plik nakładki; surowe zgłoszenia nigdy nie są stosowane u innych klientów bezpośrednio.

Jak dokładnie działa ten kanał:

• Co jest wysyłane: publiczne identyfikatory sieci (ASN, nazwa operatora), zaobserwowana i zaproponowana klasyfikacja, opcjonalna notatka administratora, znaczniki wersji zbiorów danych oraz ten sam pseudonimowy identyfikator wdrożenia, którego używa kanał AI. Jedna paczka dziennie.
• Czego nigdy nie wysyłamy: tożsamości tenanta ani użytkowników, adresów IP, danych o aktywności ani liczników zdarzeń, lokalizacji firmowych, oznaczeń zaufana/podejrzana, zgłoszeń opisujących własną infrastrukturę ("to nasz firmowy VPN") ani zgłoszeń oznaczonych "nie udostępniaj poza moją organizację". Te wykluczenia są wymuszane po stronie serwera, nie tylko w formularzu.
• Kontrola: osobna zgoda niż dla kanału AI - domyślnie włączona, przełączana per tenant w Ustawienia → Integracje na tej samej karcie udostępniania opinii o klasyfikacji, z własną opcją Zobacz przykładowe dane. Operatorzy wdrożeń self-hosted wyłączają kanał całkowicie przez GEO_TELEMETRY_ENDPOINT=''; instalacje air-gap nie są objęte (wysyłka po cichu nic nie robi).
• Audyt: zmiany zgody i transmisje są zapisywane w dzienniku audytu, a każda wysyłka pojawia się w dzienniku aktywności tenanta jako wpis 1Security ("Geolocation feedback has been sent").

Kanały zgłoszeń do katalogu AI i geolokalizacji to jedyny ruch, jaki serwer wdrożenia self-hosted wysyła do 1Security - nie ma sprawdzania licencji, pingów wersji ani telemetrii użycia. (Pobrania zbiorów danych geo - publiczne bazy IP, pliki zakresów dostawców chmury, lista węzłów wyjściowych Tor i kuratorowana nakładka 1Security - to ruch przychodzący po publiczne dane, bez żadnych danych wychodzących.)

Zgłoszenia błędów i awarii

Dwa kanały po stronie przeglądarki również wysyłają dane ze strony, na której jest użytkownik, i należą do tej samej listy transparentności:

• Okno zgłaszania problemu w produkcie wysyła treść wpisaną przez użytkownika, opcjonalny e-mail kontaktowy oraz - tylko dopóki pole wyboru pozostaje zaznaczone - dane diagnostyczne (ścieżka, przeglądarka, skrót błędu). Zgłoszenie trafia do dziennika błędów platformy: w Chmurze (SaaS) do środowiska 1Security, w BYOC/On-Premise do bazy Twojego wdrożenia.
• Telemetria awarii (Sentry) raportuje błędy po stronie klienta ze stack trace'ami i kontekstem strony - nigdy treści plików ani wiadomości. Środowiska self-hosted, które nie mogą wysyłać żadnej telemetrii z przeglądarek, mogą zablokować host Sentry na poziomie sieci; aplikacja działa bez zmian.

Częste pytania w przeglądach bezpieczeństwa