Tenant Dashboard
Interfaccia operatore tenant
Usa dashboard.attesto.eu per le operazioni rivolte al tenant. Questa pagina copre solo i workflow tenant esterni.
Identità e accesso
Gli utenti tenant accedono tramite il flusso email-first del dashboard. La prima schermata chiede solo l'indirizzo email; poi Attesto indirizza l'utente verso il percorso configurato di password, community identity, invite, signup o SSO dell'organizzazione. I tenant owners configurano Entra ID, OIDC generico e SAML in Settings → Identity Providers.
- Usa tenant roles per l'accesso dashboard: owner, admin, developer e user.
- Gli account marketplace developer sono solo per il marketplace; non concedono accesso al dashboard.
- Usa auditor invites per l'accesso audit portal; gli auditor non ricevono privilegi tenant operator.
- Leggi Tenant SSO prima di imporre SSO dell'organizzazione per un dominio.
Systems e keys
- Crea un system per ogni servizio di produzione o ambiente isolato.
- Copia la system key generata quando viene mostrata e conservala server-side.
- Ruota le keys quando un system cambia ownership, hosting boundary o deployment trust.
- Disabilita i systems inutilizzati invece di riutilizzare le loro keys per servizi non correlati.
Viste Proofstream
Le pagine stream mostrano event sequence, receipt state, window e checkpoint state, witness/quorum status, anchor status, fork evidence e verifier bundle readiness.
- Un receipt prova che Attesto ha accettato uno specifico event in una specifica stream head.
- Un checkpoint riassume una range chiusa e collega alla consistency evidence.
- Fork evidence richiede indagine immediata prima di fare affidamento su quella stream history.
- Bundle export diventa disponibile solo quando i policy requirements sono soddisfatti.
Webhooks e connettori
I webhooks notificano i tuoi sistemi quando l'evidence Attesto cambia. I connettori scrivono osservazioni dai sistemi sorgente in Proofstream. Usa il dashboard per creare e revocare tenant webhooks, signed webhook connectors, repository webhook connectors, S3/R2 object commitments e installazioni Local Vault. Conserva ogni secret restituito server-side; il dashboard intenzionalmente non lo mostra più.
- Le webhook subscriptions consegnano notifiche firmate; i receiver devono verificare la raw-body signature.
- I signed webhook connectors ingeriscono custom source events tramite una signed envelope specifica del connettore.
- I repository connectors verificano le GitHub/GitLab delivery signatures prima di scrivere evidence normalizzata.
- Gli S3/R2 object commitments registrano metadati e integrità senza fare proxy degli object bytes.
- Local Vault inoltra customer-edge events outbound e può agire come customer-side witness quando la policy lo abilita.
Evidence exports
Gli exports sono evidence artifacts immutable per il tenant scope e la date range selezionati. Condividi bundles esportati con auditor o counterparties solo dopo aver confermato range, policy e retention requirements.
Generazione del Truth Package, download/access e verifica
crittografica riuscita sono essi stessi lifecycle evidence. La
generazione del package registra truth_package.generated,
download o auditor access registra truth_package.accessed,
e un verifier report validato dal backend registra
truth_package.verified.
Handoff audit portal
audit.attesto.eu è il portale read-only per auditor esterni invitati da un tenant. Gli auditor si autenticano tramite il flusso audit, ispezionano solo i tenant scopes concessi, scaricano exports approvati e revisionano events, receipts, checkpoints e bundle evidence senza diventare tenant operators.
Il login audit è volutamente separato dall'identità dashboard e marketplace. Un auditor inserisce l'e-mail, riceve un magic link monouso quando l'indirizzo appartiene a un auditor invitato o attivo, e poi completa TOTP con un'app authenticator. Il link è valido per 15 minuti; gli auditor first-time vengono guidati prima nel TOTP enrollment. La risposta request-link rimane sempre generica per impedire l'enumerazione degli indirizzi e-mail degli auditor.
La landing page dell'auditor mostra solo tenant grants attivi con scope approvato, data di scadenza, event count su 30 giorni e indicatore dell'ultimo anchor. Da lì la tenant view rimane read-only: grant scaduti o revocati vengono negati prima del caricamento di events, exports, Proofstream bundles, forks o IVC epochs. Le audit sessions non accedono al dashboard, al marketplace o a superfici interne dello staff Attesto.
| Azione audit portal | Cosa viene registrato | Perché conta |
|---|---|---|
| Aprire dashboard | auditor.view.dashboard per tenant in scope. | Il tenant può vedere che l'auditor ha aperto la landing page audit. |
| Aprire tenant audit view | Read-only access check contro un auditor grant attivo e non scaduto. | Grant scaduti o revocati falliscono fail-closed. |
| Vedere event/export/bundle data | Tenant audit entries come view di event, export, bundle e Proofstream bundle. | L'attività di review diventa evidence visibile al tenant. |
| Scaricare export approvato | truth_package.accessed con contesto auditor e package hash. | L'accesso export diventa parte del lifecycle Proof of Evolution. |
| Verificare Proofstream bundle o IVC epoch | auditor.verify.proofstream_bundle oppure auditor.verify.proofstream_ivc_epoch con verifier result e problems. | Gli auditor distinguono evidence verificata da evidence fallita o incompleta. |
- Crea auditor access dal dashboard solo per scope e periodo necessari.
- Revoca auditor access quando la review è conclusa o il reviewer cambia ruolo.
- Ogni accesso significativo a export viene registrato come lifecycle evidence.
- Gli auditor dovrebbero verificare i bundles localmente prima di farvi affidamento in un assurance file.
Verify portal e API verifier pubblica
verify.attesto.eu è l'origine
pubblica di verifica e API. Usala per chiamate SDK server-side,
POST /v1/public/verify, POST /v2/verify,
health checks e endpoint pubblico della signing key. Non è una UI di
settings tenant e non richiede una sessione dashboard tenant per la
verifica di proof objects pubblici.
- Usa verifica online quando un sistema ricevente può chiamare la verifier API pubblica.
- Usa verifica offline quando un reviewer deve verificare un bundle senza accesso backend.
- Fissa witness keys o signing keys attese secondo la trust policy del verifier.
- Tratta un verifier report fallito come evidence da investigare, non come avviso UI.
Billing
Billing settings mostra il tenant plan attivo, i percorsi self-service Starter/Growth/Realtime subscription e lo Stripe billing portal. Nel nuovo tenant signup, l'owner sceglie un self-service tier. Stripe Checkout avvia la tenant trial configurata di 30 giorni, e il webhook Stripe verificato attiva il piano scelto. Enterprise resta sales-negotiated.