KAZ-REMOTE
RUҚАЗEN
Remote workstation support for organizations in Kazakhstan

Every technician connection is signed, and the infrastructure can be entirely yours

The user starts the session themselves and approves the technician's access, and sign-in on both sides is signed with a qualified digital-signature (ЭЦП) certificate through NCALayer. The server, the media layer, the session log, recordings and logs run either on the cloud platform, where each organisation's data is kept apart from the others, or entirely on your own servers.

Request a demo See how it works
01

Sign-in with a digital-signature certificate

Both the workstation and the technician sign their sign-in with their own certificate in NCALayer, Kazakhstan's national digital-signature software. The server verifies the integrity of the signature, the certificate's validity period, the chain up to a trusted certificate authority and the revocation status at the CA; the signature is bound to a specific action, room and session, so it cannot be reused. Administrators sign in to the console the same way, with their digital signature: the product has no passwords.

02

The user opens access to the technician themselves

Every technician request raises a dialog on screen with the details from their certificate: full name, IIN, the organization's BIN where present, issuer, validity period (IIN and BIN are Kazakhstan's national individual and business identifiers). Until it is approved, the viewer receives no stream, no control, no clipboard and no files. The certificate of an on-duty engineer can be marked as trusted on this computer — approval for it is then performed automatically, and the entry is removed from the list by hand.

03

Recording is your organisation's decision, not a property of the product

Recording is off as shipped: the "record all sessions" flag is cleared and the IIN and BIN lists are empty. The organisation's administrator can enable recording for all sessions, only for specific individuals or a specific contractor organisation by IIN and BIN, or manually for a single room in progress. The support technician neither turns recording on nor off; the user can end the session with the "Stop" button.

04

Deployment on your side

Two ways to run it. On the cloud platform each organisation works separately: its sessions, recordings and audit log are not visible to others. The on-premise version is installed on your Ubuntu server by an installer: the application server is an executable carrying your licence, and the media server, TURN, database and console run as system services on the same server. The only external calls in the working flow are the certificate status check at the certificate authority and, in the on-premise version, a time check against public time servers.

Capabilities

The workstation: what the user sees and decides

A session begins and ends on the user's side: they launch the application themselves, sign in, and decide which technicians to let in.

Starting a session with the "Start" button and a digital signature

The user launches the application and presses "Start", signing the sign-in with their certificate in the local NCALayer; without NCALayer running, sign-in is impossible. From that moment the workstation begins capturing the screen and publishing it to your media server — the approval that follows opens access to this stream for a specific technician.

A permanent five-digit workstation number

A five-digit room number stays attached to the device: it is not single-use and repeats at every sign-in, so the employee does not have to look for a new code each time. The "Copy invitation" button puts a line of the form "Room: NNNNN" on the clipboard; the server address is not included in it.

Approving or declining each request

When a technician makes a request, the application window comes to the front and shows an "Accept / Decline" dialog; until "Accept", the viewer receives no stream, no control and no files. The exception is a certificate previously marked as trusted on this computer: for that certificate approval is performed automatically, with no dialog.

The technician's certificate details before the decision

The dialog shows the full name, IIN, BIN and organization where present, the room number, serial number, validity period and issuer, and, in an expandable panel, the Subject DN, all subject attributes and the full PEM. The application itself checks that the PEM is present and that the certificate is still valid; the chain of trust and the revocation status are verified by the server at the signing stage.

Trusted certificates on a tab of their own

A certificate can be marked as trusted only through a separate confirmation prompt that states plainly that from then on this certificate will connect without asking; the list is stored on disk encrypted (AES-GCM) and matched by SHA-256 fingerprint, so it cannot be substituted by editing the file. An entry has no expiry — it is removed by hand on the "Trusted" tab, which is available while the host is signed in.

The application window is closed off from the remote side

While the window is open on screen, mouse, keyboard and clipboard writes from the technician are not carried out, held keys are released, and the technician sees an explanatory overlay: neither approving themselves nor clearing the trusted list can be done remotely. Video keeps being transmitted throughout, and after roughly five seconds without activity the window minimizes itself and control resumes.

