Due tenant, due audience

Identità e accessi

Gli accessi delle famiglie e dell'amministratore usano gruppi di rotte e controlli di autorizzazione separati. Genitori e adolescenti invitati condividono l'autenticazione Entra External ID, ma hanno permessi applicativi diversi. Il router amministrativo richiede un token workforce con il ruolo Lanternina.Admin per ogni operazione. Ogni hub presenta una chiave associata alla propria famiglia.

Identità separate per genitori e amministratori

Entra External ID permette ai genitori di registrarsi autonomamente. Il privilegio amministrativo arriva da una app registration workforce separata, invece che da un flag nel container Cosmos modificato dall'amministratore. Il privilegio e i dati applicativi hanno così piani di controllo e percorsi di bootstrap separati.

Il token dell'amministratore porta il privilegio nel claim roles. Le applicazioni del genitore e dell'amministratore hanno audience diverse e l'API controlla l'audience prima della logica applicativa. Soltanto un token workforce raggiunge il controllo dell'app role sulle rotte amministrative.

Isolamento dei nuclei familiari

Le rotte del genitore ricavano la famiglia dall'account associato al subject verificato. Le rotte del portale la ricavano dall'adesione e limitano le fotografie a quelle inviate da quel membro. Le rotte dell'hub confrontano la chiave con l'impronta configurata per la famiglia nell'URL: cambiare quell'URL non autorizza un'altra famiglia.

I dati familiari in Cosmos DB usano il partizionamento per nucleo; gli archivi delle immagini usano percorsi familiari. Inviti e adesioni condividono invece un documento Blob privato, con scritture condizionali e controlli applicativi degli accessi. Quel registro non è fisicamente partizionato per famiglia. Una casa nuova richiede una chiave distinta e la sua associazione al nucleo sul server.

Il codice impone la separazione tra nuclei familiari, ma il sistema ha funzionato in una sola casa. Il provisioning e l'uso con più nuclei restano da provare.

Autenticazione della casa

L'hub presenta la device key nell'intestazione X-Device-Key su TLS. L'API conserva la credenziale Azure ed esegue le chiamate ai modelli per leggere una pagina, interpretare un promemoria e continuare un'attività. Le rotte del dispositivo rispondono 503 finché non viene configurata un'associazione tra chiave e famiglia.

L'hub contiene quindi una credenziale per le rotte del proprio nucleo, invece di una credenziale riutilizzabile contro la sottoscrizione Azure. Questo confine rende necessaria la connessione al cloud per leggere una pagina.

L'API conserva impronte SHA-256 di chiavi casuali degli hub. Famiglie sconosciute, chiavi assenti e chiavi errate ricevono HTTP 403. La rotazione sostituisce l'impronta; la revoca rimuove l'associazione. Una chiave sottratta resta utilizzabile nel proprio nucleo finché la revoca non diventa effettiva. Questo schema non fornisce attestazione del dispositivo o mutual TLS.

Dispositivi locali

L'hub configura fotocamera e display. Il loro traffico ordinario resta sulla rete locale; non contengono credenziali dei servizi Azure né la chiave dell'hub per l'API cloud. Firmware e provisioning restano invariati. Una compromissione può comunque esporre impostazioni Wi-Fi, credenziali locali o fotografie in attesa. Il token della camera può essere usato per impersonarla verso l'hub e un dispositivo compromesso può inviare traffico ai servizi raggiungibili. L'assenza di credenziali Azure limita l'accesso diretto al cloud, ma non elimina il rischio locale.

Registrazione con TPM: proposta

Un hub futuro potrebbe registrarsi con un invito monouso e a breve scadenza creato dal genitore. Genererebbe una chiave di firma nel TPM, ne dimostrerebbe il possesso e fornirebbe un'attestazione verificabile della chiave. Il server assocerebbe il dispositivo alla famiglia dell'invito e rilascerebbe un certificato client. Gli accessi successivi userebbero mTLS o un meccanismo standard di prova di possesso legato alla chiave, con rinnovo e revoca dal genitore. Un normale bearer token copiabile non offrirebbe la stessa protezione.

La proposta non è implementata: l'hub usa ancora una chiave associata alla famiglia. Hardware compatibile e supporto dell'attestazione devono essere verificati. Una chiave non esportabile ridurrebbe il rischio di clonazione, ma non impedirebbe a software compromesso di usare il TPM per firmare.

Accesso dell'adolescente invitato

Il genitore crea un invito legato all'email e condivide il codice o il link. L'adolescente accede con l'indirizzo corrispondente e accetta l'invito. La sola registrazione non apre il portale. Un'adesione attiva permette di inviare, vedere e cancellare le proprie fotografie, ma non di approvare attività o cambiare le impostazioni familiari. La revoca chiude le richieste successive. Il gate del genitore esclude i subject già registrati come adolescenti, anche dopo la revoca. La sospensione del genitore che ha invitato chiude anche l'accesso al portale.

Il portale usa la stessa applicazione External ID e la stessa audience dei genitori. I permessi dipendono dall'adesione verificata sul server. La prima registrazione e il riscatto con un account reale invitato restano una verifica da fare in famiglia.

Confini dell'applicazione

Il router amministrativo è registrato separatamente e applica il controllo di autorizzazione a tutte le rotte sotto /api/admin. Le singole operazioni richiedono anche l'amministratore verificato quando devono registrare chi ha agito. Le rotte familiari mantengono i propri controlli sull'account e sul nucleo. I gruppi condividono ancora processo, deploy e identità di esecuzione: una compromissione del processo o l'esaurimento delle risorse può coinvolgere entrambi. L'isolamento richiederebbe un servizio amministrativo distinto con permessi e controlli di accesso indipendenti.

Approvazione delle attività

Il pannello conserva le decisioni del genitore. L'hub ritira le attività approvate attraverso HTTPS autenticato e sceglie quando avviarle. Le continuazioni sono verificate e filtrate nel container, ma non ricevono una seconda approvazione del genitore.

Deploy tramite OIDC

GitHub Actions scambia il proprio token OIDC con un token Azure tramite una credenziale federata su una managed identity assegnata dall'utente. Tre assegnazioni di ruolo limitate alle singole risorse permettono alla pipeline di scrivere in un registro, leggere quel registro e aggiornare una container app.

Lacune note nell'autorizzazione

Il validatore controlla audience, issuer, scadenza e subject del token, ma omettescp. L'applicazione espone oggi un solo scope. L'aggiunta di un altro scope richiede un controllo dello scope prima che possa separare i permessi.

Configurazione e deploy ·provisioning e revoca delle chiavi degli hub ·l'identità federata della pipeline · cosa esce dal dispositivo

Questo sito non usa cookie, non raccoglie statistiche e non carica niente da altri server.