I'd say this is a good security practice to restrict OS access to your DB files. First you should definitely restrict write privileges to DB files at the OS level, if not already configured that way. Don't allow anyone other than the OS user that runs the DB to write to the DB files. Practically any DB software I can think of restricts this by default.
If you want to additionally restrict read access, this would be a good idea, especially if your database contains sensitive information. Any unprivileged OS user that shares your OS, if he/she has read-access to your DB files, they basically can get read access to your DB. They could simply steal copies of your DB files, send them to their own server, and setup the DB system and grant for themselves unlimited access to that clone. I'd say the majority of DB software does NOT proactively restrict read access at the OS level to the datafiles. It's up to you, the DBA to restrict this. If your data is super sensitive, you might want to consider encryption, which is available in most major DBMS. If the datafiles are encrypted, a would-be information thief would most likely be foiled even if he/she made off with your datafiles.
Don't forget to encrypt your backups, too, since they are just as sensitive as the DB itself.
Generally, you don't need to worry about the impact of cutting off access to other OS tools like backup software. Most DBMS can't and don't use any OS-based backup tools since DB files are changing. Rather you use specific tools like Oracle RMAN, SQL Server native backup, Litespeed, mysqldump, etc. These tools know how to handle a database that is changing and to get a proper backup. And some other OS tools like antivirus scanners run with root/system authority, so you can't keep them from reading your datafiles by permissions alone (encryption can).
If you're doing this on Unix, it can sometimes be a matter of simply chmod 700 (or perhaps 750) on the directory that contains your DB files. On Windows you could likely do this via NTFS permissions.
If you're using IIS manager for application pools to configure identity for your application and your servers are Windows 2012 or later, you can look into using either a Managed Service Account or a Group Managed Service Account to run your app. Either approach will eliminate the need to deal with passwords yet maintain a secure application login.
The comment provided by sepupic above is spot on though in that you should manage user permissions directly against the database separately, and how that's done will heavily depend upon what level of permissions are needed.
Hopefully this provides an approach to your situation though.
Best Answer
You could use a logon trigger perhaps, going forward (see here and here).
For historical information, by default, SQL Server doesn't even track successful logins (though this can be turned on - however it means you will need to parse the SQL Server log for some little bit of information). So while you might get some information (such as which workstations were using which logins) from the default trace, it would rely on them performing actions that get logged there (and would only go back as far as your default trace data goes anyway).
Also see this answer.