Lambdaカクテル

京都在住Webエンジニアの日記です

AWSのSecurity Groupで,ソースとしてSGを指定するとどうなるか

今日はAWSのSecurity Group(以下,SG)に詳しくなった。

EC2でインスタンスを作ろうとしたとき,何の考え無しにインスタンスを公開してパブリックIPなんざ付けた日には全宇宙にインスタンスが公開されて危ない。 なのでAWSには各種のアクセス制御機構が様々な形,様々なレベルで実装されているのは知っていると思う。

例えばVPCは同じAWSアカウントの中に仮想ネットワークを作り,異なるVPCどうしでコンピューティングリソースを隔離する*1効果があるし,サブネットはさらにVPCのネットワークをIPアドレスレンジで分割して名前を付けることで,アクセス制御をやりやすくする。 例えば事業ごとにVPCを分割し,その中でも公開したいインスタンス(e.g. WebサーバやProxy)と隠したいインスタンス(e.g. DBやKVS)とを別のサブネットに配置する,といった具合でアクセス制御を行うことができるようになる。

EC2レベルで動作するSecurity Group

VPCレベルではネットワークの隔離と分割,という手段でアクセス制御を行うが,より下のEC2のレベルにもアクセス制御機構がある。SGはこのEC2のレベルで動作する。SGはEC2インスタンスにひっつけるファイヤウォール(以下,FW)みたいなもの。 一般的なFWはマシンごとに設定するが,SGは複数のインスタンスの通信を1つのSGで制御できるのでより柔軟である。 これは,SGが「EC2インスタンスにSGを割り当てる」という構成で動作するためである。SGによって,特定のIPアドレスレンジ,特定のポートのinbound/outbound通信を許可することができるようになる。

さて,今回は「特定のSGを許可対象のソースに割り当てる」というテクを覚えた。ソースというのは普通はIPアドレスレンジ,例えば10.0.0.0/8とか,::/0といったものを指定する箇所だ。ここに入力したアドレスレンジ(から/行き)の通信が許可される。 ここにSGを指定すると,そのSGがアタッチされているインスタンスのIPアドレス をソースに指定したのと同じ効果になる。

例を挙げよう。private-sgdmz-sgpublic-sgといったSGがあったとする。public-sgに属するインスタンスはどこからでも通信させたいが,private-sgdmz-sgのみと疎通させたい。そしてdmz-sgは両方のSGと通信できる必要があるとする。 普通ならサブネットを切っておいて,そのアドレスレンジをソースとして指定するが,SG単位でアクセス制御をする場合は対象インスタンスが属するSGをソースとして指定できる。例えば以下のような設定ができる:

  • private-sg
    • インバウンド ポート: 任意 ソース: dmz-sg
  • dmz-sg
    • インバウンド ポート: 任意 ソース: public-sg
    • インバウンド ポート: 任意 ソース: private-sg
  • public-sg
    • インバウンド ポート: 443 ソース: 任意

また応用として,ソースとして自分と同じSGを指定する,というテクニックがある。これは同じSGがついているインスタンス同士の通信を許可するのに使える。

ハマりどころ

ハマりどころとして注意したいのが,ソース指定はインクルードではない,という点である。別SGを指定できるので「ひょっとして別SGの設定を取り込むことができるのでは?」と思ってしまうが,ソースはあくまでも通信先を指定するもので,別SGの設定をインクルードするために使うことはできない。 自分はこれでハマった。カンでやらずにちゃんとマニュアルを読めという話でもある。

SGを使って柔軟なアクセス制御ができることがわかった。

*1:VPC間での疎通はけっこう面倒な印象がある