Meilleures pratiques de sécurité des serveurs Linux

La première étape après avoir créé un Linux® Cloud Server consiste à définir la sécurité sur celui-ci. Vous devez effectuer cette étape cruciale sur chaque serveur pour empêcher les mauvais acteurs d'obtenir un accès indésirable. Cette action se traduit par un environnement plus sécurisé qui permet d'éviter que vous et votre entreprise ne soyez compromis. L'exécution de ces étapes de base et le renforcement de la sécurité sur votre serveur découragent les mauvais acteurs et les font passer à une nouvelle cible.

Gestion des utilisateurs

Par défaut, l'utilisateur root est créé en tant que premier utilisateur sur chaque système Linux. Vous devez le désactiver via Secure Shell (SSH). La désactivation de cet utilisateur root via SSH rend plus difficile pour un mauvais acteur d'accéder au système. Étant donné que l'utilisateur root est créé par défaut sur chaque serveur Linux, les acteurs malveillants disposent déjà de la moitié des informations dont ils ont besoin pour se connecter à votre serveur si l'utilisateur root est activé via SSH. Cette situation permet des attaques SSH par force brute jusqu'à ce que le hachage du mot de passe se brise.

Pour éviter cette situation, vous devez créer un utilisateur secondaire lorsque vous devez vous connecter et administrer le système. Chaque utilisateur final du système doit avoir ses propres identifiants de connexion à des fins de journalisation. Selon les actions que l'utilisateur final doit effectuer, il peut avoir besoin de sudo l'autorisation d'effectuer des actions administratives. Cette section fournit des exemples sur la façon d'ajouter un utilisateur avec l'autorisation sudo sur les systèmes basés sur Debian® et Red Hat® Enterprise Linux.

Consignes de sécurité des mots de passe

Avant de créer des utilisateurs, assurez-vous d'utiliser des mots de passe forts qui nécessitent une longueur de caractères minimale (et peut-être même inclure des dates d'expiration). Voici les lignes directrices communes préconisées par les partisans de la sécurité des systèmes logiciels :

Utilisez un mot de passe d'une longueur minimale de 12 à 14 caractères, si autorisé.
Inclure des lettres minuscules et majuscules, des chiffres et des symboles, si autorisé.
Générez des mots de passe de manière aléatoire, si possible.
Évitez d'utiliser le même mot de passe pour plusieurs utilisateurs, comptes ou systèmes logiciels.
Évitez les répétitions de caractères, les modèles de clavier, les mots du dictionnaire, les séquences de lettres ou de chiffres, les noms d'utilisateur, les noms de parents ou d'animaux, les liens romantiques (actuels ou passés) ou les informations personnelles (par exemple, les numéros d'identification, les noms d'ancêtres ou les dates).
Évitez d'utiliser des informations qui sont ou pourraient devenir publiquement associées à l'utilisateur ou au compte.
Évitez d'utiliser des informations dont les collègues ou connaissances de l'utilisateur pourraient savoir qu'elles sont associées à l'utilisateur.
N'utilisez pas de mots de passe composés de composants faibles.

