creazione di un'area riservata con accessi personalizzati: cosa passa il convento (del cloud)?

[Ammammata]

devo valutare un paio di preventivi che sono stati fatti a un cliente
per la creazione di una "area riservata" sul cloud, contenente
documentazione sui prodotti

ci sarà un amministratore onnipotente e ci saranno N venditori, ognuno
con la sua pletora di clienti

questi venditori (incluso ovviamente l'onnipotente) avranno la
possibilità di creare utenti (visitatori, read only) e assegnare i loro
diritti di accesso alle varie sotto-aree (la suddivisione ipotizzata
per i documenti dovrebbe essere:
- brand (il marchio del cliente)
- tipo prodotto
- prodotto
- tipo documento

quindi, facendo un esempio: il venditore Pippo crea un account per il
cliente Topolino e imposta i diritti di accesso per i brand del
cliente, per i tipi di prodotto, i prodotti e i tipi di documento che
Topolino può VEDERE

va da sè che in genere, dopo il primo filtro sul brand, tutto il resto
- di solito - è full access, ma potrebbero esserci anche clienti
/potenziali/ a cui verrebbe (inizialmente) negato l'accesso a
particolari informazioni, come pure potrebbero esserci tipi di
documento che NON devono essere resi noti al cliente ma che sono
comunque disponibili sul cloud per i venditori stessi

le proposte ricevute a oggi sarebbero sviluppate con wordpress, con cui
ho già avuto a che fare in passato, ma solo per pubblicare poche cose
senza limiti di accesso da parte di utenti diversi, per cui non conosco
a fondo le potenzialità di questo strumento (ma il cliente di cui
all'inizio ne sa ancora di meno, per cui ha chiesto un parere)

un vostro parere è gradito, come pure l'indicazione di possibili
alternative a WP

grazie in anticipo (se volete sfanculare fatelo in privato che
l'indirizzo è buono)

[Mirko]

Post by Ammammata
devo valutare un paio di preventivi che sono stati fatti a un cliente
per la creazione di una "area riservata" sul cloud, contenente
documentazione sui prodotti
ci sarà un amministratore onnipotente e ci saranno N venditori, ognuno
con la sua pletora di clienti
questi venditori (incluso ovviamente l'onnipotente) avranno la
possibilità di creare utenti (visitatori, read only) e assegnare i loro
diritti di accesso alle varie sotto-aree (la suddivisione ipotizzata per
- brand (il marchio del cliente)
- tipo prodotto
- prodotto
- tipo documento
quindi, facendo un esempio: il venditore Pippo crea un account per il
cliente Topolino e imposta i diritti di accesso per i brand del cliente,
per i tipi di prodotto, i prodotti e i tipi di documento che Topolino
può VEDERE
va da sè che in genere, dopo il primo filtro sul brand, tutto il resto -
di solito - è full access, ma potrebbero esserci anche clienti
/potenziali/ a cui verrebbe (inizialmente) negato l'accesso a
particolari informazioni, come pure potrebbero esserci tipi di documento
che NON devono essere resi noti aliente ma che sono comunque
disponibili sul cloud per i venditori stessi
le proposte ricevute a oggi sarebbero sviluppate con wordpress, con cui
ho già avuto a che fare in passato, ma solo per pubblicare poche cose
senza limiti di accesso da parte di utenti diversi, per cui non conosco
a fondo le potenzialità di questo strumento (ma il cliente di cui
all'inizio ne sa ancora di meno, per cui ha chiesto un parere)
un vostro parere è gradito, come pure l'indicazione di possibili
alternative a WP
grazie in anticipo (se volete sfanculare fatelo in privato che
l'indirizzo è buono)
cl

WP e i vari CMS in circolazione di default si basano su diritti di
accesso di tipo RBAC (role based access control), praticamente si creano
dei ruoli e su questi gli si da i diritti di cosa vedere e cosa fare.
il ruolo viene poi assegnato allo user.

quello che a te serve da quel che ho capito è un accesso alle
informazioni più granulare
per fare questo hai 2 strade, 1 sbagliata e 1 corretta

quella sbagliata è creare tanti profili (ruoli) tanti quanti sono le
casistiche particolari che devi gestire, e ad ogni ruolo gestisci cosa
può vedere fare (e non sempre è possibile) un utente

quella corretta è quella di andare su un engine di tipo ABAC (attribute
based access control)
dove il diritto di vedere o modificare una risorsa (intesa come
qualsiasi cosa all'interno di un sistema informativo), è dato non solo
dal ruolo, ma dalle caratteristiche della risorsa stessa.

un esempio sono le piattaforme di streaming
dove ad esempio i vari utenti hanno piani di abbonamento differenti (ruoli)
e a seconda di come è classificato un film ad esempio vietato ai minori
di 14 (attribuo della risorsa film), da dove ci si collega italia,
piuttosto che francia (attributo di tipo environment) l'engine ABAC
conferma o nega l'accesso all'utente per la visione.

per fare un esempio più concreto al tuo caso
hai dei docuemnti con diverse classificazioni (attributo)
- public
- topcustomer
- premium

l'utente o ruolo ha un attributo di tipo docview = public, non può
vedere i documenti classificati come topcustomer e premium

se l'utente o ruolo ha un attributo di tipo docview = topcustomer
potrà vedere i documenti classificati public e topcustomer ma non
premium, e cosi via.

[Ammammata]

quella corretta è quella di andare su un engine di tipo ABAC (attribute based
access control)

grazie, ho cominciato a gurardare in giro con RBAC e ABAC e ne sono
usciti millemila

tra i tanti questo:
https://codup.co/blog/rbac-vs-abac/

che conferma quanto hai scritto e che proverò a usare per spiegare al
cliente come funziona la cosa

tra le varie note c'è questa:

Limitations of RBAC:
Rigidity:
RBAC does not provide the flexibility to accommodate complex scenarios
where users require access to resources based on multiple criteria,
such as location, time, or device type.

e dall'altra parte:

Limitations of ABAC:
Complexity:
ABAC can be complex to implement and maintain, especially in large
organizations or environments with a high degree of resource sharing.

ma visto il target potenziale (poche decine di utenti) non dovrebbe
essere un problema usare ABAC

poi vedrò se è possibile implementarlo in ambienti sviluppati con WP o
altro

[Mirko]

Post by Ammammata

Post by Mirko
quella corretta è quella di andare su un engine di tipo ABAC
(attribute based access control)

grazie, ho cominciato a gurardare in giro con RBAC e ABAC e ne sono
usciti millemila
https://codup.co/blog/rbac-vs-abac/
che conferma quanto hai scritto e che proverò a usare per spiegare al
cliente come funziona la cosa
RBAC does not provide the flexibility to accommodate complex scenarios
where users require access to resources based on multiple criteria, such
as location, time, or device type.
ABAC can be complex to implement and maintain, especially in large
organizations or environments with a high degree of resource sharing.
ma visto il target potenziale (poche decine di utenti) non dovrebbe
essere un problema usare ABAC
poi vedrò se è possibile implementarlo in ambienti sviluppati con WP o
altro

per una decina di utenti creerei i profili RBAC necessari

la complessita di implementare un sistema ABAC è la quantita di scenari
che devono essere gestiti.

un sistema RBAC è gia di default nei CMS
ABAC proprio per l'unicità degli attributi deve essere fatto custom.

un sistema ABAC prende in considerazione gli attributi degli
utenti/ruoli, delle risorse che devono essere oggetto di valutazione di
accesso (che possono essere documenti, piuttosto che parti
dell'applicazione, o dati nel db, azioni da compiere per ogni tipologia
di risorsa, etc)
può (non necessariamente) prendere in considerazioni l'environment, ad
esempio un venditore può accedere solo in orario di ufficio e dalla sola
LAN aziendale.

un sistema abac si basa su 4 componenti
PEP = policy enforcment point
PDP = policy decision point
PIP = policy information point
PAP = policy administration point

e non è banale metterlo in piedi

https://py-abac.readthedocs.io/en/latest/concepts.html

valuta se si hanno le risorse/competenze per affrontare un progetto
simile e se ne vale la pena per una manciata di utenti/situazioni