Uprawnienia w Digital Product Passport — kto powinien widzieć dane produktu, dostawcy i evidence?

Status funkcji: product-level scopes, Supplier Portal, uprawnienia do wybranych pól i evidence oraz czasowy dostęp gościa opisane w tym materiale są planowanym kierunkiem DPP Compliance. Nie są obecnie oferowane jako aktywna funkcja samoobsługowa. Poniższe role i przykłady to wzorzec projektowy, a nie ekran lub gotowa konfiguracja aplikacji.

Producent może potrzebować deklaracji od jednego dostawcy, przeglądu dokumentu przez Compliance i udziału zewnętrznego audytora. Nie oznacza to, że każdy z nich powinien zobaczyć wszystkie SKU, ceny, pliki i komentarze organizacji.

Najważniejsze pytanie przed zaproszeniem brzmi: co ta osoba ma zobaczyć lub zmienić, aby wykonać konkretną pracę? Dopiero później wybieramy nazwę roli.

Trzy różne warstwy dostępu w DPP

ESPR przewiduje określenie odbiorców danych i zakresu aktualizacji w aktach dotyczących danej grupy produktów. Wewnętrzna macierz ról firmy nie może ich zastąpić ani uchylić. Nie istnieje jedna lista firmowych ról, która sama dowodzi prawnej zgodności DPP. Podstawa: rozporządzenie (UE) 2024/1781, art. 9–11.

Dla baterii szczegółowe rozróżnienia opisuje osobny materiał Battery Passport access rights. Tutaj skupiamy się na współpracy przy przygotowaniu danych, a nie na finalnej konfiguracji dostępu regulacyjnego.

Role + Scope + Action: prosty sposób opisania uprawnień

Role określa rodzaj pracy, Scope ogranicza jej zakres, a Action wskazuje dozwoloną czynność. W praktyce potrzebna jest jeszcze lista widocznych pól i dokumentów oraz termin dostępu.

Przykład syntetyczny:

• rola: respondent dostawcy ACME;
• zakres: 12 wskazanych produktów i pytanie o skład materiałowy;
• czynności: odczytaj prośbę, przekaż proponowaną wartość, dodaj deklarację;
• niewidoczne: inni dostawcy, ceny ERP, wewnętrzne komentarze i pozostałe produkty;
• bez prawa: zaakceptuj dowód, opublikuj DPP, eksportuj katalog;
• ważność: do zakończenia zadania, nie dłużej niż zatwierdzona data.

Przekazanie propozycji nie powinno automatycznie zapisywać jej jako zatwierdzonych danych produktu. Publiczny paszport nie powinien zmieniać się po samym uploadzie pliku dostawcy.

Kto powinien widzieć dane produktu i evidence?

To przykładowa macierz do dostosowania podczas wdrożenia, nie uniwersalne prawa poszczególnych zawodów.

Jeżeli jeden dokument dotyczy wielu produktów, dostęp do jednego produktu nie musi oznaczać prawa do całego pliku. Deklaracja może zawierać inne SKU, strony lub dane handlowe. Przed udostępnieniem trzeba wybrać właściwą rewizję i ocenić jej pełną zawartość; samo ukrycie nazwy pliku nie rozwiązuje tego problemu.

RACI nie nadaje dostępu

RACI i Data Stewardship mówią, kto powinien wykonać pracę. Uprawnienia mówią, co ta osoba może zobaczyć lub zmienić.

Wpisanie Procurement jako ownera luki nie powinno automatycznie nadawać dostępu do całego katalogu. Podobnie powiadomienie o zadaniu ani link przesłany e-mailem nie są samodzielną zgodą na odczyt dokumentu.

Przykład: Procurement pozyskuje deklarację, Compliance ocenia jej zakres, a Publisher odpowiada za decyzję publikacyjną. Te etapy można rozdzielić, nawet jeżeli w małej firmie wykonuje je jedna osoba. Nazwy stanowisk nie tworzą automatycznych grantów.

Zaproszenie: najpierw podgląd dostępu, potem wysyłka

Zamiast samego „Role: Supplier” warto przygotować widok:

Co ta osoba może zobaczyć?
12 zatwierdzonych produktów ACME — lista konkretnych identyfikatorów
Pola: skład materiałowy + odpowiedź na prośbę
Dokumenty: wskazane rewizje deklaracji

Może: przekazać propozycję danych, dodać dowód
Nie może: widzieć uwag wewnętrznych, innych dostawców, publikować DPP
Eksport: niedozwolony
Dostęp wygasa: wskazana data i godzina

Podgląd „jako ten użytkownik” powinien być wyjaśnieniem decyzji, nie przejęciem jego sesji. Osoba zapraszająca nie powinna przez podgląd odkrywać danych, których sama nie ma prawa zobaczyć.

Lista nie może rozszerzać się niejawnie. Jeżeli później nowy produkt zostanie przypisany do ACME albo do rodziny Furniture, trzeba ustalić, czy obejmuje go dotychczasowa zgoda. Dla pierwszego wdrożenia bezpieczniejsza jest jawna lista produktów niż dynamiczny filtr bez reguły rozszerzania.

Dostęp czasowy, eksport i cofnięcie zgody

Audyt trwający 14 dni nie uzasadnia bezterminowego dostępu. Warto zapisać cel, odbiorcę, zakres, zatwierdzającego i datę wygaśnięcia, a następnie sprawdzać je również podczas pobierania pliku.

Read-only nie oznacza prawa do eksportu. Eksport może zawierać znacznie więcej informacji niż pojedynczy ekran i tworzy kopię poza kontrolą workspace. Wygaśnięcie dostępu nie usuwa plików już pobranych przez odbiorcę — zasady ich przechowywania trzeba ustalić oddzielnie.

Odebranie dostępu powinno chronić API, pliki i aktywne sesje, nie tylko menu. Zmiana planu abonamentowego również nie powinna zamieniać ograniczonego gościa w użytkownika z pełnym katalogiem.

Checklista przed współpracą z dostawcą lub audytorem

1. Wybierz organizację, produkty i cel współpracy.
2. Wskaż pola oraz konkretne dokumenty, które rzeczywiście trzeba ujawnić.
3. Oddziel odczyt, edycję, zgłoszenie danych, approval, publikację i eksport.
4. Ustal, czy zakres obejmuje przyszłe produkty i nowe rewizje — nie zakładaj tego domyślnie.
5. Zapisz termin, sposób weryfikacji odbiorcy oraz procedurę odebrania dostępu.
6. Sprawdź widok gościa, pełną treść plików, listy i wyniki wyszukiwania.
7. Zachowaj historię: kto, komu, co i do kiedy udostępnił.

Nie wystarczy ukrycie przycisku w interfejsie. OWASP zaleca minimalne uprawnienia, domyślną odmowę i sprawdzanie autoryzacji przy każdym żądaniu. Powyższa checklista jest propozycją wdrożeniową dla danych DPP, nie certyfikatem bezpieczeństwa aplikacji.

Jak zacząć z DPP Compliance?

W planie Free można zacząć podstawowy workflow produktu i paszportu. Nie należy jednak zapraszać zewnętrznego dostawcy z szeroką rolą organizacyjną w oczekiwaniu izolacji do jednego SKU. Granularne scopes i Supplier Portal pozostają planowane; aktualny zakres oferty pokazuje cennik.

Jeżeli chcesz przygotować współpracę z dostawcami, omów wdrożenie DPP: zaczniemy od zakresu produktów, macierzy działań i danych, które nie mogą być ujawnione. Wynik readiness ani poprawnie ustawiona rola nie stanowią prawnego potwierdzenia zgodności produktu.