TM1 Forum

Dear community,

with all that discussions about development I wonder if this the right place for some operations questions.

Being responsible for a corporate TM1 installation to be shared among diverse business functions/developers groups I am investigating how I could isolate models from each others.
I understand many installations were operated by business functions initiatially. Local admin rights for developers didn't worry anybody and many operations implemented with plain os batch files.

At the moment, any developer could write a TI-process, create and call a local batch with "format d:", TM1 service needs to run with admin user privileges.

I am aware there is some situations where a remote call of another server or a copy operation is necessary, but I want to setup them explicitly as admin, not leave it to the developers.

Is there someone else facing similar challenges and can give advice?
Any idea or best practice is much appreciated.

Regards
Aralos

The easiest way to isolate models is going to be run TM1 on separate VM instances for each of the user bases. This way you can give rights out separately and not worry about stuff you give one group affecting the others. Definitely more work on your part but not too bad. Anything less is going to be patchwork and probably above your skill level (the fact that you are asking this in this forum indicates you don't know all that's involved, sorry.)

tomok wrote:The easiest way to isolate models is going to be run TM1 on separate VM instances for each of the user bases.

That would increase costs a lot. IBM licensing is based on PVU counts and multiple instances can hardly be sized to a reasonable cost impact.
Standard operations could be cloned, but any change would require touching not one but multiple instances.

tomok wrote: Anything less is going to be patchwork and probably above your skill level (the fact that you are asking this in this forum indicates you don't know all that's involved, sorry.)

No worries, I will have experienced TM1 developers available for anything you suggest.
But to be honest, they didn't deal with security measures at all so far.

so any elements of the patchwork you have in mind?

Actually, we designed a component "RPC Dispatcher" that is used for any remote call without the need to use neither PSExec nor local login rights.
Outgoing calls are registered in a secure model/cube and calling models/users only can trigger assigned entries.

But still missing an inspiration to overcome local batch calls.

Hi Aralos

I don't think this issue is unique to TM1. A rogue developer can write DISKFORMAT D: in pretty much any programming language.

However, let us look at the worst case scenario. A developer writes this code and hides it so that it is not detected in UAT. The code gets promoted to PRD and runs there. A days work is lost. The system is recovered from backups or the DR site. The developer gets sacked. What did he really gain? We have all heard of cases where someone has done this but it is rare. Most developers who fall out with their company just go to another job, without doing anything destructive.

TM1 systems are typically not mission critical ie they are financial reporting and planning systems, not trading systems or life support systems.

Some people's approach to risk management is to try to avoid all risks. However, if I remember my lectures on risk management correctly, I think that the approach should be to try to balance the cost of avoiding/minimising the risk against the likelihood of the risk occurring and the cost, should the risk materialise.

Possible things to minimise the risk are:

a) Limit the scope of the user id under which the TM1 Service runs to files on the local machine. That limits the potential for any damage. Any files that need to arrive on the machine can be downloaded into a designated folder using a different user id that has access to the outside world. The same applies to files that need to be moved off to other machines. Another approach is to move data by writing to a relational database and ensuring that the user id that TM1 uses to access the relational database only has access to stored procedures and therefore what these stored procedures do can be controlled by people other than the TM1 developers.

b) Usual practice of having at least DEV, UAT, and PRD environment. If the developers can only amend code in DEV, then anything that gets to PRD has at least been tested in UAT. Of course, any rogue developer could easily ensure that the error does not materialise in UAT, which goes back to my original point. However, it should help to avoid genuine errors getting into PRD rather than deliberate malware. However, adopting this approach does require additional licenses, hardware, and the development of a promotion mechanism. A basic file copy while the service is shutdown is not too difficult. It is important to check that the service really has stopped as this can take a while if TM1 is writing data to disk. It is a little harder to then be able to run processes to complete the promote once the service is restarted, but I have got this to work.

Regards

Paul Simon

aralos wrote:

tomok wrote:The easiest way to isolate models is going to be run TM1 on separate VM instances for each of the user bases.

That would increase costs a lot. IBM licensing is based on PVU counts and multiple instances can hardly be sized to a reasonable cost impact.

Specific response on your licensing point. You can adjust the VM's to reflect your PVU count. eg if you have an 8 core physical server rated at 560 PVU's running 3 instances, you could transfer that to 3 VM instances, one with 4 cores and 2 with 2 cores ( assume same processor type). Subject to complying with IBM guidelines, there would be no extra costs.
Would there be a performance impact? That will depend on your models and how they are used so will be difficult to assess.

Also, I completely agree with Paul Simon's points about assessing risk vs costs. We often get asked by prospects about hot backups and failover. This is normally by IT departments who don't understand the technology and the application but are merely applying "Corporate policy". The reality is that the vast majority of TM1 applications are not mission critical and do not require this.

paulsimon wrote:I don't think this issue is unique to TM1. A rogue developer can write DISKFORMAT D: in pretty much any programming language.

I totally agree. And I am not worried too much about developers compromising the system by purpose.

paulsimon wrote: a) Any files that need to arrive on the machine can be downloaded into a designated folder using a different user id that has access to the outside world. The same applies to files that need to be moved off to other machines.

My first thought was, whenever a developer wants to load files from an external server, he should create a share there, not on the TM1 server, and grant access rights to the system user, TM1 is running.
But I guess it makes a difference if bandwidth is occupied only for the copy operation or for a complex time-consuming data processing.

paulsimon wrote:Another approach is to move data by writing to a relational database and ensuring that the user id that TM1 uses to access the relational database only has access to stored procedures and therefore what these stored procedures do can be controlled by people other than the TM1 developers.

Interesting idea, but reading huge data (some GBs) from a BLOB would take too long.

paulsimon wrote: b) Usual practice of having at least DEV, UAT, and PRD environment....However, adopting this approach does require additional licenses, hardware, and the development of a promotion mechanism.

Yes, we have those environments and take into account additional costs.
I am curious about the promotion mechanisms you have in mind. Obviously it would be nested between stop/restart of service. Process steps could be

1. review change - scan for "executecommand" etc, to be replaced by calls to admin-model/process:BATCH-CALLER
2. copy files from uat to prod

Do you think, that "BATCH-CALLER" is feasible? We successfully implemented an "RPC Dispatcher" for any outgoing remote procedure calls already, so I guess local batch calls could be triggered the same way.

Thanks a lot for your time, Simon!
Your considerations partly confirmed mine, partly inspired some new for me!

if you are going to insist on running all the instances on the same logical server, at a minimum I would do the following:

1) Create a separate Windows account for each of the TM1 server services you intend to run.
2) Create a separate folder for each of the TM1 services.
3) Give rights to the service account in step 1 to only the folder created in step 2 (and make sure all the objects and files for that service stay under that parent folder).
4) Do not give any of the service accounts admin rights on the box (this may require some additional work to determine the exact rights needed)

This should protect any TI called from Server A by "accidentally" messing with Server B and vice versa. Also, taking away admin rights should protect from the format :d type scenario.

tomok wrote:1) Create a separate Windows account for each of the TM1 server services you intend to run.

We have to run all server services with the same account to enable single-signon with reporting tools (TM1 Web + cubus EV) running on another server with the same account.

I think of creating a share for each server/developers group, so at least I can hinder them from writing to the wrong folder, but running their TI processes they still could read from "wrong" folders.
At the moment I think of a TI process in an admin model, registering valid combinations model/share and check any incoming request and execute on a match.

I am aware they still could bypass that and do direct calls, but I could easily scan for those and tell them about the proper method..