こんにちは、Mashです。
本記事は私自身がAWSをお勉強で触ってみた経験を共有するシリーズ Mash式AWSチュートリアル です。
今回はAmazon VPC編の第２回となります。
本記事では、VPCの基本的なセキュリティ機能である セキュリティグループ について解説していきます。
それではいきましょう！
前回のおさらい：EC2を外部公開しました
前回記事で構築したVPC環境をおさらいしましょう。
VPC、サブネット、インターネットゲートウェイを作成し、EC2を立ち上げてSSH接続まで確認ができました。
EC2をWebサーバとして公開してみる
さて。
作成したEC2をWebサーバとして公開してみましょう。
まずはEC2へSSH接続し、Webサーバ機能を提供する nginx をインストールします。
$ sudo amazon-linux-extras install nginx1.12 -y
(中略)
$ sudo systemctl start nginx
$ sudo systemctl enable nginxnginxがインストール、起動できましたのでブラウザからアクセスしてみましょう。
おや、、、
アクセスできませんね、、、
nginxは起動しているはずなのに、、、
これ、なんでかというと、このEC2へのWeb通信（HTTP通信 = TCP 80番通信）が許可されておらず、Webリクエストの通信がEC2へ到達していないんですね。
ここで登場するのが、セキュリティグループ です。
What is SecurityGroups?
セキュリティグループとは
セキュリティグループ はVPC内で稼働するインスタンスに設定することができる 仮想ファイアウォール 機能のことです。
作成したEC2へSSH接続はできるのにWeb接続ができなかったのは、このセキュリティグループの設定で
- SSH接続（TCP 22番通信）は許可
- HTTP接続（TCP 80番通信）は拒否
という状態になっていたからなんです。
利用料金
セキュリティグループ自体には料金がかかりません。
いくつ作成しても、いくつ利用しても無料です。
ご安心ください。笑
覚えておいたほうがいいざっくり仕様
以下、セキュリティグループ（SG）を利用する上で頭に入れておいたほうがいい仕様をまとめてみました。
インバウンドとアウトバウンド両方設定できる
SGでは、通信の向き = インバウンド or アウトバウンド のどちらも定義することが可能です。
基本的にはインバウンド通信の設定を利用することになるかと思いますが、セキュリティの要求が高い環境の場合は、アウトバウンド制御も利用することになるでしょう。（デフォルトではアウトバウンド通信は全許可になってます）
暗黙的なDenyである
本記事冒頭に記載したとおり、セキュリティグループは何も設定していない状態だと通信がブロックされましたね。
これを 暗黙的なDeny と呼んだりします。
管理者は、許可したい通信は明示的に許可してあげる必要があります。（ホワイトリスト型）
セキュリティグループはインスタンスにアタッチする
セキュリティグループ（SG）は、EC2などのインスタンスに対して割り当てます。
そして、SGは複数のインスタンスに割り当てることも可能です。
例えば「外部公開Webサーバ用SG」をひとつ作成しておいて、それを複数のEC2にアタッチすれば同一ルールを適用できる といった感じです。
インスタンスごとにSGを作成する必要はありません。
インスタンスに割り当て可能なSGは５つ
前述の通りSGはインスタンスに割り当てて利用するのですが、その数は上限５つまでとなっています。
ですので、
- SSH接続を許可するSG 1
- HTTP接続を許可するSG 2
- HTTPS接続を許可するSG 3 …etc.
といった具合に、あまりにもSGを細かく区切ってしまうとこの上限にかかってしまいます。
- 外部公開Webサーバ用のSG 1（SSH接続とHTTP、HTTPS接続を許可）
- データベース用のSG 2（SSH接続とDB接続を許可）
といったように、役割ごとにある程度ルールをまとめたSGを作成することになります。
ステートフルである
SGの通信許可は、ステートフルに稼働します。
例えば、下記のようにEC2 #01がWebサーバとして稼働していて、SGでインバウンドのTCP 80番通信を許可したとします。
EC2 #01はEC2 #02からのWebリクエストを受け取ってレスポンスを返すことになりますが、このレスポンス（アウトバウンド通信）は明示的に許可してあげなくても問題ありません。
これをステートフル・インスペクションなんて呼んだりします。（覚えなくていいです）
セキュリティグループを設定してみる
それではさきほどnginxをインストールしたEC2にブラウザからアクセスできるよう、SGを設定していきます。
セキュリティグループの作成
AWS管理コンソールからEC2へアクセスし、左側メニュー [セキュリティグループ] を選択しましょう。
そして、画面右上の [セキュリティグループを作成] ボタンをクリックします。
セキュリティグループの作成 画面に遷移したら、パラメータを定義していきます。
セキュリティグループ名と説明については、このSGがなんのためのものなのかがわかる値にしましょう。
また、VPCの選択を間違わないようにご注意ください。
つづいてインバウンドルールを設定します。こちらでは受信許可したい通信ポートを定義します。
今回はWebサーバとして公開したいので、HTTP（TCP 80）とHTTPS（TCP 443）はフルオープンにしたいので 任意の場所を、SSHをフルオープンにしておくのはセキュリティ上マズイので、自分自身のIPアドレスだけとします。
自分のIPアドレスを指定したい場合、マイIPという項目があるのでこちらを選択しましょう。
同じSGを割り当てたインスタンス同士は自由に通信させたい場合もあるかと思います。
そういった場合は、インバウンドルールで、
- タイプ：すべてのトラフィック
- ソース：カスタム SGのID
と指定し、このSGを相互通信させたいインスタンスに割り当てればOKです。
アウトバウンド通信は今回制限する予定はないため、デフォルト状態の全許可のままで進めます。
タグについても、今回はNameタグだけ付与して [セキュリティグループを作成] ボタンをクリックします。
無事にセキュリティグループが作成できました！
セキュリティグループをEC2へ割り当て
SGが作成できましたので、これをEC2へ割り当てていきます。
AWS管理コンソールのEC2一覧へアクセスし、SGを割り当てたいEC2が選択された状態で、 [アクション] – [ネットワーキング] – [セキュリティグループを変更] と選択します。
もともと付与されているSGを削除、そして、さきほど作成したSGを選択して [セキュリティグループを追加] ボタンをクリックします。
最後に [保存] ボタンをクリックしましょう。
ここまでの作業で、SGの作成とEC2への割り当てが完了しました。
動作確認
さぁ、
それではもう一度ブラウザでEC2へアクセスしてみましょう！
きたー！！
SGによりTCP 80の通信が許可されたため、無事にnginxのデフォルトページが表示されました～。
ちなみにSSH接続も問題なしですね～。
ためしに別のPCからSSH接続を試みましたが、ちゃんとブロックしてくれましたので、SGは意図したとおりに動いてくれていますね！
SGを適用した状態はこのような感じです。
まとめ
今回はセキュリティグループの主な仕様の整理と設定手順を確認することができました。
SGはVPCセキュリティにおける最も基本的な機能ですので、必ずマスターしましょう！
ちなみに、AWSの有償サポートプランを契約すると、不用意なセキュリティグループを設定したインスタンスがあると、AWSから警告メールが飛んできます。笑
それでは次回更新までお待ち下さい。
今回は以上です。
それじゃあまたね。
