Integrate e compilate il codice di autenticazione utente e autorizzazione dall'inizio del vostro progetto?

Question

Integrate e compilate il codice di autenticazione utente e autorizzazione dall'inizio del vostro progetto?

#1 da (6 voti)
#2 da (5 voti)
#3 da (3 voti)
#4 da (1 voti)
#5 da (1 voti)

3

Si tratta in particolare di quando sviluppare e implementare il codice per l'autenticazione e l'autorizzazione. Faccio non significano cose che lo sviluppatore dovrebbe conoscere come exploit o utilizzo di Prepared Statements per SQL Injection e così via . Questi dovrebbero essere assiomatici per lo sviluppatore.

Ciò che intendo è quando nel tuo ciclo di sviluppo costruisci l'Autenticazione e l'autorizzazione "sistema / appartenenza / qualsiasi cosa tu voglia chiamare"? Lo fai mentre stai andando avanti, forse lo spegni o ti rendi un amministratore, quindi puoi eseguire il tuo codice? Che si tratti di "Role Based" o "Activity Based" o qualcos'altro che non credo dovrebbe avere importanza per questa domanda. Potrei sapere quale sicurezza voglio usare, il sistema, l'architettura, ecc., Ma quando nel SDLC metto quel sistema nel codice reale (se l'ho scritto o è un plugin)?

Non intendo il database. Solo l'applicazione e quella con nomi utente e password. Non intendo nella mia mente. Intendo quando ti siedi per iniziare a scrivere i tuoi test o comunque scrivi il tuo software. Quando comincio effettivamente a digitare le informazioni sulla sicurezza? Prima di fare qualcosa, durante, dopo di esso? Tutti e tre +?

Domanda secondaria, il TDD dovrebbe richiedere la sicurezza mentre procedo?

C'erano promettenti titoli delle domande, ma non la risposta (s) stavo cercando. si sente come se potesse ostacolare il funzionamento delle cose. Ma non voglio nemmeno che sia un ripensamento.

Ho messo la parola nel titolo per enfatizzare cosa intendevo per "quando".

Modifica: ad esempio, aggiungo questo mentre faccio questo:

 // Create a PrincipalPermission object.
            PrincipalPermission MyPermission = 
                new PrincipalPermission("MyUser", "Administrator");

o

[AttributeUsage(AttributeTargets.Field, AllowMultiple=false)]

o

IsInRole...

Non sto chiedendo quale tipo di sicurezza dovrei implementare. Non c'è modo per te di saperlo. Sto solo chiedendo quando deve essere digitato.

(Codice I copiato dai siti MS)

design security

posta johnny 27.07.2017 - 22:30

fonte

5 risposte

Leggi altre domande sui tag design security

Quali strumenti usi per gestire la tua lista di cose da fare? C ++ equivalente alla specifica Sun Java Language e alle specifiche JVM?

score 6 · Answer 1

Se segui un processo agile, la risposta è "quando ne hai bisogno". Molto probabilmente sarà relativamente tardi nel ciclo di sviluppo. Il motivo è che si desidera fornire funzionalità di base realmente utili il prima possibile in modo da poter ottenere feedback dal proprietario del prodotto e dalle parti interessate. Un'infrastruttura di sicurezza senza alcuna funzionalità non può essere valutata, ma le funzionalità di base senza sicurezza possono essere valutate e ottenere un feedback utile.

Se segui un modello classico a cascata, svilupperai presto la sicurezza poiché è un'infrastruttura fondamentale su cui è costruita la logica aziendale. Ma in agile, l'infrastruttura viene solitamente posticipata fino a quando non è assolutamente necessaria.

Questo non significa che la sicurezza è trascurata e trattata come un ripensamento, è solo una questione di priorità delle attività per ridurre il rischio complessivo per il progetto.

score 5 · Answer 2

La sicurezza (in generale) è parte della funzionalità della tua applicazione. Non è un componente aggiuntivo. La sicurezza e il controllo degli accessi influiscono sulla possibilità di eseguire altre funzioni e su quali dati. Ciò significa che è anche un aspetto importante del test dell'unità e dei componenti. Impossibile essere posticipato fino all'integrazione del sistema - sarà troppo tardi allora.

Come per PrincipalPermission oggetti e amici, potresti voler specificare un permesso astratto come PermissionToAddCustomer , PermissionToModifyCustomer , ecc. Ognuna di queste autorizzazioni astratte sarà quindi associata a un dominio di interesse per ottenere autorizzazioni concrete .

La tua unità esegue il test per, diciamo, aggiungendo che un cliente potrebbe sembrare (pseudo-codice):

testAddCustomerWithAllPermissions();
testAddCustomerWithoutPermission();
testAddCustomerWithBasicPermissions();
testAddCustomerWithWrongBasicPermissions();

e così via. Il primo test nell'elenco è probabilmente l'unico a cui pensi di iniziare. Avrai bisogno di test che esplorino le combinazioni e le permutazioni del modello di permessi che implementa.

La normale conseguenza dell'aggiunta della sicurezza e del modello di accesso a fine partita è che non hai queste variazioni nei test di unità e fai tutto il test solo con "AllPermissions". Questo porta a grandi buchi di sicurezza.

score 3 · Answer 3

I meccanismi di sicurezza dovrebbero essere messi in atto fin dal momento pratico, per i seguenti motivi:

Una sicurezza adeguata può influire sulla progettazione di quasi qualsiasi cosa nel tuo sito. Ad esempio, se si dispone dell'accesso agli oggetti basato sui ruoli, potrebbe influire sul modo in cui si passano identificatori di oggetto nelle richieste HTTP (ad esempio oggetto diretto contro riferimenti ad oggetti indiretti ); può influire sul fatto che una determinata pagina accetti un POST o un GET; può influire sul modo in cui dividi i passaggi del flusso di lavoro in UX (ad es. per impedire a un utente di tentare un'attività che non sarà in grado di completare); potrebbe limitare l'utilizzo di iFrame; ecc. Per provare i tuoi progetti dovrai essere in grado di testare almeno due ruoli e dovrai essere in grado di esercitare il sito in modalità di autenticazione rispetto a quella non autenticata.
I progetti di sicurezza e l'implementazione potrebbero richiedere una revisione esterna, ad es. se stai provando la conformità di PCI / FDIC / ISO / FISMA. Quanto prima avrai messo insieme le cose, tanto prima potrai completare il processo di revisione. Fino a quando non viene eseguito, il tuo PM dovrà mantenere un elemento di rischio nei rapporti sullo stato poiché l'impatto di una revisione non riuscita potrebbe essere grave.
I meccanismi di sicurezza devono essere verificati tramite Ricerca app e Test della PEN , che non sono esercizi banali. Se si costruisce l'autenticazione / autorizzazione in anticipo, è possibile aumentare il parallelismo del progetto. Altre caratteristiche non sono suscettibili di ottenere questo livello di controllo, quindi sono candidati migliori da rimandare a più tardi.
Ci sono molte funzionalità che possono dipendere dal contesto di sicurezza, dal rendering del sistema di menu alla registrazione dei record di controllo per l'attività dell'utente. Se cambi i sistemi di sicurezza in un secondo momento, potresti finire per invalidare un sacco di QA.
I servizi di back-end possono richiedere frammenti dal contesto di autenticazione / autorizzazione, ad es. se utilizzi la propagazione del contesto .

