AutomA Wiki

Bienvenue sur le site de documentaion du projet AutomA. Vous trouverez de nombreuses informations notamment les parties suivantes :

Guide Utilisateur qui vous aidera à prendre en main notre logiciel,
Documentation Développeur qui s’addresse aux développeurs et toute personnes voulant contribuer sur les projets Github,
Guide de déploiement qui vous aidera à installer notre logiciel.

Le projet

Ce projet s’adresse particulièrement mais non-exclusivement aux administrateurs systèmes et réseaux, au RSSI et à toutes personnes voulant améliorer la sécurité de ses infrastructures. Nous avons initié ce projet suite au constat que le durcissement de machines est chronophage dans de nombreuses entreprises et qu’il n’est pas toujours évident d’appliquer les règles de durcissement.

Ce projet est mis à disposition sous la licence MIT.

Les référentiels

L’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) est constituée d’experts et notamment d’experts en durcissement de systèmes d’exploitation. Nous avons alors choisi l’ANSSI comme premier référentiels pour écrire nos actions de durcissement. Bien évidemment, nous aimerions proposer d’autres référentiels tel le CIS. Si vous voulez proposer d’autres référentiels à ajouter, vous pouvez nous contacter à l’adresse mail automa.project@proton.me.

Contribuer

Vous pouvez contribuer au projet de plusieurs manières ! Vous pouvez :

donner des idées par mail et sur les discussions,
créer des actions de durcissement (voir Contribuer et Playbooks),
améliorer le code du serveur front/back (voir Contribuer et WebUI),
auditer les codes sur les dépôts AutomA-Playbooks et AutomA-WebUI.

Chapitre 1

1. Guide Utilisateur

Bienvenue sur AutomA, vous vous trouvez sur la documentation utilisateur qui vous explique comment utiliser notre logiciel. Ci-après l’ensemble des parties disponibles :

Pour toutes questions supplémentaires, vous pouvez nous contacter par mail ici : automa.project@proton.me

Premiers pas

AutomA est un projet de durcissement de système d’exploitation automatisé, basé sur les règles et les conseils de références dans le monde de la cybersécurité tel que l’ANSSI. Ce guide utilisateur à pour but de permettre la bonne prise en main de l’interface Web ainsi que la configuration du service SSH.

Sélection de l’environnement

Après avoir cliqué sur Start sur la page d’accueil, il vous sera demandé de sélectionner l’environnement des machines qui vont êtres concernées par le durcissement.

Information

Vous ne pouvez que durcir qu’un seul type d’environnement à la fois

Hôte

Il est nécessaire de renseigner les machines à sécuriser dans l’onglet HOST INVENTORY. Cet onglet permet de définir l’ensemble des machines à sécuriser.

Vous devez renseigner les informations suivantes :

Name : Un nom arbitraire unique de votre machine
IP : L’adresse IP de votre machine ou son FQDN (exemple : samba.local)
Port : Le port d’écoute du service SSH de votre machine
Connection Method : Vous avez le choix entre mot de passe et clef
Username : Le nom d’utilisateur pour la connexion SSH à votre machine
Auth : Le mot de passe ou le chemin d’accès à votre clef privée associée
Sudo Username : Le nom d’utilisateur pour l’élévation de privilège
Sudo Password : Le mot de passe de l’utilisateur ayant les droits d’administration

Ci-dessous, voici un exemple de configuration :

Il est possible de modifier les champs en cliquant dessus directement :

Génération des actions

Dans l’onglet HARDENING ACTION, une liste d’actions de durcissement est disponible. Ces règles sont classées selon :

La catégorie de la règle parmi les suivantes :
- KERNEL
- LOGGING
- MEMORY
- MONITORING
- NETWORK_STACK
- PACKAGE_MANAGEMENT
- PARTITIONING
- PERMISSIONS
- SERVICES
- USERS
Le niveau de recommandation de la règle
- MINIMAL
- INTERMEDIATE
- REINFORCED
- HIGH
Le révérenciel de la règle (ANSSI, NIST, etc …)

Il est possible de choisir une règle en cliquant dessus et en validant celle-ci :

Certaines règles demandent des informations supplémentaires de la part de l’utilisateur pour définir le comportement adapté.

