Question

6

Ubuntu for bank dev employees

rated 0 times [ 6] [ 0] / answers: 1 / hits: 2878 / 3 Years ago, sat, may 29, 2021, 11:40:13

Are there processes and methods documented on how to run custom Ubuntu computers (from install to every day usage) for banks and other businesses that do not want users to download binaries from possibly insecure locations?

So that apt-get, update etc happen from only a few trusted internet or intranet locations?

Update : Added this after the first answer. These users are support, novice users of systems and developers of the bank software... so some of them need sudo privileges. Is there a ready way to monitor them so that any exceptions are caught quickly (like adding the sources list) but other actions like installing stuff from known repos goes unreported.

Aim is to be secure, use Ubuntu or a flavour, allow deveopers and other sudo users to be as productive as possible.
(And reduce dependence on Windows and Mac computers)

.2. And the IT folks can dicate policy to users so they can't do some actions like share a folder, even if sudo user? A complete solution?

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

cheeturage

Add To Favorites

Follow

Total Points: 432

Total Questions: 111

Total Answers: 115

Location: Bahrain

Member since Tue, Mar 1, 2022

2 Years ago

answered 3 Years ago edgehogight · Accepted Answer

This is a very good question, but it's answer is very difficult.

First, in order to start off @Timothy Truckle has a good starting point. You would run your own apt repo where your security team could verify every package. But that's just the start.

Next you would want to implement groups. You would aim to have users be able to do the things they need to without much help from support. But in banking you really want things locked down. In fact in many corporate structures you want to lock things down. So granting normal users sudo privileges at any level is probably out.

What you would probably do is set things so that certain groups didn't need elevated permissions to do their jobs.

Again, in most corporate environments installing software is something that can get you fired, so that's a no no. If you need software you call IT and they do it for you, or there's a requisition chain or some such.

Ideally you would never need a normal employee to install anything or ever need elevated permissions.

Now for Developers the question is a bit different. Maybe they need to install and maybe they need sudo. But their boxes are on the "danger network" and can NEVER connect directly to critical systems.

IT/Support staff will need sudo. But you can limit sudo access by command, or process (paperwork) or other means. There can be whole volumes about things like the "2 eyes principal" and how to implement it. But audit logs exist and can be configured to meet most needs.

So, back to your question. Timothy Truckle's answer is 100% correct, but the premise for your question is off. Securing a Linux OS is a lot more about choosing the settings that is needed for your specific use case, and less about a general idea how to secure things.