金融システムの運用保守や情報システム部門のIT支援などを経て、現在は顧客へのAWS導入・移行の提案、構築などを担当。社内向けの勉強会、技術支援などを実施し、AWSエンジニアの育成にも挑戦中。ページ/掲載記事:6件みなさん、AWSのセキュリティグループはご存じでしょうか?こんにちは。エンジニアの中井です。AWSのサービスを利用する上で、避けては通れないのがセキュリティグループの設定です。このセキュリティグループですが、改めてドキュメントを読み返すと色々と発見がありました。そこで今回は、セキュリティグループの基本的な部分をおさらいしつつ、インスタンスへの設定パターンなどについて説明していきたいと思います。セキュリティグループのおさらい一言でいうとセキュリティグループは「ステートフルなファイアウォール」で、インスタンスレベルで動作。ネットワークACLは「ステートレスなファイアウォール」で、サブネットレベルで動作。セキュリティグループとはまず、セキュリティグループとは?についてAWSのドキュメントを見てみると、次のとおり記載されています。インスタンスの仮想ファイアウォールとして機能し、受信トラフィックと送信トラフィックを制御します。インバウンドルールはインスタンスへの受信トラフィックを制御し、アウトバウンドルールはインスタンスからの送信トラフィックをコントロールします。以上のセキュリティグループを指定できます。デフォルトのセキュリティグループを使用します。各セキュリティグループに対してルールを追加し、関連付けられたインスタンスに対するトラフィックを許可できます。セキュリティグループのルールはいつでも変更することができます。新規または変更したルールは、セキュリティグループに関連付けられたすべてのインスタンスに自動的に適用されます。判断するとき、インスタンスに関連付けられているすべてのセキュリティグループのすべてのルールを評価します。上記はEC2のドキュメントですが、VPCのドキュメントにも、ほぼ同じ内容が記載されています。セキュリティグループは、インスタンスの仮想ファイアウォールとして機能し、インバウンドトラフィックとアウトバウンドトラフィックをコントロールします。つのセキュリティグループを割り当てることができます。セキュリティグループは、サブネットレベルでなくインスタンスレベルで動作します。内のサブネット内のインスタンスごとに異なるセキュリティグループのセットに割り当てることができます。箇条書きでピックアップすると、こんな感じでしょうか。インスタンスの仮想ファイアウォールとして機能する。インバウンドトラフィックとアウトバウンドトラフィックをコントロールする。インスタンスの起動時に1つ以上のセキュリティグループを指定できる。デフォルトのセキュリティグループを使用する。セキュリティグループは、サブネットレベルでなくインスタンスレベルで動作する。セキュリティグループはステートフルなので、例えば外部からのSSHを許可する際には、インバウンドにだけルールを記載すれば良いです。セキュリティグループとは別に、ネットワークACLというものもあります。こちらはVPCのドキュメントに次のとおり記載されています。用のセキュリティのオプションレイヤーです。セットアップできます。比較」を参照してください。ACL」セキュリティグループとは違って、サブネットレベルで動作するものです。リンク先のドキュメントに記載のとおり、ネットワークACLはステートレスなので、インとアウトにそれぞれルールを記載する必要があります。AWSでよくある使い方としては、ネットワークACLはデフォルト設定の「全て許可」のままにしておき、セキュリティグループでインスタンスへのアクセス制御を行うことが多いです。セキュリティグループのソースにセキュリティグループセキュリティグループのルールでは、ソースに特定のCIDRブロックが記載できるほかに、「セキュリティグループそのもの」を送信元として記載できます。VPCを作成した時のデフォルトのセキュリティグループはソースに「自分自身のセキュリティグループ」が記載されています。これはAWSならではのもので、ちょっと初めは理解が難しいかと思います。このセキュリティグループを同じVPC内の複数のインスタンスに設定すると、インスタンス間の通信がすべて許可されることになります。デフォルトのセキュリティグループは「すべてのトラフィック」がインバウンドルールで許可されているためです。なんか、不思議ですよね?ドキュメントをよく読んでみると、次のような記載があります。セキュリティグループはネットワークインターフェイスに関連付けられます。ブロックを指定すると、指定したプロトコルとポートの指定したアドレスからのトラフィックが許可されます。セキュリティグループをルールの送信元として指定すると、指定したプロトコルとポートの送信元セキュリティグループに関連付けられたネットワークインターフェイスからのトラフィックが許可されます。セキュリティグループ/セキュリティグループのルール」はい。ネットワークインターフェイスに関連付けられ、ネットワークインターフェイスからのトラフィックが許可される。いう大事なことが書いてありました。セキュリティグループはインスタンスレベルで動作するものなんだけど、さらにその中でネットワークインターフェイスに関連付けられている。ソースとして関連付けられた(複数の)ネットワークインターフェイスが許可される。とイメージできると、少しはわかったような気がします。デフォルトセキュリティグループの設定イメージソースを他のセキュリティグループで指定するパターンセキュリティグループの指定方法には色々とありますが、ソースをCIDRブロックではなく、セキュリティグループで指定すると何が良いのでしょうか?例えばこれまでは、AP-DB間の通信に必要なポートを開ける際、DB側はAPのIPアドレスを指定しておけば良かったです。AWSではIPアドレスが可変であることを前提に考えなければいけません。EC2であればオートスケールの際に、手動でセキュリティグループのIPを変更するなんてことが必要になっては困りますからね。そこでセキュリティグループで指定しておけば、IPが変わってもセキュリティグループに関連付けられているネットワークインターフェイスが許可されるので大丈夫、ということになります。次に例として、AP(EC2)側に、インバウンドに何も記載していないセキュリティグループを設定してみます。AP側へ設定するセキュリティグループ:no-rule-sgDB側には、そのセキュリティグループ名をソースとして許可します。DB側へ設定するセキュリティグループ:***-mysqlイメージとしては次のような設定状況になります。※インバウンドルールを記載。アウトバウンドはすべて許可です。設定イメージこれで、AP(EC2)からDBへのアクセスを試してみます。[(none)]>つながりました。DB側は、上記で記載された「送信元セキュリティグループに関連付けられたネットワークインターフェイス(この場合AP)からのトラフィックが許可」されているからですね。他のパターンとしては、セキュリティグループのソースを自分のセキュリティグループにして、それをAPとDBどちらにも設定してもつながります。この場合はAP側もMySQL用のポートが許可されているので、なんとなく気持ちが悪いですね。APとDBに同じセキュリティグループを設定する例まとめセキュリティグループはなんとなくでも使えるものですが、ドキュメントを改めて読み「ネットワークインターフェイスに関連付けられる」ということを初めて知りました。ドキュメントはちゃんと読まないといけませんね・・・。ソースをセキュリティグループで指定するパターンは、私がAWSを触り始めた頃によく理解しておらず、複数のインスタンスに複数のセキュリティグループを設定し、結果的に非常に分かりづらいことになってしまいました。今やり直せるなら、許可ソースに許可したいインスタンスに紐づいているセキュリティグループを設定するパターンをうまく活用して、シンプルな実装ができそうな気がします。いうわけで、セキュリティグループの基本と、ソースをセキュリティグループで指定するパターンについての説明でした。EC2インスタンスの自動復旧とは。EC2インスタンスの自動復旧とは。Serviceの紹介と設定のポイントこのカテゴリの注目用語ITSMWSUSこの記事の関連サービス初めての方でも直感的に使えるAWS管理・運用支援ツールAWSクラウドポータルIIJの法人向けサービス・ソリューションについては、お気軽にお問い合わせください。Blogこのサイトは株式会社インターネットイニシアティブが運営しています。