Who is connected right now, and how to break off the session

The "Viewers" tab shows the name from the certificate, the connection state and the state of the control, clipboard, file and video channels for each connected technician — there can be several at once. A single viewer cannot be disconnected from the interface: "Stop" closes all connections, halts capture and closes the session on the server.

An indication that recording is in progress

When the server reports that the room is being recorded, a marker with the server's explanation appears in the window header. This is a marker inside the application window, not a system banner: during a session the window is usually minimized, and the application has to be opened to see it.

Session log and technical logs

The "Log" tab shows certificate requests, approvals and refusals, viewers connecting and disconnecting, changes in recording state and files received; this log lives in the window's memory and is lost when the application is closed. In parallel the application writes a log file into the user's directory and, during a session, sends technical events to the server — this is on by default and cannot be turned off from the interface.

The technician: working tools for the session

The technician's application gives screen, control, clipboard and files in one window — after signing, and after approval on the user's side.

Connecting by room number with a digital signature

The technician enters the five-digit number and signs the request with their certificate in NCALayer; there are two minutes to sign and up to five to wait for the user's decision. A request is created only for a room where the application is already running and sign-in is complete: there is no connecting to a workstation that is switched off or not prepared, and the server address is set when the client is built, not in the window.

The workstation screen through the media server

Once approved, the technician gets access to the room's stream on your media server; the frame is fitted into the window with its proportions preserved, and F11 toggles full screen. There is no monitor selection, no zoom and no 1:1 mode — the first display found is captured.

Remote mouse and keyboard

Movement, clicks, dragging, scrolling and keystrokes are transmitted while the "Remote screen" tab is open and the "Remote control" checkbox is ticked; if the window loses focus, all keys on the workstation are force-released. The "Translate key combinations" checkbox converts common Ctrl and Cmd combinations between Windows and macOS, and for a macOS host Shift+Alt switches the keyboard layout.

A shared clipboard

Copy, cut and paste are carried out on the workstation side, and text is synchronized in both directions roughly twice a second. Only text is transferred: files and images do not go through the clipboard, and a write to the user's clipboard is rejected while their application window is open.

Files in both directions, without email or file-sharing services

The "Files" tab is two panels with the drives and folders of the technician and of the workstation, navigation by double click, drag and drop between the panels and from the file manager, and a transfer queue with progress, speed and an estimated time. Transfers run one at a time, there is no cancelling and no resuming, a matching name is not overwritten, and the technician can reach everything the user's account has rights to, except the application's own data directory.

Picture quality and frame rate

Two sliders change the capture width from 640 to 1920 pixels and the frame rate, and the workstation replies with the values actually applied. The setting changes the capture itself, so every connected technician sees it and it goes into the recording in the same form.

Paused while the user's window is open

If the user opens their window, an explanatory message appears over the picture, and input and clipboard writes are not transmitted for that time. Work can continue once the user minimizes the window; this is the same protection that prevents the approval dialog from being driven remotely.

Session metrics and log

The side panel shows the connection state, ping, the workstation's operating system, the size of the incoming frame and the frame rate, and a separate marker shows that the server is recording; the technician cannot turn it on or off. The "Log" tab keeps a technical chronicle of the connection, mostly in English and without being saved to a file.

Connection resilience and workstations with no monitor

On a drop the viewer reconnects by itself with a pause of 2 to 30 seconds, frozen video is restarted by a watchdog timer without breaking the session, and if the workstation loses connectivity temporarily, how much longer the session is being held is shown. If there is no active display, an explanation is shown instead of a black screen, while control, clipboard and file transfer keep working.

The administrator console: oversight and an evidence trail

Your organisation's web console: who connected, what is happening now, what to record, what is left in the archive, and who did what in the console itself.

Signing in to the console with a digital signature

The console opens with a signature in NCALayer: the server checks the certificate exactly as it does for the desktop applications and takes the IIN from it. A person who belongs to several organisations chooses which one they are signing in for. A console session lasts at most 8 hours and ends after 30 minutes of inactivity, and after 5 refused attempts within 15 minutes sign-in for that IIN is closed for a while.

