ASP. NET Core 6 - Architectural doubt, how to protect data access layer
Hi, I'm planning to use the architecture in the attached picture for an application that will run at the customer factory.
Basically I have the core application split into multiple projects because each one represents a feature the customer may or may not buy, and thus I'll include and dinamically load such project only if the customer buys the associated feature.
Then I'd like to protect the Data Access Layer by making its classes internal, and by letting other systems access it only by means of REST API.
However I've the following doubts with this approach:
- If I do not include e.g. feature 2, the Data Access Layer logic for accessing feature 2 data is still there.
- A customer could make a REST request directly to the Data Access Layer. Should I require an entity willing to dialogue with the Data Access Layer to have a specific role? a role that only the Server layer has.
- Even if I'm to make DbContext internal, Microsoft.AspNetCore.Identity.EntityFrameworkCore.IdentityDbContext is still public, as public are all the models in ServerShared project. However this should not be a problem since the base assumption is a potential attacker (even at the customer factory) does not have database credentials.
I'd like to know what's in your opinion the best approach to use in this scenario. Thanks!
9 Replies
You can protect the traffic between your program and DAL with certificates/api keys/passwords. Or even not have the DAL accessible to the internet.
But why is the DAL a separate server? Wouldn't you want to put the code in your program? Saves a bunch of bytes of traffic and will speed up your program a lot
I'm not sure what you mean by internal & public, is this about the C# access modifiers
public and internal?
are your clients going to be able to download your code?Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
Maybe my explanation was not very clear:
Yep, by and I'm talking about the C# access modifier.
The main problem with this application is that it will be deployed at the customer factory. This is both for performance reasons and because, since this is an OT (Operation Technology) environment, the customer must not be required to have an internet connection: the application just needs to be reachable from the customer LAN.
Both Server and Data Access Layer are on the same server, it's just that I imagine them as two separate projects
I'm trying to "protect" the program from attacks from malicious users located at the customer factory. E.g. if Data Access Layer project classes and methods had public visibility and the server was to access them directly, without a REST API in the middle, the same thing could be achievable by a malicious third party software
"You can protect the traffic between your program and DAL with certificates/api keys/passwords"
Yep, probably this is the right direction, I need to study to understand what can be done
note sure about what you mean
you should only deploy your program at the customer, not give them access to your code
and if you do that, you can have your DB access in the same program
there is no reason to make it a separate API
the problem is I don't know how to do this... .NET .dll can be decompiled easily as far as I know
I could prevent access to the PC used as server by blocking USB ports and so on, but I'm not sure that would be enough
what's the reason you are hosting something on a customer site
(site not being a website, but customer's location)
The resons are
- Performances: being it an industrial environment, every second lost may mean a second of productivity lost, so performance it's a main focus
- A customer may not have an internet connection. We could use a 4g SIM card, but I think there could be a delay.
- As of now the system talks with cameras as well. In particular there is one that, when recording at high fps, produces about 1Gbps data. There is no way we can afford to transmit such data over the internet, we would have a huge transmission loss
- In general, we'd introduce some delay even in the camera low-fps streaming. Since cameras can be used by the operator during production to oversee the machine state, the delay must be kept as low as possible
You have rhem sign a contract (license agreement) that outlines the features they may or may not use, then sue them if they violate it
Access modifiers arent secutity
Install a license file that includes a signed list of features the customer paid for, load the license on app start, and validate with that license whenever they attempt to use a paywalled feature
@alkasel
I suppose that would be a way to go, too
Thanks for all the suggestions, it was an useful brainstorming!