Tip 8: Security

Security sometimes takes a back seat, but please, please – don’t let it.  Without exaggeration it’s about 1,000,000 times easier to make security changes before a go-live than after.

Simple things need to be completed and tested before go-live:

• Complete production security model in place, including row security
• All table auditing enabled (if you do this)
• Complex JDE password for database and for JDE
• Do not use the JDE account for the system account for your users.  Please do not do this, create “jdeuser” or something much better that will not get locked out
• Check that the password expiry policy for Oracle is not default, or else your system accounts will start locking out
• Change your default node configuration, do NOT leave this standard.  This is one of the largest security holes in the suite.
• LDAP or SSO is critical.  Controlling user access is easiest if someone else is doing it (I find).  So if the desktop team is decommissioning users (oh and changing passwords) this is a big bonus and will save time and money.   The Fusion5 SSO offering is really cool too, especially if you want to use Azure to MFA people under certain criteria – all done by someone else!
• Make sure that your data is encrypted at rest and in transit
• Get your security groups tight and your firewalls enabled
• Default access should be no access
• Adopt the most stringent security posture your business can afford

Here is an interesting tip, quite often row security can be good for performance.  Why?  Because it ensures that there is a where clause that is generally an indexed field.  If you are row securing MCU or CO, then the where clause is enforcing less IO and hopefully a quicker result!