SECURITY
Security
Learn how INNORIX protects direct file operations with access control, transfer integrity, audit visibility, secure device identity, and deployment security.
Security designed around direct file operations#
INNORIX is designed to centrally connect and operate file transfers between servers, cloud environments, storage, Kubernetes, and other devices.
In the default architecture, files are transferred directly between connected devices without being copied to unnecessary intermediate servers or shared storage. The Control Plane manages device connections, transfer policies, execution status, and operational information.
This simplifies the path files take while providing access control, transfer integrity, audit records, and centralized management.
Direct File Transfer#
Reduce unnecessary places where files are stored#
INNORIX's default transfer method is direct transfer between connected devices.
There is no requirement to configure a separate intermediate transfer server or shared storage for file transfers.
In supported configurations, direct transfers can be performed between the following systems.
Server to Server
On-Prem to Cloud
Cloud to On-Prem
Cloud to Cloud
Office to Office
Object Storage to Object Storage
Server to Object Storage
Object Storage to Server
The INNORIX Control Plane is not an intermediate storage location for the files themselves; it manages device connections, policies, execution status, and operational information.
The actual data path may vary depending on the selected deployment model or separate network configuration.
Data in Transit#
Protect data while it moves#
INNORIX uses protected communications for device connections and file transfers.
Depending on the transfer environment, the following security features can be applied.
Protected communication between connected systems
Encrypted control and metadata communication
Optional file-content encryption
Secure device authentication
Transfer integrity verification
File-content encryption can be applied optionally where required, while transfer control and operational metadata are managed separately from file contents.
Transfer Integrity#
Verify what was actually delivered#
INNORIX is designed to verify not only that a transfer started, but also the actual file delivery result.
Key features include the following.
File integrity verification
Hash verification
Incomplete transfer detection
Resume after interruption
Per-file transfer result
Transfer history
Even after a power interruption, process termination, or network failure, transfers can resume based on data that was already delivered successfully.
During retries, data that has already been delivered is tracked separately from newly transferred data.
Device Identity#
Manage every connected endpoint explicitly#
Devices connected to INNORIX are registered and managed as unique Devices.
Managed endpoints can include the following.
Windows, Linux and macOS systems
Physical servers
Virtual machines
Kubernetes nodes
Cloud virtual machines
Supported object storage connections
Device information allows connection status and transfer operations to be centrally monitored and managed.
The configuration is designed to maintain the same Device identity after a reboot or Agent restart.
Access Control#
Control who can manage file operations#
INNORIX controls user access based on Organization and administrative permissions.
Administrators can manage access to product features according to each user's role and scope of work.
In supported environments, the following Enterprise identity features are available.
SSO
SAML
Centralized identity management
SCIM where supported by the applicable plan
The availability of Identity features may vary depending on the Plan and configuration in use.
Security Policies#
Apply security rules centrally#
INNORIX is designed to manage policies centrally without relying on separate scripts or manual configuration for each transfer.
Policies can be used to manage the following areas.
Device access
Transfer permissions
Network zones
User permissions
Security settings
API access
Environment-specific restrictions
Security Policy and Network Zone Security can be used to configure a transfer environment that aligns with the organization's operational requirements.
API Security#
Automation follows the same controls#
Automation using the INNORIX API follows the product's authentication, permission, and policy framework.
The following can be applied in API environments.
Authenticated API access
API credential management
Rate limiting
Plan and feature entitlements
Operational audit records
Transfers initiated through the API do not bypass the security and operational policies applied to the product.
Object Storage Security#
Keep storage credentials separate from usage records#
INNORIX connects supported Object Storage through authenticated Connections.
Supported services may include the following.
Amazon S3
Azure Blob Storage
Google Cloud Storage
IBM Cloud Object Storage
Dell ObjectScale
Alibaba OSS
Cloudflare R2
Raw Secrets or Credentials used for Object Storage connections are not stored in Metering or Billing records.
Usage and operational records use only the required identifiers and reference information.
Access permissions and Bucket policies for the Object Storage itself remain managed through the customer's Cloud or Storage Provider.
Audit & Visibility#
See what happened across file operations#
INNORIX provides records that allow file transfers and operational status to be reviewed centrally.
Depending on the product configuration, available information can include the following.
Run history
Transfer status
Per-file results
Device activity
Failure and retry history
Administrative changes
API-triggered operations
This makes it possible to see not only whether a file was transferred, but also which operation ran on which device and what result occurred.
Logs & External Monitoring#
Connect file operations to your existing monitoring environment#
INNORIX allows operational status and transfer records to be reviewed in the product and, in supported configurations, integrated with external monitoring or SIEM environments.
Supported methods may include the following.
SIEM
Syslog
Datadog
Other supported monitoring destinations
The retention period for searchable logs and the scope of external integrations may vary depending on the Plan and contract in use.
When long-term retention is required, records can be sent to customer-managed storage or an external SIEM.
Deployment Security#
Choose where the platform operates#
INNORIX supports multiple deployment models to meet an organization's infrastructure and security requirements.
INNORIX Cloud
Hybrid
On-Premises
Sovereign Cloud environments
Air-Gapped environments
The areas managed by INNORIX and the customer vary by deployment model.
INNORIX-managed services#
Service components operated by INNORIX are within INNORIX's management scope.
Customer-managed infrastructure#
The following customer-operated environments are within the customer's management scope.
Servers
Operating systems
Networks
Firewalls
Cloud accounts
Storage
VPN and private connectivity
Customer-managed Kubernetes infrastructure
This separation clarifies the scope of Security and SLA coverage.
High Availability#
Build resilient deployments where required#
Enterprise environments can use architectures that support HA configurations.
HA-ready software is distinguished from the Infrastructure actually operated by the customer or INNORIX.
In On-Premises or customer-managed environments, the customer can configure underlying Infrastructure such as servers, networks, Databases, and Load Balancers.
If INNORIX directly manages that Infrastructure, the management scope is defined in the individual contract.
Backup & Recovery#
Separate operational recovery from customer archives#
INNORIX-managed services may use Backups required for service operation and recovery.
Backup is an operational function for service recovery and does not replace the customer's long-term Archive.
Logs or operational records that customers need to retain long term can be stored separately in customer storage or supported external systems.
Data Minimization#
Keep billing and operational systems focused on what they need#
INNORIX's Metering, Policy, and Billing systems use data required for service operation and usage calculation.
As a general rule, these systems do not store the following information.
File contents
Passwords
Raw access tokens
Raw object-storage credentials
Secret keys
Instead, they use Device ID, Run ID, Transfer ID, and required usage information.
Customer Responsibilities#
Security is shared across the service boundary#
Customers are responsible for maintaining the security of the systems and accounts they manage.
This includes the following.
Protecting account credentials
Managing user permissions
Protecting API credentials
Securing customer-managed servers
Maintaining operating systems
Configuring networks and firewalls
Managing cloud and storage permissions
Controlling access to connected endpoints
INNORIX security features are most effective when used together with appropriate security configurations for customer-managed Infrastructure.
Security and Privacy#
For details about the processing of personal information and service data, see the INNORIX Privacy Policy and Data Processing Addendum.
Service Status#
The current status of INNORIX-managed services, ongoing incidents, and planned maintenance can be viewed on the Status page.
Service Level Agreement#
The SLA defines availability coverage, exclusions, and Service Credit criteria for INNORIX-managed Cloud services.
Subprocessors#
External service providers used by INNORIX to operate the service are listed in the Subprocessor List.
Related Resources#
Status
Current service availability and incident information.
SLA
Availability commitments for eligible INNORIX-managed services.
DPA
Terms governing the processing of Customer Personal Data.
Subprocessors
Service providers involved in operating eligible INNORIX services.