Should fg_sysadmin have access to /myfilegateway?
Ekmekvar 2700053NMH Visits (3768)
We have had some customers ask about allowing the fg_sysadmin user account to have direct access to the /myfilegateway URI (MFG below) in order to upload and download files. This is my two cents worth on that subject.
Most people have seen or heard of Windows/Linux administrators who have two separate accounts on the machine that they administer. They use one account that has their full administrative privileges for doing things that only an administrator can and should do. However, a lot of what administrators do is more mundane work that can be performed by accounts that do not have administrator level privileges. The administrator's second account has lower level privileges, and cannot do all of the Administrator's job functions. The reason Administrators use two accounts is that mistakes made when using an administrative account can have more far-reaching effects than mistakes made while logged in as a user with lower level privileges. That increases the security and stability of the system. For example, it is hard for hackers or rogue employees to steal administrative user accounts and passwords when they are not in use. Also, it makes sense not to use much higher privileges than necessary to do lower level work.
The situation with fg_sysadmin and MFG is similar. Under the current programming the fg_sysadmin account cannot log into MFG. That was done by design. MFG is designed to be used by SFG partners, not SFG administrators. Generally speaking, an SFG partner only needs access to its own mailboxes, and the combination of a virtual root for the partner and limited mailbox permissions ensures that the partner cannot upload to another partner's mailbox, download from another partner's mailbox or see another partner's data. If sfg_sysadmin were able to log in to MFG in order to upload and download files, its permissions and privileges would allow it to upload files to the wrong mailbox. While that would not necessarily happen with any regularity, it would likely happen at some point due to the human propensity for making errors, and could cause problems. Would it be a good thing if you accidentally uploaded an invoice for your second biggest customer to your biggest customer's mailbox?
The fg_sysadmin, can see everything that needs to be seen and do everything that needs to be done in the way of administrative tasks using the SFG screens. Uploading files to and downloading files from SFG partner mailboxes is not an administrator level task. In addition, if fg_sysadmin wants to upload files to or download files from an SFG partner's mailbox, there are multiple ways to do that which do not involve logging in to MFG as fg_sysadmin, such as:
* log out of SFG as fg_sysadmin, then log in to MFG as the desired partner, then do the uploads & downloads
Given the above, I believe that people with fg_sysadmin rights should think of the inability to log in to MFG as more of a security precaution against human mistakes by the account rather than as an impediment to their work.
The only reason other than file upload or download that I can think of for fg_sysadmin ever to be in MFG is to subscribe or unsubscribe the partner from email notifications. There again, rather than have fg_sysadmin go from partner account to partner account doing such a task, which increases the chance that a mistake will be made, it would make more sense for either (1) fg_sysadmin to log in to MFG as the partner in order to do that, which means it could only be done for one account, or (2) to change the SFG screens' programming rather than MFG screens' programming to let fg_sysadmin subscribe or unsubscribe partners to notifications.
Put simply, if security is important for your company, and you believe in avoiding easily preventable mistakes, then any minor inconvenience caused by the inability of fg_sysadmin to log in to MFG should be more than outweighed by the increase in security gained by not allowing that account access to MFG, where any mistakes it may make might be high impact mistakes.