I too often have seen internal company software with a SQL Server data source which relies on a single user name and password in a connection string. Even though the software itself creates tiered security and roles, if the connection string(or connecting user) is compromised so is all the security assignments set up by the programmers.
My solution to this problem is to use the Windows Authentication model and assign roles to specific users based on what they can and can not do.
I call this stored procedure on the program startup(which does connect using a single SQL authenticated user with Execute permissions on the procedure) to determine which roles the user has.
Using this sproc on the startup gives our programmers the flexablity to taylor the program choices and views to what the user has the ability to do. It also prevents unauthorized access exceptions.
Currently, this procedure is not designed to work with users that actually own a role but it could be modified.