Aiuta con la definizione di tipi di utenti ampi

1

Sto cercando di definire il confine tra due ampi tipi di utenti. I primi sono quelli che fanno uso di sistemi aziendali (contabilità, ERP, CRM, ecc.) E questo include anche utenti B2B, ad esempio consulenti esterni, partner di mercato, aziende che utilizzano i nostri servizi aziendali e così via. Il secondo tipo sono gli utenti finali che utilizzano applicazioni rivolte al cliente, come app mobili ecc.

Nella mia mente è intuitivamente chiaro, ma ho difficoltà a articolare questa distinzione. Sto cercando di trovare, in primo luogo, il vocabolario corretto per riferirsi a questi due tipi di utenti, e in secondo luogo, un semplice insieme di regole per determinare il confine tra questi due.

La ragione di ciò è perché inciderà sull'implementazione tecnica dell'autenticazione e dell'autorizzazione dell'utente. Un'idea che avevo era di differenziare in base al tipo di dati che gli utenti avrebbero usato. Il primo utilizza i dati aziendali, mentre il secondo utilizza dati personali e privati. Per il primo gruppo di utenti (l'unico tipo con cui abbiamo avuto a che fare finora) sono tutti gestiti all'interno di Active Directory e l'autenticazione / autorizzazione è implementata tramite un servizio Single Sign-On. Tuttavia, questo non è necessariamente appropriato per gli utenti di app mobili (per esempio), ma ho bisogno di dare definizioni chiare e input al nostro team di sicurezza che dovrà modificare le politiche e le direttive di sicurezza che governano il modo in cui gestiamo identità, autenticazione e autorizzazione.

Gradirei qualche indicazione, in particolare se esistono alcune best practice consolidate o standard del settore che si riferiscono alla mia domanda.

    
posta ralfe 05.10.2018 - 08:11
fonte

1 risposta

3

Il problema:

Una politica di autenticazione e accesso basata su una classificazione così ampia e confusa degli utenti sembra una pessima idea:

  • Innanzitutto, il sistema aziendale contiene anche dati privati, non solo sull'utente stesso ma su altri utenti e terze parti.
  • I secondi utenti possono utilizzare diversi tipi di applicazioni, ad esempio applicazioni rivolte ai clienti e CRM. Anche se un determinato utente ne utilizza solo uno, può evolvere nel tempo.

Soluzione

Innanzitutto, fai la differenza tra account utente (identificazione di un utente) e utenti (persone) .

È quindi possibile definire categorie orientate allo scopo di account utente, senza doversi preoccupare delle persone che potrebbero corrispondere a diverse categorie. Tipicamente, considererai categorie come personale (primo anello di fiducia), fornitori di servizi esterni e clienti (o pubblico in generale, se fornisci servizi Internet di ampio pubblico).

Alcuni principi che puoi applicare:

  • Compilazione: qualsiasi account utente deve appartenere a una sola categoria. Questo è particolarmente importante se si lavora con sistemi di informazioni sensibili: se uno stesso account utente dovesse appartenere a gruppi di diverso livello di attendibilità, si rischierebbe di far sì che le credenziali venissero dirottate su un sistema di sicurezza inferiore e si vedessero sistemi più sicuri compromessi.
  • I criteri di autenticazione potrebbero dipendere dalla categoria dell'account: ad esempio "dispositivo chiave per personale e fornitori di servizi e ID utente + password per clienti esterni".
  • I controlli generali sul controllo degli accessi potrebbero attirare incongruenze, con l'aiuto di alcune semplici regole sulle categorie (ad esempio "la categoria X dell'applicazione è accessibile solo dai conti della categoria A", o "I sistemi air-gapped devono essere utilizzati solo dall'utente account locali alla rete isolata "o" Il personale che utilizza i nostri prodotti pubblici utilizza l'account del personale per le applicazioni interne e un altro account pubblico generale quando utilizza i nostri prodotti come utente finale ".

Ora categorie così vaste non sono sufficientemente granulari per essere sufficienti come soggetto esclusivo delle regole di accesso. Pertanto, su ciascun sistema (o per ogni categoria di account), è necessario anche un modello di ruolo che definisca ciò che un utente di un determinato ruolo ha diritto a fare oa non fare.

    
risposta data 05.10.2018 - 19:45
fonte