I've been fighting with a nearly-identical issue for the last couple of days, but with DB2 on AIX instead of SQLServer on Windows, so maybe I'll write down some of the thoughts I've had and some of the advice I remember from the plentiful advice freely given on the CB.
In my mind, the best solution is one that uses the OS to authenticate instead of a password. You can run your maintenance code from under a service of some sort which can run as an authorised user, and problem is solved. I don't know if that is an option with SQLServer. It is a partial solution to DB2 - in my case, I needed to use the other connect type to do certain tests, and that connect type does not use the currently-logged-in user for authentication; it's user and password only.
Next best is a password safe of some sort. On Linux with KDE, I've used KWallet (with Net::DBUS to query from it - I posted my code earlier, but it's not likely to help you so I'm not going to look it up link it). I don't know if KeePass for Windows has some interface that you can use to query from Perl. Other similar solutions include a GPG-encrypted password where you have a gpg-agent running. The downside to these is that you do have to log on to open the safe after every reboot. This may not be a viable option. For this reason, and due to a lack of any of these types of tools on AIX, and the short turn-around time required eliminating legal approval for anything, it was not an option for me this time, either. As I said, I use KWallet to store these types of passwords, but not for fully-automated tools.
After that is a tightly-locked down source. This is hard to quantify. In my mind, a plain-text password stored on the system such that only the user that the script is running as has read access to it, and no one else, is sufficient. Any obfuscation or further encryption of the password is, in my mind, a waste. The difference between a plain-text password stored in a locked-down file and a mangled/encrypted password stored in the same locked-down file is akin to the difference between storing your apartment key on a hook just inside the door vs storing the apartment key inside the cookie jar in the kitchen. The thief has already gained access to the apartment (the user ID who has read access to the file) at that point, you're just making it more difficult for them (a malicious user) to find the key, without preventing the theft of any other valuable. After all, whatever algorithm you have for retrieving the password from that file is stored in plain text in your perl code, which that user must also be able to read merely so that perl can execute it, so the malicious user could just grab both the password file and the source to the decryption, and decrypt it at their leisure.
In the case of a malicious user, encoding the password delays password retrieval by minutes. In the case of a non-malicious user, they won't even look anyway. It's not worth the effort in my mind. Apparently, many companies' security policies do not agree.
Someone in the CB metnioned something about a secondary machine to hold the password to lock it down. I wasn't entirely clear on how this would help, other than if it used your OS user implicitly (again, no password) and then logged the request. It wouldn't remove the risk from a malicious user, but it would provide a safer avenue of detection.
The best advice, which I also could not avail myself of, but you might, was to talk to the security officer of the company. S/he may have insight as to what the company has available, if anything. If nothing, s/he may have advice on what the company deems "acceptable security risk."
In the end, the stakeholders who objected to the plaintext password in a safe file eventually agreed to withdraw the requirement that absolutely had to depend on the password, and I rewrote the part that did not depend on the password in such a way to guarantee a timeout ("alarm" doesn't necessarily fire if DBD::DB2's connect hangs): I shunted it to a child process via fork, and put the timeout in the foreground process, kill -9'ing the child if the timeout was reached. I ended up without a password requirement at all, but perhaps some of the above will help you.