Par exemple cette règle permet de faire des mise à jours automatiquement sur une fréquence que l’utilisateur peut choisir. Un menu déroulant apparait avec une liste de choix possibles :

Ici nous avons choisi monthly :

Lancement des actions

Une fois que la configuration est terminée, l’utilisateur doit générer sa configuration en cliquant sur le bouton GENERATE.

Il est ainsi possible de lancer les règles sur les machines configurées en appuyant sur le bouton RUN. Il est aussi possible de cliquer sur la flèche pour afficher le bouton DOWNLOAD, vous permettant alors de récupérer l’ensemble des fichiers pour les lancer manuellement.

Nous pouvons ainsi observer l’exécution des playbooks et des actions grâce à la génération de logs directement sur l’interface :

Configuration du SI

Nous utilisons Ansible pour propager les actions de durcissment, il est alors nécessaire d’ouvrir un port ssh pour qu’Ansible puisse y effectuer les actions nécessaires. Dans cette page, vous trouverez les informations nécessaire à la mise en place d’un serveur SSH sur une machine linux de type Debian 12.

Configuration du service SSH

Vérification du statut

La commande suivante permet de vérifier l’état du service OpenSSH :

sudo systemctl status ssh

Activation du service

Si le service est désactivé, la commande suivante permet de le lancer :

sudo systemctl start ssh

Service au démarrage

Sur la plus part des systèmes Linux, le service SSH se lance au démarrage. Si ce n’est pas le cas et que vous voulez obtenir ce comportement, la commande suivante permet de l’activer au démarrage de la machine :

sudo systemctl enable ssh

Configuration du service

Le fichier /etc/ssh/sshd_config permet de configurer le daemon SSH. Par défaut, le service s’exécute sur le port TCP/22.

Il est recommandé de :

Désactiver la connexion du compte root
Désactiver la connexion par mot de passe et préférer la connexion par clé
Désactiver l’écoute sur l’IPv6 si elle n’est pas utilisée
Désactiver le X11 Forwarding
Changer le port d’écoute (22 par défaut)

# OpenSSH config file
Port 50122 # Mettez le port que vous souhaitez
ListenAddress 0.0.0.0 # Ecoute sur l'IPv4

# Pour désactiver l'IPv6, vous devez avoir la ligne suivante commentée
#ListenAddress ::

PubkeyAuthentification yes
PermitRootLogin no
PasswordAuthentification no
PermitEmptyPassowrd no

X11Forwarding no

Génération des clés

Pour générer une paire de clés, SSH intègre la commande suivante :

ssh-keygen -t ecdsa -b 521 -f /home/user1/.ssh/id_ecdsa_debian12

Remarque

Il est fortement recommandé de protéger votre clef privée avec un mot de passe !

Cela permet de générer deux fichiers, id_ecdsa_debian12 qui contient la clé privée, et id_ecdsa_debian12.pub qui contient la clé publique. Ces deux fichiers sont stockés dans le dossier ~/.ssh.

Utilisation des clés

La clé privée de la machine est requise pour utiliser l’authentification par clé dans AutomA. Veuillez générer les clés sur la machine hébergeant AutomA et ajouter la clé publique correspondante dans le fichier ~/.ssh/authorized_keys de la machine concernée.

Pour mettre votre clef publique sur la machine distance, il existe plusieurs techniques :

SSH-COPY

Vous pouvez utiliser le binaire ssh-copy comme suit :

ssh-copy-id -i ~/.ssh/<your_key>.pub <username>@<ip_address> -p <port>

Cette technique ne fonctionne que si le serveur SSH accepte la connexion par mot de passe.

Clef USB

Vous pouvez copier votre clef publique sur une clef usb qui est maitrisée. Ensuite, sur la machine de destination, créer le dossier ~/.ssh et le fichier ~/.ssh/authorized_keys dans lequel vous copiez le contenu de la clef publique provenant de votre clef USB.

Il est nécessaire d’y appliquer les bonnes permissions.

chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/authorized_keys
chown -R user:user /home/user/.ssh

Chapitre 3

Référentiels