Ajouter un utilisateur (système d'exploitation Debian et Ubuntu)

Pour les systèmes d'exploitation Debian et Ubuntu®, ajoutez un utilisateur en suivant ces étapes :

Créez un nouvel utilisateur et définissez son mot de passe :

useradd {nom d'utilisateur}passwd {nom d'utilisateur}
Donnez au nouvel utilisateur sudo autorisations pour les opérations privilégiées sur le système. Cet utilisateur est l'utilisateur principal pour se connecter à distance et apporter des modifications au serveur.

Utilisez l'une des méthodes suivantes pour implémenter sudo autorisations pour l'utilisateur.

un. Exécutez la commande suivante pour ajouter l'utilisateur au admin groupe d'utilisateurs.
```
usermod -aG admin {username}
```
Alternativement, vous pouvez modifier les sudoers fichier pour donner à l'utilisateur sudo autorisations.

un. Exécutez la commande suivante en tant qu'utilisateur root pour modifier la liste des autorisations utilisateur :
```
visudo
```
Remarque : Sur certaines distributions, les systèmes utilisent le vi éditeur de texte pour visudo . Parce que vi n'est pas un éditeur convivial, vous devrez peut-être consulter un didacticiel vi pour obtenir de l'aide.

b. Ajoutez la ligne suivante directement après la ligne contenant root ALL=(ALL:ALL) ALL :
```
{username}     ALL=(ALL:ALL) ALL
```
c. Enregistrez et quittez.
Passez au nouvel utilisateur et testez ses autorisations en utilisant sudo pour exécuter une commande nécessitant un accès root, telle que la commande suivante :
```
su {username}
sudo systemctl status sshd
```
Une invite vous demande de saisir le mot de passe du nouvel utilisateur pour vérification avant d'exécuter la commande.
Vous pouvez également vérifier que votre utilisateur peut s'élever à la root compte en exécutant la commande suivante :
```
 sudo -i
```

Si vous effectuez ces étapes correctement, votre utilisateur a maintenant sudo accéder et peut élever les autorisations. S'il n'est pas exécuté correctement, vous obtenez un message indiquant que l'utilisateur n'est pas dans les sudoers filelorsque vous tentez de vous authentifier.

Ajouter un utilisateur (Red Hat et CentOS)

Pour les systèmes d'exploitation Red Hat et CentOS®, ajoutez un utilisateur en suivant ces étapes :

Créez un nouvel utilisateur avec adduser et définissez le mot de passe de l'utilisateur avec passwd :
```
useradd {username}
passwd {username}
```
Donnez au nouvel utilisateur sudo autorisations pour les opérations privilégiées sur le système. Cet utilisateur est l'utilisateur principal pour se connecter à distance et apporter des modifications au serveur.

Utilisez l'une des méthodes suivantes pour implémenter sudo autorisations pour l'utilisateur.

un. Exécutez la commande suivante pour ajouter l'utilisateur à la wheel groupe
```
usermod -aG wheel {username}
```
Alternativement, vous pouvez modifier les sudoers fichier pour donner à l'utilisateur sudo autorisations.

un. Exécutez la commande suivante :
```
visudo
```
Remarque : Sur certaines distributions, l'éditeur de texte que le système utilise pour visudo est vi . Parce que vi n'est pas un éditeur convivial, vous devrez peut-être consulter un didacticiel vi pour obtenir de l'aide.

b. Ajoutez la ligne suivante directement après la ligne contenant root ALL=(ALL:ALL) ALL :
```
{username}     ALL=(ALL)       ALL
```
c. Enregistrez et quittez.
Passez au nouvel utilisateur et testez ses autorisations en utilisant sudo pour exécuter une commande nécessitant un accès root :
```
su {username}
sudo systemctl status sshd
```
Une invite vous demande de saisir le mot de passe du nouvel utilisateur pour vérification avant d'exécuter la commande.
Vous pouvez également vérifier que votre utilisateur peut s'élever à la root compte en exécutant la commande suivante :
```
 sudo -i
```

Si vous avez effectué ces étapes correctement, votre utilisateur a maintenant sudo accéder et peut élever les autorisations. S'il n'est pas exécuté correctement, vous obtenez un message indiquant que l'utilisateur n'est pas dans les sudoers filelorsque vous tentez de vous authentifier.

Générer une paire de clés SSH

Pour une méthode de connexion plus sécurisée que l'utilisation d'un mot de passe, créez une paire de clés SSH avec l'utilisateur que vous avez précédemment créé. Ces instructions fonctionnent avec n'importe quelle distribution Linux.

Remarque : Ces instructions concernent les postes de travail Linux et macOS®. Si vous vous connectez à partir d'un bureau Windows®, suivez les instructions de Générer des clés RSA avec SSH PUTTY et Connectez-vous avec une clé privée SSH sous Windows pour générer et ajouter la paire de clés SSH.

Exécutez la commande suivante pour générer une paire de clés sur votre local Ordinateur Linux ou Mac® :
```
ssh-keygen -b 4096 -t rsa
```
Lorsque vous êtes invité à enregistrer la clé, utilisez l'emplacement par défaut. L'ajout d'un mot de passe est facultatif et plus sûr, mais peut être gênant.

Cette opération crée deux fichiers. Les noms par défaut sont id_rsa pour votre clé privée et id_rsa.pub pour votre clé publique.
Après avoir créé la paire de clés sur votre ordinateur local, téléchargez la clé publique sur votre serveur distant pour l'utilisateur que vous avez créé précédemment.

Avertissement : Assurez-vous de télécharger le public clé, et pas la clé privée.
```
ssh-copy-id -i ~/.ssh/id_rsa.pub {username}@{remotePublicIPAddress}
```
Connectez-vous au serveur distant en utilisant ssh {username}@{remotePublicIPAddress} et exécutez la commande suivante pour vérifier qu'aucune clé supplémentaire inattendue n'a été ajoutée :
```
cat .ssh/authorized_keys
```

À ce stade, vous avez ajouté ssh-key et l'authentification par mot de passe pour l'utilisateur. La section suivante décrit les étapes facultatives de désactivation de l'authentification par mot de passe.

Configuration du démon Linux SSH

Maintenant que vous avez un nouvel utilisateur avec sudo autorisations et une paire de clés SSH, vous pouvez travailler avec la configuration du démon SSH (serveur) pour améliorer la sécurité.

Remarque : Pour les clients Managed Operations et RackConnect uniquement : Pour garantir que nos systèmes automatisés ont accès à votre serveur en cas de besoin, nous vous demandons de ne pas modifier la configuration SSH et de passer à la section suivante. Lors de la connexion à votre serveur, l'équipe Rackspace Support se connecte en tant qu'utilisateur rack et utilise l'authentification par mot de passe sur le port 22. En outre, la reconstruction de serveurs existants ou la construction d'un nouveau serveur à partir d'un instantané nécessite que vous activiez les connexions root en définissant le PermitRootLogin option sur yes . Si vous avez besoin de modifier ces valeurs, parlez à un membre de votre équipe d'assistance Rackspace afin que la modification soit effectuée d'une manière qui n'affecte pas notre capacité à vous fournir une expérience Fanatical ™.

Les exemples de commandes pour le reste de l'article supposent que vous êtes connecté en tant que votre nouvel utilisateur, en utilisant sudo pour effectuer des opérations privilégiées.

Options de configuration SSH

Cette section couvre les options courantes du fichier de configuration SSH qui aident à améliorer la sécurité. Ces informations sont utilisées pour configurer votre pare-feu ultérieurement.

Cette section ne présente que quelques options à modifier et décrit ce qu'elles font. Pour plus de détails sur les autres options de configuration, consultez la documentation OpenSSH.

Cette section se concentre sur les options suivantes :

Port XX :Cette option est le port sur lequel le démon SSH écoute (port 22 par défaut).
PermitRootLogin :Ce drapeau active (oui) ou désactive (non) la connexion root via SSH. Par défaut, cette ligne est commentée et autorise la connexion root.
PubkeyAuthentication :Ce drapeau active (oui) ou désactive (non) les clés SSH pour l'authentification. Par défaut, cette ligne est commentée et autorise ssh-key accès.
PasswordAuthentication :Cet indicateur active (oui) ou désactive (non) l'authentification par mot de passe. Par défaut, cette option est activée.

SSH utilise le port 22 par défaut pour la communication. Les mauvais acteurs essaient le port 22 avec le nom d'utilisateur root sur chaque serveur qu'ils attaquent. Pour cette raison, la désactivation de l'utilisateur root via SSH et la modification de SSH pour écouter sur un port non standard permettent d'éviter une violation.

Changer le port n'arrêtera pas un intrus déterminé, mais cela fait que la plupart des analyses superficielles des opportunités de connexion SSH négligent votre serveur. De même, la suppression de l'accès SSH pour l'utilisateur root interfère avec les attaques occasionnelles par force brute via SSH.

Vous devez également réfléchir à la méthode d'authentification à utiliser lors de la connexion. Par défaut, tous les systèmes Linux utilisent l'authentification par mot de passe. Il existe plusieurs façons d'effectuer l'authentification sur le serveur, mais les deux principales consistent à utiliser un mot de passe et des clés SSH.

Les clés SSH sont générées par paires, l'une publique et l'autre privée, et vous ne pouvez les utiliser qu'en combinaison les unes avec les autres. Vous devez stocker la clé privée dans un emplacement sûr sur l'ordinateur à partir duquel vous vous connectez, et vous ne devez jamais la donner. Vous pouvez donner la clé publique, et c'est la clé que vous placez sur le serveur auquel vous vous connectez. La clé privée sur votre ordinateur local exécute un algorithme lorsque vous établissez une connexion, accordant l'accès si le hachage de la paire de clés correspond à la clé publique.

Modifier sshd_config

À ce stade, vous avez ajouté un nouvel utilisateur avec sudo autorisations, créé une paire de clés SSH et téléchargé votre clé SSH publique. Vous pouvez maintenant modifier votre fichier de configuration SSH pour améliorer votre sécurité. Pour ce faire, vous pouvez modifier SSH pour écouter sur un port personnalisé, restreindre la connexion root via SSH, activer l'authentification par clé publique et désactiver l'authentification par mot de passe en procédant comme suit :

Ouvrez le fichier de configuration du démon SSH pour le modifier :
```
sudo vim /etc/ssh/sshd_config
```
Modifiez les lignes suivantes :

Remarque :Par défaut, le Port et PermitRootLogin les lignes sont commentées comme indiqué par le # symbole. Lorsqu'elles sont commentées, ces lignes sont lues comme options par défaut, même si des modifications sont apportées à la ligne. Pour implémenter ces modifications, vous devez décommenter les lignes associées en supprimant le # symbole au début de la ligne associée. De plus, avant de désactiver PasswordAuthentication assurez-vous que vous avez configuré une clé SSH ou vous ne pouvez pas vous connecter au serveur.

Modifier :
```
#Port 22
#PermitRootLogin yes
PasswordAuthentication yes     
```
À :
```
Port 2222
PermitRootLogin no
PasswordAuthentication no
```
Remplacer 2222 avec le port que vous souhaitez utiliser. Assurez-vous que le nouveau port n'est pas déjà utilisé par un autre programme en utilisant netstat.

Important : Comme mentionné précédemment, vous ne devez pas apporter cette modification au sshd_config si votre serveur dispose d'un niveau de service Managed Operations. Ces modifications pourraient empêcher Rackspace d'accéder à votre serveur.
Testez la configuration SSH modifiée pour détecter les erreurs en exécutant la commande suivante :
```
sshd -t
```

Si vous ne recevez aucune erreur, SSH est maintenant configuré pour s'exécuter sur un port personnalisé et accepter uniquement les utilisateurs non root qui transmettent une clé SSH valide. Pour que ces paramètres s'appliquent et persistent, vous devez redémarrer le service SSH. Toutefois, ne redémarrez pas encore le service. Le redémarrage de SSH maintenant peut vous empêcher d'accéder au serveur, vous obligeant à utiliser le mode de secours ou la console Web pour restaurer la configuration. Vous devez configurer le pare-feu avant de redémarrer le serveur. Nous discutons du pare-feu dans la section suivante.

Modifier le pare-feu logiciel et redémarrer SSH

Remarque : Clients RackConnect : Pour gérer les règles de pare-feu, utilisez la gestion RackConnect au lieu de iptables sur le serveur. Vous ne devez pas modifier le port SSH si vous utilisez RackConnect. Pour plus d'informations sur les pare-feux et RackConnect, voir Gestion des politiques réseau RackConnect v2.0.

Chaque distribution Linux utilise une solution de pare-feu logicielle différente. Dans Red Hat Enterprise Linux (RHEL) et CentOS 7, le pare-feu par défaut est firewalld . Sur les distributions basées sur Debian et Ubuntu, la solution de pare-feu par défaut est Uncomplicated Firewall (UFW). Pour RHEL et CentOS 6, la solution par défaut est iptables . Reportez-vous à la section suivante pour le système d'exploitation de votre serveur.

RHEL, CentOS 7 et firewalld

Ouvrez le nouveau port SSH en exécutant les commandes suivantes :
```
 sudo firewall-cmd --permanent --remove-service=ssh
 sudo firewall-cmd --permanent --add-port=2222/tcp
 sudo firewall-cmd --reload
```
Remplacer 2222 avec le port que vous avez utilisé pour le démon SSH.
Redémarrez le sshd service en exécutant la commande suivante :
```
 sudo systemctl restart sshd
```
Vérifiez que votre port SSH personnalisé est ouvert sur le serveur :
```
 netstat -plnt | grep ssh
```

Si vous avez suivi ces étapes, vous devriez voir quelque chose de similaire au résultat suivant :

    tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN      1341/sshd           
    tcp6       0      0 :::2222                 :::*                    LISTEN      1341/sshd

Ubuntu, Debian et UFW

Ouvrez le nouveau port SSH en exécutant les commandes suivantes :
```
 sudo ufw allow 2222
```
Remplacer 2222 avec le port que vous avez utilisé pour le démon SSH.
Redémarrez le sshd service en exécutant la commande suivante :
```
 sudo systemctl restart sshd
```
Vérifiez que votre port SSH personnalisé s'est ouvert sur le serveur en exécutant la commande suivante :
```
 netstat -plnt | grep ssh
```

Si vous avez suivi ces étapes, vous devriez voir quelque chose de similaire au résultat suivant :

    tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN      1341/sshd           
    tcp6       0      0 :::2222                 :::*                    LISTEN      1341/sshd

CentOS 6 et iptables

Remarque :RHEL et CentOS 6 seront marqués en fin de vie en novembre 2020. Pour les meilleures pratiques de sécurité, nous vous conseillons vivement d'envisager une version plus récente du système d'exploitation pour héberger votre application ou votre site Web.

Ouvrez le nouveau port SSH en exécutant la commande suivante :
```
sudo iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 2222 -j ACCEPT
sudo service iptables-save
```
Remplacer 2222 avec le port que vous avez utilisé pour le démon SSH.
Exécutez la commande suivante pour redémarrer le démon SSH afin que le démon applique la nouvelle configuration que vous avez définie :
```
sudo service sshd restart
```
Vérifiez que votre port SSH personnalisé s'est ouvert sur le serveur en exécutant la commande suivante :
```
 netstat -plnt | grep ssh
```

Si vous avez suivi ces étapes, vous devriez voir quelque chose de similaire au résultat suivant :

    tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN      1341/sshd           
    tcp6       0      0 :::2222                 :::*                    LISTEN      1341/sshd

Après avoir apporté les modifications à votre système d'exploitation, ouvrez une autre fenêtre de terminal sur votre ordinateur local et connectez-vous au serveur en tant qu'utilisateur que vous avez créé précédemment. N'oubliez pas de spécifier le nouveau port modifié. Gardez votre connexion d'origine active au cas où vous auriez besoin de dépanner la configuration.

Pour vous connecter à SSH avec la nouvelle configuration, vous devrez peut-être spécifier le numéro de port et la clé à utiliser. Par exemple :

    ssh -p 2222 -i ~/.ssh/id_rsa {username}@{remotePublicIPAddress}

Le -p L'option spécifie le port et le -i option spécifie la clé privée à utiliser pour la connexion.

Si vous vous connectez à partir d'un bureau Windows, lorsque vous créez la connexion dans PuTTY, vous pouvez spécifier le numéro de port et une clé privée.

Prévention d'intrusion simple

La plupart des intrus potentiels exécutent plusieurs attaques contre le même port pour essayer de trouver quelque chose qu'ils peuvent exploiter dans le logiciel exécuté sur ce port. Heureusement, vous pouvez configurer un outil de prévention des intrusions commefail2ban sur votre serveur pour bloquer les attaques répétées sur un port.

Remarque : Les serveurs d'opérations gérées ont fail2Ban installé et configuré par défaut pour surveiller les tentatives de connexion SSH. Contactez votre équipe d'assistance si vous avez des questions ou des préoccupations.

fail2ban surveille les journaux et bloque automatiquement les connexions s'il en détecte trop sur le même hôte en peu de temps. Pour installer et configurer fail2ban sur votre serveur, procédez comme suit :

Pour installer fail2ban sur votre serveur, exécutez l'une des commandes suivantes.

RHEL et CentOS :
```
sudo yum install fail2ban
```
Debian et Ubuntu :
```
sudo apt-get install fail2ban
```
Utilisez la commande suivante pour copier votre fail2ban par défaut configuration. Le fichier nouvellement créé remplace la configuration par défaut et vous permet de modifier le fichier en toute sécurité.
```
sudo cp -pf /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
```
Modifiez votre fichier pour personnaliser votre niveau de sécurité dans fail2ban .
```
vim /etc/fail2ban/jail.local
```
Dans ce fichier, vous pouvez définir les options suivantes :
- ignoreip :Ce paramètre vous permet de spécifier n'importe quelle adresse IP qui ne doit pas être bannie.
- bantime :Ce paramètre permet de spécifier le nombre de secondes pour bannir une adresse IP.
- findtime :Ce paramètre vérifie les indications de maxretry se déclenche dans le délai spécifié.
- maxretry :Ce paramètre définit le nombre de tentatives autorisées avant que l'adresse IP ne soit interdite.
Créez un fichier jail pour les tentatives de connexion SSH.
```
vim /etc/fail2ban/jail.d/sshd.local
```
Dans le fichier créé, copiez-collez le texte suivant :
```
[sshd]
enabled = true
port = ssh
#action = firewallcmd-ipset
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400
```
Ces options bannissent une adresse IP après trois tentatives infructueuses de connexion via SSH pendant 24 heures. Si vous connaissez votre adresse IP locale, nous vous recommandons fortement d'ajouter cette adresse IP dans la section précédente en tant que ignoreip paramètre.
Démarrer et activer fail2ban sur votre serveur en utilisant les commandes suivantes :

RHEL et CentOS 7 ou Debian et Ubuntu :
```
 sudo systemctl start fail2ban
 sudo systemctl enable fail2ban
```
RHEL et CentOS 6 :
```
 sudo service fail2ban start
 sudo chkconfig fail2ban on
```

Détection d'intrusion

Un système de détection d'intrusion (IDS) peut aider un administrateur à surveiller les systèmes à la recherche d'activités suspectes et d'éventuels exploits. Un IDS est plus robuste qu'un outil de prévention comme fail2ban mais peut être plus compliqué à configurer et à entretenir.

Un IDS open source populaire est OSSEC. OSSEC maintient des agents sur plusieurs systèmes qui rendent compte au serveur principal, permettant l'examen des journaux et des alertes d'un serveur potentiellement compromis même si ce serveur est arrêté.

Si vous pensez qu'un système est déjà compromis, vous pouvez enquêter à l'aide de procédures telles que la recherche de portes dérobées et d'intrus et d'une enquête en mode de secours.

Gardez votre système d'exploitation à jour (correction)

Il est très important de maintenir à jour votre noyau, vos packages et vos dépendances, en particulier pour les modules et packages liés à la sécurité. Certaines mises à jour, telles que les mises à jour du noyau, nécessitent que vous redémarriez votre serveur. Vous devez programmer les maintenances pour qu'elles aient lieu pendant les périodes qui perturbent le moins les utilisateurs, car ces maintenances entraînent une courte période d'indisponibilité.

Important :Bien que la mise à jour de votre système soit d'une importance vitale, assurez-vous que les mises à jour que vous appliquez n'ont pas d'impact négatif sur votre environnement de production.

Pour vérifier et installer les mises à jour sur les systèmes d'exploitation Ubuntu et Debian, exécutez les commandes suivantes :

sudo apt-get update
sudo apt-get upgrade

Pour vérifier et installer les mises à jour sur les systèmes CentOS, Red Hat et Fedora, exécutez la commande suivante :

sudo yum update

Fin de vie du système d'exploitation

Découvrez quand la version de distribution Linux que vous exécutez sur vos serveurs atteint sa fin de vie (EOL). Lorsqu'une version atteint sa fin de vie, les responsables de la distribution ne la prennent plus en charge ou ne fournissent plus de mises à jour de paquets via leurs dépôts officiels. Vous devez planifier votre migration vers une version plus récente bien avant que votre version actuelle n'atteigne sa fin de vie.

Utilisez les liens suivants pour savoir quand votre version de distribution Linux est prête à atteindre sa fin de vie :

Systèmes d'exploitation Ubuntu :https://wiki.ubuntu.com/Releases
Red Hat Enterprise Linux (RHEL) :https://access.redhat.com/support/policy/updates/errata/
CentOS :identique à Red Hat
Fedora :https://fedoraproject.org/wiki/End_of_life
Debian :https://wiki.debian.org/DebianReleases

Sécurité au niveau du compte

Bien que la sécurisation de vos serveurs soit une partie essentielle des opérations sur Internet, la sécurisation de votre compte est également nécessaire. Votre nom de compte, votre mot de passe et vos clés API sont des éléments essentiels de la façon dont vous interagissez avec les offres Rackspace Cloud. Comme tout autre mot de passe ou identifiant d'accès, vous souhaitez les garder en sécurité. Cependant, vous devez également permettre à votre équipe d'agir et d'effectuer les tâches nécessaires.

En utilisant le contrôle d'accès basé sur les rôles (RBAC), vous pouvez créer des utilisateurs et accorder des autorisations aux personnes ou aux applications responsables de l'utilisation de divers services Rackspace. En tirant parti du RBAC, vous pouvez donner à votre équipe et à vos sous-traitants l'accès uniquement aux utilitaires dont ils ont besoin et révoquer l'accès si nécessaire.

Voici quelques scénarios d'utilisation :

Autorisez les sous-traitants à configurer l'environnement que vous leur avez demandé de créer, mais limitez leur capacité à afficher ou à modifier les informations de carte de crédit ou à supprimer votre compte.
Autorisez votre comptable à voir la facture, mais pas à supprimer vos serveurs.
Engagez un administrateur de base de données (DBA) et accordez-lui l'accès à vos instances DBaaS.
Autoriser un client à importer des fichiers directement sur votre compte Cloud Files.
Configurez vos serveurs pour enregistrer et utiliser des utilisateurs spécifiques pour vos agents de surveillance et de sauvegarde qui sont distincts de votre compte administrateur.

Pour plus d'informations sur RBAC, consultez la FAQ sur le contrôle d'accès basé sur les rôles (RBAC).