RBAC dla DPP — jak udostępniać dane dostawcom i audytorom bez odsłaniania całego katalogu

Status funkcji: Scoped Collaboration, product/product-group/supplier scopes, temporary guest access i uprawnienia do wybranych pól oraz evidence są planowanym kierunkiem DPP Compliance. Nie są obecnie oferowane jako aktywna funkcja samoobsługowa. Materiał jest wzorcem architektury i listą pytań wdrożeniowych, nie opisem dostępnego Supplier Portal ani gwarancją bezpieczeństwa.

RBAC, czyli dostęp oparty na rolach, odpowiada na pytanie, jakie działania należą do danej roli. Przy danych DPP potrzebne jest jeszcze ograniczenie na których rekordach i polach wolno je wykonać. „Viewer” całej organizacji i audytor dziesięciu produktów to dwie różne potrzeby.

Współpraca z dostawcą powinna umożliwiać wykonanie konkretnej prośby, bez otwierania wszystkich dokumentów firmy. Poniżej proponujemy model Role + Scope + Action, rozszerzony o widoczne pola, wersje dowodów i termin ważności.

1. Najpierw tenant, później zakres wewnątrz organizacji

Izolacja tenantów oddziela prywatne dane różnych organizacji. Nie rozwiązuje jednak przypadku dwóch dostawców pracujących dla tej samej firmy. Supplier A i Supplier B mogą uczestniczyć w jednym workspace, ale nie powinni otrzymywać wzajemnie swoich danych.

Proponowany porządek decyzji:

Potwierdzona tożsamość
→ właściwa organizacja
→ aktywny grant
→ dozwolony produkt / wymaganie / dokument
→ dozwolona czynność
→ dozwolone pola i rewizje
→ odpowiedź lub odmowa

Brak zakresu nie oznacza „cała organizacja”. Nieznana relacja produktu z dostawcą, wygasły grant lub brak wersji polityki powinny kończyć się odmową, nie zgadywaniem dostępu.

2. Rola, zakres i działanie muszą pasować do tej samej operacji

Przykład syntetyczny:

Principal: respondent ACME
Organization: organizacja klienta
Products: P-184, P-185, P-186
Requirement: material_composition
Actions: view_request, submit_value, upload_evidence
Visible fields: nazwa, identyfikator, pytanie i własna odpowiedź
Internal comments: hidden
Export / approve / publish / manage_access: denied
Expires at: jawny termin

Uprawnienia do submit_value nie należy zastępować zwykłym edit całego produktu. Dostawca może zaproponować odpowiedź, która następnie przechodzi review. Osobne prawo publish dotyczy decyzji o udostępnieniu paszportu.

Jeżeli ten sam użytkownik posiada kilka grantów, nie wolno połączyć prawa edit dla produktu A z prawem view dla produktu B, aby pozwolić mu edytować B. Każda operacja musi być pokryta właściwym grantem; reguły konfliktu i łączenia projekcji wymagają jawnego kontraktu.

3. Scope produktu nie wystarczy bez projekcji danych

Produkt może zawierać materiał od wielu dostawców, ceny, komentarze, dane source system i dokumenty z innym zakresem. Odpowiedź dla gościa powinna zawierać tylko potrzebną projekcję danych, nie cały obiekt z ukrytymi polami w interfejsie.

Maskowanie jest projekcją odpowiedzi, nie usuwaniem wartości z kanonicznego modelu. Historia produktu pozostaje pełna dla uprawnionych osób, ale jej udostępnienie też wymaga kontroli zakresu.

OWASP Authorization Cheat Sheet rozróżnia logowanie od autoryzacji i wskazuje potrzebę sprawdzania dostępu także do zasobów statycznych. Dla tego workflow proponujemy traktować download i eksport jako osobne chronione operacje, a nie skutki uboczne prawa do ekranu produktu.

4. Czy supplier scope obejmuje nowe produkty?

Filtr supplier_id = ACME może dziś obejmować 12 rekordów, a jutro 184. Zmiana relacji, import CSV albo przeniesienie rodziny produktu może niejawnie rozszerzyć dostęp.

Na początku warto zamrozić listę identyfikatorów objętych zgodą. Dynamiczne scopes powinny później mieć jawne zasady: czy nowe rekordy wchodzą do zakresu, kto to zatwierdza i jak odbieramy dostęp po zmianie dostawcy. Podgląd liczby produktów w momencie zaproszenia nie jest gwarancją niezmiennego zakresu.

Podobnie prawo do Declaration v3 nie musi obejmować przyszłej v4. Wersjonowanie dokumentów powinno zachować dowód użyty w konkretnej ocenie i oddzielnie określać, które rewizje wolno pokazać gościowi.

