Ubuntu pour les employés de la banque
Existe-t-il des processus et des méthodes documentés sur la manière d’exécuter des ordinateurs personnalisés Ubuntu (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’endroits potentiellement non sécurisés?
Pour que apt-get, update, etc se produisent à partir de quelques sites Internet ou intranet de confiance?
Mise à jour: ajouté après la première réponse. Ces utilisateurs sont des utilisateurs du support, des utilisateurs novices des systèmes et des développeurs du logiciel bancaire… certains d'entre eux ont donc besoin des privilèges de Sudo. Existe-t-il un moyen rapide de les surveiller afin que toutes les exceptions soient rapidement détectées (comme l'ajout de la liste des sources), mais d'autres actions, telles que l'installation d'éléments provenant de dépôts connus, ne sont pas signalées.
L'objectif est d'être en sécurité, d'utiliser Ubuntu ou une variante, de permettre aux développeurs et aux autres utilisateurs de Sudo d'être aussi productifs que possible. (Et réduire la dépendance vis-à-vis des ordinateurs Windows et Mac)
.2. Et les informaticiens peuvent attribuer des règles aux utilisateurs afin qu'ils ne puissent pas effectuer certaines actions telles que le partage d'un dossier, même si l'utilisateur est Sudo? Une solution complète?
C'est une très bonne question, mais sa réponse est très difficile.
Premièrement, 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 paquet. Mais ce n'est que le début.
Ensuite, vous souhaitez implémenter des groupes. Vous voudriez que les utilisateurs puissent faire les choses dont ils ont besoin sans beaucoup d'aide de la part du support. Mais dans le secteur bancaire, vous voulez vraiment que les choses soient verrouillées. En fait, dans de nombreuses structures d'entreprise, vous souhaitez verrouiller les choses. Donc, accorder des privilèges aux utilisateurs normaux de Sudo à n'importe quel niveau est probablement annulé.
Ce que vous feriez probablement, c’est d’arranger les choses de sorte que certains groupes n’ont pas besoin d’autorisations élevées pour effectuer leur travail.
Encore une fois, dans la plupart des environnements d’entreprise, l’installation de logiciels peut vous renvoyer, c’est donc un non. Si vous avez besoin de logiciels, vous appelez le service informatique et ils le font pour vous, ou il existe une chaîne de réquisition ou autre.
Idéalement, vous n’auriez jamais besoin d’un employé normal pour installer quoi que ce soit, ni 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 informatique/support aura besoin de Sudo. Mais vous pouvez limiter l’accès à Sudo par commande, processus (paperasserie) ou d’autres moyens. Il peut y avoir des volumes entiers sur des choses comme le principe "2 yeux" et la façon de le mettre en œuvre. Mais les journaux d'audit existent et peuvent être configurés pour répondre à la plupart des besoins.
Donc, revenons à votre question. La réponse de Timothy Truckle est correcte à 100%, mais la prémisse de votre question est erronée. 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 sécurité des choses.
Configurez votre propre proxy du référentiel Debian dans votre intranet.
Personnalisez l'installation d'ubunt afin que votre proxy de référentiel Debian soit la seule entrée de /etc/apt/sources.list.
Et voila: vous avez le contrôle total sur les logiciels installés sur vos clients (tant qu'aucun utilisateur ne dispose des autorisations super utilisateur).
Mise à jour: ajouté après la première réponse. Ces utilisateurs sont des utilisateurs du support, des utilisateurs novices des systèmes et des développeurs du logiciel bancaire… certains d'entre eux ont donc besoin des privilèges de Sudo. Existe-t-il un moyen rapide de les surveiller afin que toutes les exceptions soient rapidement détectées (comme l'ajout de la liste des sources), mais d'autres actions, telles que l'installation d'éléments provenant de dépôts connus, ne sont pas signalées.
Dans votre installation personnalisée, vous pouvez modifier le fichier /etc/sudoers afin que vos utilisateurs soient autorisés à exécuter Sudo apt update et Sudo apt install mais aucune autre commande 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 ne disposent généralement pas d'autorisations administratives ou sur lesquelles elles ont besoin d'autorisations administratives), puis déployé pour tester les systèmes ayant 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 les machines non approuvées se situe entre des machines distinctes, leur interface étant vérifiable (telle que les validations de code source).
Les employés de la réception ne bénéficient d'aucun privilège administratif. Lorsque nous avons déployé Solitaire sur toutes ces machines, les plaintes concernant cette politique ont quasiment cessé.