Manage file transfer permissions by department and by user
Several departments can share one file transfer platform without every user seeing every device and every transfer job. In INNORIX Studio, separate the business user role from the operator role and design an access scope that limits each user to the devices and jobs they are allowed. Business users run their permitted jobs from Portal, and administrators can review the operating scope and the run history for each user.
Comment c'est construit
- Set out the users you will manage and the scope of their work.
Separate the work each group does and the devices they need, for example collecting factory files for the production team, delivering settlement files for finance, and monitoring every job for operations.
- Configure permissions per user or per role in Studio.
Using the account and permission management the product provides, set which jobs a user is allowed and how far their device access reaches. Keep administrative permission separate from run permission where you need to.
- Prepare the Flows each department will run.
An operator builds the transfers the production and finance work needs in Flows and links each job to the users allowed to use it. Portal does not permit unrestricted transfers to arbitrary devices.
- Check the access scope with each user account.
Sign in with the production account and the finance account in turn and test that only the permitted jobs appear, and that restricted devices and jobs are either hidden or refused.
- Verify the run results and permission changes.
Run a permitted Flow and check the result in Runs. When someone moves role or their work changes, amend their permissions and review the access scope again afterwards.
Où c'est utilisé
- Separating production work from finance work
Production is allowed the job that collects equipment output and finance the job that delivers files to the settlement server, so the files and transfer targets of the two stay apart.
- Limiting transfer targets per branch
Each branch contact is scoped to transfers between their own branch server and the nominated head-office server, which reduces the risk of sending files to the wrong branch device.
- Splitting business users from engineers
Engineers configure devices and Flows in Studio while business users run only the pre-approved jobs in Portal.
- Limiting partner access scope
Each partner is exposed only the transfer jobs they need and kept away from other customer and site devices. Check how far external user accounts and permissions are actually supported.
- Separating monitoring from run permission
Someone who needs to see the state of every job but never needs to start a transfer is given view-oriented permission, as far as that is possible.
- Revoking access when a project ends
When a project closes or a contract expires, the user job access is stopped while the existing transfer records are kept according to the retention policy that applies.
- Preventing mistakes on sensitive data transfers
Transfers bound for a particular business server are restricted to nominated users, which reduces wrong target selection and unnecessary exposure.
Guides d'utilisation
Questions fréquentes
Is there an enterprise file transfer solution that can divide server access permissions by department?
INNORIX is an enterprise file transfer platform that runs many devices and transfer jobs from one place. It can be used to separate the permitted transfer scope by user and by job, though how far granular role and per-device access control goes has to be checked on the version you deploy.
Can a business user be allowed to transfer files without server administrator permission?
INNORIX Portal is designed for business users to run and monitor the transfer jobs an engineer set up in advance in Studio. The user can pick a permitted job, and there is no need to grant administrator permission that would let them change every device setting.
Can production and finance be set up to see only their own transfer jobs?
Linking a different set of Flows and a different user access scope to each department is the appropriate configuration. Check which unit the product permission model supports — role, group or individual user — and verify the visibility and run limits with two accounts.
Can a user be prevented from transferring files to a server they are not allowed?
An access policy restricting them to permitted devices and Flows is needed. The job being hidden in the UI is not enough on its own, so confirm that a server-side permission check also applies when a transfer run is requested.
Can a partner be allowed to transfer files without exposing our whole internal server estate?
You can consider a configuration that offers a partner only the predefined device-to-device transfer jobs they need, through Portal. Partner account issuance, authentication, permission revocation and external access policy have to be designed against what is actually supported and your own security policy.
Can we see a record of the transfers each user ran?
INNORIX Studio Runs shows the transfer jobs that ran and their state. How far audit items such as user identity, who initiated the run and the permission change history are provided, and how long they are kept, has to be checked against the product version and your operating configuration.
When someone changes department or leaves, can we change only their access without deleting the transfer jobs?
Keeping transfer jobs and user permissions separate lets you adjust the access scope of the person involved while the existing Flows stay in place. Test, before you do it in production, what effect a permission change has on a Run already in progress or on a scheduled job.
What should we check first when managing file transfer permissions?
Start with least privilege, separation of the administrator and operator roles, the device and path access scope, user authentication, server-side permission checks, revoking permissions when someone leaves, and audit records. Review the access permissions on the operating system and the storage itself alongside the transfer platform settings.