How to secure an ASP.NET MVC application from the administrator?

Question

ASP.NET

Good afternoon, dear colleagues!
There is a corporate (one might say "intranet") ASP.NET MVC application. The data is stored in a local database on Firebird. This application is delivered "to the masses". There are system administrators who deploy this application on their servers (i.e., deployment is not centralized). In an MVC application, all logic, as you know, is in *.dll. But Views is open for viewing and editing, and if desired, some "cunning" administrator can either break something in the View, or write some JS code (or change the existing one) that will work "bypassing" the main application logic (change the behavior of some buttons, for example).
The question is: how can you protect the entire application in such a way that "smart" users cannot change the logic of the application or its components (Views, JS code)?
Possible options:

1. you can obfuscate everything that is possible, but then how to make it so that both Views are rendered normally and the JS code is successfully executed?
   
2. you can encrypt all the contents of Views and JS code, but where to store the key then? (the key, in principle, can also be stored in a local database - there will be nothing particularly terrible here, because the encryption / decryption logic will be "hardwired" into * .dll, which, as far as I understand, are quite difficult to decompile - or I'm wrong ?)
   

Note: in a local database on Firebird, data is stored in clear text, and in fact, nothing prevents them from being read from there. In principle, it is not particularly scary that system administrators can see this data - the main thing is that it is impossible to "read" and change the logic of the work and behavior of the entire application.

Answer 1

Colleagues, in principle, this can be attributed to the solution of the issue - in Visual Studio, when publishing an ASP.NET application in the Publish settings, there is such an option - " Precompile during publish ". When configuring this option, the " Allow precompiled site to be updatable " checkbox is unchecked + you can play around with the " Merge option " block . This checkbox ensures that all Views will be converted to *.dll files when published, and the "Merge option" block, as I understand it, allows you to configure various ways of this View -> dll transformation. I will not mark the decision yet - I would like to hear more options and "play around" with these publishing settings.

Answer 2

IMHO while both the data and application are at the user - in any way.
just take the data and business logic into the controlled space, give the user only the interface

Answer 3

Or maybe the server still have one? Why a bunch of copies?

Answer 4

You can anally fence the Base. Access only to the storage level, grants for storage are issued only by you when the database is initiated.

Answer 5

Remove all logic from the client - let there be good old postbacks. Do everything on the server, including enhanced validation. Obfuscate server assemblies when building. If you really want hardcore and the UI is not too complicated, you can also render it on the server.
However, physical access to a protected object is, by definition, a security breach. The issue with a centralized server protected from access by strangers can also be solved on the intranet.