Vous trouverez dans ce chapitre, les informations concernant les référentiels actuellement utilisés ainsi que leur état d’avancement pour chaque environment. Ces pages vous propose des métriques permettant de vous exposer les avancés. Les métriques sont les suivantes :

Taux d’applicabilité : Expose le pourcentage d’actions de durcissement qui seront, à terme, disponibles dans AutomA pour une version d’un système d’exploitation. AutomA ne pouvant agir sur le durcissement matériel (exemple : BIOS/UEFI). Il peut y rester certaines inconnues d’où le troisième taux nommé ?.
Plateforme de test : Toutes les règles ne pouvant être testées sur un docker, nous exposons ici les pourcentages de tests possible sur docker. Les tests se font sur machine virtuelle lorsque docker ne peut être utilisé.
Taux de couverture : Ce taux espose le pourcentage d’actions effectuées pour un référentiel et une version d’un système d’exploitation donnés.

Information

Les métriques Plateforme de test et Taux de couverture sont effectuées sur l’ensemble des recommandations sur lequel nous avons enlevé les règles non-applicables.

Le référentiel Recommandations de sécurité relatives à un système GNU/Linux de l’ANSSI ⇨ici⇦

ANSSI - Linux

Dernière mise à jour : 8 décembre 2023

Debian 12

Applicabilité

%%{
    init: {
        "theme": "base",
        "themeVariables": {
            "pie1": "#b6d7a8",
            "pie2": "#e06666",
            "pie3": "#ffe599"
        }
    }
}%%
pie title Taux d'applicabilité dans AutomA
    "OUI" : 49
    "NON" : 11
    "?" : 20

Vous trouverez ci-dessous la liste des règles non-applicables :

Numéro	Niveau	Nom
R1	Renforcé	Choisir et configurer son matériel
R2	Intermédiaire	Configurer le BIOS/UEFI
R3	Intermédiaire	Activer le démarrage sécurisé UEFI
R4	Elevé	Remplacer les clés préchargées
R28	Intermédiaire	Partitionnement type
R64	Renforcé	Configurer les privilèges des services
R65	Renforcé	Cloisonner les services
R66	Elevé	Durcir les composants de cloisonnement
R76	Elevé	Sceller et vérifier l’intégrité des fichiers
R77	Elevé	Protéger la base de données des scellés
R78	Renforcé	Cloissoner les services réseau

Plateforme de test

%%{
    init: {
        "theme": "base",
        "themeVariables": {
            "pie1": "#674ea7",
            "pie2": "#ff00ff",
            "pie3": "#d9d9d9"
        }
    }
}%%
pie title Répartition plateforme de test
    "Docker" : 6
    "VM" : 2
    "?" : 61

Couverture

%%{
    init: {
        "theme": "base",
        "themeVariables": {
            "pie1": "#4285f4",
            "pie2": "#ffff00",
            "pie3": "#00ff00"
        }
    }
}%%
pie title Taux de couverture du référentiel
    "À Faire" : 60
    "En cours" : 1
    "Fait" : 8

Fichiers

Vous trouverez l’ensemble des fichiers qui contiennent les données présentées.

Fichiers d’avancement

anssi.debian.12.json

Chapitre 2

2. Documentation Développeur

Vous trouverez deux grandes parties dans cette documentation, la première traite de la gestion et création des playbooks, la deuxième partie, quand à elle, traite de l’architecture logiciel et du code concernant le serveur front/back.

Première partie : automa-playbooks
Deuxième partie : automa-webui

Chapitre 1

AutomA Playbooks

Introduction

Ce chapitre traite de la documentation sur la partie des playbooks et des questions pour l’ensemble des recommendations mise à disposition des utilisateurs. Vous trouverez le projet AutomA-Playbooks sur github ainsi que la démarche à suivre pour contribuer sur le projet dans la partie Contribuer.

Arborescence

L’arborescence du dépôt github se découpe selon la forme suivante :