D'altra parte, se il tuo sistema di autenticazione è molto complesso, o fa affidamento su terze parti (ad esempio se accetti SAML o qualche tipo di token al portatore da un sistema di autenticazione federato), potresti essere in un vicolo cieco, dal momento che Non voglio aspettare le dipendenze prima di costruire la carne del tuo sito. In questa situazione potresti voler scrivere una porta sul retro che crei un contesto di sicurezza che il tuo sito può utilizzare. Una backdoor può essere semplice come un URL bookmarkable che ti consente di specificare un ID utente ma non richiede alcuna password o altra convalida. Il tuo codice principale dovrebbe comunque utilizzare l'interfaccia "finale" per accedere al contesto di sicurezza, ma la creazione e la demolizione del contesto di sicurezza sarebbe semplificata, possibilmente con elementi codificati, per consentirti di procedere.

Metterlo alla fine non è una buona idea, a meno che il tuo sito non abbia requisiti di sicurezza molto labili, ad es. è per condividere le foto dei bambini e non per inviare pagamenti o completare gli acquisti.

score 1 · Answer 4

Prima inserisci il modulo di autenticazione nel tuo codice, meglio è. Il motivo è che il consumatore della tua API può includerlo e testarlo. Altrimenti potrebbe darti la falsa impressione che tutto funzioni bene mentre tecnicamente non lo è.

score 1 · Answer 5

Varia per diversi progetti e aziende. Se sai quale sicurezza, autorizzazione e autenticazione hai bisogno (spesso non è molto complicato), allora lo costruisci prima piuttosto che dopo.

Tuttavia, se pensi che ci siano altre decisioni di progettazione che potrebbero influire sul modo in cui è implementato, potresti voler aspettare. Alcuni clienti vogliono un sistema molto sofisticato fino a quando non scoprono che avranno molte amministrazioni con cui fare i conti, quindi taglieranno. Altre volte, potresti non sapere come verranno implementate parti dell'applicazione. Una modifica a loro potrebbe influire sull'autorizzazione.

Qualcosa come avere le divisioni di vendita in un Customer Relationship Management (CRM) può alterare i requisiti durante il processo di sviluppo mentre il cliente ottiene una migliore comprensione di ciò che desidera. I venditori in una divisione possono vedere i clienti nell'altra? Diverse linee di business potrebbero voler effettuare il cross-selling in diversi territori, quindi la risposta sarebbe sì. La riassegnazione deve essere un processo semplice e facile? Forse no se non succede spesso.

Di solito metti tutte le decisioni il più tardi possibile. Puoi sviluppare un sacco di software e business logic prima ancora di scegliere un database o forse non ne hai affatto bisogno. Le decisioni sulla sicurezza sono le stesse.