Tenant Dashboard
Interface opérateur tenant
Utilisez dashboard.attesto.eu pour les opérations côté tenant. Cette page couvre uniquement les workflows tenant externes.
Identité et accès
Les utilisateurs tenant se connectent via le flux email-first du dashboard. Le premier écran demande uniquement l'adresse e-mail; puis Attesto oriente l'utilisateur vers le parcours configuré: mot de passe, community identity, invite, signup ou SSO d'organisation. Les tenant owners configurent Entra ID, OIDC générique et SAML dans Settings → Identity Providers.
- Utilisez les tenant roles pour l'accès dashboard: owner, admin, developer et user.
- Les comptes marketplace developer sont réservés au marketplace; ils ne donnent pas accès au dashboard.
- Utilisez les auditor invites pour l'accès audit portal; les auditeurs ne reçoivent pas de droits tenant operator.
- Lisez Tenant SSO avant d'imposer le SSO d'organisation pour un domaine.
Systems et keys
- Créez un system par service de production ou environnement isolé.
- Copiez la system key générée lorsqu'elle est affichée et stockez-la server-side.
- Effectuez une rotation des keys lorsqu'un system change d'ownership, de hosting boundary ou de deployment trust.
- Désactivez les systems inutilisés au lieu de réutiliser leurs keys pour des services sans rapport.
Vues Proofstream
Les pages de stream affichent event sequence, receipt state, window et checkpoint state, witness/quorum status, anchor status, fork evidence et verifier bundle readiness.
- Un receipt prouve qu'Attesto a accepté un event spécifique dans un stream head spécifique.
- Un checkpoint résume une range fermée et pointe vers la consistency evidence.
- La fork evidence exige une investigation immédiate avant de s'appuyer sur cette stream history.
- L'export de bundle devient disponible uniquement lorsque les policy requirements sont satisfaits.
Webhooks et connecteurs
Les webhooks notifient vos systèmes lorsque l'evidence Attesto change. Les connecteurs écrivent les observations des systèmes source dans Proofstream. Utilisez le dashboard pour créer et révoquer les tenant webhooks, signed webhook connectors, repository webhook connectors, S3/R2 object commitments et installations Local Vault. Stockez chaque secret retourné côté serveur; le dashboard ne l'affiche volontairement pas une seconde fois.
- Les webhook subscriptions livrent des notifications signées; les récepteurs doivent vérifier la raw-body signature.
- Les signed webhook connectors ingèrent des custom source events via une signed envelope propre au connecteur.
- Les repository connectors vérifient les signatures de livraison GitHub/GitLab avant d'écrire l'evidence normalisée.
- Les S3/R2 object commitments enregistrent métadonnées et intégrité sans proxy des object bytes.
- Local Vault relaie les customer-edge events en outbound et peut agir comme customer-side witness lorsque la policy l'active.
Evidence exports
Les exports sont des evidence artifacts immutable pour le tenant scope et la date range sélectionnés. Partagez les bundles exportés avec des auditeurs ou des counterparties seulement après confirmation de la range, de la policy et des retention requirements.
La génération d'un Truth Package, son download/access et sa
vérification cryptographique réussie sont eux-mêmes de la lifecycle
evidence. La génération du package enregistre
truth_package.generated, le download ou auditor access
enregistre truth_package.accessed, et un verifier report
validé par le backend enregistre truth_package.verified.
Transmission au audit portal
audit.attesto.eu est le portail read-only pour les auditeurs externes invités par un tenant. Les auditeurs s'authentifient via le flux audit, n'inspectent que les scopes tenant accordés, téléchargent les exports approuvés et examinent events, receipts, checkpoints et bundle evidence sans devenir tenant operators.
Le login audit est volontairement séparé de l'identité dashboard et marketplace. Un auditeur saisit son adresse e-mail, reçoit un magic link à usage unique lorsque l'adresse appartient à un auditeur invité ou actif, puis complète le TOTP de son application d'authentification. Le lien est valable 15 minutes; les auditeurs first-time sont guidés dans l'enrollment TOTP avant l'accès normal. La réponse request-link reste toujours générique afin d'empêcher l'énumération d'adresses e-mail d'auditeurs.
La landing page auditeur liste uniquement les tenant grants actifs avec le scope approuvé, la date d'expiration, le count d'events sur 30 jours et l'indicateur de dernier anchor. La tenant view reste ensuite read-only: les grants expirés ou révoqués sont refusés avant le chargement des events, exports, Proofstream bundles, forks ou IVC epochs. Les audit sessions ne connectent pas l'auditeur au dashboard, au marketplace ni à une surface interne du staff Attesto.
| Action audit portal | Ce qui est enregistré | Pourquoi cela compte |
|---|---|---|
| Ouvrir le dashboard | auditor.view.dashboard par tenant dans le scope. | Le tenant peut voir que l'auditeur a consulté la landing page audit. |
| Ouvrir la tenant audit view | Read-only access check contre un auditor grant actif et non expiré. | Les grants expirés ou révoqués échouent fail-closed. |
| Voir event/export/bundle data | Tenant audit entries telles que vues event, export, bundle et Proofstream bundle. | L'activité de review devient une evidence visible par le tenant. |
| Télécharger un export approuvé | truth_package.accessed avec contexte auditeur et package hash. | L'accès export devient partie de la lifecycle Proof of Evolution. |
| Vérifier un Proofstream bundle ou IVC epoch | auditor.verify.proofstream_bundle ou auditor.verify.proofstream_ivc_epoch avec verifier result et problems. | Les auditeurs distinguent l'evidence vérifiée de l'evidence échouée ou incomplète. |
- Créez l'auditor access depuis le dashboard uniquement pour le scope et la période nécessaires.
- Révoquez l'auditor access lorsque la review est terminée ou que le reviewer change de rôle.
- Chaque accès significatif à un export est enregistré comme lifecycle evidence.
- Les auditeurs doivent vérifier localement les bundles avant de s'y fier dans un dossier d'assurance.
Verify portal et API verifier publique
verify.attesto.eu est l'origine
publique de vérification et d'API. Utilisez-la pour les appels SDK
server-side, POST /v1/public/verify,
POST /v2/verify, les health checks et l'endpoint public
signing key. Ce n'est pas une UI de settings tenant et elle ne requiert
pas de session dashboard tenant pour vérifier des proof objects publics.
- Utilisez la vérification online lorsqu'un système récepteur peut appeler l'API verifier publique.
- Utilisez la vérification offline lorsqu'un reviewer doit vérifier un bundle sans accès backend.
- Épinglez les witness keys ou signing keys attendues selon la trust policy du verifier.
- Traitez un verifier report échoué comme une evidence à investiguer, pas comme une simple alerte UI.
Billing
Les billing settings affichent le tenant plan actif, les parcours self-service Starter/Growth/Realtime subscription et le Stripe billing portal. Lors d'un nouveau signup tenant, l'owner choisit un tier self-service. Stripe Checkout démarre la trial tenant configurée de 30 jours, et le webhook Stripe vérifié active le plan choisi. Enterprise reste sales-negotiated.