SecurityGroupについて

• AWSにはセキュリティグループという俗にいうファイヤーウォール機能があります。
  ただ、Iptablesなどと違い、許可ポリシーしか設定できません。
  また、ステートフルなので、戻りの通信は明示的に設定しなくても許可されます。
  特定のIPアドレスからの接続拒否とかしたい場合は、NetworkACLという機能を使いますが、
  これはサブネット単位になるのでちょっと使い勝手が違ってきます。
  デフォルトでは、インバウンドをすべて拒否、アウトバウンドはすべて許可のルール指定がされています。
  （無指定の場合は拒否、あとは許可ポリシーを追加していく）
  なお、地味に重要なのですが、セキュリティグループはEC2インスタンスにつくのではなく、EC2インスタンスについているNICに紐づきます。
  大抵EC2インスタンスはNIC一つなのですが、複数グローバルIPを持たせたい場合などで複数NICをEC2インスタンスへ刺した場合、各NICごとに最大５つのセキュリティグループが設定できます。
  例えばこんな感じです。
  
  ここではEC2インスタンスにNICを二つ(eth0、eth1)を追加しています。
  EC2インスタンスの画面で表示、変更できるのはeth0に関連付けられたセキュリティグループだけです。
  では、各NICのポリシーを見てみましょう。
  
  
  eth0にあるlaunch-wizard-1が見えていること、eth1にしかないdummyがEC2インスタンス画面に非表示なのが分かると思います。
  追加したNICのセキュリティグループ設定は各NICの画面で行います。
  セキュリティグループを変更したつもりが、変更されたのはeth0だけでした。と言う事故がありますので要注意です！
  

• セキュリティグループには、ソースアドレスとしてIPアドレスだけでなく、セキュリティグループIDを指定することができます。
  これはどういうことかというと、IPアドレスの変更に縛られなくなる。という事です。
  ここでは少し具体例として以下の構成を上げます。
  
  インターネットからのアクセスはELBで受けます。
  ELBにはそれを受け入れるためのポリシー設定(elb_webserver)が指定されています。
  また、メンテナンス用に踏み台サーバがあり、メンテナンス用PC(52.XXX.XXX.XXX)からのSSHアクセスを許可するポリシー設定(bastion)があります。
  次にバックエンドを見てみましょう。
  バックエンドのEC2インスタンスには、ELBからのアクセスを受け入れるためのポリシー(ec2_default)が設定されています。
  ここで、通常ソースとしてIPアドレスを指定する箇所に、ELBに設定したセキュリティグループIDが指定されている点に注意します。
  ELBの内部IPアドレスは何が振られるのか分からないのでそもそもIPで指定することはできません。
  また、所属するサブネット全部許可というのも少々乱暴です。
  そのような場合に、セキュリティグループではソースアドレスとしてセキュリティグループのIDを指定することができます。
  これを指定することにより、該当セキュリティグループIDが割り振られた所からの通信を識別することができます。
  つまり、IPアドレスが何だろうと、RDSやELBやEC2だろうと関係なく、セキュリティグループIDが割り当てられたところからの通信をソースとして扱うことができるのです。
  これを応用して、上記構成では
  • デフォルトのセキュリティグループポリシー(ec2_default)として、踏み台サーバ(に割り当てられているセキュリティグループbastion)からのSSH接続を許可するポリシーと、Zabbixサーバ(に割り当てられているセキュリティグループzabbix_server)からの通信を許可するポリシーを設定しています。
  • EC2には、ELB(に割り当てられているセキュリティグループelb_webserver)からの通信を許可するポリシー(ec2_webserver)を設定しています。
  • RDSには、EC2（に割り当てられているセキュリティグループec2_webserver)からのMySQL通信を許可する設定をしています。
    これにより、EC2をオートスケーリングしてN台になっても、踏み台サーバやRDSのIPが変わっても変更に強くなります。

(余談ですが、ZabbixサーバのIPが変わっても通信上は問題ないのですが、現実には各エージェントが参照する先はIP指定なので変更する必要があります・・）

このページの参照回数は、516です。