Tenant Dashboard
Panel operatora tenant
Używaj dashboard.attesto.eu do operacji po stronie tenant. Ta strona opisuje wyłącznie zewnętrzne tenant workflows.
Tożsamość i dostęp
Użytkownicy tenant logują się przez email-first dashboard flow. Pierwszy ekran prosi tylko o adres e-mail; następnie Attesto kieruje użytkownika do skonfigurowanej ścieżki password, community identity, invite, signup albo organization SSO. Tenant owners konfigurują Entra ID, generic OIDC i SAML providers w Settings → Identity Providers.
- Używaj tenant roles do dostępu do dashboard: owner, admin, developer i user.
- Marketplace developer accounts działają tylko w marketplace; nie dają dostępu do dashboard.
- Używaj auditor invites do audit portal; auditorzy nie otrzymują uprawnień tenant operator.
- Przeczytaj Tenant SSO przed wymuszeniem organization SSO dla domeny.
Systems i keys
- Utwórz jeden system dla każdej usługi produkcyjnej lub izolowanego środowiska.
- Skopiuj wygenerowaną system key, gdy zostanie wyświetlona, i przechowuj ją server-side.
- Rotuj keys, gdy system zmienia ownership, hosting boundary albo deployment trust.
- Wyłącz nieużywane systems zamiast wykorzystywać ich keys dla niepowiązanych usług.
Widoki Proofstream
Strony stream pokazują event sequence, receipt state, window i checkpoint state, witness/quorum status, anchor status, fork evidence oraz verifier bundle readiness.
- Receipt dowodzi, że Attesto zaakceptowało konkretny event do konkretnej stream head.
- Checkpoint podsumowuje zamkniętą range i linkuje do consistency evidence.
- Fork evidence wymaga natychmiastowego dochodzenia przed poleganiem na tej stream history.
- Bundle export jest dostępny dopiero po spełnieniu policy requirements.
Webhooki i konektory
Webhooki powiadamiają systemy klienta, gdy zmienia się Attesto evidence. Konektory zapisują obserwacje z systemów źródłowych do Proofstream. Użyj dashboard, aby tworzyć i odwoływać tenant webhooks, signed webhook connectors, repository webhook connectors, S3/R2 object commitments oraz instalacje Local Vault. Każdy zwrócony secret przechowuj server-side; dashboard celowo nie pokazuje go ponownie.
- Webhook subscriptions dostarczają podpisane notifications; odbiorcy muszą weryfikować raw-body signature.
- Signed webhook connectors przyjmują custom source events przez signed envelope specyficzne dla konektora.
- Repository connectors weryfikują GitHub/GitLab delivery signatures przed zapisaniem znormalizowanej evidence.
- S3/R2 object commitments zapisują metadane i integralność obiektu bez proxy object bytes.
- Local Vault przekazuje customer-edge events outbound i może działać jako customer-side witness, gdy policy to włącza.
Evidence exports
Exports są immutable evidence artifacts dla wybranego tenant scope i date range. Udostępniaj wyeksportowane bundles auditorom lub counterparties dopiero po potwierdzeniu range, policy i retention requirements.
Generowanie Truth Package, download/access i udana weryfikacja
kryptograficzna same są lifecycle evidence. Generowanie package
zapisuje truth_package.generated, download lub auditor
access zapisuje truth_package.accessed, a verifier report
zweryfikowany przez backend zapisuje truth_package.verified.
Przekazanie do audit portal
audit.attesto.eu to read-only portal dla zewnętrznych auditorów zaproszonych przez tenant. Auditorzy uwierzytelniają się przez audit flow, widzą tylko przyznane tenant scopes, pobierają zatwierdzone exports i przeglądają events, receipts, checkpoints oraz bundle evidence bez stawania się tenant operators.
Login audit jest celowo oddzielony od tożsamości dashboard i marketplace. Auditor podaje adres e-mail, otrzymuje jednorazowy magic link, jeśli adres należy do zaproszonego lub aktywnego auditora, a następnie kończy TOTP z authenticator app. Link jest ważny przez 15 minut; first-time auditorzy przechodzą najpierw TOTP enrollment. Odpowiedź request-link jest zawsze generyczna, aby nie umożliwiać enumeracji adresów e-mail auditorów.
Landing page auditora pokazuje tylko aktywne tenant grants z zatwierdzonym scope, datą wygaśnięcia, 30-dniowym event count i wskaźnikiem ostatniego anchor. Tenant view pozostaje read-only: wygasłe lub odwołane grants są odrzucane zanim załadują się events, exports, Proofstream bundles, forks albo IVC epochs. Audit sessions nie logują auditora do dashboard, marketplace ani żadnej wewnętrznej powierzchni staff Attesto.
| Akcja audit portal | Co jest zapisywane | Dlaczego to ważne |
|---|---|---|
| Otwarcie dashboard | auditor.view.dashboard per tenant w scope. | Tenant widzi, że auditor otworzył audit landing page. |
| Otwarcie tenant audit view | Read-only access check wobec aktywnego, niewygasłego auditor grant. | Wygasłe lub odwołane grants fail-closed. |
| Podgląd event/export/bundle data | Tenant audit entries, takie jak event, export, bundle i Proofstream bundle views. | Aktywność review staje się evidence widoczną dla tenant. |
| Pobranie zatwierdzonego export | truth_package.accessed z kontekstem auditora i package hash. | Dostęp do export staje się częścią lifecycle Proof of Evolution. |
| Weryfikacja Proofstream bundle albo IVC epoch | auditor.verify.proofstream_bundle albo auditor.verify.proofstream_ivc_epoch z verifier result i problems. | Auditorzy odróżniają zweryfikowane evidence od evidence błędnego lub niekompletnego. |
- Twórz auditor access z dashboard tylko dla potrzebnego scope i okresu.
- Odwołuj auditor access po zakończeniu review albo zmianie roli reviewera.
- Każdy znaczący export access jest zapisywany jako lifecycle evidence.
- Auditorzy powinni lokalnie weryfikować bundles przed poleganiem na nich w assurance file.
Verify portal i publiczne verifier API
verify.attesto.eu to publiczny
origin weryfikacji i API. Używaj go do server-side SDK calls,
POST /v1/public/verify, POST /v2/verify,
health checks oraz publicznego endpointu signing key. To nie jest UI
ustawień tenant i nie wymaga sesji dashboard tenant do publicznej
weryfikacji proof objects.
- Używaj online verification, gdy system odbierający może wywołać publiczne verifier API.
- Używaj offline verification, gdy reviewer musi zweryfikować bundle bez dostępu do backend.
- Przypinaj oczekiwane witness albo signing keys zgodnie z trust policy verifiera.
- Traktuj nieudany verifier report jako evidence do zbadania, a nie ostrzeżenie UI.
Billing
Billing settings pokazują aktywny tenant plan, ścieżki self-service Starter/Growth/Realtime subscription oraz Stripe billing portal. Przy nowym tenant signup owner wybiera self-service tier. Stripe Checkout uruchamia skonfigurowany 30-dniowy tenant trial, a zweryfikowany Stripe webhook aktywuje wybrany plan. Enterprise pozostaje sales-negotiated.