2.10 Security

2.10 Security

In this lesson: you will be able to manage users and roles, manage the gateway's TLS certificate, and use remote support access responsibly.

Security is part of commissioning

You are deploying a system that controls a real building and sits on a customer's network, so security is part of commissioning, not an afterthought. Three areas: users and roles, TLS, and remote support.

Users and roles

The gateway has four roles that build on each other. A Viewer can only look. An Operator adds writing setpoints and placing overrides. A Technician adds programming controllers — the role you have been using in this track. An Admin adds everything, including managing users and viewing the audit log. Give people the least role that lets them do their job: operators get Operator, not Admin. On handover, create the customer's own accounts and change the default admin password — a factory-fresh gateway ships as admin / admin, and leaving that in place is the single most common security lapse. Every significant action is written to an audit log, so who-changed-what is always answerable.

TLS

The web interface should be served over HTTPS, not plain HTTP, so credentials and data are not sent in the clear. The gateway can generate its own self-signed certificate to get you encrypted immediately, and it supports installing a proper certificate as well — you manage this on the TLS settings page. When the page is loaded over HTTPS, the live-data WebSocket automatically upgrades to the secure form too, so there is nothing extra to configure there.

Remote support

When you (the integrator) or OpenBMCS support need to reach a gateway that is not directly accessible, the gateway can open a time-limited, outbound support tunnel — the customer stays in control because it is initiated from the device and it expires. It is the safe alternative to poking holes in the customer's firewall. Turn it on only when support is needed, and let it close itself.

Handover checklist

Bring it together: real accounts created with least-privilege roles, the default admin password changed, HTTPS on with a certificate in place, and remote support left off until it is needed. Do those four and you have handed over a system that is secure by default.

Key points

• Four roles build up: Viewer (read-only) → Operator (setpoints/overrides) → Technician (programming) → Admin (user management + audit log).
• Give everyone the least role for their job; every significant action is written to the audit log.
• On handover, create the customer's own accounts and change the admin / admin default.
• Serve over HTTPS/TLS (self-signed or installed cert); the live WebSocket upgrades to secure automatically.
• The remote support tunnel is device-initiated (outbound) and time-limited — leave it off until needed.

Check your understanding

1. List the four roles from lowest to highest, and what each adds.
2. Name two things you must do on handover for security.
3. Why serve the interface over HTTPS/TLS rather than HTTP?
4. What makes the remote support tunnel safer than opening a firewall port?