Control of employee access to cloud servers
One of the challenges is to define the access boundary for the employees of the company providing the service.
In general, it can be very useful if support engineers can perform certain actions with the cloud server - reboot, connect / disconnect disks, access the console, etc.
However, this causes understandable concerns. And what are they (and round-the-clock support service, that is, “they” are not two or not five people) they look at the console of my server without asking? And if I have a password there or any other information that I don’t want to disclose?
Original in the selectk corporate blog
')
Thus, there is a contradiction between the two good wishes. We add that in spite of the rather strict policy of manipulating the client servers (only after a direct confirmation of the wish in the ticket), there is still a shadow of doubt. The human factor (dispersion or malice) may well violate any corporate policy.
Technical equipment works best in such situations.
I think this picture will explain more than all the following words:
We have provided the user with the ability to manage these permissions himself. On the newly created cloud server, they are: Engineers are forbidden
Engineers are allowed by default to view the console. Some problems manifest themselves on the console (for example, kernel messages with a priority of KERN_ERROR and higher are displayed there). This allows you to quickly answer the question “what is wrong” given in the ticket.
All these nuances can be changed. Permissions are used for this. For each of them, you can set the expiration date (at least an hour, at least indefinitely). You can also disable viewing the console.
For the convenience of interaction, support staff can send an action request. The client receives the following request:
If you click "allow", then the permissions will be set for the specified time, and then they will expire. If you click "ignore", the request will be rejected. Issuing and requesting permissions is recorded in the transaction log of the virtual machine.
Just in case there is no misunderstanding: robots use their own interface, in which user permissions and prohibitions do not work. If the robot detects that the money has run out, it will turn off the cloud server, regardless of whether there is permission or not. Alas.
I hope people trust the robots more than the people.
In general, it can be very useful if support engineers can perform certain actions with the cloud server - reboot, connect / disconnect disks, access the console, etc.
However, this causes understandable concerns. And what are they (and round-the-clock support service, that is, “they” are not two or not five people) they look at the console of my server without asking? And if I have a password there or any other information that I don’t want to disclose?
Original in the selectk corporate blog
')
Thus, there is a contradiction between the two good wishes. We add that in spite of the rather strict policy of manipulating the client servers (only after a direct confirmation of the wish in the ticket), there is still a shadow of doubt. The human factor (dispersion or malice) may well violate any corporate policy.
Technical equipment works best in such situations.
I think this picture will explain more than all the following words:
We have provided the user with the ability to manage these permissions himself. On the newly created cloud server, they are: Engineers are forbidden
- change settings
- delete / reinstall the cloud server
- view the root password and enter anything in the console
Engineers are allowed by default to view the console. Some problems manifest themselves on the console (for example, kernel messages with a priority of KERN_ERROR and higher are displayed there). This allows you to quickly answer the question “what is wrong” given in the ticket.
All these nuances can be changed. Permissions are used for this. For each of them, you can set the expiration date (at least an hour, at least indefinitely). You can also disable viewing the console.
For the convenience of interaction, support staff can send an action request. The client receives the following request:
If you click "allow", then the permissions will be set for the specified time, and then they will expire. If you click "ignore", the request will be rejected. Issuing and requesting permissions is recorded in the transaction log of the virtual machine.
Just in case there is no misunderstanding: robots use their own interface, in which user permissions and prohibitions do not work. If the robot detects that the money has run out, it will turn off the cloud server, regardless of whether there is permission or not. Alas.
I hope people trust the robots more than the people.
Source: https://habr.com/ru/post/166211/
All Articles