デフォルトVPCを使う場合に最低限注意しないといけないこと

この記事は，マイナビ Advent Calendar 2019 5日目の記事となります。

そもそもVPCって？

インフラに詳しくない人からするとよくわからないのではないかと思いまして
軽い説明からさせていただきます！

VPCとは

Amazon Virtual Private Cloudが正式名称 VPCは略称
簡単に説明すると仮想のユーザー専用プライベートなクラウド環境を提供するサービスで
ネットワーク設定を簡単にカスタマイズすることができます。

具体的に何が設定できるの？

ざっくり書くと以下のようなネットワーク・セキュリティ設定が可能です。

• ネットワーク設定
  • IPの割り当て
  • サブネット設定
    • 外部ネットワーク
    • 内部ネットワーク
  • ルーティング
  • etc…
• セキュリティ周り
  • ネットワークアクセスコントロール
  • アクセス制御
    • IPアドレス
    • プロトコル
  • etc…

これらの設定をおこなうことで
インターネット向けシステムやオンプレミス向けシステム、
インターネット兼オンプレス向けシステムなど使い分けることが可能です。

デフォルトVPCとは

AWSアカウントを作成するとAWSの各リージョンごとにデフォルトVPCが備え付けられています。
最初からデフォルトVPCは使用できる状態になっているため、
面倒なVPCの作成、設定はその他必要なNWリソースの作成、設定をおこなう必要がなく
すぐにEC2インスタンスを利用できますよ～ってものです。

インフラの設定よくわからんけどこれ使えばEC2とかRDS建てれんじゃん！
ってなった方も少なくないかと思います(身近にも何名かいました…)

では、デフォルトVPCはどんな設定になっているのかを確認しておこう

デフォルトVPCとそれに紐づいているリソースとその設定をまとめてみた

AWSの公式サイトを見るとこんな設定になっている

• サイズ /16 の IPv4 CIDR ブロック (172.31.0.0/16) の VPC を作成され最大65,536 個のプライベート IPv4 アドレスを使えます。
• 各AZに、サイズ /20 のデフォルトサブネットを作成 (サブネットあたり最大 4,096 個のアドレスが作成され、その中のいくつかは Amazon が使用するように予約されているよう)
• インターネットゲートウェイを作成して、デフォルトVPCに接続
• デフォルトのセキュリティグループを作成し、デフォルトVPCに紐付ける
• デフォルトのネットワークアクセスコントロールリスト (ACL) を作成し、デフォルトVPC に紐づける
• デフォルト VPC を備えた AWS アカウントに、デフォルトの DHCP オプションセットを紐づける

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/default-vpc.html

ざっくり図にするとこんな感じです。

なんかやばそうな気がしませんか？

デフォルトVPCを使う場合に注意しないといけないこと

前置きが長くなり申し訳ないです…

図を見ていただくとわかるかと思いますが、
デフォルトVPCをそのまま使う場合は
少なくとも以下の2つの設定は変更したほうが良いかと思います。
①セキュリティ設定
②サブネットをプライベートとパブリックに分ける

①セキュリティ設定

デフォルトVPCの主なセキュリティ設定は
セキュリティグループとネットワークACLです。

セキュリティグループとネットワークACLの比較
次の表は、セキュリティグループとネットワークACLの基本的な違いをまとめたものです。

セキュリティグループ	ネットワークACL
インスタンスレベル	サブネットレベル
ルールの許可のみがサポートされます	ルールの許可と拒否がサポートされます
ステートフル:ルールに関係なく、返されたトラフィックが自動的に許可されます	ステートレス:返されたトラフィックがルールによって明示的に許可されます
トラフィックを許可するかどうかを決める前に、すべてのルールを評価します	トラフィックを許可するかどうかを決めるときに、順番にルールを処理します
インスタンスの起動時に誰かがセキュリティグループを指定した場合、または後でセキュリティグループをインスタンスに関連付けた場合にのみ、インスタンスに適用されます。	関連付けられているサブネット内のすべてのインスタンスに自動的に適用されます(そのため、セキュリティグループのルールの許容範囲が広すぎる場合は、保護レイヤーを追加する必要があります)。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Security.html

デフォルトVPCのセキュリティ設定

デフォルトのネットワークアクセスコントロールリスト (ACL) の設定

デフォルトのセキュリティグループの設定

ノーガードなんですよね（　＾ω＾）・・・

このままだと攻撃者の格好の的ですので
ある程度、ルールの設定をする必要があります。

最低でもセキュリティグループのインバウンドが0.0.0.0/0となっているのは絶対変更する。
登録するルールは必要最低限に絞ることをお勧めします。
開発環境だから個人で利用しているAWS勉強用だからといってインバウンドの設定を
0.0.0.0/0にしてしまうと攻撃の被害にあったりしちゃいますよ～
(できればフロントとなるALBのみが0.0.0.0/0を受けて、そこからの通信だけEC2に許可とかしてほしいのですが…)

WEBなら必要なHTTPやHTTPSの通信だけ許可するなど
必要のないプロトコルは全部塞いじゃいましょう
例 こんな感じ

この辺りは最低限注意したほうが絶対いいです！

②サブネットをプライベートとパブリックに分ける

WEBとDBを分ける際はサブネットも別するようにしてください！

デフォルトVPCを利用する場合、
備え付けのサブネットは各AZに一つずつしかないです。
そのまま利用するとなると、Webサーバ、APサーバ、DBは全てを
同じサブネットに配置ことになります。

DBがパブリックからアクセスされることはあまりよろしくないです。
せめて、サブネットをプライベートとパブリック分けて利用するようにしてください。

パブリックサブネットに配置するのは各種LBサービスと踏み台サーバのみとしてください。
Webサーバ、APサーバ、DBは全てプライベートサブネットに配置することがAWSべスプラです。

まとめ

だらだらとまとまりのない記事で申し訳ないです…

デフォルトVPCは便利なのですが、
そのまま使うとリスクは存在してしまします。

なので、EC2を配置する前にセキュリティ部分の設定は必須となってしまします。
以下のURLにベストプラクティスがまとまっておりますので一度読んでおくことを強くお勧めします！
https://d1.awsstatic.com/whitepapers/ja_JP/Security/AWS_Security_Best_Practices.pdf

私的な主観ですが、デフォルトVPCは個人の検証用途なら使ってもいいが、
決してサービス環境は避けたほうが良いと思います。

ただ、一からVPCを作るのが難しい人もいるかと思いますので、
あとでこの記事に簡単なテンプレートを載せておきます。(急ぎます)
何かのお役に立てば幸いです。