Security
Jelina takes fleet security seriously. We understand that your data and devices are valuable and often critical, and take precautions to protect them from harm.
To secure the Jelina ecosystem, we focus on least privilege: grant permissions only when necessary, and provide accounts or devices with information only when their current task requires it. We isolate components throughout the update process so that unauthorized access to one does not reveal enough information to access others, accounts, or devices.
API access control is central to this approach. By controlling API access, permitted operations, and available communication channels, we protect fleets at every entry point.
User security
Section titled “User security”Access is fully isolated between organizations. Users can access only organizations they created or joined; even Jelina administrators cannot access user organizations. Accounts use email and password authentication, with optional two-factor authentication for additional protection.
Device security
Section titled “Device security”Devices authenticate to JelinaCloud using a unique ApiKey generated randomly during registration. Only the device and the JelinaCloud system can obtain this key.
By default, all external access ports are closed, leaving only one port for JelinaCloud communication.
Azure Virtual Network Gateway enables access to your devices through Jelina from anywhere, at any time. Supported remote protocols include SSH, VNC, and RDP.
SSH key and certificate authentication
Section titled “SSH key and certificate authentication”Remote SSH connections support passwords, SSH private keys, and OpenSSH user certificates. Certificates are signed by an organization-trusted issuing CA. The platform validates certificate validity periods, credential scope, and usage permissions; the device SSH service checks its actual CA and principal configuration. This authentication applies to SSH connections; web login and device cloud onboarding retain their respective authentication mechanisms.
Administrators can configure shared public keys or CA trust at fleet level, or dedicated authorization for individual devices. Users configure device CAs and principals themselves. After an administrator manually registers and confirms the host identity, users connect with personal certificates and matching private keys. Importing a certificate alone does not authorize a system account.
Administrators store user private keys and required passphrases encrypted on fleet or device management pages. Connecting users select permitted credentials but cannot view or download private keys. The issuing party retains the CA private key; the platform does not issue or renew user certificates. Disabling or revoking stored credentials prevents further platform use. Platform revocation applies only to JelinaCloud connections; users maintain device-local revocation and removal of old authorizations, without requiring device acknowledgment.
For usage, see SSH key and certificate authentication. For administration, see remote access management.
Data security
Section titled “Data security”All internal service requests use HTTPS. All JelinaCloud communication, including data exchanged between devices and the platform, is encrypted in transit.
Uploaded files are securely stored in dedicated Azure Storage containers for each organization. File isolation prevents other organizations from accessing your organization’s files. Stored files are private. When a device needs a file, JelinaCloud generates a download link using a temporary SAS key; the link expires after a period of time.
Private deployment
Section titled “Private deployment”If you prefer not to store data in Jelina’s Azure Storage, Jelina supports standalone deployment. We support mainstream cloud platforms such as AWS and Alibaba Cloud. Deploy Jelina on your own servers or cloud platform and manage all device and user data yourself. Even with standalone deployment, the Jelina team provides long-term technical support and ongoing updates.