I have heard thoughts that using a three-tier architecture is the best practice for web applications that need to be secured.
My understanding of this architecture is as follows:
- Web Tier Servers - Field requests and communicate with a middle layer for database communication. The database is completely walled off from the web server environment.
- Middle Tier Servers - Expose an API that will handle the retrieval and storage of all information. The web server communicates to this server to handle data operations.
- Data Tier Servers - Stores all of the user data. Allows communication from the middle tier, but not from the web tier
The other option is direct communication from the web server to the database. This communication would be done as a specific user who only had access that the application needed (SELECT, INSERT, UPDATE on the necessary tables). This user, for example, wouldn't be able to delete records from the user table or drop tables.
The logic behind the three-tier approach being more secure is that if your web server is compromised, the attacker would only be able to get data in the same way that you can use your API.
My question: Is this type of approach necessary for a web application where potentially sensitive data is stored? All incredibly sensitive data would be encrypted at rest, but other personally-identifiable information would be stored in plaintext to allow searching.
If it is necessary, what is the best way to secure such an approach? Should your API require a valid session token in order to get data for a particular user? My concern would be that an attacker could simply use the API to get the data they wanted if you didn't have another layer of security in it. How would you secure your API to prevent this?