6 votes

EC2 - les groupes de sécurité doivent-ils être spécialisés et empilés ?

Je n'ai pas été en mesure de trouver de bonnes pratiques pour les groupes de sécurité AWS. Je suppose qu'il existe deux approches que je pourrais prendre, mais je ne suis pas sûr s'il y a des inconvénients particuliers à l'une ou à l'autre.

Scénario 1:
Définir des petits groupes de sécurité spécialisés tels que "ssh", "mongodb", "web", etc., puis en essence "empiler" plusieurs groupes de sécurité sur chaque instance EC2 pour spécifier quels ports sont ouverts.

Scénario 2:
Définir des groupes de sécurité plus grands et plus génériques tels que "web1" qui ouvre les ports 80, 443, ssh, base de données, et appliquer cela à toutes les instances EC2 appropriées.

Je pense que je préférerais choisir le scénario n°1, mais je ne sais pas s'il y a des inconvénients ou des problèmes techniques avec cette approche. Y a-t-il une bonne pratique ?

2voto

Chris Vosnidis Points 626

AWS limite le nombre de groupes que vous pouvez appliquer à une interface réseau: Groupes de sécurité par interface réseau 5

Une approche courante consiste à créer des SG de manière à ce qu'il soit facile de mettre à jour votre parc de serveurs, mais de manière cohérente pour tous les hôtes auxquels ils sont appliqués.

Considérez ces points

Ces facteurs détermineront ce que vous voudrez ouvrir pour les groupes de sécurité de vos instances.

  • Utilisez des NACL pour des autorisations de niveau grossier
  • Utilisez des SG pour un accès plus spécifique
  • Placez vos instances dans un sous-réseau privé (ce conseil est pour les instances non publiques. par exemple, lorsque vous avez utilisé un ELB pour vous connecter à votre instance web)

Une approche générique

Compte tenu de tout cela, une approche courante serait la suivante:

  • Toutes les instances obtiennent un groupe de sécurité commun (ce groupe a des règles que vous souhaitez appliquer à chaque instance)
  • Chaque instance a un rôle, tel que "serveur web" ou "serveur de messagerie" ou "base de données postgres" et chaque rôle a un groupe de sécurité associé
  • Votre instance spécifique peut avoir un groupe de sécurité supplémentaire pour toutes les personnalisations qui ne sont pas couvertes par les deux premiers groupes

Variations sur le SG "commun":

  • "linux_commun OU windows_commun"
  • "commun" ET "linux_commun OU windows_commun".

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X