J'ai besoin d'aide pour définir un plan de sécurisation de mes activités.
Comme je ne suis qu'un simple utilisateur qui ignore presque tout de ce qui se cuisine en arrière-boutique,
j'aborde le problème de mon point de vue,
c'est à dire "superficiellement" au sens propre (en restant à la surface du système).
Mes investigations et cogitations me conduisent au concept suivant :
Étant donné que :
- Les solutions de types antivirus ont toujours une guerre de retard.
- Que tous les rempares sont potentiellement contournables.
- Sûre
- Non-Sûre
Cette zone n'a qu'un seul accès vers l'extérieur : APT uniquement vers les dépôts stable Debian.
La zone "Non-Sûre" étant le reste du monde,
ce qui inclue les partitions pouvant recevoir des données venant de l'extérieur.
Bien sûr les mesures de durcissement "classiques" :
- Cloisonnement, c'est l'idée de base
- Minimisation de la surface
- Moindres privilèges
- Mots de passe forts et bien gérés
- Pare-feu
- AppArmor
- Firejail
- Discipline et bonnes pratiques de l'utilisateur (unique)
Par "sereinement" j'entends sans crainte de compromettre le(s) serveur(s) via un poste de travail lui-même compromis.
Je ne l'ai pas déjà précisé,
mais le poste de travail et le(s) serveur(s) sont sous Debian stable
et n'utilisent que des paquets paquets provenant de main
sauf firmwares non-free incontournables.
Cela peut se résumer par ce schéma :
Mon premier questionnement :
Cette approche vous semble-t-elle soutenable ?
Mon second questionnement :
Comment mettre cela en place simplement et efficacement ?
Pour isoler les usages sûrs / risqués,
j'ai envisagé l'usage de 2 utilisateurs "Trusty" et "Risky" sur le poste de travail.
Trusty étant en fait l'utilisateur classique
et
Risky un "sous-utilisateur" : le pendant de root à moindres privilèges.
Dans cette conception Trusty utiliserait : $ su Risky
pour des interactions avec la zone "non-sûre" ou l'extérieur,
de la même manière qu'il utilise su - pour les tâches d'administration système.
Mais sans savoir vraiment pourquoi,
cela ne me semble pas pleinement satisfaisant,
j'ai la sensation d'une complication supplémentaire et inutile.
Autres pistes envisagées :
- Qubes OS a été testé et jugé pour lourd au niveau des ressources et pas très pratique à l'usage.
- Docker => Conteneurs plus adaptés à des applications serveur qu'à des applications graphiques dans un environnement de Bureau.
en utilisant firecfg pour généraliser l'usage des bacs à sable,
mais cela, par défaut, restreint drastiquement les accès.
P.ex:
Geany (mon éditeur favori) n'a plus accès qu'à ${HOME} et encore partiellement.
Et je ne suis pas parvenu à désactiver ou à surcharger la configuration par défaut,
afin de l'adapter à mes besoins.
Voilà, je sens confusément que ça coince quelque-part,
et j'espère que vos remarques me permettront de préciser la voie à suivre.
Notez que ce questionnement devrait aussi concerner la majorité des utilisateurs.
Je suis même un peu surpris que ce sujet ne soit pas le standard N°2 des tutos "Tous publics" après :
"Comment installer son système ..."
Merci.
