Una domanda sui permessi si pone come una ricerca e si comporta come un calcolo. Gli input, l’ordine in cui si risolvono, perché la risposta richiede sei schermate, e cosa un livello in sola lettura può dirti in merito senza toccare nulla.
Chiedere se una certa persona può aprire una certa dashboard suona come una ricerca. Si comporta come un calcolo, su input che stanno in posti diversi e vengono cambiati da persone diverse in giorni diversi.
Il ruolo di sito, che fissa il tetto per tutto ciò che sta sotto.
Le regole di permesso scritte sul contenuto stesso.
Le regole sul progetto in cui si trova, e se quel progetto gestisce i permessi per il contenuto al suo interno.
Ogni gruppo a cui la persona appartiene, ognuno dei quali può portare una propria regola.
Le regole sull’origine dati pubblicata dietro il contenuto, che si impostano separatamente dal contenuto.
Qualsiasi filtro sulle righe dentro i dati, che decide cosa compare una volta aperta la vista.
Sei input, e la schermata che stai guardando di solito ne mostra uno. Questa è tutta la difficoltà, ed è una proprietà di qualsiasi modello di permessi a livelli, non un difetto di questo.
Come i pezzi si combinano
Una capacità si risolve per una persona in un ordine fisso, e conoscere l’ordine trasforma la maggior parte delle sorprese in una risposta da cinque minuti.
Prima il ruolo di sito. Limita ciò che è possibile: una capacità concessa oltre ciò che il ruolo consente non ha alcun effetto quando conta.
Poi la proprietà e la guida del progetto. Il proprietario di un contenuto, e un responsabile del progetto che lo contiene, portano le capacità su di esso.
Poi le regole scritte direttamente per la persona. Una capacità impostata su Negato per quell’utente chiude la questione, e una capacità impostata su Consentito per quell’utente la chiude nell’altro senso.
Poi le regole scritte per i gruppi a cui la persona appartiene. Un diniego in un gruppo qualsiasi vince su una concessione in un altro, ed è lì che di solito inizia l’accesso accidentale.
Poi ciò che resta. Non specificato è lo stato di riposo, non concede nulla, ed è la cosa giusta in cui lasciare la maggior parte delle capacità.
Due regole reggono quasi tutto. Una regola scritta per una persona batte una regola scritta per un gruppo, e un diniego batte una concessione allo stesso livello. La maggior parte delle sorprese sugli accessi si riduce a una di queste due, di solito la seconda, e di solito perché qualcuno è entrato in un gruppo che porta un diniego impostato anni fa per una ragione non correlata.
Il progetto è l’unità che porta il permesso
Il contenuto eredita da dove sta. Un progetto può avere un modello predefinito applicato ai contenuti pubblicati al suo interno, e un progetto può essere impostato per gestire i permessi di tutto ciò che contiene, il che sposta la decisione dall’elemento su al progetto.
Una conseguenza vale la pena dirla chiaramente, perché è quella che sorprende le persone a metà di un riordino: spostare contenuti cambia chi può vederli. Uno spostamento sembra pulizia e si comporta come una modifica ai permessi. È esattamente per questo che un piano di offboarding segnala uno spostamento tra progetti come rischio con un nome mentre il piano è ancora in sola lettura, prima che qualcosa sia stato alterato.
Pubblicare è lo stesso evento visto dall’altro lato. I nuovi contenuti atterrano sotto le regole del progetto di destinazione, e la pubblicazione gira come l’utente connesso, quindi si ferma in modo pulito se quell’account non ha il permesso di pubblicare o sovrascrivere sulla destinazione. Entrambe le cose è molto meglio saperle prima di una promozione che durante.
Perché la risposta è lenta da raggiungere cliccando
Rispondere per una persona e una dashboard significa aprire la vista, la cartella di lavoro, il progetto, le appartenenze ai gruppi, l’origine dati pubblicata e il ruolo di sito. Sei schermate per una risposta, e la risposta copre una persona.
Poi scade. Il contenuto non è mai stato toccato e la risposta è cambiata comunque.
Qualcuno è entrato in un gruppo, o ne è uscito.
Un ruolo di sito è cambiato, il che sposta il tetto su tutto ciò che quella persona tocca.
Un modello di progetto è cambiato, o il progetto ha iniziato a gestire i permessi dei suoi contenuti.
Un contenuto si è spostato da un progetto a un altro.
Sotto tutto questo c’è un problema di direzione. Una revisione degli accessi chiede chi può vedere questo. Un’interfaccia costruita per il lavoro quotidiano è organizzata intorno a cosa può vedere questa persona. Entrambe sono domande ragionevoli, si risponde percorrendo lo stesso grafo in direzioni opposte, ed è per questo che la verifica che richiede dieci minuti per una persona richiede due settimane per un reparto.
Il livello sotto il permesso
Il permesso sul contenuto decide se la vista si apre. Ciò che compare al suo interno può essere ristretto di nuovo da un filtro a livello di riga, che sia un filtro utente nella cartella di lavoro, una tabella di diritti unita all’origine dati, o una policy applicata nel warehouse.
Due frasi sono allora vere nello stesso momento. Tutti nel gruppo possono aprire la dashboard, e ognuno di loro vede un insieme di righe diverso. Di solito è la progettazione che funziona esattamente come previsto, ed è anche la ragione più comune per cui due persone confrontano gli schermi e concludono che la piattaforma è rotta.
Scrivi quale meccanismo sta facendo il restringimento, e dove vive. La governance a livello di campo è inventariabile: un profilo di livello semantico conta quale frazione dei campi porta una decisione di classificazione e la pubblica come una delle cinque componenti del suo punteggio di qualità. Tutto ciò che è contato può essere rivisto. Tutto ciò che sta solo dentro un calcolo che qualcuno ha scritto nel 2021 viene riscoperto nel modo costoso.
Cosa può dirti un livello in sola lettura
Un livello di governance sta sopra il sito ed eredita le sue regole invece di tenerne un secondo insieme accanto. Qui questo è scritto nell’accesso stesso: ogni utente si connette con il proprio token Tableau, e quel token, che porta i suoi permessi esatti, è il confine per ogni lettura, ogni scrittura e ogni chiamata dell’assistente fatta per suo conto.
Il che dà alla lettura una proprietà piacevole. Ciò che il prodotto ti mostra è ciò che avresti già potuto raggiungere, assemblato più in fretta e in un unico posto. Rispondere così a una domanda sui permessi non ha bisogno di un account con privilegi elevati, e la lettura stessa non cambia nulla: il browser del sito è in sola lettura per costruzione, senza percorso di pubblicazione, senza endpoint di scrittura, e senza nulla conservato su disco oltre a un elenco di sessione di ciò che hai guardato di recente.
Dove la lettura è parziale, dice di che tipo di parziale si tratta. Un’estrazione di metadati che incontra un catalogo disattivato o un confine di permesso restituisce un risultato vuoto con un avviso leggibile e non solleva errori, così il rapporto può distinguere non ho trovato nulla da non ho potuto guardare. Il punteggio di rischio fa lo stesso dall’altro capo: l’esposizione, cioè quanto ampiamente è autorizzato il contenuto interessato, è tenuta a un valore fisso finché quella superficie non è abilitata, e la metodologia pubblicata lo dichiara nella stessa frase del punteggio.
Una vista parziale che si annuncia è utilizzabile lunedì. Una vista parziale che sembra completa è quella che ti costa un rilievo di audit, perché tutti a valle la leggono come copertura e nessuno ricontrolla un risultato verde.
Trasformare la risposta in un registro
Fissa la domanda prima di aprire qualsiasi cosa. Nomina la persona o il gruppo, nomina il contenuto, nomina la data, perché una risposta sugli accessi è vera per un momento, non in generale.
Leggi prima il ruolo di sito. Limita tutto ciò che sta sotto ed è l’input più economico da verificare.
Percorri il progetto, poi l’elemento, poi i gruppi, e scrivi la regola che ha davvero deciso, non solo l’esito.
Verifica separatamente l’origine dati pubblicata dietro il contenuto. Porta le proprie regole ed è l’input che viene saltato più spesso.
Registra cosa hai potuto vedere e cosa è rimasto fuori dalla vista. Le lacune diventano parte del registro invece di un silenzio al suo interno.
Conserva il risultato con la sua data e il nome di chi lo ha eseguito.
Gli ultimi due sono ciò che ne fa una prova, non uno screenshot. Una risposta sui permessi che porta una data, un autore e un confine dichiarato può essere consegnata a qualcun altro e rieseguita da lui. Tutto il resto è il ricordo di un martedì, e i ricordi dei martedì sono ciò che le revisioni degli accessi dovrebbero sostituire.
Quattro cose vengono chiamate governance: certificazione, proprietà, contenuti obsoleti e controllo delle modifiche. Qui ognuna è scritta come una verifica che puoi eseguire, non come un obiettivo che puoi dichiarare. Si parla anche dell’unica modifica che supera una revisione visiva ed è comunque sbagliata.
Una persona se ne va. Il suo nome resta su cartelle di lavoro, pianificazioni e sottoscrizioni, e diverse di queste si guastano senza un rumore. Cosa possiede, cosa si rompe, e l’ordine che mantiene la licenza recuperabile.
Una certificazione è un contrassegno e una frase, impostati da qualcuno che all’epoca era sicuro. Cosa afferma, cosa lascia a te, chi dovrebbe detenerla, e i tre modi in cui smette silenziosamente di essere vera.