Ubuntu for bank dev employees [fermé]

Existe-t-il des processus et des méthodes documentés sur la façon d'exécuter des ordinateurs Ubuntu personnalisés (de l'installation à l'utilisation quotidienne) pour les banques et autres entreprises qui ne souhaitent pas que les utilisateurs téléchargent des fichiers binaires à partir d'emplacements potentiellement non sécurisés?

Alors que apt-get, mise à jour, etc. se produisent à partir de quelques emplacements Internet ou intranet fiables?

Mise à jour: ajouté ceci après la première réponse. Ces utilisateurs sont des supporteurs, des utilisateurs novices de systèmes et des développeurs de logiciels bancaires ... donc certains d'entre eux ont besoin des privilèges sudo. Existe-t-il un moyen prêt de les surveiller afin que toutes les exceptions soient détectées rapidement (comme l'ajout de la liste des sources), mais d'autres actions telles que l'installation de choses à partir de dépôts connus ne sont pas signalées.

L'objectif est d'être sécurisé, d'utiliser Ubuntu ou une version, de permettre aux développeurs et autres utilisateurs de sudo d'être aussi productifs que possible. (Et réduire la dépendance aux ordinateurs Windows et Mac)

.2. Et les informaticiens peuvent dédier la stratégie aux utilisateurs afin qu'ils ne puissent pas faire certaines actions comme partager un dossier, même si vous êtes utilisateur sudo? Une solution complète?

C'est une très bonne question, mais sa réponse est très difficile.

Tout d'abord, pour commencer, @Timothy Truckle a un bon point de départ. Vous exécuteriez votre propre référentiel apt où votre équipe de sécurité pourrait vérifier chaque package. Mais ce n'est que le début.

Ensuite, vous souhaitez implémenter des groupes. Vous viseriez à ce que les utilisateurs puissent faire les choses dont ils ont besoin sans beaucoup d'aide de l'assistance. Mais dans le secteur bancaire, vous voulez vraiment que les choses soient bloquées. En fait, dans de nombreuses structures d'entreprise, vous souhaitez verrouiller les choses. Ainsi, l'octroi de privilèges sudo aux utilisateurs normaux à n'importe quel niveau est probablement supprimé.

Ce que vous feriez probablement, c'est de régler les choses de sorte que certains groupes n'aient pas besoin d'autorisations élevées pour faire leur travail.

Encore une fois, dans la plupart des environnements d'entreprise, l'installation de logiciels est quelque chose qui peut vous faire virer, c'est donc un non non. Si vous avez besoin d'un logiciel, vous appelez le service informatique et ils le font pour vous, ou il existe une chaîne de demande ou quelque chose du genre.

Idéalement, vous n'auriez jamais besoin d'un employé normal pour installer quoi que ce soit ou vous auriez jamais besoin d'autorisations élevées.

Maintenant, pour les développeurs, la question est un peu différente. Peut-être qu'ils ont besoin d'installer et peut-être qu'ils ont besoin de sudo. Mais leurs boîtiers sont sur le "réseau de danger" et ne peuvent JAMAIS se connecter directement aux systèmes critiques.

Le personnel IT / Support aura besoin de sudo. Mais vous pouvez limiter l'accès sudo par commande, ou par processus (paperasse) ou par d'autres moyens. Il peut y avoir des volumes entiers sur des choses comme le "principe des 2 yeux" et comment le mettre en œuvre. Mais les journaux d'audit existent et peuvent être configurés pour répondre à la plupart des besoins.

Revenons donc à votre question. La réponse de Timothy Truckle est 100% correcte, mais la prémisse de votre question est éteinte. Sécuriser un système d'exploitation Linux consiste beaucoup plus à choisir les paramètres nécessaires à votre cas d'utilisation spécifique, et moins à une idée générale de la façon de sécuriser les choses.

Configurez votre propre proxy de référentiel debian dans votre intranet.

Personnalisez l'installation d'ubuntu pour que votre proxy de référentiel debian soit la seule entrée dans /etc/apt/sources.list.

Et voila: vous avez un contrôle total sur le logiciel installé sur vos clients (tant qu'aucun utilisateur ne dispose des autorisations de super utilisateur).

Mise à jour: ajouté ceci après la première réponse. Ces utilisateurs sont des supporteurs, des utilisateurs novices de systèmes et des développeurs de logiciels bancaires ... donc certains d'entre eux ont besoin des privilèges sudo. Existe-t-il un moyen prêt de les surveiller afin que toutes les exceptions soient détectées rapidement (comme l'ajout de la liste des sources), mais d'autres actions telles que l'installation de choses à partir de dépôts connus ne sont pas signalées.

Dans votre installation personnalisée, vous pouvez modifier le /etc/sudoersfichier afin que vos utilisateurs soient autorisés à s'exécuter sudo apt updateet sudo apt installaucune autre commande ne commençant par apt. Bien sûr, vous devez également restreindre sudo bash(ou tout autre shell).

Dans presque tous les magasins que j'ai vus jusqu'à présent, les développeurs avaient un accès complet aux machines de développement, mais ces machines n'avaient accès qu'à Internet et au référentiel de code source.

Le code source est archivé et compilé sur des machines de confiance (sur lesquelles les développeurs n'ont généralement pas ou n'ont pas besoin d'autorisations administratives), puis déployé à partir de là pour tester les systèmes qui ont accès au réseau interne.

Que ces machines soient utilisées par les développeurs ou par une équipe de test distincte dépend de votre organisation - mais généralement la frontière entre les machines approuvées et non approuvées se situe entre les machines distinctes, avec l'interface entre elles vérifiable (comme les validations de code source).

Les employés de la réception ne bénéficient jamais de privilèges administratifs. Lorsque nous avons déployé Solitaire sur toutes ces machines, les plaintes concernant cette politique ont quasiment cessé.