└── KERNEL
    └── OS
        └── VERSION
            ├── CATEGORY
            │   ├── REFERENCE
            │   │   └── LEVEL
            │   │       └── RXX_ACTION_NAME
            │   │           ├── playbook.yml.j2
            │   │           └── questions.yml
            │   └── REFERENCE2
            │       └── LEVEL2
            │           └── CXX_ACTION_NAME2
            │               ├── playbook.yml.j2
            │               └── questions.yml
            ├── CATEGORY2
            │   └── REFERENCE
            │       └── LEVEL
            │           └── RXX_ACTION_NAME3
            │               ├── playbook.yml.j2
            │               └── questions.yml
            └── CATEGORY3
                └── REFERENCE2
                    └── LEVEL
                        └── RXX_ACTION_NAME4
                            ├── playbook.yml.j2
                            └── questions.yml

A la date du 30 novembre 2023, le projet ressemblait à l’arborescence suivante :

└── LINUX
    └── DEBIAN
        └── 12
            ├── KERNEL
            │   └── ANSSI
            │       └── 1_INTERMEDIATE
            │           └── R11_CONFIGURE_YAMA_LSM
            │               ├── playbook.yml.j2
            │               └── questions.yml
            ├── NETWORK_STACK
            │   └── ANSSI
            │       └── 1_INTERMEDIATE
            │           └── R13_DISABLE_IPV6
            │               ├── playbook.yml.j2
            │               └── questions.yml
            ├── PACKAGE_MANAGEMENT
            │   └── ANSSI
            │       └── 0_MINIMAL
            │           └── R61_PERFORM_REGULAR_UPDATES
            │               ├── playbook.yml.j2
            │               └── questions.yml
            ├── PERMISSIONS
            │   └── ANSSI
            │       ├── 0_MINIMAL
            │       │   └── R54_ACTIVATE_STICKY_BIT
            │       │       ├── playbook.yml.j2
            │       │       └── questions.yml
            │       └── 3_REINFORCED
            │           └── R36_CHANGE_UMASK_VALUE
            │               ├── playbook.yml.j2
            │               └── questions.yml
            └── USERS
                └── ANSSI
                    └── 0_MINIMAL
                        └── R30_DISABLE_UNUSED_USER_ACCOUNTS
                            ├── playbook.yml.j2
                            └── questions.yml

Nous avons réfléchis et choisi cette structure de dossier pour permettre une meilleure intégration des futures règles et environnements de durcissement. Le principe de cette structure légèrement conséquente est de permettre une meilleure modularité du projet.

Vous voulez contribuer au projet en ajoutant des règles de durcissement pour windows serveur 2022 ?

Vous devez créer l’arborescence (si inexistance), ici /WINDOWS/SERVER/2022/. Ensuite, vous devez créer la structure suivante selon les actions de durcissement que vous voulez ajouter. De manière générique, voici les dossiers à créer (dans l’ordre) :

CATEGORY : Le nom de la catégorie dans laquelle la règle de durcissement s’inscrit. Il est possible que des actions de durcissements puissent être dans plusieurs catégories. Dans ce cas, choississez la catégorie dans laquelle cela serait le plus logique mais en cas de questionnement, vous pouvez ouvrir une issue sur le projet Github ou par mail à automa.project@proton.me.
REFERENCE : Le référentiel dans lequel l’action de durcissement est tirée. Nous basons la globalité de nos actions sur les recommandations de l’ANSSI mais il est possible d’utiliser d’autres référentiels tel que le CIS.
LEVEL : Ce dossier est tiré du système de niveau de l’ANSSI dans son guide de Recommandations de sécurité relatives à un système GNU/Linux. Dans ce guide, ils proposent une grille de niveaux de durcissement qui permet donc de situer le niveau de l’action de durcissement. Il est nécessaire de bien choisir le niveau de durcissement des règles de durcissements pour permettre une meilleure segmentation et expérience utilisateur. Les niveaux possibles sont les suivants :
- 0_MINIMAL
- 1_INTERMEDIATE
- 2_REINFORCED
- 3_HIGH
HARDENING_ACTION : Le nom de l’action de durcissement précédé d’un identifiant non-nécessairement unique. Dans le cas des Recommandations de sécurité relatives à un système GNU/Linux, l’identifiant est constitué d’un R suivi d’un nombre, par exemple R30. Le but étant de garder la même nomenclature pour un même référentiel.