Roles within the organisation

The organisation's administrator invites people by IIN and grants the Operator role (support technician) and the Auditor role (read-only); the person accepts the invitation when signing in. Changing someone's roles or blocking them ends their console sessions at once. Each organisation sees only its own sessions, recordings and audit log, and an operator only their own sessions. The administrator is whoever signed the registration request, or, in the on-premise version, the person whose IIN is given at installation.

Dashboard and live event feed

One screen shows active rooms, connected technicians, workstations ready to be connected to, how many members are in the console right now, the state of the media server and TURN, the signaling server's memory and uptime, and the authorization queue counters. The sessions, recordings and policy pages refresh themselves through a server event stream that reconciles state every two seconds; the dashboard itself refreshes on a button.

A session log with both parties' details

For each session the room, the start and end time, the reason it closed and the IP addresses are stored, and for the host and each viewer the full name, IIN, BIN, serial number, validity period, issuer and Subject DN from the certificate. A database is required: without it the list is empty; the server returns up to the last thousand records, and search and paging are performed in the browser.

Exporting an evidence package for a session

A ZIP can be exported for any session: a text summary (room, time, reason for closing, full names, IIN, BIN, serial numbers) and the CMS signature files themselves with which the host and each viewer signed the connection. Certificate PEMs are not placed in the archive, although they are stored in the database; for sessions recorded before these fields existed, the archive contains only the summary.

A live view of a session in progress from the console

The organisation's administrator and auditor can open the stream of a session of their organisation in progress in the browser — with no request and no approval from the user, and nothing about it is shown on the workstation. It is video only, without control and without audio; every time it is opened is written to the audit log with who and when.

Recording policy by IIN and BIN

Three parameters: "record all sessions", a list of IINs and a list of BINs — a match on the host or on any connected viewer switches recording on, and the comparison is exact, with no masks and no groups. Each organisation has its own policy; recording is off as shipped (the flag cleared, both lists empty), and the page shows who last changed the policy and when.

Manual start and stop of recording for a specific room

The organisation's administrator can switch recording on or off for a session in progress, and that decision overrides the policy until the end of the session. Recording works only with a viewer connected and does not apply retroactively: nothing that happened before the button was pressed goes into the file.

A recording archive with roles separated

Recordings are grouped by session, played back right in the console and downloadable; the server converts finished captures to webm itself, while audio segments stay in the media server's original format and are not played back in the browser. The organisation's administrator deletes recordings; an auditor views and downloads but does not erase, and an operator sees only the recordings of their own sessions. Viewing, downloading and deleting are written to the audit log; there is no automatic cleanup, no quota and no retention period.

The platform: how this works on the server

What your information-security team will read: the checks, the time limits, the constraints and the honest boundaries.

Exactly what is verified in the signature

The server verifies the CMS signature itself, the certificate's validity period, the chain up to a trusted certificate authority, the validity period of the issuer's certificate and the revocation status over OCSP. The OCSP address of the national CA (ocsp.pki.gov.kz) is set in the code, an unreachable or unknown response leads to sign-in being refused, and the set of trusted CAs ships inside the build and is not extended through configuration.

The signature is bound to the action, the room and the session

What is signed is a structure with the kind of action, the room number, the session identifier, the time of issue and expiry and a random value; the server extracts the content from the CMS and compares it byte for byte with what it issued itself. A signature from another room or another moment is not accepted, and there are five minutes to sign.

A workstation is bound to the owner of a certificate

The first certificate to sign a sign-in on a machine becomes its owner; after that only registered owners are accepted — this workstation's host cannot be brought up with someone else's certificate — and a shared computer can have several owners. There is no self-service rebinding: a device can be released by the platform owner, or in the on-premise version by the organisation's administrator, and at present that is an API call — there is no screen for it in the console.

Access lifetimes

