Neither option is remotely secure. But you present those as THE options, so I'll address them first, then present you an option 3.
Given your two options, neither is technically superior. The addition of SSL/TLS would only be security theater.
In regards to your public internet exposure, neither option provides reduction of attack surface or hardens your underlying systems from attack. An attacker accessing your sites from the public internet would be able to simply accept any self-signed certificate if you have one, and would not worry about it if you do not.
In regards to your internal exposure, SSL/TLS is primarily intended to mitigate man-in-the-middle attacks (not its only use, but primary). Since this is internal and all persons log in using shared user/pass, there is minimal gain for a potential internal attacker. If the internal attacker has access to the shared user/pass, the attacker can generate any traffic any other user would generate.
Note: I yield a TINY amount of extra security with the SSL/TLS (at least our attacker can't see what others are doing). Given the described scenario, I evaluate the worth of that tiny sliver to be otherwise not worth mentioning.
In terms of process, leaving SSL/TLS out is actually more secure. Given the above technical lack of additional security, you've now added management of a security resource to the mix.
Unnecessary complexity is an enemy of security.
Security: Human Factor
In terms of process, leaving out self-signed certs is more secure.
Consider what you will be training users to do: adopt a workflow where self-signed certs are to be accepted. You want users to always, ALWAYS seek guidance when they receive a browser warning regarding certificates - be that from the company's help desk or from the site's help desk.
Regardless of cert or no cert, you say that you will change the password whenever someone leaves the company. This requires all users every time to adopt a new password. If your turnover is high, users will inevitably start writing down the current password.
Do not train your users into bad patterns.
If ONLY the two options are options...
Leave out the SSL/TLS. The described scenario is severely security deficient, and adding security theater only provides a false sense of doing something.
So Option #3, as promised, requires you, the asker, to adopt a security-minded approach. Big factors I see as problematic in the situation you describe:
Technical Gap: Adding SSL/TLS does not necessarily add security (or at least, any amount worth mentioning). The reasoning behind shared user/pass is faulty. This indicates the overall system was designed by someone lacking technical cybersecurity knowledge and understanding.
Attack Surface: Having these internally used sites publicly available is a massive attack surface. If they are to be used only internally, they should be accessible only internally.
Shared credentials: While there are certainly some edge cases where I'd entertain the prospect of shared credentials, it is a bad design pattern. If a person leaves your company, you have to change a password -- it does not matter if it is their personal password or if it is the shared password. The risk of overlooking this step is identical for both shared and individual credentials.
Taking the given scenario, the following corrective actions would help reduce risks (listed in order of greatest value to least value):
- Any and all technical staff should seek cybersecurity training. This should include engineers, systems administrators (OS, DB, network, etc...), architects, developers/coders, even help desk. All users should also receive basic security training (which should be broader in scope than cybersecurity training, but shallower in depth).
- Use an edge firewall to block access to the sites IPs from outside. Most modems/bridges have a basic firewall built in; while a dedicated appliance that can create external, internal, and DMZ zones would be better, using the existing built-in firewall is a step in the right direction.
- As soon as feasible, retool the system to use individual credentials. Realize that an account has to be updated whenever a person leaves the company anyways -- choose the option that least inconveniences other users.
- If you've implemented individual credentials, SSL/TLS finally offers a reasonable addition of security. Self-signed certs are not HORRIBLE, but given the low costs of getting a proper chained cert from a public CA, a public CA vs a self-signed cert would be the superior option of the two. If you MUST use self-signed certificates, ensure these are pre-bundled when a new system is deployed; this prevents training users to ignore certificate warnings.