Lorsque vos dossiers sont créés, il ne manque plus deux fichiers playbook.yml.j2 et questions.yml. Le contenu de ces fichiers sera décrit dans les parties playbook.yml.j2 et questions.yml.

Tester les playbooks

Les playbooks une fois créés doivent être testé pour vérifier la bonne conformité de l’action de durcissmenent. Pour simplifier le processus, nous mettons à disposition des containers Dokcer permettant alors de tester les playbooks. Chaque environment doit avoir son propre container à la bonne version. Par exemple même si Debian 11 et Debian 12 sont proches en terme de fonctionnement, il en reste néanmoins nécesseraire de séparer les deux versions en deux images dockers différentes.

Remarque

Il est probable que certaines actions de durcissement ne peuvent pas être testées sur un environnement containeurisé. Il sera nécessaire alors d’effectuer les tests sur une machine virtuelle.

Images Docker existante

Vous trouverez les images dockers ici. Il sera uniquement nécessaire d’effectuer un pull.

Images Docker manquante

Faire une requête

Vous pouvez nous envoyer une demande par mail ou ouvrir une issue ou une discussion sur le Github d’AutomA.

Créer l’image

Dans cette partie, nous traiterons l’exemple pour une image de Debian 12, cependant le processus restera identique quel que soit l’environment que vous contenairiser.

Prérequis

La liste ci-après décrit l’ensemble des composants nécessaires pour la création d’une image :

python3
python3-pip
python3-venv
sshpass

ensuite effectuer les commandes :

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install ansible-core

Dockerfile

Dans un fichier nommé Dockerfile :

FROM debian:12

RUN apt-get update -y && \
    apt-get install openssh-server sudo python3 -y

RUN sed -i "s/#PermitRootLogin prohibit-password/PermitRootLogin Yes/" /etc/ssh/sshd_config

RUN useradd -m -s /bin/bash user && \
    echo 'user:password!' | chpasswd && \
    echo 'root:password!' | chpasswd && \
    service ssh restart

EXPOSE 22

CMD ["/usr/sbin/sshd", "-D"]

Pour créer votre image : docker build -t automa-debian12 . (N’oubliez pas le point à la fin de la commande !)

Dès que la commande est terminée, vous pouvez instancier votre image en container :

docker run -d -p 2222:22  --name debian-ssh-container automa-debian12

Fichiers nécessaires

inventory.yml

Ce fichier donne la configuration de notre container à Ansible.

all:
  hosts:
    docker-debian12:
      ansible_host: 127.0.0.1
      ansible_port: 2222
      ansible_user: user
      ansible_password: password!
      ansible_become: yes
      ansible_become_method: sudo
      ansible_become_user: root
      ansible_become_password: password!

playbook.yml

Le fichier playbook est celui qui sera donnée à Ansible pour qu’il puisse appliquer une règle sur le container. En voici un exemple :

---
- name: "Disable unused user accounts"
  hosts: "all"

  tasks:

    - name: "List all users"
      ansible.builtin.getent:
        database: "passwd"
        split: ":"
      register: "all_users"

    - name: "Disable user"
      ansible.builtin.user:
        name: "{{ item }}"
        state: "absent"
      with_items: "{{ all_users.ansible_facts.getent_passwd }}"
      when:
        - item not in ['root','user','_apt','sshd']

Tester !

Vous pouvez lancer la commande suivante :

python3 -m ansible playbook -i inventory.yml -l all playbook_example.yml -vvv

Fichier playbook.yml.j2

Les playbooks sont des modèles Jinja de playbooks Ansible. Cela nous permet de rendre les playbooks en fonction des paramètres définis par l’utilisateur.

Exemple

---
- name: "R30_Disable_User"
  hosts: "all"

  tasks:

    - name: "Disable user"
      ansible.builtin.user:
        name: {% raw %}"{{ item }}"{% endraw %}
        state: "absent"
      with_items: "{{ used_users }}"

Cette règle mélange le rendu AutomA jinja et le rendu Ansible jinja. La variable used_users est celle fournie par le questions.yml, elle sera donc codée en dur dans le playbook. Pour la variable item, elle est entourée de balises jinja raw pour forcer l’absence de rendu de cette variable par le moteur de rendu AutomA car c’est une variable rendue par Ansible.

