The easiest way to penetrate any company currently is to bribe or extort an employee with access to provide the information.
I assume "staff theft" is used to describe this pattern.
The only way to combat this is to assume everyone is a potential exploiter.
This, in turn, leads to sensible business practices where you do not have a single customer table exposed to your IoT server at all (for client verification purposes), and instead the IoT server only knows about client IDs and what level of service that ID is entitled to.
Most employees have no access to the customer/payment database; only those involved in payments have, and they need to be monitored for financial security anyway.
I don't think this will lead to a workable situation.
You mean, you think implementing sensible business practices requires actual experience and knowledge of how to do secure systems, and thus is too costly in your opinion? That kind of thinking is exactly why so many peoples' personal details and credit card information has been "accidentally leaked".
People from this call center will need to be able to look at payment status and be able to change the state of the subscription quickly in order to keep customers happy.
Sure. They have very limited access to the customer/payment database. In that database, any change to the service status must trigger a related push to the IoT server within a guaranteed service interval, and here that could be seconds, say one minute maximum to see the server response change.
When you break this down to an operator level, you can easely see if a call center employee is handing out too many freebees or not.
That kind of thing is easily monitored automatically, and is not an actual problem in real life.
I'm not sure whether having seperated databases is a good idea. Lots of synchronisation issues.
There is no synchronization. There is exactly one direction in which changes are pushed, and enforcing this is crucial for the security model. If you have synchronization issues doing this you should not be doing anything with databases.
Even having the IoT server be technically capable of querying the customer/payment database for details instantly breaks the security model. Separated databases are required for true privilege separation. If the IoT server is technically able to access the customer information, then the customer information will be exfiltrated in the very first break of the IoT server. In my opinion, any company that does that should get heavy penalties when that happens.
Security models that survive in the real world are those that do not assume every part in the model is secure. They still provide security, albeit in degraded/reduced form, when invididual parts are compromised. There are single point failure sources, like the customer/payment database implementation; minimizing both their number and access/exposure to them is at the core of proper security design.