Security & data privacy
The application is installed on your own infrastructure and connects to your databases from your network. It holds no copy of your business data, asks for no inbound access, and is a guest in your schema — it never creates or alters structures.
Standard ASP.NET Core site on your Windows server + IIS. No external services, no agents, no telemetry in the data path. If your network policy says “inbound: none,” the data path agrees — the application simply talks to SQL Servers it is allowed to reach.
Every user has an individual account — no shared credentials. Login issues a signed JWT session (HS256, per-deployment key); locked accounts are rejected. The API is stateless, so it sits comfortably behind IIS or any reverse proxy.
User → single group → area & menu permissions. The data engine requires read rights to return rows and edit rights to save them — enforced server-side, not merely hidden in the UI. Administrators bypass by role; everyone else receives a clear, multilingual “no access” message.
Data-source and user passwords are protected at rest with the ASP.NET Core Data Protection framework — a per-deployment key, never plain text, never returned by any API. Passwords are write-only. The browser never sees data-source credentials; the API resolves each screen’s connection server-side.
All data access is parameterized; table and column names pass a strict identifier whitelist before use. The application never issues DDL against your business database — it reads and writes rows only.
Fail-soft design: an unreachable data source produces a readable error for that screen only, and the rest of the application keeps working. Structured logging (Serilog) and standard IIS tooling keep operations familiar to your team.