Fichier questions.yml

Cette page contient les spécifications des types de variable utilisés dans les template jinja de playbook.

Exemple

---
id: "The ID of the rule"
title: "The title of the Rule"
description: "The description of the rule"
author: "The author name"
last_modified: "MM/DD/YYYY of the corresponding last modifiction"
tags:
  - "Tag1"
  - "Tag2"

questions:
  - title: "The first value to fill"
    name: "The name of the variable to render with this result"
    required: "A boolean to say if the value can be None or not"
    type: "One of the defined types"
    value: "None by default, the value filled by this question"

  - title: "The first value to fill"
    name: "The name of the variable to render with this result"
    required: "A boolean to say if the value can be None or not"
    type: "One of the defined types"
    value: "None by default, the value filled by this question"

### EXAMPLE ###
---
id: "R42"
title: "This rule is an example"
description: "You will answer a famous question: what is the life answer ?"
author: "aiglematth"
last_modified: "10/24/2023"
tags:
  - "life"
  - "answer"

questions:
  - title: "What is the answer of the life ?"
    name: "life_answer"
    required: yes
    type: "u8"
    value:

  - title: "Are you sure of your answer ?"
    name: "are_you_sure"
    required: yes
    type: "bool"
    value:

Types

Type	Description
`str`	Simple chaine de caractères
`list<x>`	Liste de type x
`choice<x>[y1,y2,...]`	Liste de choix y1, y2, … de type x

Contribuer

Objectif

Ce document a pour objectif de proposer une procédure à suivre pour développer sur le projet AutomA. Cette procédure s’applique que vous soyez interne ou externe au projet.

Procédure

A - ISSUE

Quelque soit le dépôt github sur lequel vous voulez travailler, vous devez créer une issue en y mettant les éléments nécessaires. L’issue doit impérativement être rédigée en anglais. Prenons le cas suivant : vous voulez effectuer une nouvelle recommandation de l’ANSSI par exemple la recommandation R30, voici les champs à remplir :

Champ	Contenu
Titre	[Make-Rule] R30 - Disable unused user accounts
Commentaire	Todo : questions.yml + playbook.yml From : ANSSI Rule : 30 Level : Minimal

De plus si vous êtes dans le projet, vous devez rajouter :

Champ	Contenu
Assignés	la ou les personnes qui travaillent dessus
Labels	[TODO]+[enhancement]
Projet	Kanban (penser à mettre en TODO sur le projet dès que créée)

B - BRANCHE

Cas : Vous travaillez sur le dépôt source du projet

Depuis la page de l’issue, vous pouvez créer une branche de développement associée à celle-ci. Un simple clic sur “Créer une branche” permet de faire afficher une pop-up qui demande plusieurs informations. Vous n’avez pas besoin de changer les informations par défaut.

Vous avez maintenant une branche pour développer ! N’oubliez pas de changer de branche (sur vscode un clic en bas à gauche). Voici les commandes à faire dans votre terminal :

# Pour récupérer les modifications du dépôt, notamment la nouvelle branche
git fetch --all
# Changer de branche de développement
git checkout <nom_de_votre_branche>
# Vérifier
git branch --show-current

Cas : Vous travaillez sur un fork du projet

Vous devez forker le projet sur votre compte, cela vous permettra d’obtenir les droits pour modifier le code. Une fois sur votre dépôt, vous pouvez soit directement développer sur votre branche main ou créer des branches auxiliaires comme nous faisons sur le dépôt officiel.

C - FUSION

Se mettre à jour

Cas : Vous travaillez sur le dépôt source du projet

Avant de demander à pousser vos modifications sur la branche principale, vous devez vous assurez que vous n’écraserez pas le travail des autres contributeurs. Pour se faire, vous devez dans un premier temps mettre à jour votre branche au même niveau que la branche main.

Depuis votre branche de développement, effectuer les commandes suivante (dans l’ordre):

git checkout <votre_branche_de_developpement>
git fetch
git merge origin/main
# Gestion de conflits sur votre branche
# (en ligne de commande ou via votre IDE) 
git push

Cas : Vous travaillez sur un fork du projet