A workstation session lives for 12 hours and is extended by activity, on a drop there are two minutes to restore it, and the viewer's token for entering the room is valid for two minutes and is voided on first use. Alongside it a viewer API token is issued that is valid while the request is approved and is purged roughly forty minutes after it was created; the 12 hours are a build constant, not a setting.

Media server and TURN

Media rooms are created by the signaling server itself — private, with recording switched off and with changing that from a participant's side forbidden, and with a list of tokens admitted to enter; the media server does not start without an administration key, which only the signaling server holds. TURN credentials are issued only to an authorized party, but this is a single static pair from the configuration, shared by all clients, so rotating it is your operational task; relaying into private and reserved ranges is forbidden by the relay service's configuration.

The service channel is confined to the session's room

After sign-in a participant may relay only offer, answer and candidate; everything else is rejected. The server fills in the sender, session and role itself and does not route messages beyond the room. A silent connection is closed after 30 seconds, a participant who has disconnected has two minutes to return, after which the room and the media room are torn down.

Rate limits and device registration limits

From a single address: no more than 600 host sign-in starts per minute, 10 signatures pending at once and 200 first-time device registrations per hour; new registrations stop once 80 percent of the number space is filled, that is at 72,000 devices in one deployment. These are build constants counted by source address, so an office behind a single NAT shares one limit; there is no separate limit on creating viewer requests.

Log collection and search inside your perimeter

The signaling server, the media server, the console and TURN write structured logs, and the desktop applications' logs land there too, along with the workstation name, the operating system and the IP address. In the cloud version the logs go to a closed storage and search stack; in the on-premise version, to the server's system journal; access to the logs and their retention on your server are set by your own means.

Updating the desktop applications

The server can serve release manifests, but it signs nothing itself: signing is done offline, and the client checks the signature against a key embedded in its own build, so compromising the server does not make it possible to push code out to workstations. The feature is off by default and replies 404 until manifests are published on the server.

How a connection is put together

No step happens without a signature and the user's confirmation.

Workstation

The employee starts the session and signs in with a certificate. They decide who is let in, and can end it at any moment.

Server

Verifies both signatures, connects the two sides, routes the traffic, and keeps the session journal and the server-side recording.

Technician

Signs the connection request and receives the screen, control and files only after the user confirms.

Administrator console

Your organisation's supervision: active sessions, live view, the recording archive, recording policy and the audit log.

access after confirmation

How a session works

  1. The user starts the session

    The employee opens the application and presses "Start", signing the sign-in with their certificate in NCALayer. From that moment the workstation publishes the screen to your media server, and the connection card shows the permanent five-digit room number, which can be read out or copied.

  2. The technician signs a request

    The technician enters the room number and signs the request with their certificate. A request is registered only for a room where the application is already running and sign-in is complete, so every connection has a signatory behind it and not merely someone who learned the number.

  3. The user makes the decision

    A dialog with the technician's certificate details appears on screen. "Accept" opens access to the stream, control, clipboard and files; "Decline" closes the request. If this certificate was previously marked as trusted on the computer, approval is performed automatically.

  4. Working in the session

    The technician sees the screen, controls the mouse and keyboard, exchanges text through the clipboard and moves files in both directions over the same approved connection. While the user's application window is open, input is not carried out; after roughly five seconds without activity the window minimizes itself.

  5. Ending the session and the trace it leaves

    The "Stop" button closes all viewers, halts capture and closes the session on the server. Both parties remain in the session log with their certificate details, and the connection signatures can be exported as an archive; if the recording policy was on, the session lands in the recording archive as well.

What an information-security review will find

We describe the boundaries before the pilot, not after. Below is what is worth checking in the code and on a deployed stand.

Sign-in is signed, not typed in

The workstation and the technician sign in with a certificate signature through NCALayer; the server verifies the signature, the validity period, the chain up to a trusted CA and the revocation status. The revocation check requires access to the national CA's OCSP: without it, sign-in does not go through.

Approval constrains the technician, but not the console administrator

No support technician receives the stream, control or files without approval on the user's side, or without a certificate marked as trusted in advance. Your organisation's administrator and auditor are a separate case: in the console they can open a live view of a session of their organisation in progress with no approval and with no indication to the user. Every such view goes into the audit log, but console roles are still worth granting as strictly as access to surveillance tools.

