Qual è il vero vantaggio di un'architettura a tre livelli?

2

Come per titolo, qual è il vero vantaggio dell'utilizzo di un'architettura a tre livelli, in cui l'interfaccia utente in un livello, il secondo livello per l'applicazione e il terzo livello per il database? Posso capire che, ad esempio, se l'interfaccia utente viene compromessa, gli hacker hanno altri due livelli da hackerare per accedere ai dati. Tuttavia, da un altro punto di vista, le mie applicazioni non sarebbero più lente se il mio database si trova su un altro server? Inoltre, un'architettura a tre livelli deve sempre essere protetta da un firewall tra ogni livello? Nel complesso, penso che se uno strato è compromesso, significa che è compromesso ... non importa quanto bene proteggi i tuoi sistemi.

    
posta Pang Ser Lark 26.08.2015 - 06:57
fonte

2 risposte

4

Un'architettura a tre livelli non significa necessariamente che tutti i livelli si trovano su server o processi diversi. È più una cosa che si astraggono le parti della propria applicazione l'una dall'altra che consente loro di interagire solo con interfacce chiaramente definite. Nel tuo caso significa mantenere la logica di archiviazione (database) separata dalla logica aziendale (applicazione) e dalla visualizzazione dei risultati (HTML, CSS, ...). Questa separazione è principalmente una separazione logica che consente una separazione fisica più semplice se ne hai bisogno. La separazione può essere effettuata all'interno dei processi (ad esempio, oggetti diversi per i livelli) o anche sistemi diversi.

La separazione tra queste parti non viene effettuata principalmente a causa della sicurezza ma in modo che sia più facile capire e gestire l'applicazione. Permette di apportare modifiche su un livello senza molte modifiche all'altro livello, ad esempio è possibile ridimensionare il database o persino modificare il database sottostante senza un impatto significativo sul livello dell'applicazione. Oppure potresti avere una diversa interfaccia utente (web, app mobile ...) idealmente senza modificare il livello dell'applicazione e il database.

Naturalmente questo tipo di separazione può essere utile anche per la sicurezza. Interfacce chiaramente definite tra i livelli facilitano il controllo dell'applicazione. È inoltre possibile rilevare e dissuadere i possibili attacchi se si conosce effettivamente come le parti devono interagire tra loro. In breve, l'applicazione può essere resa più robusta con meno sforzo, il che aiuta a ridimensionarla, ma aiuta anche nella sicurezza. E se i diversi livelli sono in realtà processi separati (che di solito è il caso con almeno web server e database), è possibile inserirli in diversi ambiti di sicurezza, ovvero account utente diversi, contenitori diversi, VM o persino server diversi. Ciò aiuta a mantenere il sistema più robusto e anche meno attaccabile.

    
risposta data 26.08.2015 - 07:23
fonte
1

Al giorno d'oggi, il modello Model-View-Controller è diventato molto più di quanto originariamente era previsto:

Utilizzato per es. pulsanti in un'applicazione, l'intento era quello di disaccoppiare la Vista dal Modello e dal Controller, rendendo il design, il comportamento e la logica del pulsante intercambiabili, risultando in un più orientato agli oggetti , dinamico e modulare .

Oggi è diventato molto più di un modello di progettazione best-practice per l'implementazione di elementi come i pulsanti in un'applicazione.

Tornando alla tua domanda, penso che il vantaggio della sicurezza nell'usare il pattern MVC per la progettazione di livelli applicativi è fondamentalmente che hai un design generale molto più chiaro, facendo un sacco di potenziale sicurezza- bug correlati impossibili.

es. non è possibile fare in modo che il controllore esegua qualcosa per cui non è stato creato, essendo in grado di manipolare la vista, dato che MVC è implementato correttamente.

    
risposta data 26.08.2015 - 11:41
fonte

Leggi altre domande sui tag