Identity come vincolo di architettura: progettare l'IAM prima dei dati

Fondere attestazione, rotazione e vaulting in un unico workflow ha tagliato il tempo di revoca da circa tre giorni a meno di uno¹. Accade quando l’identità entra nell’architettura in servizi finanziari regolamentati, dove un’abilitazione sbagliata è una non conformità¹.

Per una singola applicazione basta scegliere un identity provider, collegare l’SSO e validare i token all’ingresso. Funziona. Quando l’organizzazione cresce, il login regge e il resto si complica: chi ha approvato un accesso e se deve ancora esistere quando l’auditor lo chiede mesi dopo¹.

L’identità diventa un vincolo di progetto perché impone scelte sul modello dati. Si deve poter rispondere “Chi aveva accesso a questo sistema il 14 marzo?” solo dal modello, senza cercare tra log eterogenei. Se no, l’audit non è entrato in fase di design¹. Una security review può trovare uno scope errato o un controllo mancante. Non può ricostruire a posteriori uno schema incapace di spiegare chi avesse accesso e quando. La via più economica è registrare da subito ogni grant, revoca e attestazione come evento, con timestamp e attore. Così la domanda dell’auditor diventa una query sul log eventi¹.

Il modello RBAC piatto regge finché le domande restano binarie. Cede quando servono relazioni. Le richieste operative ricorrenti sono: chi possiede un account, quali accessi sono ancora validi, cosa controlla una persona. In tabelle di ruolo, “chi possiede questo account” chiede catene di join. In un grafo è una singola traversata¹. Qui i nodi sono tre: Person, ServiceAccount e Resource. Le associazioni sono due: una persona OWNS un account di servizio, un account HAS_ACCESS a una risorsa. La validità è proprietà del legame, non di un nodo: scadenza ed attestazioni vivono sull’arco tra account e risorsa¹.

Per questo il backend modella le relazioni in Neo4j e le espone via GraphQL. GraphQL funziona perché l’annidamento della query replica la traversata: account, poi proprietario, poi accessi. Il chiamante chiede esattamente la porzione di grafo che gli serve. Niente traversate scritte a mano, niente over-fetching di oggetti enormi filtrati in memoria¹.

La scala sposta l’asse sulla governance. Circa ottantamila persone possiedono account di servizio nel caso descritto. Il lavoro è tenere quegli owner coinvolti durante cambi di ruolo e uscite. Un account il cui proprietario è andato via è una credenziale senza guardiano¹.

La revoca che viaggia su uno stream di eventi è solo eventualmente consistente. Bisogna conoscere la staleness nel caso peggiore, imporre un’età massima della cache e comunicarla al team di sicurezza¹.

Il testo dà per acquisita esperienza con OAuth 2.0 o SSO. L’attrito nasce dopo il login, quando molti servizi e molti owner entrano nella stessa equazione e l’auditor chiede storia, non solo stato¹.

L’identità condiziona scelte che sembrano non correlate, e questo emerge prima nel modello dati. I confini di servizio e i flussi di eventi hanno problemi propri¹.