Vous devez ajouter le dépôt officiel en remote supplémentaire.

git remote add source <url_depot>

Mettre à jour votre branche :

git pull source <votre_branche_de_developpement>

Vous devez gérer les conflits qui peuvent subvenir tout en veillant à ne pas casser le code déjà existant. Votre dépôt local est maintenant à jour, il faut mettre à jour votre dépôt distant :

git push

Effectuer la demande de fusion

Depuis l’interface web de github, vous pouvez effectuer une “pull-request” pour fusionner votre branche à la branche main. Lorsque le nombre de relecteurs correspond au nombre minimun, vous pourrez valider la fusion.

Chapitre 3

3. Guide de déloiement

Vous trouverez les étapes pour installer AutomA sur votre système d’information. Avant d’expliquer, ces étapes, nous aimerions présenter quelques aspect d’AutomA qui ont un impact sur son installation. AutomA est :

Hors-Ligne : AutomA est prévu pour fonctionner sans connexion à internet, il est alors possible de déployer notre logiciel sur tous vos systèmes d’informations.
Sans-Agent : AutomA utilise Ansible pour fonctionner et donc utilise ssh, aucun agent n’est installé sur vos machines. Seule votre machine d’administration est nécessaire.
Exportable : AutomA permet d’exporter ses configurations pour les appliquer sur d’autres systèmes d’informations. Cela permet par exemple d’installer AutomA sur une machine ayant internet pour profiter des dernières mise à jour tout en déployant les configurations sur d’autre systèmes d’informations.

Installation Manuelle

Etape 1 - Prérequis

La liste des logiciels requis pour installer AutomA :

git
python3 (>3.9)
pip3
un navigateur web à jour

Etape 2 - Téléchargement du dépôt

Grâce à git, clonez le dépôt du projet :

git clone https://github.com/Autom-A/AutomA-WebUI.git

Un fois effectué, il est nécessaire de télécharger les playbooks :

cd AutomA-WebUI
git submodule update --init --recursive

Etape 3 - Téléchargement des dépendances

Le projet a besoin de quelques dépendances python3 :

ansible-runner
Flask
flask-core
jinja2
pyyaml

Pour les télécharger, exécutez la commande suivante :

pip3 install -r requirements.txt

Etape 4 - Lancer le projet

Il suffit de lancer la commande suivante :

python3 src/main.py

Puis ouvrez votre navigateur et tapez dans la bar d’adresse http://localhost:9123 (avec la configuration par défaut).

AutomA Wiki

Le projet

Les référentiels

Contribuer

Sous-sections de AutomA Wiki

1. Guide Utilisateur

Sous-sections de 1. Guide Utilisateur

Premiers pas

Sélection de l’environnement

Hôte

Génération des actions

Lancement des actions

Configuration du SI

Configuration du service SSH

Vérification du statut

Activation du service

Service au démarrage

Configuration du service

Génération des clés

Utilisation des clés

SSH-COPY

Clef USB

Référentiels

Sous-sections de Référentiels

ANSSI - Linux

Debian 12

Applicabilité

Plateforme de test

Couverture

Fichiers

2. Documentation Développeur

Sous-sections de 2. Documentation Développeur

AutomA Playbooks

Introduction

Arborescence

Sous-sections de AutomA Playbooks

Tester les playbooks

Images Docker existante

Images Docker manquante

Faire une requête

Créer l’image

Prérequis

Dockerfile

Fichiers nécessaires

inventory.yml

playbook.yml

Tester !

Fichier playbook.yml.j2

Exemple

Fichier questions.yml

Exemple

Types

Contribuer

Objectif

Procédure

A - ISSUE

B - BRANCHE

Cas : Vous travaillez sur le dépôt source du projet

Cas : Vous travaillez sur un fork du projet

C - FUSION

Se mettre à jour

Cas : Vous travaillez sur le dépôt source du projet

Cas : Vous travaillez sur un fork du projet

Effectuer la demande de fusion

3. Guide de déloiement

Installation Manuelle

Etape 1 - Prérequis

Etape 2 - Téléchargement du dépôt

Etape 3 - Téléchargement des dépendances

Etape 4 - Lancer le projet