I understand where you are coming from, the thing is im not the boss, so as illogical as theirs security rules are, i cannot change them (actually thats not true, i could change them, but that'll mean nobody would had the access to the source code and will greatly delay developing time).

Still, is there a any way of actually handle a cripted information, or make something where the source code handle a crypted information (with no posibility of simple decryption). Or Some dark way of integrated a .pl with an exed pl script?

You could create a proxy, but then you've simply changed the problem from "controlling access to the database" to "controlling access to the proxy".

...although you seem ok with having a child do the connecting, so you could pass a random token generated by the child to the parent to serve to authenticate the connection to the child. It's a pity that DBD::Proxy doesn't require any authentication, but maybe you could edit it to your needs.

...although DBD::Proxy's cipher options might do the trick.

Update: Added second paragraph.
Update: Added third paragraph.

It's not the security policy that makes no sense. It's how the intent of the security policy is being subverted by everyone. If only DBAs are supposed to have DBA like access, then your database handle is clearly violating that goal. The policy may be poorly worded, but the intent seems clear and you should really be trying to encourage people to follow it.

With that said, the only "solution" I can think of is to write a daemon to handle the database connection that they do not have access to. Then have the scripts connect to the daemon. But you still have to trust the scripts (use a firewall to restrict access to localhost) and the developers still have practically full access to the database. It's a security nightmare, period.

Elda Taluta; Sarks Sark; Ark Arks

Either way you look at it, if a script has access to the database then anyone with physical access to that script will be able to access the database directly if they unravel whatever obfuscation scheme you come up with. Basically: If the script can do it, so can anyone else.

The proper solution IMHO is to create a database user with restricted access, the DBA password is for the DBA only. In real life, this may ofcourse be anything from trivial to impossible depending on exactly what the script is supposed to do and how the data is organized. The key issue here is exactly how much access do you need?

This is for the script programmer to figure out and the DBA to set up. Either start with everything and then tighten it down until things break, or (better but more painful) start with nothing and then grant every bit of access you need as you proceed.

Security through obscurity doesn't work and policy makers must be made aware.

-- Time flies when you don't know what you're doing