The screen is published from the moment of "Start"

Capture and publishing begin when the user has pressed "Start" and completed sign-in, before any request from a technician appears; approval opens a viewer's access to a publication already in progress rather than starting the transmission. The media server in all this is yours — the stream goes through nodes you deployed.

Rooms and channels are confined

The service channel is confined to the session's room: messages and requests are not routed beyond it, and the sender and role are filled in by the server. The media room is private, entry is by the list of issued tokens; tokens remain in the list until the room is destroyed, and the room is destroyed once all participants have left it.

The public API surface is listed by name

The public part lists every available path explicitly and ends with a deny, and the site's files are listed one by one as well, so a new file in the static directory is not published by itself.

Console sign-in and the audit log

The console is entered with a digital signature; the role and the organisation are checked on the server on every request, the interface merely hides buttons, and the server does not find another organisation's objects at all. The audit log records sign-ins, invitations and role changes, policy changes, manual recording, live views, viewing, downloading and deleting recordings, and releasing a device binding — with the actor, their organisation and IP address. The administrator and the auditor see their own organisation's log.

Personal data and retention

Full names, IIN, BIN, IP addresses and certificate PEMs are stored in the sessions table and end up in the logs. The product currently has no means of automatic cleanup and no retention setting: which details are stored and for how long is determined by your data-processing rules and your own means on the database and log-storage side.

What runs on your infrastructure

The on-premise version is installed on your Ubuntu server by an installer. The application server ships as an executable with your organisation, licence term and number of concurrent sessions built in; the media layer, traffic routing, database and console run as services of the operating system. The installer adds the packages it needs, generates the services' secrets and asks for the administrator's IIN, the server name and the TLS certificate; network access and the certificate are your part.

  • Signaling server Digital-signature verification, console sign-in and authorisation of both parties, the session limit and licence term, the session lifecycle and the logs.
  • Media layer Receives the shared screen from the workstation, delivers it to approved participants, and performs server-side recording under the policy you set.
  • Traffic routing STUN and TURN for workstations behind NAT and firewalls.
  • Administrator console Web interface: members and roles, sessions, live view, the recording archive, recording policy and the audit log.
  • Data storage Database and volumes for recordings, logs and configuration. Capacity, backup and retention stay on your side.

Questions

Where are sessions, recordings and personal data physically stored?

Wherever you place the stack: in your deployment all components point at your addresses, and there is no vendor service in the scheme. The session log with certificate details sits in your database, recordings on your volume, technical logs in your log store. The product has no means of automatic deletion and no retention setting; that is done with your own means.

Who can see an employee's screen?

A support technician — only after approval on the user's side, or with a certificate the user themselves previously marked as trusted. Separately: your organisation's administrator or auditor can open a live view of a session of their organisation in progress in the console without approval, and nothing about it is displayed on the workstation. This is a standard oversight capability; every view is written to the audit log, and it is worth taking into account when granting roles.

Are sessions recorded by default?

No. As shipped the "record all sessions" flag is cleared, the IIN and BIN lists are empty, and the policy evaluates to "do not record". Recording is switched on by the organisation's administrator: for all sessions, by name through the IIN or BIN of one of the parties, or manually for a specific room in progress. Recording runs only while a viewer is connected to the workstation, and it does not apply retroactively.

Does the system work in a fully closed perimeter with no outside access?

Today, no — and it is better to know that before the pilot. All components run inside your network and NCALayer runs locally on the workstation, but the certificate revocation check reaches out to the national CA's OCSP at an address set in the code; if that address is unreachable, sign-in does not go through. A fully isolated deployment requires development work, not configuration.

What has to be installed on the workstation and on the technician's side?

The desktop application and NCALayer, on both sides. The applications are built for Windows and macOS; once installed, their windows are called "Remote Assistant - Host" and "Remote Assistant - Viewer". A permanently running background agent is not needed: until "Start" is pressed the application publishes nothing, and capture runs only while a session is running.