5. Audytor: read-only, konkretny zakres, termin

Proponowany dostęp audytora obejmuje wybrane produkty i dokumenty, cel audytu oraz expires_at. Odczyt nie daje domyślnie prawa do eksportu. Samo nazwanie roli „External auditor” nie nadaje praw organu nadzoru rynku.

Wygaśnięcie trzeba sprawdzać w momencie żądania, również gdy job przypomnień się spóźnia. Odebranie grantu powinno działać dla aktywnej sesji oraz plików. Podpisany URL do storage nie może pozostawać drogą obejścia odebranego dostępu; należy dobrać gateway lub mechanizm storage do tej zasady.

Pobranej kopii dokumentu nie można zdalnie odebrać. Dlatego zatwierdzenie eksportu powinno obejmować również cel, odbiorcę i zasady przechowywania kopii poza systemem. Nie należy obiecywać, że wygaśnięcie konta usuwa wszelkie wcześniej pobrane materiały.

6. Access preview i historia grantów

„Preview access as this user” warto zaprojektować jako read-only wyjaśnienie: jakie zasoby są dostępne, jakie pola zostaną pominięte i które czynności będą odrzucone. To nie impersonacja ani sesja z możliwością zapisu. Podgląd nie może ujawnić autorowi danych poza jego własnymi uprawnieniami.

Zmiana grantu powinna zachowywać aktora, odbiorcę, zakres przed i po zmianie, powód, termin oraz wersję polityki. Log nie musi kopiować treści dokumentu, hasła lub tokenu zaproszenia, aby pokazać, kto rozszerzył dostęp.

Kontrola planu abonamentowego jest oddzielna. Downgrade nie może rozszerzać dostępu: jeśli kończy się zaawansowana funkcja współpracy, nie należy zastępować ograniczonego grantu szeroką rolą organizacyjną.

7. RACI, uprawnienia workspace i prawa DPP to osobne modele

RACI wskazuje odpowiedzialność za dostarczenie lub poprawienie danych. Grant wskazuje autoryzację. Profil regulacyjny wskazuje wymagania i prawa odbiorców paszportu. Zmiana jednego modelu nie powinna automatycznie nadawać uprawnień w pozostałych.

W ESPR, art. 9–11 zakres dostępu do DPP zależy od właściwych aktów produktowych. Poniższa architektura współpracy jest propozycją techniczną, nie prawnym upoważnieniem do ograniczania odbiorcom należnych informacji.

Publiczny DPP i prywatny workspace to różne projekcje. Udostępnienie evidence audytorowi nie powinno go publikować pod QR. Zmiana grantu nie powinna nadpisywać niezmiennej historycznej wersji paszportu. Wynik gotowości danych nadal nie jest ustaleniem zgodności prawnej.

Checklista testów przed uruchomieniem współpracy

• Użytkownik innej organizacji i dostawca B nie odczytują zasobów dostawcy A przez podmienione ID.
• Listy, search, facet, readiness count i eksport nie ujawniają danych spoza zakresu.
• Respondent może przesłać propozycję, lecz nie może zatwierdzić własnego dowodu ani opublikować DPP.
• Owner zadania w RACI nie otrzymuje automatycznie grantu.
• Expiry i revoke chronią sesję, download i worker; link przekazany innej osobie nie zastępuje weryfikacji odbiorcy.
• Nowy produkt, rewizja dokumentu i zmiana dostawcy nie rozszerzają uprawnień bez reguły i decyzji.
• Access preview zgadza się z rzeczywistą odpowiedzią API, nie ma skutków ubocznych i nie eskaluje praw.
• Zmiana planu nie odsłania katalogu, a zmiana dostępu nie modyfikuje historycznych DPP.

Zakres wdrożenia i oferta

Nie trzeba zaczynać od rozbudowanego silnika polityk, SSO i SCIM. Pierwszy etap może obejmować jeden workflow dostawcy, zamrożoną listę produktów, kilka dozwolonych pól, review i wygaśnięcie dostępu. Kolejne scopes mają sens dopiero po sprawdzeniu tej granicy bezpieczeństwa.

Materiały te nie dodają Scoped Collaboration do aktywnego zakresu Free ani zapowiadanych planów płatnych. Dostępność pokazuje cennik, a wdrożenie DPP może zacząć się od warsztatu zakresu współpracy. Uporządkowanie modelu dostępu nie zastępuje analizy prawnej ani nie stanowi certyfikacji bezpieczeństwa lub produktu.