RS5 Interface and Config db must be common for all deployed Instances?

Forum Home Forums Understanding the Software RS5 Interface and Config db must be common for all deployed Instances?

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #15234
    Sergei
    Participant

    Hi.
    I have several instances in a project and deploy them to different remote scada machines.

    I’m worried about deploying the instances to different machines on different locations due to the fact the Users table seems to be common for all instances.

    Say I have the following instances and users for each
    useradmin
    Instance A
    usera1
    usera2
    Instance B
    userb1
    userb2

    When I upload the project to each instance server, ALL users are uploaded to each server, so userb1 and userb2 can log into the Instance A server. Solely the Rights table limits them to access the Instance A interface..

    BUT if they login, they will get an Instance B interface instead, although with no data or with errors, depending on whether the A machine has the required plugins or so.

    Furthermore, this architecture seemingly forces me to set unique Server, Agent, Communicator and WebStation passwords for ALL instances, be it the Default instance or remote ones.

    Besides this, uploading all interfaces to each Instance should be pretty unnecessary, inefficient and time consuming, imho.

    All the former is weird behavior and a potential security risk considering unwanted and unneeded user credentials and plant information (diagrams, panels, signal info, etc) is uploaded and stored in non-related machines at all times. Is there a way to avoid all or some of these issues? (especially the unique password for system accounts and limit the list of users uploaded to each instance)

    Thanks in advance.

    #15236
    manjey73
    Participant

    You have one Server database. Instances are required in the current version for remote Communicators.
    If you need different Server databases, you should have several projects, not one.

    #15239
    Mikhail
    Moderator

    Hi,

    In Rapid SCADA 5, user passwords that stored in the database are not encrypted, which is not safe for the described architecture.

    In Rapid SCADA 6, only password hashes are stored in the Users table. So it’s safe to spread the table to several instances. It’s not possible to restore a password from its hash. Users can login to another server, but they have no access to views and other functions.

    #15240
    Mikhail
    Moderator

    Specify the object filter in the deployment profile to skip unnecessary channels and views when upload. I suggest to check the actually uploaded files on the target server.

    #15241
    Mikhail
    Moderator

    Probably, it’s technically possible to filter users that have custom roles based on an object filter (version 6, in the future).

    Yes, you need different passwords or different secret keys for application accounts that belong to different instances.

    #15242
    Mikhail
    Moderator

    Despite the high isolation between instances, do you collect data on a central server?
    Do remote users connect to their local and the main servers?

    #15244
    Sergei
    Participant

    Do remote users connect to their local and the main servers?

    Indeed yes. For our and our clients’ OT networks security and efficiency on the use of bandwidth and machine resources, our remote Scada machines are mostly intended for data collecion and transmission to the central server. In fact in most of our architectures, these remote Scadas are located within an OT infrastructure, behind segregated VLAN’s and isolated from TI infrastructure (safe from the VPN tunnels that connect RapidGates and the central server). Users cannot access these remote machines, which are mostly Raspberry Linux servers without WebStation or interface hosting and connected to cloud server via limited bandwidth available on the field (3G or even microwave links).

    #15255
    Mikhail
    Moderator

    If remote Raspberries belong to the same client organization, it’s OK to send the user table with password hashes (v6).
    If they are different customers, may be consider using different main servers for them, or create separate projects and then merge into the main project in order to hide other client’s configuration.

    #15256
    Sergei
    Participant

    or create separate projects and then merge into the main project in order to hide other client’s configuration.

    How is this carried out? Haven’t even thought this was possible. The different projects reside in the central server?

    #15263
    Mikhail
    Moderator

    This discussion may contain sensitive information. So email the details of the system architecture and what services based on Rapid SCADA do the end customers pay for. It helps me to find the best solution.

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.