Is a VPN needed if workstations are behind NAT?

TURN is part of the stack, so workstations behind NAT and behind typical corporate firewalls usually connect without a separate VPN channel. With strict outbound traffic rules, proxy arrangements and traffic inspection, the required addresses and ports are agreed during rollout.

Can a workstation be connected to when the employee is not there?

No. A request is created only for a room where the user has already launched the application and completed digital-signature sign-in; a connection scenario without the user's participation is not supported.

What can be handed to the security team for a specific incident?

An archive can be exported for each session: a summary with the room, the time, the reason for closing and the details of both parties, plus the CMS signature files themselves with which the parties signed the connection. To that are added the session log and the audit log in the console, server and client logs and, if the recording policy was on, the recording file.

What happens if the workstation has no monitor?

The session continues: control, clipboard and file transfer work, and instead of a black screen the technician gets an explanation and a recommendation to connect a monitor or a dummy plug. One caveat: on Windows a disconnected monitor often leaves a phantom display, and the system then considers a display available while the technician sees a frozen picture with no explanation.

What languages is the interface in?

Kazakh, Russian and English — in the desktop applications and in the administrator console alike. Some service strings (the technical log, transfer queue statuses, window titles) remain in English, and a language change in the desktop applications applies fully after the window is reopened.

Pricing

You pay for concurrent technician sessions. Employees and workstations are not limited by the plan.

Start

For a small support team or a sole proprietor

15,000 ₸ per month, billed yearly 180,000 ₸ per year
18,000 ₸ per month billed every month

1 concurrent session

15,000 ₸ per session per month

18,000 ₸ per session per month

Get started
  • Unlimited employees, technicians and workstations
  • Digital-signature sign-in and access only with the employee's consent
  • Session log, recording and audit log
  • Administrator console with roles
Recommended

Team

For a support department with several technicians at work at once

60,000 ₸ per month, billed yearly 720,000 ₸ per year
72,000 ₸ per month billed every month

5 concurrent sessions

12,000 ₸ per session per month

14,400 ₸ per session per month

Get started
  • Unlimited employees, technicians and workstations
  • Digital-signature sign-in and access only with the employee's consent
  • Session log, recording and audit log
  • Administrator console with roles

Organisation

For an organisation with branches and its own IT service

150,000 ₸ per month, billed yearly 1,800,000 ₸ per year
180,000 ₸ per month billed every month

15 concurrent sessions

10,000 ₸ per session per month

12,000 ₸ per session per month

Get started
  • Unlimited employees, technicians and workstations
  • Digital-signature sign-in and access only with the employee's consent
  • Session log, recording and audit log
  • Administrator console with roles

Enterprise

For large organisations and installation on your own servers

On request from 8,000 ₸ per session per month

30 or more concurrent sessions

Discuss terms
  • Term and number of sessions to suit your organisation
  • The on-premise edition on your Ubuntu servers
  • Rollout support under contract

The first 14 days after the request is approved are free, with up to 2 concurrent sessions.

Prices are in tenge. What every plan includes and how to pay →

Connect your organisation to the platform

An organisation registers with a request that its administrator signs with their digital signature through NCALayer. The connection takes effect once the request is approved.

Register an organisation

Applications for the workstation and for the technician

The desktop applications are built for Windows and macOS: one for the employee being helped, the other for the support technician. A build is released with the server's address — the cloud platform's or, for the on-premise version, your own server's — so the client for the on-premise version is requested for a specific environment.

Request a build for your environment

Sign-in requires NCALayer running locally on the same computer: there is no other way to join a session in the desktop applications. The administrator console is entered with a digital signature too; technicians and auditors are invited by your organisation's administrator. Once installed, the windows are called "Remote Assistant - Host" and "Remote Assistant - Viewer".

See it on a live session

We are ready to show the system on a live session, go through the deployment scheme with your information-security team and support the launch of a pilot environment on your side. The scope and volume of work are defined by contract.

Email info@kaz-remote.online Phone +7 701 377 72 00
Call us Get in touch